Software development can be like chasing Lewis Carroll’s White Rabbit: You’re trying to solve a particular problem that, at first seems straight forward, but you soon realise that it’s actually composed of a number of different ‘sub-problems’. So you start working on one of the sub-problems and before long, you realise that that sub-problem itself contains more sub-problems and so on. It’s a necessary part of software engineering and without careful management it can be a source of distraction that derail a project.
There’s another way in which software development can be like chasing the White Rabbit, which I think can happen with many creative pursuits like writing, music, art and video game creation: one idea leads to another idea, which leads to another and before you know it, you’re in a Wonderland of many ideas and half complete works.
This can be a productivity killer if you’re aim is to complete a work or produce something useful – ideas are great, but when you want to focus, it’s best to write your ideas down and put them aside for later. However, if your aim is to learn, sometimes following the White Rabbit into Wonderland can be fascinating experience. Here’s my story how I went down, down, down into my Wonderland of coding. I wonder if I shall ever get out again?
Down the Rabbit-Hole (Pokémon)
It all started while I was playing Pokémon LeafGreen, a GB Advance remake of the original Pokémon Blue for the Game Boy (how I got into playing this is another story…) Anyone who’s played at least the original Pokémon1 knows that a Pokémon can perform one of four moves once per turn. I noticed how, at least when I play, I rarely, if ever, use certain kinds of moves – namely those like Growl or Harden that don’t cause damage but instead modify the stats of the player or enemy Pokémon. It never seemed worthwhile – I almost always preferred using the damage causing moves.
To me it’s seemed a substantial flaw in the game’s design. Not a showstopper, clearly given my the popularity of the game (and it didn’t stop me enjoying it), but still in a flaw nonetheless. It got me think of ways which could make these moves more useful. I pondered, if a Pokémon could combine multiple moves per turn, that could make these moves much more useful. It made perfect sense in many ways: why can’t Charmander Scratch and Growl at the same time? I think there’s a lot of scope for interesting gameplay here by allowing trainers to combine moves in certain ways, and not in others. For example, Ekans could Wrap and Leer in combination, but not Bite and Screech.
The Pool of Tears (Inquisitor)
So you might be thinking I went and created my own Japanese style RPG. But no, a new idea came to me. The thought of multiple moves per turn reminded me of another game I had played a few times in past. This time not a video game, but a table-top wargame called Inquisitor, one of Games Workshop’s specialist games.
In this turn-based ‘narrative wargame’ (as the rule book describes it), combines elements from tabletop war-gaming with traditional D&D style role-playing games. Each player is responsible for a small band of characters, who take turns to perform one or more of a range actions, such as walking, running, jumping, shooting or engaging in close combat. A character is able to perform more less actions per turn depending on their speed and luck (roll of a dice). They could also combine multiple moves into a single action (with a greater chance of failure).
I thought this might make an interesting gameplay mechanics for a turn-based action role-playing video game. At the time, I was just beginnings to learn test-driven development with the Unity game engine. So, as an exercise, I got the Inquisitor rule book (which I still had despite not playing the game for years), and started to design and create a video game based on the rules of Inquisitor using Unity.
It’s been long, and while I’m far from finished, it’s also been an enjoyable and fascinating learning experience. I learned about Unity features such as ScriptableObjects and the Test Runner. I was able to practice some software development techniques – not just TDD, but also Separation of Concerns and design patterns like the State pattern. It’s also through this project that I got interested in game development using TDD and (in part) starting this very blog.
To be continued…
Well done for making it this far in my story. I think I’ve written enough for now. Through the Inquisitor game project, I learnt about mocking, an important part of unit testing and test-driven development. Perhaps I’ll write about this next time.
- For the few readers that haven’t played Pokémon, it’s a turn based Japanese style RPG where ‘trainers’ battle monsters called Pokémon. They can learn up to 4 ‘moves’. In a head-to-head battle, each trainer takes turns to command their Pokémon to perform a move. There’s a vast number of moves, which can broadly be categorised as those causing damage, those changing the enemy Pokémon’s state (e.g. sleep, poison) modifying stats of your or the opponent’s Pokémon (e.g. increase or decrease attack or defence). ^