Postmortem: NinjaBee's A Kingdom for Keflings
February 4, 2009 Page 3 of 4
What Went Wrong
1. Lack of mid-game and end-game playtesting
Sure, we extensively playtested the early experience. But it was a long time before we had a stable build that let us play through the game. That plus too much focus on the early game and not enough on the middle and the end resulted in balance and quality issues.
We played through to the town hall what feels now like a thousand times, but played the mid-to-late games far less. There are some confusing points mid-game where it's easy for players to get stuck.
There's a bit of a late-to-mid-game grind that I wish we had eliminated. There's a general lack of balance in some of the late game when it comes to time between accomplishments for the user. And there are crashes later in the game that more thorough testing would have uncovered.
2. Dynamic Music System
I know we're far from the first developer to tell this sad story. The original design called for a flexible dynamic music system, avoiding the monotony of the standard music loop by using a system of layered, changing riffs and variations.
We put huge amounts of time into this from designers and programmers and audio people. We rewrote the code several times, spent many hours massaging the music assets, and wrote pages and pages of scripting. But...
While there were moments where it seemed like it was going to work great, the final results were ultimately not acceptable.
At the very end of the project we scrapped the dynamic flow of music and rewrote the system one more time, keeping only a simplified version of the dynamic layering of tracks based on city complexity. And even that is a subtlety that was easily not worth the effort we put into it.
3. Texture Management
One problem with an open sandbox world is that we don't directly control the complexity of the scene being shown to the user. Almost the entire tech tree can be unlocked and built in one world.
Add in the multi-texture effects in the terrain, support for user-painted roofs and walls, and season-specific building and ground textures, and texture management gets pretty complicated.
We knew it would be an issue, but we underestimated the painful impact this would have on total memory usage and we planned poorly from the start.
It would have been harder to arrange, but we should have been more aggressive in making building assets share common elements (roof materials, wall materials, etc.), and we should have been more consistent in building design.
Page 3 of 4