13
\$\begingroup\$

I'm creating a platformer game that has a "co-operative" feature which I'd like to work over networks / the internet.

Now I've read up on network game programming including articles like What every programmer needs to know about game networking and so I understand the difference between techniques like Peer-to-Peer lockstep and Server-Client prediction architectures:

  • I've concluded that for any real-time game that is going to be played over the internet, Peer-to-Peer lockstep simply isn't an option.
  • I'm also concerned that even for a platformer a simple client-server architecture (without some sort of client prediction) would result in degraded gameplay due to the delay between action and reaction caused by a round-trip to a server. (Having said that I want to eliminate the need for a central server, and so only one of the players, the client, will actually experience this lag).

This leaves client prediction, but even for a simple game like a platformer this still sounds pretty complex.

How would I go about creating a working client predictive system for a multiplayer platformer game?

\$\endgroup\$
6
  • 1
    \$\begingroup\$ One thing that you'll have much less to worry about in a cooperative game is cheating ;) \$\endgroup\$
    – Jonathan Connell
    Jul 13, 2011 at 15:36
  • \$\begingroup\$ I flagged this as not constructive. The questions posed ("How much work is it to write a networked game that ues client prediction? Am I going to end up with half of my codebase consisting of networking code?") are way too broad and not problem-specific at all. The answer would basically be "it depends", which isn't a good answer. \$\endgroup\$
    – TravisG
    Jul 13, 2011 at 16:37
  • \$\begingroup\$ -1, "How much work" is subjective. \$\endgroup\$
    – Tetrad
    Jul 13, 2011 at 18:50
  • 1
    \$\begingroup\$ How much work, is not subjective as it stands alone but it does depend on a few factors (size of game, accuracy requirements, etc) those factors can effect if its a lot of work, a little work, or somewhere in between (though what type of work is a better question); however, I think the OP is really asking how much effort is required and how big a part of the code-base this type of code would be. As worded, its may be too broad. I chose a more narrow interpretation and answered that. I think that the OP should put in a bit more effort to narrow the questions to a few very specific points. \$\endgroup\$
    – Nate
    Jul 13, 2011 at 19:10
  • \$\begingroup\$ @Tetrad Sorry - I tried hard to make this question as objective as possible, but my question boils down to "is it difficult to create a working client predictive system for a game of type Y" - if not then I'll learn as I go, but my time is limited so learning that is too much work after X days of playing is too late. I'd try and provide more details on Y, but I don't want to make the question "too localised". The main problem here is the movement, which is common to all platformers (I want others to find this question useful). If I can improve this question then suggestions are appreciated. \$\endgroup\$
    – Justin
    Jul 13, 2011 at 22:14

3 Answers 3

Reset to default
6
\$\begingroup\$

I don't think that half of your code base will turn into network code if you decide to implement a feature such as this.

In my opinion, the most simple way to do this, is to setup a "central" server (even if that means that one player "hosts" the game and then connects to his own server) that accepts all user input as fast as possible, and sends it back out to each client.

On the client, you implement this no differently than if you were doing a co-op game for two players locally, except you read P1 from keyboard, and P2 from network.

You'll need to have the server send out a full game state every once in a while, and both clients can either snap to the new authoratitave state from the server, or they can slide into the new state (over a few seconds). Unless you have horrible packet loss or tons of clients per server, this approach should suffice for the situation you outline.

\$\endgroup\$
2
  • \$\begingroup\$ Which is about as easy as a Client Server approach (except one client hosts the server -> you don't need a dedicated server but you have to go witth something line UDP + NAT Punchthrough which needs a dedicted server anyhow). Secondly, you propose the lockstep method (as you are talking about sending complete gamestates), this isn't, IMHO, the best method if the game runs over the internet (it probably is over LAN though) where client-server is much easier to implement. \$\endgroup\$
    – Valmond
    Jul 14, 2011 at 15:35
  • 1
    \$\begingroup\$ No, I'm suggesting that you send full game states occasionally, so the client can make sure that it is not too far off. \$\endgroup\$
    – Nate
    Jul 14, 2011 at 21:00
2
\$\begingroup\$

I have a fully functionnal mMORPG style game with client prediction (the game is far from finished but it runs 'OK') and I have something along 40.000 lines of code for the server and the double for the client (add same amount for tools etc.). The Prediction is probably not more than a few hundred lines (if even that) and the whole network part a couple of thousand lines but not more than say 5.000 (it depends a bit where you draw the line).

Fuzzy question fuzzy answer ;-)

\$\endgroup\$
2
\$\begingroup\$

A significant proportion of the networking code can be independent of the game that you're playing. Because of that, and because you're new to networking, the first thing I'd suggest you do is to find libraries that will do that work for you. RakNet for example.

One thing you will want in your game code is the ability to handle multiple different game states, which you can use for interpolation and prediction. That's fairly simple to design in up front, but can be a significant quantity of work if you're modifying an existing single player game.

Also note that if you want to get strangers to play a peer to peer game over the internet, you will probably need at least one server somewhere that handles the lobby / matchmaking.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .