Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Im programming on a turn based war-game for some years now (along with the engine) and Im having quite a hard time at figuring out what the games server architecture should look like, since most game server architecture articles I found focus either on FPS oder MMOGs, which doesn't really fit since I want many matches with 1- 16 players on my server, with each match being played in turn based mode.

My chief concern is memory usage, since the most basic approach of loading every game that is being played completely into RAM should be quite inefficient, so is there a suitable strategy for selecting only the needed bits and loading them?

Another question I got is how to design the threading on the server, since I think using only a single thread could be a problem due to the fact that the game or part of it might have to be loaded from the database.

I would be very happy if you could share your knowledge or point me to material on this topic.

share|improve this question
    
Is this a server that runs multiple games at once? You need to be specific on this. Also, do you have any evidence to suggest that you won't have enough memory for this? As for threading, you don't necessarily need that - some database APIs let you read asynchronously. So you might want to rethink a requirement for threading here. –  Kylotan May 30 '12 at 13:00
4  
And while you're reconsidering your threading model, per @Kylotan, maybe consider an event driven architecture which will lighten the processing load considerably versus a continuously running model. Your chief concern is to get one game running and then measure resource usage, not daydream about problems you don't have yet =) –  Patrick Hughes May 30 '12 at 13:42
    
@PatrickHughes completely agree about event driven architecture for a turn based game. Provided it really is turn based. You can dump the state to each client on each turn shift, and then only verify the move that a player tries to make after that. Offload chat to a different server. If your turns (or phases/movements of turns) are longer than a few seconds, you'll be walking down easy street with this model. –  DampeS8N May 30 '12 at 17:58
    
If it is turn based, I'd probably do this as a webservice, and provide a 'default' client. Make it easier for porting to other platforms, too... –  Clockwork-Muse May 30 '12 at 20:31
    
@Kylotan Yes, the server runs multiple games, the game is planned to be played online, but with a standalone client. Im also planning to use mongodb so far, since it seemed pretty easy to integrate with the webpage used to buy stuff for the game (micropayment). –  SkeletorFromEterenia Jun 1 '12 at 7:00

2 Answers 2

up vote 0 down vote accepted

Of course I can't tell how much data there will be for each game as I don't know what you are planning, but in general I'd say that the state of a turn based game should not fill more than 1 MB given a reasonable format. In most cases a lot less will do. See one of my other answers for a bit on the concept of counting memory: http://gamedev.stackexchange.com/a/22305/3505

So you should have the memory for keeping "everything" there, and from a performance perspective it's probably best to do so. If you deem it important you can save players' orders to a database to be able to regenerate the games in case of a crash.

While a database can save you from many worries, performance in general is not one of them. A typical SQL database might give you 100 000 simple queries per second, application memory is more likely to give you 1000 000 000 I/O operations per second. (Note for those who like to argue: The numbers vary wildly between configurations, but the fact that a typical database is a huge drag is a constant.)

As for threading, the easy route is to have one process, with one thread for each game. Depending on language of choice that will give you a few MB of overhead for each game, and a lot of process switching. Depending on exact circumstances this will give you a limit somewhere between a few hundred and some thousand simultaneous games.

If ever this is not good enough for you multiple games per thread/process is the most straight forward improvement.

share|improve this answer
    
Thank you for your answer, this was really what I wanted to know. So Ill stick with the "load everything" and "run each game in a thread" strategy to keep it simple and save the time implementing more complex stuff (I already read about the reactor pattern ) for now. –  SkeletorFromEterenia Jun 1 '12 at 7:19
    
@SkeletorFromEterenia Do note though that it's not like it's impossible to spend a lot more memory, but typically this will only happen if you make a world that is bigger or has more details than it ought to to have gameplay wise. –  eBusiness Jun 1 '12 at 13:44

(Hm, I'll add this as an answer because I can't seem to comment for some reason :()

I think you need to use a database instead of keeping the games in RAM. With a database you don't need to think about memory because it is handled by the os and the db software.

I have worked on a real-time MMO and you are right that you have to worry about memory concerns there because the server has to keep every players info in memory while they are logged in. This is mainly because of position. The users expect the location of their players to be the same on every machine, much like a multiplayer fps game.

However; a turn based game does not need all players info in memory to do operations on it. You have "unlimited" time to process an operation. I have not done any work on a turn based game, but I believe there are two things here you need to worry about: verifying a users move and reacting to that move. As we have unlimited time to process this, we could easily use a database here to directly process every input that we get. With postrgresql we could even put the reaction rules into the database. Then you don't have to worry about memory or threading because it is handled by the database.

In practice you will need an executable in between your database and the input from the users because of security and some things that the database could not do. Even if you have a lot of connections at the same time, I cannot see that memory would be a problem here.

So really the answer is: use a database, you don't really need to worry about memory with a turn-based game if you do.

share|improve this answer
    
Thank you for the hint to PostgreSQL, Ill check that out, although I m pretty happy with mongodb so far. –  SkeletorFromEterenia Jun 1 '12 at 7:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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