Hello, everyone!

Since I started working at my current job I began to learn about Test-Driven Design, also known as TDD, and used it daily in the projects I worked on there. From the beginning I started learning it, I tried to apply those practices in my personal projects. So I could say that I had been using it for almost three years as an Indie Game Dev.

If you are now wondering what is TDD here you can read about it in this Wikipedia post and get an idea. In my personal opinion, it can be very useful but is not for every project and it has a steep learning curve before being able to see its benefits.

How do I decide if I want to do TDD

First of all, in order to clarify, I will only talk about my personal indie game projects and this is a totally personal opinion. I will try to provide clear and complete examples of my experience so far so you are able to decide for yourself.

When trying to decide if I want or not to do TDD, I take into consideration two things:

• Is this project going to be something I consider big?
• I am trying to test how would I use TDD on this project?

If the answer to any of these two questions is yes, then I would try to use TDD instead of just jumping into the production code. Of course, and it has happened, the answer to the first question can be wrong and maybe I should have approached the project in a different way but it is all part of the learning process that goes with the game development.

Why do I choose these kinds of questions? Well, the first one is because I believe one of the biggest advantages of the TDD is in the long term. I believe that I take that extra time to set up the correct tests and everything so that in the future the number of bugs or playtests needed decreases significantly improving the development times. For someone that did already TDD for a long-term project it may seem something obvious but for someone who has never done it, it’s probably hard to believe. It is something you have to try out for real and with conviction at least once to actually see it.

For the second question, even doing TDD is the same concept regardless of the implementation, the implementations may vary and even people would do some things a bit different than others when doing TDD so I also like to learn and experiment with other ways of doing it.

Now let’s jump into real-life experiences for me when using TDD for my indie game projects!

Re-doing Summer Snow Day but this time using TDD

If you had seen my blog for a long time, not that I am counting on this one, you will notice that I started working on Summer Snow Day a long time ago, around early 2018 to be more precise. As you see, the development has been really slow, mostly because we have our jobs and other projects that we work on during our free time but we had been able to achieve progress constantly.

Sadly, or not that sadly, at some point the Summer Snow Day project got corrupted, and also the codebase was already a mess. A lot of back and forth + experimentation was made and is still being made, so the project was a total mess.

So we used that in our favor and started from scratch, regarding code, and we started using TDD when developing it.

Here is where we encountered a specific question that will be repeated throughout all the projects. How much should we test and what is the right amount of testing? For this project, we aimed to do something similar to what we do in our current job (Lauta works in the same place as me), and we decided to go for an MVP and test only the Presentation layer.

In my opinion, since we have this new project with a new structure and having this codebase tested, we had been able to tweak a lot more the dialogue system more than we would have been able without it. Also, we didn’t have the need to playtest a lot through all the game over and over again which is a really cool thing. But, I have to admit, in this particular case I have the feeling that we didn’t tweak that much the Dialogue system or things like that to say that we actually took huge advantage of TDD. Having the test coverage is definitely a nice thing but I can’t say that every visual novel should go for this approach.

Canceled project: Roque’s Life

In 2020 we worked on Sense of Unity. We were pretty happy with the results and we definitely wanted to make a game based on that gameplay and started working on Roque’s Life.

We started this project by using TDD as our main way to develop code. The idea behind doing it with TDD was that we already tested the gameplay and we were happy with the results, we would only add new code to experiment with different mechanics for it, and we knew more or less the scope of the game and we thought it was worth.

Sadly, in the end, we decided to not keep working on this project. The issue was that it was very consuming art and the artists didn’t have enough time to work on it. I personally think that if we would happen to continue working on it, the TDD was already giving us clear advantages and facilities for making progress on it but in the end, you never know if the whole team will have enough available time to keep working on big projects.

Jam Games

During this time, I participated in multiple game jams but we always decided not to do TDD in those.

I think it is important to mention this. In my opinion, TDD has a big overhead at the beginning that just won’t be useful for jam games because you won’t keep working in the future on those. You need to get quick results and that’s it.

I do believe that using TDD brings a great advantage in the long term, but if that long term doesn’t exist then I don’t find it to be a useful tool. My advice here would be to be wise when to choose TDD and when not.

Regrets in Is This Still Tennis

One of my biggest latest regrets is that I decided not to do TDD in the Is This Still Tennis project. As we always aimed for a simple web browser game, I thought it wouldn’t take us too much and that the main mechanic would be very simple and direct.

Opposite to what I thought, a lot of iteration has been made to the game. For example, if you had seen the latest screenshots I shared on my Twitter Account you would have noticed that we no longer have those baby otters or the character leaning to the sides when hitting the projectiles like the screenshot I am showing here. If I would have guessed that this project would take this long I would have probably worked on TDD.

Even though starting with TDD would have been the best option probably, I am still available to switch and start testing the game. It would give me a big overhead in the beginning but I should be able to see advantages in the end. I haven’t decided to do this yet but is something I need to keep in mind and decide on at some point.

Paused Project: Dungeon with Dices

Another project that I just don’t want to cancel yet but the truth is that it has been at least indefinitely paused is the Dungeon with Dices game. Hugo, who was the current artist, hasn’t been able to continue with it and I didn’t find time to keep working on it and find someone else who joins me in making this game.

Anyway, apart from this, the new thing this game had was that I was trying to test as much as possible. From the presentation to the domain and up to the view. This made the current state of the code something that I am pretty proud of. Even more, since stuff like the view was tested, a new artist would be able to join the project, modify some stuff and run the tests. If they don’t pass, the artist will know that something is missing and the test will tell exactly what.

I feel like that code state should be the goal for long-term projects but sadly, I can’t use it as a good example since the game is currently on hold for now. Hopefully, in the future, I get to continue it and prove if I was right or learn if I was wrong.

Tested Stonks

For last! We had been using also TDD in order to develop Stonks. This game has a similar completion of tests as Summer Snow Day. I personally found some cases where I was glad there were tests but then I also felt that some parts were just redundant. The issue here is that sometimes TDD is one of those things that you don’t think you should have unless you find a problem and you weren’t doing TDD.

Anyway, I think that if I have to bet, I would say I am glad we did TDD for this project. It wasn’t a really complex project but I feel it has enough complexity to actually have benefited from doing TDD and I am pretty proud of the current result. Also, if we are lucky and the game does well, we will have a solid base in case we want to continue it.

And this brings me to a small announcement that is that the game is really soon to be finished. I wouldn’t expect it to take too much more so stay tuned!

Wrapping up

So I guess I said everything I had to say but as a small wrap up:

• Only consider doing TDD in indie game productions if you think the game is going to be big, Considering big basically if it’s going to be something you work on for a long time, or you are just planning to learn how to do TDD.
• TDD helped some of my projects to focus on only the needed code and gave me and the other team members a lot more of a free bug experience.
• I would have hoped that if I guessed Is This Still Tennis would take longer, to actually do it with TDD.
• If you consider a game will be in production for a really short time, like a game jam, for example, I wouldn’t do TDD.

And I guess that is all for now! Hopefully, you find this post useful, and thank you for reading!