Agile vs Waterfall - The Waterfall Approach

This article is the first in a series exploring how we can apply Software Development principles and practices to designing Tabletop Role-Playing Games. This 3 part series looks at Software Engineering Methodologies and how we could learn from them to help us design games better.


A quick google of “Agile vs Waterfall” will yield you hundreds upon hundreds of articles, videos, and courses on the benefits and costs of each approach for Project Managers and Software Engineers. Current thinking largely leans toward Agile being a “better” methodology for most development teams and there is even a whole industry spun up around Agile ways of working. But what are these approaches and how can they help you develop a TTRPG?

Waterfall

An image showing the design flow of waterfall. Requirements to Design to Implementation to Testing to Release

The waterfall methodology

The basic principle of Waterfall is that you undertake each of the stages above to completion before moving into the next stage.


Requirements - Define what the application or service you are trying to build needs to do and what user need are you trying to fill. At the end of this stage, you will have a list of requirements.

How this applies to TTRPG Design - You have an idea already right? You think you have found something that doesn’t exist. You talk to friends, your gaming group, your partner, and your dog about it and they all think it sounds cool! You know what you want it to do already, it’s a rules-lite Lazers & Feelings hack that uses D20s instead of D6s and explores themes of loneliness amongst researchers in the arctic circle. You might even use something like the Board Game Identity Pyramid to clarify your design requirements.


Design - Outline the intended final product including software architecture, user interfaces, test strategy, etc based on the requirements gathered in the first stage. At the end of this stage, you will have many documents and diagrams that will be used for the following stage.

How this applies to TTRPG Design - You start your rough draft, open up a google doc and start throwing mechanics and theme at the page, you pull together some mood boards or something using a tool like Canva. You find stock art or even find some artists whose work you like the look of. You make the key decisions around how things are going to work; is there combat? what resolution mechanic are you using? what do the characters do? is this a game with a GM? GM-less? Shared GM responsibilities? Is it a one-page RPG? A 400-page tome?


Implementation - Using the proposed design in the previous stage, this stage is about actually building the thing. This is where software engineers actually write the code based on the output of the design stage. For most projects, this is the longest-running stage.

How this applies to TTRPG Design - So now you know what you want to make and probably have a rough draft together, it makes sense to YOU and is mostly hastily scribbled notes or maybe a set of well laid out bullet points. Now you have to write the thing. This is the part where you spend hours listening to lo-fi playlists hunched over a laptop and googling synonyms (just me?). But at the end of this, you THINK you have a game.


Testing - Quality assurance testers try to break the delivered software from the implementation stage. They will try to simulate what a user might do, ensuring that the system is robust and doesn’t fall over when a user puts something unexpected into the system.

XKCD New Bug comic

Relevant XKCD

How this applies to TTRPG Design - This is it, the point where you reveal your magnum opus. Hours of research and design and modelling dice probability curves are going to pay off. You put it in front of your gaming group or friends or maybe even internet strangers. You playtest the thing (you are playtesting your thing right?) and it WORKS. Far more likely it doesn’t and you have to go right back to the drawing board.


Release - The test team has said the software is great so you can release it into the hands of the users and then maintain and improve it move on to the next project.

How this applies to TTRPG Design - This is where you submit your game jam entry, start your Kickstarter or IndieGoGo or GameFound campaign, pitch to a publisher, or release your PDF on DriveThruRPG or Itch.io. It’s done! Your game is out in the world and the profits (jk) start rolling in!

Problems with this approach

1. Dependent on requirements

The success of waterfall is HIGHLY dependent on the quality of your requirements gathering stage. It assumes that everything that is required of the product is fully articulated and understood and that the output of this stage will be complete and understandable at all future stages of the project. And I just don’t think we can have those clear with 100% certainty when designing games. Listen to ANY game designer talk about their most successful designs and they will wax lyrical about how they all started as something else. The game I am working on right now started as a bright and airy superhero game and it has turned into a near-future sci-fi game set on a space station run by gangs. That wouldn’t have happened if I had adhered to any requirements coming out of the original inception and the game is better for it.

2. Inflexible

With the waterfall approach, change is BAD. If you get deep into the process and realise that something wasn’t correct in the initial requirements, or the people who are going to use what you have developed want something quite different, your only option is to go right back to the start of the process. And due to how late in the process the product is put in front of users or testers, you often won’t realise that something needs to be changed until it’s an integral part of the system. In your game design, as with software development, you might find that making changes such as this towards the end of the development process requires swathes of redesign, removing or adding entire subsystems and depending on the complexity of your game, it may be nigh on impossible to foresee the impact of such changes.

3. Test feedback

By the time your project has got into the testing phase you already have a “complete” system. If the test team tells you that there is an issue, dealing with it is a real headache. You have much much more code to dig through to find out what is going on, and changing anything can have unintended consequences throughout the system, leading to having to make many hacky attempts to fix things, ultimately resulting in a less stable and reliable product. This is related to the points above regarding change but has the additional issue of our natural reluctance to kill our darlings. By the point you are testing in the waterfall process, you have potentially poured HOURS into developing and writing up these mechanics and story and lore and those darlings are enormous beasts. It’s going to be so hard to hit the delete key on all that work when you need to.


That's it for this time. In the next article, we’ll take a look at what how the Agile approach can solve some of these problems and how it can work for your TTRPG design.

Thanks for dropping by! If you have any questions or comments, please leave them below.

You can also find me on Twitter.

Take Care!

Anthony


Previous
Previous

Agile vs Waterfall - The Agile Approach