Multiplayer Networking Framework

[cgreer]

Hi Everyone,

So I think it's time to start thinking about what kind of networking framework we should implement so that the code we write from here on out will take it into consideration. I've put these small summaries of two types of systems that I think would be doable. What are your thoughts?

Peer-to-Peer (Only Input is exchanged over the network)

These are two canonical articles on the topic: http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php http://www.buzzbox.com/news/2011-07-22/rts:starcraft/?clusterId=4547141

I really would LIKE to implement this kind of system (just for the fun/challenge of it), but I think it's a bit too complicated for what we are trying to accomplish. It's difficult for a couple reasons:

• A system has to be set up a where the commands that are inputed are executed two logic steps in the future
• The simulation (game) on each computer has to be COMPLETELY deterministic. If it isn't then the two games running on separate machines will not match. These bugs are EXTREMELY hard to find/deal with (see article)

Pros:

• Completely Peer to Peer
• Network speed does not need to be fast (only input is exchanged)
• Easy to do replays

Cons

• Harder to develop than the Central Server framework.

Central Server

A Central Server setup will have a server and two clients (one for each player). I think the server could be one of the client's machine (I could be mistaken). In this setup the two clients send their input to a server which simulates the game and sends the resulting game state info back to the clients. It's easier to develop for this type of system.

Pros

• Easier to develop

Cons

• Requires a higher network speed (how bad could it be for simAnt?)
• Can't easily do replays
• Not sure if it is entirely P2P.

[Rinum]

Not sure... though I was thinking... if we use a Central Server, we could eventually create a browser-based version of the game in the future.

[cgreer]

You mean that we could run the Python/glMod version on the server and have dummy clients connect? I still think that dummy clients will have to have some logic operations (not just updating pictures). We'd have to implement that in the web framework client (shouldn't be too hard?).

If we lock step the logic/drawing to 200ms, then we can just have dummy clients that are gfx only? But then the framerate is 5fps....

[Oipo]

HTML5 would allow a lot more, I assume we'd just have to port the client to that. I'd vote for a server/client model though, since if we might want to turn this into an MMO, that'd probably be the only way to do so.

[cgreer]

Yeah I think so too (maybe I'll branch it later to try and make a input only P2P, I think that stuff is crazy). I've never done this before so I'm confused about a central topic:

If a "turn" is say 200ms but the client's graphics update as fast as possible, how does the graphics frame rate interpolate? I don't understand how the gfx loop is doing anything but displaying exactly what was there the frame before if it is in-between steps. For instance, our move fxn is encoded within the logic loop, so the positions of the ants won't move until the logic loop is called....Do we have to move it to the gfx loop once we have differentiated the two?

I use the example below to conceptually try to figure it out for myself...

Assume we track three states: Ant Position, Ant queue, and Ant new position. L = Logic and Network (get state, update), G = Gfx loop (draw)

Loops: L1 (update state --> Pos (10, 10), queue[move], newPos(20,20)) update moves ant to (10.2, 10.2) G1 draw ant @ (10.2, 10.2) G2 draw ant @ (10.2, 10.2) G3 draw ant @ (10.2, 10.2) G4 draw ant @ (10.2, 10.2) G5 draw ant @ (10.2, 10.2) G6 draw ant @ (10.2, 10.2)

L2 (update state --> Pos (15, 15), queue[move], newPos(20,20)) [server moved ant] update moves ant to (15.2, 15.2). G7 draw ant @ (15.2, 15.2) G8 draw ant @ (15.2, 15.2) G8 draw ant @ (15.2, 15.2) G9 draw ant @ (15.2, 15.2) G10 draw ant @ (15.2, 15.2) G11 draw ant @ (15.2, 15.2)

I can only think of two solutions:

• allow the gfx loop to update moving thing/animations
• have 3 "loops": gfx (as fast as possible), network(fixed, 200ms), logic (<100ms for good framerate...)

What am I missing?

[Oipo]

Usually what games do is interpolation. The game knows that one game tick is X seconds, and every frame in between, they draw the image at time_passed/X pixels or so.

[cgreer]

Right, so when we re-write the move script to accept deltaT, we have to put it in the gfx loop then?

[Oipo]

Correct.

[cgreer]

So what are examples of things that go solely in the logic loop? My guess is the computationally taxing stuff like the path calculation algorithm? I guess I am too idealistic about abstracting the gfx from the logic. in reality the gfx loop has some logic in it...

[Oipo]

It all depends on how much we're going to put in the server. If we put all the path calculation stuff on the server, then the client needn't worry about it.

Mostly though, the logic loop is the networking and updating of the position of sprites/objects. If we do path calculation in the client(with possible desync issues), that would go there as well.

gfx would mainly have drawing + interpolation.