Post Partum

I started this project about a year ago with the intention of creating the kind of game that I like to play, using the techniques that I like to use in game development.  The intention was mostly to have fun with the development, but partly to make a super casual game that I could pick up and play on my phone and browser. I have often struggled to stay focused on projects that I start for myself, partly because they are often started only to test a coding strategy rather than to make a full game, and partly because I struggle to stay interested in the project. This time, by making a game that I have enjoyed playing, I have kept on it throughout the year.

Development

I had not used TypeScript before, so opting to switch from my more usual JavaScript was a personal development goal and I can say fairly happily that I won't now go back to JavaScript now. The language is not without some limitations and integrating it with some elements of the react framework have not been pain-free but I now have a game framework that I am pretty happy with.

The game editor and run-time type information has been a real pleasure and not something that I would have undertaken at the beginning of the project. I will try and take some time to document that separately (and link it here). Suffice to say that whilst the modding tools are not perfect, they would not have happened at all if I was not able to factor out the editor to a general solution - there was simply too much data in too many different formats to spend the time on a bespoke edit tool.

Data Driven Design

The game is almost entirely data-driven and I am a firm believer in pushing as much agency to the designers (in this instance, me) as possible during game development. This goes as far as a factory for requirements so that the designer is able to build complex logic trees to define what the requirements are for assets, achievements, cultural developments, news items and many more.  Again this is a feature that will move with me to other titles and I would encourage other developers to think about.

A lot of the design came about from playing with the first prototype, it was clear that once a map was in place with counters on it, there were only so many ways a player could interact with it. Clearly adding a radial menu around a selected icon gives up to six buttons to press but as I started populating those I really wanted to avoid an more UI cluttering the map. Consequently the gameplay is unlocked by clicking and dragging icons on the map - so once implemented, this offered the design questions, what happens when you drag this icon? Consequently, settlers can move some resources, can spread some resources around the map, settlements can develop ballista to "interact" with nearby enemies, shooting an enemy that was not strong suggested pinning and flying enemies.

An often repeated mantra in game development is to avoid "design on the fly" - I remember one producer at Eidos saying that paper was cheap, software expensive - but there is something about playing the game that does unlock the creative juices and I am increasingly thinking that some iterative design, coupled with data-driven and more general code solutions can lead to a fertile development space

QA and Automation

I've used a little AI generated art in project for backgrounds and I have relied on the excellent Game Icons icon set as well. What is very clear to me is that the growth in quality and number of generative AI solutions is going to have knock on consequences for the indie community. Computer generated art, enough to breathe life into a game concept, is accessible now, lowering the bar to get small teams (and individuals). Where I have not been able to get any traction however, and I think this will continue to be the case for some time, is in QA.

I can write unit tests to keep an eye on code stability - and I should probably have done more of that - but a critical eye, spotting non-crash errors, where something makes no sense, is not easy to use, or presents exploits, for the time being, needs a human in the loop. It is only in the last few weeks where my son has been playing and critiquing the game that I have relented, offering the import/export facility outside of the debug tools.

Further Development

 I've added some modding tools for those that would like to explore the nuts and bolts further, I feel like I've done about as much as I want to, so unless the game finds a broad audience I'll leave it here. I'll keep an eye on the excellent Sentry bug tracking dashboard to see if any issues arise but otherwise I think I'll park it there.

Credits

Development would not have been possible without the following tools, in no particular order

• Firebase
• Git
• Husky
• Rider IDE
• Typescript
• Sentry
• Craco
• Standard Version
• Redux
• Material U
• Game Icons