Introduction

I've been developing games in some form for thirty years, starting with BASIC on the Amstrad CPC 464 in my early teens, working on MUDs as a hobby during university, before getting a job as a software engineer and eventually landing in the video games industry about fifteen years ago. In my time so far in that industry just one of those projects, Fall Guys, was a well-known success. And while I learned a lot during that development cycle, I've arguably learned a lot more from previous projects that underperformed or didn't ship at all. As Tolstoy said, "each unhappy family is unhappy in its own way", and perhaps the same can be said for game development teams.

I believe that video game development has only 2 major problems. Unfortunately, the first is that we're not very good at writing software, and the second is that we're not very good at designing games! It's only through the dedication and hard work of the developers, combined with the public's insatiable appetite (and thus, funding) for new games that we're somehow able to keep cranking out new ones despite all the odds.

Elaborating on these two points is the primary purpose of this blog, so for now I'll just provide an overview and set the stage for what to expect from future entries.

Over the years, software development has followed a curious course. The continual advance of free or cheap third-party libraries of software means that developers can deliver more and more functionality while writing less and less code. Many modern apps are mostly existing components bolted together with a thin layer of application-specific 'glue' code. But while this paves the way for increasing numbers of creators able to make useful and entertaining applications, it comes at a cost - fragile software that breaks in ways that the creator does not understand, insecure software that leaks personal data or exposes security flaws, inefficient software that uses more of your computing resources in order to save the original programmer time. This is going to get worse before it gets better - a wave of self-taught programmers are using these components to achieve great things with unmaintainable code, many embracing a culture that dismisses fusty old software engineering formalisms in favour of the "move fast and break things" ethos popularised by the world of tech startups.

The games industry has been spared the worst of this, but not all of it. The dominance of the two major games engines (Unity and Unreal) is a similarly two-edged sword, allowing developers to achieve great success with less training or rigour. And while the games industry was never a bastion of perfect code, poor software engineering practices are arguably increasing now that more developers are self-taught and engines isolate them from their errors in ways that previously could not be ignored. As with non-game applications, we're seeing an explosion of new programs that do more than ever before but which are increasingly fragile.

Game design has a different problem. It's a far older craft and most of what we know about games and play in general can be transferred to the digital medium. We may not have developed the same sort of 'game components' that can be bolted together, but at least there is this rich history of past games - digital or otherwise - plus our understanding of related media such as cinema and prose, which can guide and inform us as we make new works.

But if this is so, and we have decades if not centuries of game and narrative design to draw upon for designing video games - why are we so bad at it? As veteran game designer Daniel Cook said recently, "an expert game designer is 20x more effective than a newbie. They are correct 20% of the time instead of 1%". We tend to assume that good games are discovered through a process of iteration rather than designed explicitly, and this is the accepted wisdom - at least in video game design, where the themes of iterative and 'Agile' development processes are applied to the design of the game as well as the software implementing that game. But I would argue that not only is this excessively iterative approach unnecessary, but it's inefficient, ill-suited to game development, and actually adds to the trouble we have when trying to successfully complete a video game project.

I think it's no coincidence that many - perhaps most? - game designers I've met were not really 'designing games' in the sense that someone making a card game or board game might design a game. Instead, they were usually creating and tweaking content for systems that already existed, often without ever choosing that system or planning its parameters. But if we were to take a more systems-oriented view of game design, as designer and author Raph Koster does by temporarily setting aside the aesthetics and considering the core "mechanics, inputs and processes, rules and tokens and actions", we should be able to use our experience to structure a game that effectively delivers something close to our final intent earlier on, reducing the amount of subsequent iteration time needing to be spent on it. The aesthetics are still essential, but to some extent these two strands can be managed separately, with the interface between the two arguably being easier to manage when there is less iteration and therefore less of a moving target.

Thankfully, I think both of these issues - how we approach software development (especially for games) and how we approach game design (especially for software) are both fixable. I don't have all the answers, but in the spirit of Thomas Edison, I do know a lot of ways that don't work, and I hope to share various suggestions based on those experiences over the weeks and months ahead.