I’m making an engine/CMS for story-based web browser games. I have quite a bit of data: characters, items, and the bits of story that the player will interact with. The intention behind this project is that writers don’t have to be programmers in order to create a narratively-driven web game. It would only require basic knowledge of FTP and website management in order to start creating content.
The problem is that I think the database is going to bog these games down. Each character can have a lot to them, and the stories are going to be extensive. Each bit of story will have its own written text, which could be 100 characters or 500 characters. There’s no way I could cache that all with memcached or something similar!
Thankfully, each state of the game is “pushed” through a deploy, meaning you don’t just add a character and they appear in the world; you have to add them, and then push a build of the game. I believe I can use this to my advantage. My working notion right now is:
There will be three databases total. One will be the ‘working’ content DB, another the ‘live’ content DB, and then finally the DB that holds all user data. (where they are in the story, items they’ve obtained, etc.) My idea is that I’ll push with the working DB, completely destroy the live, and rebuild the live based on what’s in the working DB at the time of the push. The live DB will then benefit from read-only abilities: such as the ARCHIVE storage engine and quite a bit of indexing. This sounds pretty solid, but I’m not experienced enough to be confident that this is the best way to go about my business.
I’d love to know if anyone has any suggestions for a new model, or even a suggestion to my current model.
What you’re saying sounds like it’ll work. You’ll have to build your framework and then inject some dummy game data to see how it responds.
One nice thing about gaming is that you can get away numerous loading screens/bars, so take advantage of that. 🙂