2
\$\begingroup\$

I'm creating a networked frame-based game (like Tetris battle), using the Java Sockets API, and right now my main concern is how to 'synchronize' the game state between two players. I've already implemented a multi-client chat, just to warm up.

In turn-based games (like chess), a simple solution is to send a 'move packet' and wait for the other player to send a 'received move' packet, so that the game can continue in a consistent state. Now, in a frame-based game (not real time though), I'm not sure if this is the best solution (the game will run in a local network, but I could scale it later).

Should I use this same technique? What are the other options? I'm new to networking, so I appreciate any help.

Improve this question
\$\endgroup\$
3
  • 1
    \$\begingroup\$ peer to peer lockstep: gafferongames.com/networking-for-game-programmers/… \$\endgroup\$
    – wes
    Aug 5 '13 at 19:14
  • \$\begingroup\$ What do you mean by "frame-based"? You say it's neither turn-based nor real-time. If it's close enough to turn-based, using the same strategy will work fine. If it's closer to real-time, you'll probably want to do something more complicated. \$\endgroup\$
    – John McDonald
    Aug 6 '13 at 17:13
  • \$\begingroup\$ by 'frame-based' i mean it has a low frame rate, like Tetris. One player sees two screens: his own and his adversary. \$\endgroup\$
    – Fernando
    Aug 6 '13 at 17:52
1
\$\begingroup\$

There are multiple options to this, but one popular one is to encode everything you do in a game as actions transmitted over the network and putting their "time of execution" slightly to the future. The core idea here is to give the action (such as player moving a tetris tile) some time to reach the other player's program before executing it from a queue or such.

The latency between clients can then be adjusted to fit the network speed. In case of an out of sync packet arriving, there are a few options depending on how your game is constructed. If it's something simple like tetris, you can probably just implement a resync that sends over the current gamestate in some neat format. Another option if the actions player can take are limited is to simply resync the delta since some unit in time. This requires you to keep some amount of history of the gamestate in the memory.

The solution can vary depending on how your game actually is like. Stuff like tetris blocks not being 100% in sync is not a big deal while victory conditions are. By this I mean that having a way to verify who wins first is more important, but other kind of resyncs can be done on the fly without affecting the player's experience vastly. In a game like Tetris (sorry for getting hung up on that), the player could technically be playing against a recording without ever knowing it (also an used technique in games like this, but not fit for all games that want to be more "real-time").

If you're using TCP sockets, missed packets will be fixed on their own so you're saved that trouble.

I think that in order to receive more specific information on the subject, you probably have to describe the context in a bit more detail.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Hi, thanks for your answer. I'm using TCP sockets (doing it in Java). The game is pretty much like Tetris Battle (the cleared row goes to your opponent, to drown him up). What i'll try to do is to run the game on the server and 'listen' to player1 + player2 commands. If there are any commands on the queue, process them immediately. My big question now is how to 'synch' things and ran the game on the client. Can you elaborate on that? Thanks again! \$\endgroup\$
    – Fernando
    Aug 21 '13 at 19:37
  • \$\begingroup\$ Just to elaborate: i'm using a client server model, not p2p. \$\endgroup\$
    – Fernando
    Aug 21 '13 at 20:01

You must log in to answer this question.

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