Ludum Dare 42: Post Mortem
For this past weekend’s Ludum Dare 42 I knew I was going to be away for the weekend with limited time to work on the game, so I kept the scope very small. During game idea pre-preparation I also ended up deciding that I’ll try to make a turn-based strategy (TBS) game of some sort - it’s my favourite genre to play, but all my attempts at making games in it in the past have ended in abject failure - using a jam to practice seemed like a great plan to start fixing this.
As expected the jam turned out to be a weird for one me: I spent relatively little time working on Saturday and Sunday, with a lot of time instead going to cooking, napping, walks and boardgames. In spite of this the game I built is one of the few attempts that I would consider a success in the TBS genre - given how little time I was able to spend during the weekend that was quite a surprise!
I suspect the limited number of mechanics I tackled to keep the scope small allowed me to focus on the most essential basics of what makes a turn-based game and the template project I quickly put together on Friday evening definitely helped (even though the code is quite terrible).
So instead of trying to gain some general game development or game jam wisdom from this post-mortem I want to focus on just two things:
- What I learnt about making TBS games.
- Identifying problems with my TBS template project.
Making TBS Games
The bulk of the learning about making TBS games came on the Friday evening while trying to put together the my template project…
What I realised as I struggled to put together a few different scenes with the necessary code to make them behave in ways that match different types of TBS game, was that I don’t really have a good mental model of even a small fraction of the mechanics that can be in a TBS game… this idea was confirmed when I started digging around on the internet a bit in the process of writing this post-mortem. I have a wealth of experience of playing these types of games, but it’s one big jumbled mess in my head - more raw data than knowledge - which is why I struggle to apply it.
It’s like a big messy toolbox that needs some organisation to become useful…
I find one of the best ways to sort through a jumble of thoughts is to write about it. The process forces you to sort out what you know from what you thought you knew and then to structure it well enough to communicate the concepts to others. So in an effort to turn my jumble of experience into a useful toolbox, I’m going to start a series of blog posts about turn-based mechanics. Keep an eye out here for the overview post which should be up shortly after this post-mortem.
One other idea also kind-of coalesced in my mind this jam. In all my previous attempts at TBS games I have focused heavily on building the complex internal mechanics of the game - board games seem to thrive on this interesting complexity. This jam instead I had simple mechanics, but spent a lot of time on tweening and animation to try to make it clear to the player what is happening - the result is a TBS game that feels much more approachable and understandable.
I think I understand why this is: in a board game the play session starts with all players learning the rules from the rulebook (or at least getting a refresher). Then during the course of play all players are constantly parsing events in the game through this set of rules in their head - the results may be complex, but that’s not a problem, because each player has their own mental model of what’s supposed to happen that they are constantly revising during the course of the game. It’s complex, but the complexity is in no way hidden from the player - they know exactly what’s going on all the time.
When you try to build similar or greater complexity into a computer game, this is not the case… All that complex processing is being done internally by the computer and the player has no idea what’s going on! So to succeed as a developer TBS games, I think you have to work very hard at making clear to the player what’s happening inside your complex simulation through polish and animations. I have to go make some more games to test my theory, but I’d almost go so far as to state this might be the cardinal rule of successful TBS game design.
1st Rule of TBS Design
Complex mechanics require high levels of polish to make the complexity understandable to the player.
TBS Template Project
The template project is on Github if you want to take a look, but be warned that the code is quite bad and that it was out of date almost the instant the jam started as I started making changes to the copy that I used as the basis for my jam project.
That’s one of the glaring flaws in the template project: it’s designed as a template project that you copy and extend, but this makes it very difficult to contribute improvements and fixes back upstream into the template project. There are a few others:
- Combining tweening with physics-based collision detection caused some weird temporal bugs that are damn-near impossible to debug.
- The lack of a game state data structure separate from the Unity objects made path-finding a very difficult task. The hack to solve it was big if statement to move towards the centre, but this results in units sometimes ending up on top of each other.
- My poor mental model of TBS games is reflected in the code - it doesn’t provide clear extension points, names are unclear and different mechanical concepts frequently bleed into each other in the component implementations (for example player input handling happened in the movement component, which the AI also ended up needing - so then I had to introduce a flag to prevent the player input from moving all the AI units around).
- The code does not consider network multiplayer concerns at all - that was not a problem for this jam, but it is a problem for any serious future use of the template project.
After wasting half a day trying to come up with solutions to these problems, I still don’t have a clear course of action. I suspect many of them will become much easier to think about once I have a better mental model of TBS mechanics to work from, so for now I’m going to defer coming up with solutions and instead focus on knocking out some articles about TBS mechanics. Once I have a few mechanics down on paper (so to speak) I can test my new mental model by seeing if writing a new version of the template project is any easier than the first attempt.
So keep an eye out here for my TBS Genre Overview article which should be out a bit later today, with posts on various mechanics following from that as soon as I can get them ready.
