Asterism

Full Moon
Dev Blog #04

13 July 2022

Production and project organisation

It's now three months since I began development on Asterism, and I've been thinking a lot about production over the last week or two. This is partly because I've now had some amount of time to evaluate if the production timelines and methods I planned at the start of the project are working for me. It's also come up in conversations I've had with a few people I am currently mentoring about their own projects, as well as with my production mentor for Asterism, so I've been in an interesting position of both giving and receiving advice on the subject alongside trying to take a step back and look at my own process. Lastly, I've experienced myself over-scoping projects or taking inefficient development routes enough to know that it's very stressful and I want to avoid those mistakes in future.

This is the first of my own projects that I've taken a structured approach to production, though I've been involved in a number of projects during freelance work and employed work that had a dedicated producer or a solid production plan. It's been interesting seeing different approaches, and has given me a good sense of which methods I respond to best. So below I'll be sharing the approach that I'm taking, and why. I might also do a future blog post at the end of the project to compare my experience then to now. Maybe I'll find that none of these methods work the way I expected them to, only time and admin will tell!

Initial Decisions

At the start of this project there were two process goals I set out for myself, which were:

1. Make the development process a positive experience.
2. Avoid scope-creep.

These goals were mainly driven by previous experiences, both positive and negative. I thought about other projects I'd been involved in - what kept me motivated, happy and on track, and what I would like to have changed to make development smoother.

1. Make the Development Process a Positive Experience

With Asterism, I had a couple of years of vaguely thinking about the project from time to time, writing music, and doing some mechanics experiments before I decided to take a more structured approach. All I really knew at that point was that I wanted to make an 'interactive music album' that explored some personal topics in a space-themed environment. I had a Google Jamboard that I put some initial ideas down on, including how the songs on the album might map over to planets in the solar system:



The blue wavy line represents something like emotional intensity, or maybe happiness / sadness. I also had some mood boards for the songs / planets which helped me to think about the tone. What was important for me here is that I was able to map out the extent of the game very visually (which blends into goal number 2) and keep the space theme at the forefront of my thoughts. I started using Miro some time after this and decided to make my notes on there space-themed too.



On this section of the Miro board "Asterism: planning" is a star, orbited by five planets - "Game", "Music", "Narrative", "Process", and "Funding". Each planet has lots of satellites which go into more detail about questions I want to answer in order to define what the game is, the development process, how to approach funding etc.

If I zoom into the 'Process' section on that Miro screenshot, you can see the questions I asked myself at the start of the project when I was thinking about this first goal.



'Process' has three concentric orbits around it containing satellite questions. The broadest questions are in the closest orbit, and the outer orbits contain off-shoots of these or more specific questions. So there's questions like "What do I want to feel during the experience", which leads out to "How will I acheive this?", and also "Keep the end goal in mind. What is the end goal (of the project)", which I felt were important to define. If I zoom further into this one in particular, you'll see I'm not really talking about the end goal of the game, but more the general experience I personally want from the development.



Something else I wanted to make more enjoyable, and effective, was my approach to bug-fixing. I have a tendency to get frustrated easily with debugging, and can rush without working through the problem logically, which ends up taking longer. I can also find it difficult to work through bugs on my own. A friend at university who studied Computer Science told me about a method called rubber duck debugging, which uses the idea that when explaining a problem to someone else you are forced to work through it logically in order to communicate it and are therefore likely to identify a solution in the process. This method always stuck with me, and I wanted to recreate it recently in a way that gave me a structure to follow whenever I felt stuck. When I came across this incredible notebook, I decided that instead of a rubber duck I would have a pink fluffy unicorn cat to assist me.



On the first page I wrote down a series of questions that would guide me through articulating and identifying the problem, and a second set of instructions for working through solutions. On the next page you can see my first attempt at using this system.



It worked really well and made the whole process a *lot* less stressful! However, for some reason I did it once and then put the notebook away for two years until the other day when it came up in conversation.



Why did I stop using this method that worked so well for me? Who knows. Brains are complex. The important thing is that I picked it up again the other day and the method still worked, so I'm going to try very hard to keep using it!

I try to make other aspects of digital organisation playful too - here are some cases I made for my two backup hard drives and the project hard drive I use for Asterism. I feel like if something is fun to look at or to use then I'm going to enjoy doing it more. If I enjoy it then I'll look forward to it and am more likely to do it regularly. Backing up files feels like a nicer task when I get to look at these silly monster faces.

2. Avoid Scope-Creep

In any game development that doesn't have a very rigid specification to begin with, new features will be added as the development progresses. In my experience, scope-creep tends to happen if these features are more ambitious than the time, money or skill resources of the developer allows. It can also happen when you get new ideas you are excited about and start implementing them before you've finished designing other parts of the game.

