I am creating a mutiplayer turn-based tactical game played over the internet. The players will play duels against each other on a 2D small map with a small number of units, a game should take less than 30 minutes to complete.

In order to assure synchronization and to prevent cheating, the server will do all the calculations and will accept action request and send back results in terms of game board status.

I plan to have the server run continuously, with all the games currently in progress being stored in RAM. This will enable a much faster response rate as the server won't have to load the game board data etc. from the database. The server will only save the game report to the hard drive once the game is completed.

This means, of course, that in the event of server shutdown, all data on current games will be lost. That is no problem.

Still, I want to ask whether what I just described is a good or feasible model, or whether it cannot work. If it can't work, what can I do?

It's the way I created three MORPGs. I actually had no idea that some people actually considered storing everything in the database rather than in RAM until sometime after releasing the third game.

It depends on your projected load and how much hardware you can throw at this, really. How much data will an average game hold? How many concurrent games will you expect on average? What about peak values of these? You'll need to give a lot more detail before we could even begin to answer this question.

In the mean time, here are some generic thoughts:

With a large enough page file this could easily work, as active games will be in RAM and abandoned or slow games will be moved to make room for them. Whether the amount of paging will bring the server to its knees is another matter. If the game is CPU intensive then this obviously could cause issues. Having a per-game allocator that keeps all memory for a particular game in the same cluster of RAM pages could help in such a scenario, but may not be necessary.

The only way to know is to try it out; write a sample application and stress test it. See what is feasible, decide if that is what you can live with - and afford. The main thing is to have a scaling plan. What happens when you max out one machine? Can you application handle being spread over more than one?

You'll need to do cost/benefit analysis to determine whether it makes sense to implement scalability stuff now or not. For example, instead of directly saving the game report to the hard drive, if that is stored in a database then it should be easy to move this data off the primary game server. Indeed, multiple game servers could talk to a single database. While individual games would be tied to a particular server, the players win/loss record (and whatever else) remain consistent no matter which server they find themselves playing on. If your game never gets popular enough to require a second machine all development time put into scaling* is effectively wasted.

* I don't necessarily include "using a database" in "developement time put into scaling", because databasen have lots of non-scalability related advantages in terms of running arbitrary queries and ACID guarantees.

[quote name='VBStrider' timestamp='1303394490' post='4801229']
It's the way I created three MORPGs. I actually had no idea that some people actually considered storing everything in the database rather than in RAM until sometime after releasing the third game.

For FPS and RTS games where there is only the one game and its over it doesn't really matter (though keeping a record of games is a good idea). But for games with progressive stat tracking you want the stats to persist after the next server restart. Databases are much better setup to handle this kind of thing then continuously trying to read and write from the hard drive of the computer running the server. There is no way a MMO of WoW scale could get by without using a database.
[/quote]

Well yeah, a database is used, but I don't write to it rather than to RAM every time something changes (same goes for reading). I store everything which is needed in RAM and sync to the database whenever the character leaves the game or something important happens, such as a level up.

On a related note, a database is just that: A database. I'm not sure how it would be excluded from existing on a hard drive (that is in fact where it exists in most cases in my experience).