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.
[In this Gamasutra-exclusive postmortem, NinjaBee explain what went right - and wrong - while creating Avatar-enabled Xbox Live Arcade worldbuilding game A Kingdom For Keflings.]
A Kingdom for Keflings is NinjaBee's fourth self-published Xbox Live Arcade game for the Xbox 360 (after Outpost Kaloki X, Cloning Clyde, and Band of Bugs). Following our usual passion for something new, we created an original IP and designed a new game with unique game mechanics.
We hoped a happy avatar-themed city-builder with a focus on the inhabitants of the world would appeal immediately to sim game players and be easily accessible to anyone else who wanted to give it a try.
The core team was the usual mix of programmers, artists, and designers, but in this case most of them had worked on one or more of our previous Live Arcade games and brought helpful experience with them.
After the release of A Kingdom for Keflings, we made a particular effort to play the game online with strangers and hang out in forums, listening to feedback, helping with questions, and generally collecting notes.
The total response to the game has been more positive than we ever expected, and playing with enthusiastic players has been a joy. On the other hand, there's plenty of negative feedback to go with the positive, and we've dutifully taken our lumps there as well.
As one of the designers of the game, I've put more of my own weird ideas on the line in this game than in any game I've worked on before. It's thrilling for me to hear praise and deeply painful to listen to well-deserved criticism.
This contrast results in great psychological trauma, and rather than work it out on a psychologist's couch, I'm going to seek therapy through this post-mortem analysis of the project.
1. Happy Creation-Focused Design
Play as a giant, interact with the little inhabitants of your world, and build them a kingdom. This was the core idea of the game, and from the first few days of actually putting together a production plan, it was clear that what we wanted was happiness, love, and creation instead of pain and loss.
This was questioned continually throughout production, usually by any new member of the team. Where's the fighting? Where's the conflict? When does my village get attacked by Godzilla? I personally lost a lot of sleep over this question. But we stuck to the original vision that the game would be compelling and fun because of what you were creating, not because of what you were fighting over.
We couldn't be more pleased with the results. As a designer, the first time I finished testing a feature and kept playing because I was having so much fun was a pretty good moment, with many moments like that to follow. For every player who suggests we add combat, there are five players who thank us for creating a fun, relaxing experience that their whole family can appreciate.
2. Evolving Design
While holding on to the core concept of the game, the team leads tried to be as flexible as possible with new ideas and feedback and let the design evolve naturally. The original prototype for this game, which art director Brent Fox and I threw together as a game-in-a-day challenge, featured villagers and seasons. Pretty much everything else changed many times over, with good results.
The idea of playing the game with an avatar character came well after the initial concept document, as did the tech tree interface, the intro cinematic, love as a resource, banner towers, ground markers for blueprints, and many other core elements of the design. If this meant throwing out half-baked ideas and spending extra time experimenting, we accepted this as part of the process.
We consider this one of the huge advantages of an indie studio developing a self-funded game -- this approach seems most viable when the development team has the final say and the final responsibility for success or failure.
As a side note, using a Wiki system (like MediaWiki) to maintain design documentation is a big win when the design is continually mutating.