Question

I’m looking for a bit of guidance on designing an efficient turn based system using mysql. The requirements and game flow would be similar to the game “Words with Friends”. But here are the requirements of the system off the top of my head:

• History of each battle must be stored so battle statistic can be calculated. At the moment this would simply be for determing win/loss count.

• The current state of battle must always be available (a user should be allowed to close the app and resume play by choice or by push notification).

• Must be efficient and have as minimal database requests as possible. Potentially there could be many requests per second with a larger client base so the less requests the better!

The general game flow:

1. Player selects another player to battle and a turn-timeout value, then waits for confirmation.
2. After confirmation succeeds the initiating player must take their turn. Taking a turn simply means selecting an attack/move to do.
3. The damage dealt etc is calculated by the player taking their turn and propagated to the database. A push notification is then sent to notify other player it is their turn.
4. Process is repeated until a win condition is met (most likely when a particular players health is at a certain level or if their turn times out).

Can anyone suggest ways to incorporate this efficiently into a database?

Answer 1

games:

id – varchar 255 (int 11 auto increment could run out if your game is huge)
start_date – datetime
end_date – datetime
current_user – int 11 (not likely you will exhaust this many users)
map – int 10 (depends on how many maps you have or if they’re random)
gamestate – … this part depends heavily on how you plan on sending the state to your app
token – varchar 50 (something to authenticate against)
status – tinyint 1 (or enum if you want pending, ready, closed)

actions:

id – varchar 255
game_id – varchar 255
user_id – int 11
datetime – datetime
action – tinyint 1 (depends on how many actions you have .. enum attack, move, defend, etc)
data – some detail about what was done but this data is for stats only and not to send to the other user

users:

id – int 11
username – varchar 50 (for example)
etc… users not so important since id is the only thing we care about here

I didnt go wild explaining every detail like unsigned, myisam vs innodb etc. The basic idea is to have a game table with the relevant game data in it and an actions relational table so you can process your stats, or timelines, etc later.

The key thing here is gamedata and token since those are what you would be passing back and forth between games. Ideally token is a hash to compare against in app unique to each game so a user can’t just use a browser or something and post an update to a game. there’s a whole other philosophy behind this that may not be important now.

So gamedata COULD be a serialized array, text, blob, etc. It depends on how much data you pass, and in what format. so an unserialized response might be like

[0] => [ // player 1
    [0] => [ // army position and status
        [0] => '2,2,98,1', //x, y, health, mode (1 => defense, 2 => offense, etc)
        [1] => '120,10,45,2', // could also break down into another array layer
        [3] => '222,155,100,1'
    ],
    [1] => [  // bases
        [0] => '130,45,34', //x, y, health
        [1] => '356,25,10'
    ],
    [2] => [ // game data
        [0] => '12245' // money
        [1] => '41324131232' // timestamp of when last turn began
        [2] => 0 // bool whether or not they are up at bat
    ]
]

and this is just player 1’s data. So you can serialize this, encrypt it, whatever. But this is what I am saying should be in the gamestate field. So you would use whatever datatype suits the need, which may be more apparent with more info on the game itself.

You can also look into relational options, but without knowing the intimacy of the game itself, this basic sample would suit a small game.

Anyhow, this answer may not be all what you wanted or even remotely close. But it is probably better than what I originally posted. Good luck with your game though. Tons of fun making games and now is definitely the time to do it for ios and android.