On making a game

This essay is how it feels to make a game, which is different from any other piece of software I’ve worked on. These notes are specifically in relation to a cyberpunk-themed game show shooter titled Resonance.

Immediately, this project took on a wider scope. Networked multiplayer brings many challenges along with it. It’s not difficult to understand conceptually, but everyone must know how to work with it. Add in real-time events that can happen anytime during a round, and a scoring system that is heavily dependent on timing and showmanship? All for a roughly ten-person team to complete in five-ish months? Good luck.

Several months into this project, there are so many things that I want to fix, given the time. But we’re at a point where the game can be seen as fun. And to a degree, I think that’s mostly what matters.

It’s more interesting to smash every aspect of the game together instead of trying to perfect this piece of software. That can’t be said about a regular old frontend app or a critical piece of backend infrastructure.¹ You can have perfectly structured code, but if you can’t move at the pace of the different roles on a team, then the game becomes less fun. The gameplay mechanics, the game feel, and how it looks all contribute far more to a game’s fun-ness far more than a refactoring job.

All in all, fun-ness is a significantly different metric than I’m used to. You can’t really optimize for it; fun-ness is not to be solved as an engineering problem. Fun-ness is a uniquely human attribute that can not only be assigned to games, but to all sorts of human creation. It cannot be ranked by artificial intelligence, or other forms of automation, in the same way that stability can. If humans don’t find something fun, then it’s simply not fun.

From a traditional engineering perspective, it feels like there’s less affordability to cut features that “aren’t achievable.” You can cut game mechanics from a design perspective, but that is not the role of the engineer.

---

There was a talk at this year’s GDC that I missed and wish I had gone to, and it was about the creation of Peak. My key takeaway from my friends who attended it was the term cowboy coding, which is just another way to say: fuck it, we ball.

And I love this attitude for games, in a way that I don’t for critical infrastructure.² Ultimately, for a small team, you’re limited by what you can do. Games are such a complex piece of software, and for a small team, that imposes a lot of limitations. With a big team, you can throw all the resources you have at, say, QA or build engineering, and ensure stabilization that way. With a small team, most of your team needs to be focused on finding the fun. It’s okay if the code suffers a bit as a result.

Of course, there comes a point where it’s good to take a step back and control for code quality. It just can’t come at the expense of fun. Without code quality, there is still a game; Without fun, there is none.