For my browser based Flex game (for the Facebook platform), I am using PHP and MySQL for the server side programing and for saving data (using amfPHP)
Since I was very new to both game development and PHP and I wanted to see my game running, I have wrote all server-side coding (amfPHP services) with very ugly and dirty code which hits the DB for fetch, update the game state (including the players stats and inventory).
Definitely its not efficient, so I have started to find the best way available in PHP for implementing the caching. By caching, I mean I don’t want to hit the DB all the time to save the latest game state of the player but just save at the end of the session (when player leaves the app).
Typically, my game/app flow is like this
- Player launches the app/game from FB
- Authentication
- Load user session(previously saved game state).This includes fetching the user stats like how much energy, coins, experience etc., he has, his inventory, current active quests etc. and also static information like market items, offers, drops etc.
- Update the game state as and when there is some change in the game, most commonly when a user clicks on some building to collect, consume energy, add coins, give experience or rewards and so on.
Now, there are few things which are common data to be yield to all the players, like “market items and their prices and graphic assets etc.,” and there are player specific data.
I have some ideas in my mind and I need experts help in what I am thinking is good or bad or if there’s any better way?
Save Static(common) data permanently in the cache and have an admin panel to clear/update
After authentication, retrieve the data and save in the cache (as JSON objects) and all read/writes until the session ends will be done to the cache, after the session ends, save the cache data into DB.
Here I want to use APC. Do you think it is reliable?
I guess, in worst case, when the webserver crashes all the cache data will be lost, so I was thinking to save them in the session, but I think PHP maintains them in files which means there will be lot of I/O which is again not recommended? Or would that be acceptable?
I am also thinking how good it is to save game state in serialized objects?
Did you profile your application and identified the DB as bottleneck? It seems like you’re trying to optimize things that are most likely not an issue at all.
Fetching data from the DB is really fast. Writing to DB can be a bit slower, especially if you use transactions. But the DB can still handle lots of write/update calls per second easily.
It looks like you’re doing some premature optimization which will lower the security and stability of your whole game.. which is simply not worth it, unless you really identified the writing to DB as a performance bottleneck. Then again you really don’t want to lose user progress, because your session gets destroyed. Better look at something like NoSQL then.