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.

Been thinking of creating a js/PHP/MySQL game, with multiple players / games happening concurrently. Is there any chance SQLite might be faster for something like this than MySQL? Keep in mind that I'll propably test this on a shared hosting server...

share|improve this question
add comment

3 Answers 3

up vote 1 down vote accepted

You probably don't care. I'd suggest that maybe it's not necessary to use a database at all, and a commercial gaming company almost certainly uses a custom server process (not a web server at all). However, you can do whatever you like.

In particular, you're very unlikely to have either enough data or players that you will actually notice. Gaming data are very, very small unless you start storing huge amounts of historical reporting data for previous games. And if you do decide to start doing that, you can host historical data on independent servers so they can't interfere with new games.

share|improve this answer
    
By custom server process you mean php scripts that keep session data for game states? That's what I've come up to... –  ioannis Apr 29 '12 at 9:51
    
I mean, it uses a custom protocol, not HTTP, no PHP (probably not, anyway, PHP is hopeless for long-running server processes). As far as I know, all gaming sites (I mean gambling for real money of course!) use some Windows binary, activeX control, Flash or Java applet in the page, so they can use whatever protocol they like. –  MarkR Apr 29 '12 at 13:33
add comment

Writing every single action to the database, like you are suggesting you are doing, is usually a bad idea.

You would do much better writing a real server, and update the database only once a match ends.

share|improve this answer
    
That entirely depends on the time requirements of the game. If it's a turn based or tick based game with a low update frequency (<1/sec or less) then there's no problem with writing it as a traditional database-oriented application. –  Wouter Lievens Apr 26 '12 at 9:32
add comment

My advice is to look at a PHP interface that is database agnostic, so you can switch it later.

share|improve this answer
add comment

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.