[In this in-depth postmortem, the Dutch independent developer Ronimo Games discusses what went right -- and wrong -- in creating critically acclaimed WiiWare side-scrolling console RTS Swords & Soldiers.]

A year ago, our big adventure started. As a young studio -- having previously created De Blob as a student game before THQ bought the rights and made a console version -- we began working on our first console title for WiiWare: Swords & Soldiers. It's a streamlined RTS that plays out on a single line with a castle on each end. Though it started out as a Flash game, we quickly saw great potential at an early stage of the prototype process.

We strongly believe that a good game is a fun game. If the core mechanics of your game are enjoyable to play, then the rest should come naturally. In the case of Swords & Soldiers, this turned out to be mostly true.

Of course, that doesn't mean that finishing the game was easy, because we never actually finished a game on a commercial level before. So for various reasons, the development time took about 3 times as long as we first estimated.

We started the project with the core team of seven, and with a varying amount of interns. With help from the Dutch Game Garden, we began working in their office. Simply said, they are a foundation that helps multiple young developers in all kinds of ways, including helping them find an office space.

Their building holds multiple game-related companies, who help each other out on projects, so we had great fun and a whole bunch of play testers just down the corridor. It was only after a few months in development we could move to our own office, just a few streets away.

Testing was super fun. On Saturdays we would arrange open house testing -- gamers could sign in by sending us an email and we would allow them to come and play the game as long as they wanted. After signing NDAs (and eating lots of candy) the gamers would be assigned to a PC, and we'd and observe them while asking them questions on their experience with the game.

In total we had over 60 different gamers test the game, all of them doing it for the fun of it; most of them continue to help us out on our new projects. In the end we feel this helped us greatly in achieving such a positive critical reception.

What Went Right

1. Bloat! Bigger and Better

This point wasn't experienced as a positive by everyone during large parts of the development cycle, but in hindsight, it definitely is. At the start of development, we planned to create a game which would just feature multiplayer gameplay, a split-screen mode, and two factions: the Aztecs and the Vikings.

We made these decisions based on a couple of arguments. First was the fact that we did not know how WiiWare games were doing (having no sales numbers at that time). Second, the project was mostly to prove that we could create a game from A to Z, so priority was to get it through the Nintendo checks as soon as possible and on the market.

Third, the multiplayer game mode was the most fun and essential. Last but not least, making the multiplayer first made it possible to balance the game from the beginning of the project (we could build the AI later on).

But to get players started, we needed some form of a tutorial, so tools were built to create some single player levels which explained the basics of the gameplay. Once the tools for building those levels were in place, and those levels worked pretty well, it seemed like a small step to just design some more single player content. This is especially true because it required a lot more design work, but hardly any coding, which was a precious resource.

Once we decided to go down that road, we went all the way. So we ended up with 30 campaign levels, three unlockable challenge modes, achievements and skirmishes. Or, simply put, a well-rounded single player mode. All in all this added a lot of work to the project. But seeing the reactions by players and critics made it all worth it.

2. Play Testing Gives More than Just Test Results

One of the more important things we took away from our education was a strong emphasis on play testing as a great tool to improve your game, and we applied it to Swords & Soldiers in spades. During a few months at the end of 2008, we invited lots of people on Saturdays to come over and test our game.

We especially wanted them to check out our single player content. This was both make sure we had a proper difficulty curve, and also to verify that they understood the gameplay lessons we tried to convey to them through the game's dialog. It was also a great motivational tool, since as a developer, nothing feels better than seeing other people really enjoying your game.

Later on, we also tried to use play testers to help us balance the game, but this was less successful. It just took them too long to reach the full strategic depth of each of the factions, making them a bit too unreliable to use as an indicator for faction strength.

But play testing gave us such an amount of eye-opening data about how players experienced our game, it wouldn't have been possible to make it this fun without them. A positive side effect was that our play testers started to post their experiences on the web, thus starting a fan community which helped with promoting the game.

3. Focused Development

We've had a very clear vision about what we wanted to make from the first moment we started working on the game in earnest. The visual style and the gameplay mostly fell into place pretty quickly. Most of the time, it felt like we were on a very clear track to a clear goal, which made a lot of things easier.

Every step towards that goal made us that bit more motivated to push onwards. Within a few short months we had a working tool chain and slice of the game which already contained 90 percent of the gameplay functionality.

During development, only two things were a bit unclear. Firstly, we wanted to have a troop manipulation mechanic. Or at least we thought we did, "because the other RTSes were doing it". So we tried a lot of systems, like dragging units backwards or being able to stop units by clicking them.

But in the end, we decided that such a mechanic would pull too much attention away from the tactical choices and put too much emphasis on micromanagement and twitch gameplay. Secondly, adding the menus came pretty late in development, though they turned out fine.

In the end, the game was mostly a very polished version of the vision we had early on.

4. Involved Audio

For the audio of Swords & Soldiers, we collaborated with an external audio studio called Sonic Picnic. Situated in the same city as our studio, they were very accessible, helpful and provided us with exactly the kind of audio experience we wanted for our game.

Since we had very little budget developing this game, we offered them a royalty percentage. Luckily, they saw enough in our prototype to go along with it. And even though it's not really common practice in the games industry, we had a really good experience working this way. It kept everybody motivated in working towards a successful game.

