Multiplayer game with authoritative server

[Schlaus]

Greeting, ye people of Haxeland!

I admit it, I'm a complete noob when it comes to Flixel, Haxe, or game development. I do have plenty of coding experience though, mostly from working on several web apps made with Javascript and PHP. Every now and then I get some game ideas that I'd like to try one day and now I've finally come up with something that I think would be a good learning project, and I've chosen Haxe and HaxeFlixel as the tools I'd like to get acquainted with.

My game is nothing fancy, a really simple fly-in-space-and-shoot-stuff kind of game, but there's one aspect I can't find too much information on that I'd be really grateful if someone would be up for exchanging some ideas on, and that's online multiplayer with an authoritative server. Let me make a list of things I think might be relevant here:

• the game is for 2 - 4 players
• there might be AI-controller entities
• physics will be involved (using Nape, though I'm not committed)
• game is in real time and rather fast-paced (but not FPS-fast-paced)
• clients should work on Win and Mac, possibly Unix, and mayhaps even mobile at some point
• server will be a Unix (Ubuntu) machine
• the possibility of cheating should be as minimized as sanely possible
• this is a learning experience so I don't mind writing bits and pieces that wouldn't maybe be mission-critical in a commercial project

The thing I'm looking to get some ideas on is how exactly to make this all work together so that neither the server nor the clients have to do too much extra work, computation-wise. I've thought about a couple of different models:

• "Dumb" clients that simply send input information to the server, which calculates everything and streams game state back to clients. This is very server-intensive and possibly not optimally responsive, but it also doesn't really leave any room for cheating.
• Each client manages their own ship, ie. the game client does all the physics calculations related to the player ship and only transmits speed / rotation / velocity / etc to the server. Server manages non-player assets, and verifies client-transmitted data. In this model I'm thinking physics would be disabled in the client for everything but the entities that particular client is managing, and their state would be streamed from the server. The server could verify the transmitted data by doing sanity checks, ie. can a player turn that fast / go at that speed / be at that location. As far as I can think of, this should be relatively cheat-proof and in general a pretty good solution.
• Each client calculates everything, and streams changes in the game state to server as they happen. Then there's always the (even likely in case of lag?) possibility of game state mismatches, where the server would have to mediate the state to be resumed from. I'm not sure if the game play would get choppy? In any case this should be really easy on the server, and should feel really responsive on the clients as well.

So, any ideas on how I should go about this? Are there some pros or cons I'm not noticing, or perhaps completely different solutions that I've missed? Is there a method that's already been battle-tested (with something created with Haxe/HaxeFlixel)?

I'd appreciate any and all input, and I'm sure helping a noob such as myself would earn a couple of extra karma points.

[Chase de Languillette]

don't quote me on any of this! :) I'm not really a pro in this field, but it's something i've been looking at a lot lately.

if you're super concerned about cheating, an authoritative server is the only way to go. your game can become considerably less responsive, as clients will have to wait for a round trip to the server to see something happen (this can take anywhere from 20 milliseconds to 20 seconds lol).  this setup is suitable for certain games, but not others. generally, i'd say that this setup is probably better suited to RTS-style games, where the input you're sending to the server is at most a mouse click each tick.  here's a pretty great write-up about tackling this approach in an old school RTS (great title too btw - "1500 Archers on a 28.8") http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php

if you're NOT concerned about cheating, another approach to this problem is to make everything peer to peer.  everyone manages their own ship and broadcasts their position/velocity/attack events to every client as frequently as possible.  if you shoot your weapon and it looks like a hit on your simulation, a 'hit' is broadcasted to all clients.  this approach is not as insane as it sounds, but it does have drawbacks - latency can make close escapes actually look like a hit to the victim. however, this approach IS used by some reputable, shipped games.  Awesomenauts immediately comes to mind (the devs have an amazing blog that talks about their multiplayer issues here - http://joostdevblog.blogspot.com).  Halo historically also used a peer to peer networking model (but it looks like they're dropping that in Halo 5).  Here's a lengthy talk about the networking setup used in Halo Reach (i confess i haven't watch the entire video yet) http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking

personally, i'd say don't worry about cheaters too much if you're making a new indie multiplayer game.  your biggest problem you should be considering is getting people to play the game in the first place.  if your game becomes so popular where cheating becomes an issue that's too time consuming to solve by monitoring and banning players, then you've actually got a wonderful problem on your hands.

[Mihai_Morosanu]

www.nuggeta.com/