A few years ago, the Levy & Campaign Series burst on the scene with Nevsky: Teutons and Rus in Collision, 1240-1242 from the gifted and beautiful mind of Volko Ruhnke. A series focused on medieval logistics and the feudal system where the arts of war and careful building of alliances were so important to the fabric of society all boiled down into a very playable game was like catnip to the wargame masses. Since that time, there have been several new designs in the series come about including Almoravid: Reconquista and Riposte in Spain, 1085-1086 from Volko as well as from other designers including Inferno: Guelphs and Ghibellines Vie for Tuscany, 1259-1261 from Enrico Acerbi and now Plantagenet: Cousin’s War for England 1459-1485 from Francisco Gradaille with many more coming and in design. Francisco has agreed to write a series of posts for our blog on his designs and way of thinking through issues a bit non-conventionally.

Iterative Design and Incremental Model Building Applied to Game Development

A few months ago, we published an article that posted here on The Players’ Aid Blog about applying software development and model building tools to boardgame design. In this article I will expand on that piece and focus on one of the processes that is used extensively in software development and can be easily applied to wargame design – Iterative Design and Incremental Model Building. I’ll start with a definition and explanation of the process, and then will show how it works with an example.

As a disclaimer, let me say that this is just one way of working. As game design is mostly a creative adventure, and you should use whatever method you feel most comfortable with. This is just one that I have found that I use to organize and speed up my work. There isn’t any “perfect” method. The best one is the one that you feel most comfortable with.

“Iterative Design (ID) and Incremental Model Building (IMB)” what does it mean? There are two separate but distinct processes going on here that can, if one is not careful, get mushed together into a muddle that can be hard to manage.

The first process, Iterative Design, refers to a work flow that follows this structure:

  • Prototype
  • Test
  • Analyse
  • Refine
  • Start Again

So, the idea is that you start with a prototype of what you want to be the game, then test it, then analyse the results of the test and refine the prototype with the feedback from the analysis. And then start again, building a new prototype with the data gathered, testing, etc. making changes and corrections as needed and then starting over again testing those and analyzing the results.

Easy enough, isn’t it? It feels totally natural, it’s hard to argue against this way of working, and almost all game designers do this in one way or another. The key is having the process and the steps firmly in mind and to follow the steps in order. Don’t rush to refine without the testing and the analysis. Don’t start again without refining the rough edges. Stick to the process and record it while you follow it.

The second process, Incremental Model Building, is used while working with each design developed to gradually and systematically build the multiple parts that interact one with each other in the game. The idea is to think of the project kind of as a human body. Find the central system or mechanic, the one that defines the game. And consider it the skeleton.

At this moment is when Iterative Design enters the process. Work on that system, the skeleton, using ID until you have the basic mechanic doing what you want it to do.

Once it does, then identify another mechanic that you want to add to your game, a very important one. Think about it as the Nervous System. Go back to your ID to prototype it and make it work. Once it does then, you can go back to the beginning of the ID process and build a prototype that adds it as a whole to the Skeleton that you had tested previously. Cycle through the process again and use ID to get both systems working together.

This would keep on going on with more subsystems, diminishing in importance regarding the final flow of the game. Respiratory system, digestive system, circulatory system… and ending in the finishing touches: hair, nails, eye colour, etc … these final steps are the very important “chrome” that often provide the key color and flavour to the game.

The strength of this methodology is that at any point in the design process you have a game that works. Maybe it’s not the one you wanted or that has all the features you intended, but it works. When you add a new subsystem, if the game suddenly becomes unbalanced, you know the probable culprit. It’s likely the new system doesn’t fit well with the others, and it needs to be refined. 

Let’s take a look at an example. Let’s say we want to design a game about Roman Chariot Races in the Colosseum. We want a Ben-Hur style racing kind of game.

What would be our central system? Probably chariot movement. So, our first step would be to design a system that moved pieces around a race track. Will we use a square grid? Rectangle? Point to point? An abstraction? Will movement be fixed? Will it be depending on a die roll? A card draw?

Once we have this solved, we could add a chariot vs. chariot combat system. Depending on the previous structure, we would use cards, dice, resources with wood cubes, etc. We already have the information of how the movement will work, so we know where the chariots are usually located, how much they move, how fast, etc.

Then we would mix both of them, and test how the combat system works with the central movement system.

We would then start adding new systems, one at a time: horse stats, driver stats, betting system, preparations before the race, a campaign system, etc. Each developed and tested one by one, then added to the general system and tested again to check if it fits.

What are the pros and cons of working this way?

The pros, as we have seen, are that at each step you have something to play and test, on each step you can scratch the new systems and go back to something that works, and on each step you can stop if you feel comfortable with the game as it is.

The cons are important too. And will more often than not teach you more about your design.

While this is a working methodology for building the elements of a game, it’s not how the idea for a game comes into being. To make ID and IMB work you should have a general idea of how the game is going to work, before you start, with most of the features that you want it to have in mind and a bit of an idea about how they will flow together. If you don’t prepare a draft of the general project, you can find that all mechanics work together well but seem artificially stitched. They seem to have no connection between them. So don’t forget about this. First, make a draft of the game with everything on it.

ID and IMB can also make the designer feel constrained, like doing work and not having fun. Instead of going on a walk on the park, you are following a carefully planned course. It will considerably speed your travels but maybe it will spoil part of the fun for you.

Finally, it may not fit your personality at all. Maybe your mind is structured in a certain way, and you prefer more chaotic developments. That’s fine, really. Everyone of us has a particular way of thinking and that’s great because we develop different ideas and works of art. Use this methodology if it suits you and you like how it sounds.

In the end, however, I believe that ID and IMB can be a useful tool to give structure to a massive project – especially for people that are in front of their first design and are lost in the sea of options and possibilities that lays in front of them.

And with that, I’ll stop talking about ID and IMB. In the next article I will look at how programming a simulation of parts of your game can improve playtesting speed.

Who is Francisco Gradaille –

Francisco Gradaille, Paco, is a mathematician from Barcelona that works as the CIO for an investment firm. He played chess in his young age, with moderate success. In the little spare time that his cats, kids, wife and ultra-running training leaves him nowadays, he plays wargames. He also is the DM of a role playing group that has been together for most of the last 25 years (wife included).

Regarding wargames and rules, he is always tinkering with the system trying to make them more soloable or fixing their shortcomings if there are any. He prefers games from before the 20th century and, with the American Civil War being one of his favorite conflicts, his most recent project involves testing a rules variant for the old American Civil War Series from Clash of Arms. He also has embarked upon his first design with GMT Games called Plantagenet: Cousins’ War for England, 1459-1485, which is currently on P500 and for which we posted an interview on the blog in December 2021.

We also posted a guest post from Paco in September 2020 showcasing a variant for the Men of Iron Series that was quite interesting.

Thanks to Paco for his work on this series. I know that there are lots of aspiring game designers out there and any advice is a good thing, especially from someone that is in the middle of a design themselves. Look for the next part of this series later this summer!

-Grant