I’ve mentioned in a couple of previous posts about a wargame idea I’ve had swishing around my brain for a while now. The good news is that I finally made a start.
The main problem with getting started was, simply, getting started. No matter how many times I sat down to code, I ended up getting distracted or hitting coder’s block and staring at a blank source file in Aquamacs. Evenings aren’t my best time for programming, especially after a tiring day, which doesn’t help much. The other problem was that the overall task looked both large and hazy. A bit like most projects, except this time the customer is me and the deadline is “whenever”.
The game has three main aspects: historical and non-historical unit availability and deployment, unit combat and movement, political opinion and events. The first area was already the subject of an earlier prototype, of which the only thing I have retained are the unit availability data files, and seemed like a good starting point.
Given the coder’s block, I went back to basics and wrote out a series of bullet points on things needed for this part of the game. After struggling to get a couple of bullets down, things began to flow and I racked up quite a good list of functionality. Some of the ideas have been with me since the very first time I thought about writing this game (a couple of years ago!), while others were fresh. Although I reviewed the list to weed out any weak ideas, I ended up sticking with the list as-is – give or take a few tweaks of terminology to keep things consistent.
Now, the obvious starting point would’ve been to start writing some PyGame code straight away. Much as I’m a visual person, my lack of experience of PyGame encouraged me opt to hold back and take a different approach. My main worry was that I would bog myself down in PyGame, without really considering what I was going to achieve. Looking at my list of tasks, I started to model some of the data required and began to pick and implement some basic functionality using test-driven development. By isolating these models from any user presentation, and from writing any UI code before I had gained some ground learning PyGame, I found myself gaining a much better appreciation for what I was aiming to implement overall.
As I wrote little bits of functionality, I refined my existing task list and design until I reached the critical point: I needed to start on a UI. My first thought was that I should prompt the user for a screen resolution and so on, but then I realised I could hard-code it to my MacBook’s screen dimensions. There was a tinge of guilt, but it was the simplest option at the time to get something working and I’m the only customer so far, okay? After a few iterations of work, I now have a screen displaying three different lists (deployed units, units available for deployment, and units that are likely to become available soon). I can increment the game turn, each one representing a week of real time, and can watch units switch between the various views as time progresses and forces arrive and depart the theatre of operation.
As a game, it currently sucks: it’s not so much a game as a rolling chronology of the order of battle. But that’s okay because it’s barely a fraction of the final vision and the current process is geared at building a suitable foundation for the rest of the game. I’m not thinking “game” just yet, because most of the real gameplay happens in the other two aspects. The current UI itself is temporary, because the different lists will not be presented in their current format later on. The deployed units, for example, will be shown on a game map as NATO-style unit symbols, not a list.
The great thing about tackling little chunks is the motivational factor. Never has the term “low hanging fruit” been more apt – by searching the to do list for small tasks, I can fit coding into spare moments. The sense of progress by chipping away at the tasks is a great motivator. Periodically I refactor the code to keep things fresh, to remove code smells and ugliness that I feel guilty about, and generally improve the design based on my experience of the project so far.
Anyway, that’s my little reflection on the work so far as I’m too tired to write any Python tonight. After hitting some more internal milestones, I want to have a public milestone of some screenshots of the first game aspect. Since I’m the customer and don’t have a deadline, I can’t say when that will be… but hopefully in the next few weeks.