Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: NinjaBee's A Kingdom for Keflings
View All     RSS
February 29, 2020
arrowPress Releases
February 29, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: NinjaBee's A Kingdom for Keflings

February 4, 2009 Article Start Previous Page 3 of 4 Next

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.

Article Start Previous Page 3 of 4 Next

Related Jobs

ArtCraft Entertainment, Inc.
ArtCraft Entertainment, Inc. — Austin, Texas, United States

Data Analyst
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Art Outsourcing Manager
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Lead Producer
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Experienced Game Developer

Loading Comments

loader image