As an example, the first game I made by myself was a text-based adventure game with monster mechanics heavily inspired by Pokémon. I began by writing a lore extending back thousands of years, and progressed by designing multiple evolution, type-advantage, battle, side-quest, main-quest, and narrative systems. I finished 18 months later with 'chapter 1' published to my itch page and decided never to return to it based on how long it was taking. You can watch me talking about this while endless pages of my project notes scroll behind me here:



In the talk I gave at A MAZE I used it as an example of how 'small tools' such as Bitsy helped me learn to scope better. I also think that even when using larger tools, such as Unity, there are similar approaches that can help with scope management, they're just not built into the tool itself. Setting yourself constraints about what the game actually is and being realistic about your resources can save you a lot of stress later down the line. If you haven't made many games before it can be difficult to estimate how long development will take you, so in general I would always hugely overestimate. Also, the more games you make the easier it becomes to estimate how long making games will take you, so aiming to make lots of small games has a two-fold positive effect on scope management!

When planning Asterism, in order to set constraints on what the game actually is I tried to map out a full playthrough of the game. For this project it was easiest for me to do that visually (see Google Jamboard screenshot above), but I think this would work in a similar way to writing a rough outline of a novel, for example. From there I was able to start thinking about the types of mechanics, narrative, art, etc. in each area of the game. There's a term minimum viable product, which I think of as the smallest version of the thing that you're making that still showcases the core experience. My plan for the first section of this project is to get to that point as quickly as possible and have a full playthrough of the game that's extremely rough and only features mechanics, art, and music that are necessary to make it functional. By doing that I'll be able to have a really good sense of the game as a whole and how each scene and idea within it impact the others. I'll also be able to identify any major design issues early on, and avoid the temptation to add lots of new ideas and polish to one small area of the game that could end up needing to be changed later down the line anyway.

With this plan in mind, here's what my overall production timeline estimate looked like:



Though in reality so far it's looked like this:



The reality actually isn't far off, but I did underestimate creating this initial draft of the game - even though I thought I was overestimating! I'll keep updating it and it will be interesting to see how this looks at the end of the project. Overall I think it's more important to keep track of where I am in the project and shift tasks around as I need to. If at some point it feels like the whole project is slipping behind too much then I'll take some time to re-evaluate the scope and may have to cut some features.

During this project I have also been receiving production mentorship from Malath Abbas, an extremely talented designer and creative producer who I know through Biome Collective. Having someone to check in with regularly and offer guidance on production has been super helpful and has motivated me to be more organised and gain new perspectives on development and production. I would definitely recommend seeking mentorship where possible for areas you are less experienced in, even a one-off conversation can be extremely valuable!

I wanted to talk next about task management and progress tracking. A tool that's helped me a lot so far with this is Trello. The most common way I've seen it used is like a Kanban board, with columns for 'to-do', 'in progress', 'done' etc. This is pretty useful in a team environment as you can assign tasks to different team members and easily get a snapshot of what tasks are being worked on or are being blocked etc., but on solo projects it's never really worked for me. Instead, I used my production timeline as a starting point and created a column for every month over the estimated duration of the project. Then I began by filling in these really broad tasks as 'cards' in Trello, such as 'Pre-production' and 'Production consultation' in April 2022. After that I was able to break down the larger tasks into smaller ones. Generally I've only done this for a couple of months ahead at a time, and I'll shift things around and add new sub-tasks every month. Instead of having a 'done' board I use the navy coloured label to indicate a task is complete. That way it's easier to get an overview of the progress I've made so far and what still needs doing each month. With a Kanban-style Trello board I found it easy lose sight of the bigger picture without having some other kind of production timeline alongside it.



The last thing I wanted to mention regarding scope-management and staying on track is stand-up meetings. If organised well, these can be extremely useful in team environments, whether or not you're physically standing or sitting at opposite ends of a video call, for you to understand where the rest of the team is at and to focus on the tasks you want to work on that day. To incorporate this into Asterism I basically do a solo-stand-up. I don't do this every day, just if I feel like I'm unfocused and have too many tasks floating around my head. I made a Google Slides template that allows me to write what I did yesterday and what I will do today.



I've also embedded it in Miro so it's there alongside everything else, I like being able to see everything all in one place and give all the zones spacey names.



After all, the development, production and game are just different sides of the same three-sided coin. In fact, it's probably more like an infinite-sided shape with as many categorisations as you can think of, sub-categories and sub-categories until it becomes meaningless and they all blend into one super smooth sphere that is whatever experience you're creating.

That seems like a good place to end this blog post, thanks for reading :)

Previous Full Moon Dev Blog

Next Full Moon Dev Blog

Sign up to my newsletter to get updates about the project!