In 2019 I made a collection of 12 games that I released all at once early in 2020. I learned a lot during the process of making the games and I'd like to share some of what I learned along the way with folks.

What did I actually do? And why?

For the last few years I've participated in the Global Game Jam that runs every year. It's an event I love doing and it's always been a fantastic atmosphere at the sites. One thing I often struggled with though during the GGJ is scope. My game dev work has mostly been on large projects (multiple years, large teams, systems heavy etc). I also really love designing, building and playing systems heavy and narrative heavy games. That doesn't work out so well in a game jam with a very constrained amount of time, or for reliably delivering on solo dev.

After the last GGJ I was talking about this with one of the team and they suggested setting myself the challenge of making a bunch of small games which is how this all began. The overall goal was to get better at scoping, to learn a bunch of new things, and to have fun along the way. I also settled on some rules for myself, namely:

I was happy that the rules provided the right mix between keeping things focussed while allowing enough freedom to produce something that felt substantial. 20 hrs felt achievable providing I focussed largely on a single mechanic or system as the lynchpin for the game and providing I planned well. 

What tools did I use for the projects?

Due to the short time constraints I largely stuck with tools that I have used extensively and was confident would save time, or a least not hinder things.

What did I learn from it?

In terms of what I learned from the series of projects I want to focus mostly on areas that are transferable to other projects rather than on specific technical systems or solutions.

Scoping the planning and production along with the project

As someone who has worked in games for a while and also taught game development I've used a lot of tools for planning a project and managing the production. I'm also someone who has really struggled with finding planning & production tools that feel like they work well for when I'm doing a game jam or small project. I have very little patience for a tool or process that is cumbersome. As soon as it feels like it's slowing me down and/or not adding value I will throw it away and look for an alternative or build my own solution.

That hasn't often been a great approach though. I can burn a lot of time making my own solution and it can easily be no better than what I already had. And if I don't use any solution, or don't use an effective one, then that gets in the road of making the project to the level of quality that I would want to. With the goals here of delivering 12 projects, releasing them all at once, and being finished in a year I had to use something.

For the first and second projects ... I didn't. I used Toggl to keep track of my total time but that was it. Nothing in terms of managing tasks or times or even a written down plan of what the game would be. To all producers reading this ... I'm sorry and I learned my lesson! I got lucky and the first game it worked out. I delivered a game I was happy with and the development went quite smoothly. I ... very foolishly, didn't recognise the level of luck that was involved there and did the same on the second game ... it did not go well.

I burned roughly 25% of the time on the second game designing, implementing and debugging a moderately complex dialogue system. It was data driven, it had state, it had items that could be displayed based on the state, it could prevent repetition of options and it worked perfectly. It did everything that I had coded it to do. I got all the data setup within it, everything was perfect. Then I ran it ... and the conversation flow wasn't happening like I expected. I spent hours stepping through the logic ... checking every conversation ... there weren't any bugs.

It was only after multiple hours that I realised what I had built did not have the majority of the features I needed. I didn't have time to do it properly (ie. actually design it this time) so it ended up having what hacks I could do to make it roughly work and the game as a result suffered. This was a game that hinged on the conversations feeling right and my beautiful, data driven and bug free system was not able to deliver on it. If I'd spent even 30 mins planning out the features and the tech that all could have been avoided.

I did learn from this though and the rule I set going forward was I need to plan things out on paper. So task lists with estimated times went on an A4 page (if it needed more pages or another column the scope was too large). Periodically, or if a task took much less (or much more) time than expected, I would redo the task list and estimated times. I would also do level layouts and sketches of key elements within the game to act as a visual reference. That helped substantially with all of the future games and felt of a scale that it was doable within a game jam or very small project. I'm still not sure what I'll use for projects slightly larger than that, likely I would take the overhead hit and use a digital system.

Key Lessons

Recognising when an idea isn't working

When I'm developing the idea for a project I always aim to be able to picture the game in my head and to be able to playthrough it. I try and visualise what the player would be seeing, how they're interacting with the world and how that looks from moment to moment.

That doesn't always happen though, sometimes I just can't picture a version of it that is interesting. Other times the picture of it keeps shifting and never settling. In the past what I've often one is push through it and make the game anyway and hope as I make more of it that it will become clear. If you've worked on any creative projects you're likely right now either shaking your head or despairingly saying "noooooooo" ... and rightly so. For me at least that approach has never worked out, the games always end up being something that misses the mark I was going for and end up being frustrating to work on.

I was lucky with this set of games that I only hit into the issue with one game. That game, Resist!, was frustrating every step of the way through development. I let myself lock in on the mechanic I wanted which was the player destroying propaganda and that causing the community to rise up against oppression. The mechanic was interesting but I could never find a setting or an expression of the mechanic that I was happy with.

I considered everything from a futuristic version with a floating city hovering over an oppressed undercity to a fantasy setting. I considered having AI characters that would hunt down anyone attacking the propaganda. I considered a lot of options and none of them created a compelling picture in my head. Unfortunately, instead of recognising that as a problem I pushed ahead and the result was a game that didn't hit the mark. It didn't convey a point with any impact and it didn't have interesting gameplay or setting.

What I should have done, and what became a rule for me on the later games, was to get external input and make changes. With all of the later games I made a point of actually talking about the design, and design challenges, early on with friends. Getting that external input, even just articulating the idea to another person, was immensely helpful.

Key Lessons

Driving simple systems with data

As I mentioned early on, I love designing, building and playing games with systems in them. Inevitably, that meant I was going to tend toward building games in the series that would be systems based. In the past I have often tended to over engineer those systems. Making ones that are too generic (without the use cases to back it up) or that have such complex data they are unusable without an editor and specialised debug tools.