Also, we decided to use our own voices for the characters pretty early on. During the recording day we had a lot of fun, which was also reflected in the end result.

5. Three Distinct Factions

One of the biggest inspirations for building Swords & Soldiers was a little game called StarCraft. And one of the things that distinguished StarCraft from other strategy games was the uniqueness of its factions in style -- visually, as well as gameplay wise. So from very early on we strived to have three factions which played very differently from each other.

Not only did we try to make all units and spells unique, but we tried to add other differences as well. For instance, each faction has their own way to aquire more mana for their army. For the Vikings it's simply an upgrade they can buy, reflecting our desire to make it the most accessible faction. For the Aztecs there's a spell which is called Sacrifice, which kills a unit and turns its health into mana, reflecting the playful cruelty we wanted this faction to embody.

Finally, there's the Buddha statue, which can be built by the Chinese faction, and which generates mana until destroyed, so the player needs to defend these statues, reflecting the more complex synergies envisioned for the Chinese faction.

At one point we also had differences in the miners, making each faction feel very differently in economy as well. But in the end this turned out to be too much for us to balance, so we removed that variable from the equation.

Even so, we're still very happy with the results. Every faction feels distinct and every matchup between factions plays very differently, giving the game a lot of replayability.

What Went Wrong

1. Schedule, and Underestimating the Amount of Work

As explained earlier, we decided at the start of the project to only build a multiplayer experience; therefore, the first playable version of the game was ready in just two months.

The Vikings were playable in split-screen multiplayer and the basic interface was there. When we played the game it was already great fun and we decided that the game deserved more than only multiplayer. We wanted to give the game a single player experience with three campaigns, one for every faction. At that time we also decided to add another faction, the Chinese.

We made a schedule for the game, and with no experience of building a campaign, we thought we could build the campaigns in three to four weeks. We totally underestimated the amount of work and ended up spending three to four months on building and polishing the campaign. At one point we just hired an extra design intern to help with building and testing all the levels.

2. School Projects versus Full Development

Another point which required a lot more work than expected was simply polish. We wanted the game to be as good as we could make it at that time.

During our game design education we worked on games, so we thought we knew how to make games. But school projects have strict deadlines, and once those pass, the game gets evaluated. This meant we had never actually completely finished a game. We always went about 90 percent there, which was good enough for good grades.

As the saying goes, the last 10 percent of the work takes 90 percent of your time. It might not have been quite that extreme for us in this case, but it still took a good deal longer than we expected.

3. Having One Programmer: The Notepad Issue

The levels took a lot of time to build with the limited tools we had. With only one programmer, you can't ask for a good level design tool. For design, then, we had to use the stock Windows text editor, Notepad. We used it for almost everything -- editing the levels, writing a script for the game.

Adding all of this text to a huge text file and testing all the different versions in all languages took quite some time -- especially since every change required the level to be restarted. But we had three designers and five artists vs. one programmer, so we put up with Notepad.

There was one exception: AI. Our AI routines were built in a simple logic tree editor, which was built by a programming intern. And though the editor was a bit buggy, it was still a major improvement over editing those XML files in Notepad.

In hindsight, we probably should have put some time in coding creating a visual level editor. In about two weeks, we could've created an editor which, while it wouldn't have been too user friendly, would still have been a massive improvement over Notepad. This, in turn, would've allowed us to tweak the whole game that much better, and also would have saved the rest of the team a lot of time.

4. Adding Stuff at the Last Moment

A few big features we created pretty late in the process, such as different speed settings, which were implemented in the last week! This, of course, had to be balanced and checked for every level, and quite a few nights of sleep were skipped to check all of these last-minute features.

Another thing which came very late was the actual balance between factions. Halfway through development, we had the impression that the balance was okay, since we did a few basic balancing sessions at the start. But by the time the campaigns were nearly done, we decided to take another hard look at this balance. It turned out that the balance was horrible and would need a lot of work.

Once we started investing in this work, it of course shook up a lot of the work on the campaign. Levels were suddenly way too hard, or too easy. This added another chunk of unexpected work. Needless to say, we learned a lot about the sequence in which we should design our games.

5. Promoting Your Game Is Hard Work

After the game was out, we had to do a lot of work to promote it. We had a marketing plan, in which we would release occasional stuff like videos and screenshots. But this was not nearly enough to get the game out there.

Because our deadline was pushed back four to five months, and we had started the marketing with the original release date in mind, we had to fill this time with enough marketing materials to keep momentum going.

Marketing took a full time artist, creating videos, screenshots, logos and high resolution materials for press. We did not plan on marketing taking that amount of work. Thankfully, Nintendo helped us out by giving us some extra promotional support.

To know when your project is done is pretty important, and to arrange everything for your release is something we will take in account from the moment we start our next project.

Conclusion

In the end, we are very happy with the game; it definitely worked out pretty well for us. We have a great game as track record and we managed to make some money off it too. A game can't ask for much more than an 84 on Metacritic, a bunch of awards, and being called "one of the best RTS games for consoles".

We have plenty of ideas for a sequel and combined with the numerous ideas from our game's fans, we have more than enough to make the next Swords & Soldiers title even bigger and better.