2
\$\begingroup\$

We came up with an idea for a real-time strategy game for mobile devices that can play with other players over a network. I'm trying to plan out the architecture/protocol required for such as system. Some other related questions (1,2) mention that P2P is the way to go for RTS games. The problem is that most mobile phones cannot open TCP ports to allow incoming connections, so a central server would be required to relay messages between the players. Another issue that is mentioned on the linked questions is the difference in floating point operations and random number generators, etc among different platforms (Our game would run on iOS and Android for example) so running the game simulation on each device may not be optimal. I could run the game simulation on a server and have it broadcast updates, but simulating/broadcasting up to 200 units per game would be quite expensive especially when multiple people are using the same server to play games. The server's performance might drop significantly with more than a few hundred people using it.

I'm currently thinking the central server would be the best method, but would require a lot of server power. I'm looking for any suggestions on a architecture/protocol that would work for this game and any insight on the issues I mentioned with existing protocols.

\$\endgroup\$

closed as too broad by Josh Jul 18 '14 at 16:56

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

0
\$\begingroup\$

Random number generator: you actually want a pseudo-random number generator that will give the same result for each player at the same situation. There are several ways to implement it, for example you may make the player agree a seed over the network then generate the pseudo-random number from that seed. Or you hash somehow the current game state and use the hash as a random number. This of course implies that the hashed components of the states are guaranteed to be the same with each player.

Floating-point differences: this depends on how tolerant you wish to be against floating-point errors. Firstly, you must decide the maximum allowable error that data can have to be consistent between each player. Then you have to synchronize this data. You may have different options:

  • If synchronizing, synchronize as soon as possible to have minimal erroneous feedback to the player or synchronize every second to save bandwidth?
  • Do computations on the server, or let the devices do computations and let the server “merge” conflicting computations, or let the devices do computations and merge conflicting information from other devices together (you may be interested in the notion of conflict-free replicated data type for the notion of “merging”) ?

Server overload: to avoid it - letting the server only relay messages seems reasonable. Then you need to decide a way to merge conflicting data, for example by using an a identifier of who made the modification, and letting the parameter controlled by a player A and computed by the device player A have authority. This is only a quick answer and there are so many possibilities! Google for 'consistency', you may find good advice.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.