[originally posted on: 2010-04-18]

Changes to the development model

As I started the browser game project Little Goblin, my goal was to create a program where I could make little changes, one after another, and watch the game grow from a barely usable prototype to a full featured game. And for the first few weeks this did really work. Grails makes the fast development of a web project possible. It offers a good Model-View-Controller architecture and helps with bringing the database objects through the controller to the view (by using and extending the ORM features of Hibernate and offering the features of GSP, Groovy Server Pages).

I would create some basic game objects in the Grails Bootstrap class, run the code and be able to see it working in the browser. Each little step would be reflected immediately in the state of the game as it ran in the browser. Fixed a typo in a page? F5-reload- and there is the correct version. For major changes (like adding a new domain class which requires extensive changes to a controller), a restart of the server would be necessary. But then, as the database was completely held in memory and repopulated in seconds by the Bootstrap class, this was no problem.

Development sure was easy and fun.

Deployment was not as easy, as the Windows 2008 dedicated server which I happen to share with my friends (I guess that makes it semi-dedicated) is not as easy to administrate as my Ubuntu workstation. I have to delete the temporary files of the game from the temp directory if I want to publish a new version, and there are sometimes strange error messages in the log. Recently, I sometimes encounter an Exception message upon visiting the main page of the game, which vanishes after a reload. I guess Jetty with a 32 Bit service wrapper behind Apache on a 64 Bit Win2008 server is not as stable as I thought. But then, this is not a big problem, as the current installation is more of a testing ground. I will probably need a dedicated Linux server just for this project alone.

Too many little changes have a large update overhead

But back to the changes I needed to make to my development model. There is a problem with doing many changes to the domain model when you happen to have a production server: each time you make a change to the database layout, like adding a MobImage class to the Mob objects, you have to convert the existing data and make sure that foreign key and other constraints are working as intended with the legacy data. For a server in test mode, which can repopulate the database programmatically, this is easy. For production data, this is getting harder the more complex your domain model is. And believe me, the data model is quickly getting really complex when Grails is dynamically creating the database tables as needed.

So, how can I have a game which is already playable by users, and where I can make lots of changes to the domain model? The answer is: at the moment, this does not work. It is one thing to periodically release an upgrade to the game which adds a new feature (and change some database tables etc). It is another to make those changes several times a week. The amount of work to keep the legacy data up to date is prohibitive. And should an update fail, the players would be very disappointed. So, a mixture of beta testing for alpha code is out.

Solution: Create the framework first, add content later

At the moment, I think a workable solution is to finish the game engine and add the main content later. For testing purposes, the game will have a very limited amount of game objects with which a user can interact (one or two quests, not a hundred). This way I can iterate faster and get the core game features in place without having to worry about an update breaking the game. The disadvantage is: I won’t be getting as much feedback as when having a evolving game with more content. But then, a game that is eternally pre-alpha is not much fun, either. I think that the game can go from working full featured prototype to beta quite quickly, provided the content is created fast enough. And the development style is still iterative rather than a water-fall-process, but the iterations are done first in the core and then, when the development spirals further, the content iterations are added. This seems better than needing to also iterate the content each time a new core feature is added (to avoid “Monsters may also use items. Please update hundreds of quests.”).