I knew that if I fell into that trap on these projects it would burn a lot of time with likely nothing to show for it. To try and avoid that trap I set some constraints to help:

Ultimately, what I went with using was sets of scriptable objects. In rare cases a scriptable object would refer to one or two others but never more than that. The depth of the data structures was also kept to 1-2 layers in all cases. That approach worked well and meant it was fast to have something up and running and also fast to iterate on and improve it.

The approach would also, for the most part, work on larger scale projects as well. On a larger project I would retain the constraints of it being fast to setup and iterate on the data. I would also still have constraints, albeit larger ones, on the depth of the data structures. The major change would be to not only allow for custom tools for editing the data but ensuring that they are given dedicated time to develop robust and fast tools that help the team work better.

Key Lessons

Properly evaluating new technologies

I've been using Unity for several years now and something I've been guilty of at times is not properly evaluating new tools. And while it's absolutely important to make informed decisions about new tools I do err on the side of sticking with what I know. That absolutely manifested on the majority of the games I made in the set and across a few different areas.

The third game in the series (What happened to Survey Team 4?) had a day/night cycle as a crucial element of it. I spent a substantial proportion of the time developing a data driven system that could adjust multiple lights (angle, intensity and colour) as well as the ambient lighting and fog to create a day/night cycle that worked well. It was just missing one thing ... a changing skybox. That I didn't have an immediate solution for, it wasn't something that I had done previously.

So I researched, not because it was the smart move but because I had to, and I found a great solution. That great solution ... it was an asset that did changing skyboxes, weather and managed the day/night cycle far far better than my solution (easier to configure, had excellent defaults and more options for tuning). I ended up removing the majority of the system I made for the day/night cycle because it was now redundant. If I had recognised that the skybox was an unknown for me and researched it first I would have saved myself 1-2 hrs which on a 24 hr project is substantial.

I mostly, but not fully, learnt my lesson on properly researching at that point. Which meant I had new mistakes to make. Quite a few of the games, in particular the latter games, needed to blend between different cameras or to have a specific sequence of events playout. In particular in Fragments the end sequence had the player interact with a giant artifact. The artifact would move in response to this, it's material and lighting would change and a sequence would play out where it launched upwards and the player camera would follow it.

I manually set that up ... mostly in code. I coded lerps for the lighting and the movement, kicked off audio at different times, manually coded logic to override the player controller to look at the artifact. It was honestly a mess. It took a long time (over an hour) to setup and adjust it to the point it worked tolerably, not well, just tolerably. The worst part? I knew Cinemachine and Timeline existed and what they could do. I had never used them before but I'd seen them used. Because I never tried them though I didn't even consider using them.

By the time I came back to polishing fragments I had used both Cinemachine and Timeline. That was due to having projects (Encore and A Wizard's Life) that would have been enough of a nightmare to do manually that it forced me to consider other options. During polish I switched the end sequence over to Cinemachine and Timeline. In less time (20-30 minutes) I put together an end sequence that was better than the manual one and lined up with what my vision was for it. The only bit of code it used was to make the roof explode out. For me the big takeaway from this was to always make sure I assess what technologies I'm using for solutions and make sure they are the right one. When new tools come out, I also want to invest the time in making a quick demo scene with them so I know what they can do.

Key Lessons

Being kind to myself

Working on any project is going to have its good and its bad times. Development doesn't happen in a vacuum and it's going to be impacted on what is happening in the lives of the people working on it as well as the project itself. During the development of these games I was also working full time so these games needed to fit in around a full time job and everything else.

There was also a tendency to put a lot of pressure on myself. Taking on creating twelve games, with tight constraints and wanting to do them in a short period was a lot. I wanted the games to connect with people and for people to enjoy playing them. I also wanted to do different things in the games to what I'd done before. I wanted to have some games with a story that would hit hard and others where I'd ask the player to quite literally do nothing. That all created a lot of pressure to be working on the games.

That pressure ran up against the reality though that I'm human and had a fulltime job that needed to take priority. I was lucky that I really enjoy my job but as I tell my students: it's easiest to burn out working on the things you love. There were days, many days, where I would be exhausted to the point of falling asleep on the bus on the way home (apologies to any fellow passengers if I snored). Trying to work on the projects at those times was tough. Creative work isn't something you can grind out through brute force. Coming up with good solutions, the kinds of solutions that are efficient and deliver a great player experience, really doesn't happen when you're tired. It took a while for me to fully recognise and appreciate that and to work out a good approach to managing it.

What I settled on by the end was firstly setting time limits on the blocks of work I'd do. I wouldn't sit down and intend to do 4 hrs. I'd do 1-2 hr blocks and then take a short break. If I felt I could do another set of work after the break then I would. I'd also start out the blocks of work by doing smaller tasks. Ones that didn't demand creative solutions and that were solving familiar problems. I'd use how that went as a gauge to see if I was in the headspace to tackle larger tasks. If I was then I would move on to the bigger areas. If not then I'd take a break till later in the day or the next day. The key there was making an attempt and then giving myself permission to rest.

Key Lessons

Wrapping up

I learned a lot during the making of these games. Along with the lessons above there were a lot of new tools and systems that I dived into. By the end of the series I reached a point where I could feel fairly confident in knowing what I could deliver in the timeframe and to what quality. I made a lot of mistakes along the way but more importantly learned how to recognise them next time round and avoid them (so I can make new and more interesting mistakes!).

I don't think I'd ever set the same goal again of making 12 games in a year but I'm very glad I did. If you want to check out the games the full collection of them is available here.