Is real-time multiplayer possible using the Google App Engine?

Question

I am currently developing a real-time multiplayer game and evaluating various cloud hosting solutions. I'm not sure if App Engine meets my needs, and would appreciate any feedback.

In essence, I want the system to work as follows: Player A computes the rounding of n and generates a hash from the game state at the end of this round. He then sends his commands for this round and hash like http post to the server. Player B does the same, in parallel.

The server, when processing POST from the player, first writes the received hash code to memcache. If the hash from another player is not already in memcache, it waits and periodically checks memcache for the hash of other players. Once both hashes are in memcache, it compares them for equality. If they are equal, the server sends the commands of each player to another, as an http response.

Such a round should last about one and a half seconds, which means two requests per player per second.

Of course, this way of working will work only if there are at least two instances of the application, since two requests must be considered in parallel. In addition, the memory cache must be consistent across all instances, be reasonably reliable, and update immediately.

I can’t use XMPP because I want my game to work on restricted networks, so it should be limited to http on port 80.

Is there a way to ensure that two instances of the application run? Are there any obvious flaws in my design? Do you think this architecture can work on App Engine? If not, what cloud solution do you offer?

Answer 1

I think this might work. The key API for you to learn about / the test will probably be the Channel API . This is what will allow maintaining communication between the client and the server.

The next question to worry about is memcache. In general, it is reliable, but in the strict sense, we assume that memcached data may disappear at any time.

If you decide that you cannot risk losing data like this, you need to save it in the data warehouse, which means that you have to experiment so that you can withstand 2 moves per turn. I think this is possible, but not trivial. If you said 1 move every 3 seconds, I would say "no problem." But several updates for one object per second begin to face a practical limit on recording per second, especially if they are transactional.

Having multiple running instances will not be a problem - you can pay to keep the instances warm if necessary.