Brainroll Postmortem Part 1: History, Planning & Design
Brainroll Postmortem Part 1: History, Planning & Design
Maybe it is too soon to make a proper postmortem but I still feel like there are enough thoughts and lessons learned in process of making this game that I can write this post. I will go over a brief history of Brainroll’s development history and the challenges I faced both technically and mentally, some reflections on the release and some improvements I could have made in the process as well as what I will do different in the future.
I have not read any other postmortems before so I don’t know if there is any specific format to adhere to, I will just try to talk about things that I found interesting to point out. I will release these posts in several parts starting with just how I got started with the project, then with how I planned and executed the project and finally some notes on the design of the game.
History
I want to start out with a very brief history of how I got started making my own game in my own engine. Ever since I got into software development I did it for my love of games, from the first line of code I wrote I’ve always had games in mind. I first got in contact with programming when I was about 13 years old when my father gave me the idea that I could make games instead of just spending my time playing them. He only have heard about C++ previously and told me that it’s what people use to make games, after some trial and error I managed to go out on the web and download Visual Studio and follow some guides to print out “C++ Rocks!” in the terminal.
Over the following years I really deep dived into programming making some small game prototypes. I never finished any of them but I was playing around and started to kind of get an idea of how to make my way around code. Just the fact that I could read and understand the basics of code made all my education a real breeze to get through.
During my spare time in university I was introduced to handmade hero which is a YouTube series on how to create a game completely from scratch. I consider this a key point in my life because this series fed me what no other course or literature ever could, it explained everything, opened every single black box in programming and honestly by just following along with the 20 first episodes something just clicked for me and then I was able to write my own programs completely from scratch without the analysis paralysis that comes with many modern software development practices. Following along in the series I was inspired to write my own game engine, which I did. I iterated on this game engine a lot and at a certain point I felt like I could make a real game in it. It started with me trying to create a pinball game which I eventually scrapped because the scope got to big so I decided to make something way simpler as my first game in order to be able to follow through and finish the entire project.
So the main goal for the project was to finish it, but other than that I set up some other goals that I had:
Focus on simplicity and manage the scope to not let it grow to big and become overwhelming. The main goal is to actually finish the project.
Don’t be scared of learning things or trying new stuff out.
I wanted control over the project. This means I wanted to use my own tech so that the game will be able to live on my terms and not stop working due to some software update for example.
All non-game specific code should be re-usable for my next project. Graphics, UI System, Audio, etc.
Real production-grade assets to make it look like a good quality indie game.
A very tight budget on total maximum of 1000$ to spend on assets, tools or whatever else I need to finish the project.
Project planning & structure
Before moving onto details about the actual game I want to start with how I usually go about planning and structuring my projects. This is by no means a guide or me telling you what works and what doesn’t but just a walkthrough of how I personally get things done. It is also important to know that this was a solo project from start to finish (except for graphics) so I didn’t have to manage tasks for other people, instead just focus on myself and the project. Some of the things I mention here goes hand in hand with how I approached game design for Brainroll but I will go over that in a separate section.
The initial planning document
Before starting to work on the project I tried to dive deeper to flesh out the idea and brainstorm basically anything surrounding it. For a game project I usually start with the idea itself, it can be a section where I immerse myself a bit by making up a small story but more importantly I try to note down the rules of the game. For Brainroll the rules was the different tiles that the game would support and how they would interact with each other. This doesn’t have to be very serious because the rules will most likely change this over time but it is just to have some sort of guideline so I would know in which direction I am heading. It is also a good way to get the first couple of tasks going which helps if you’re programming because you get an idea of what you need to setup before you can get the most basic of the basic rules going.
I also try to investigate other games in a similar genre to take inspiration and perhaps note things that these games have in common.
Within this document I also touch a bit on the technical and art side of things where I note down ideas for graphical styles and what types of technical challenges that I predict that I will face along the way. This just like the game rules doesn’t have to be set in stone but can help because I can make a very brief plan very far ahead of time of how I want to deal with sounds or textures for example. If I know I want a graphical style that requires high resolution assets then I can have that in mind when programming. A concrete example of this is that I knew that I wanted to have pixel art graphics so I was planning in this document to use a sprite sheet or texture atlas, for convenience I noted down that I wanted to build a system where I only need to load one asset from disk and then I can re-use this several times when rendering things to the screen.
The mistake I did when it comes to this document is that over the course of the project I rarely refered back to my original plan. I basically created this plan and then started working on the project, the initial goals and ideas kind of faded away over time and as I came up with new ideas for the project. This is something I need to keep more track of in the future, perhaps instead of just making an initial plan it can become a more living document but deffinately not thrown away like it was this time.
Task management
During any project I like to keep a living list of tasks, ideas or questions that needs answers. I don’t have any good task management software that I like, I’ve tried using task boards like trello but what has worked best for me is to keep all of the things I need to do close to the software itself. For me this has been GitHub issues, it happens to be GitHub just because that is what I used for this project but other git solutions tend to have something similar.
Anyway, why issues in Github? First of all it is dead simple, all you really have is markdown text and labels and thats it. But second is that it lives together with the code. This means that I can control my list of tasks by just using git like I do with my everyday use. How I structure this is that I have a set of labels that I use to identify what each task is about and what priority it has.
This allow me to filter things depending on what is important or what mood I am in. Maybe sometimes I am not in the mood of programming than I can solve the issues marked as questions or documentation.
To make this work I let documents live inside my game’s repository alongside with the code and then when I work on a new task I simply create a new branch with the issue number as well as some identifier. For example if I were to implement achievements in Brainroll I would open a new branch called 317-achievements where I work on this task untill it is finished, when it is I just create a new pull request into the master branch where I can code review my own code as well as link the issue to the pull request.
This may sound like a lot of overhead but in most cases it is just creating a pull request and typing “resolves #317” and Github just links the issue to the pull request automatically as well as closes the issue when the pull request is merged. I can agree that this gets a bit noisy but with this I am only using a single system for my code and tasks which I think is a big win. The markdown inside Github issues is also very flexible where you can paste images or links to make them very descriptive.
Daily lists
The final but probably most important part of planning and executing the project is my daily lists that I’ve kept almost everyday for the entire span of the project lifetime. This is actually something that I’ve done long before I started programming and it has been the only way for me to be productive and stay on track for long periods of time. After the release of Brainroll I have abandoned this list for a couple of weeks and I can say I have not been that productive since.
So my daily lists are just like what it sounds like, a list that I build up once per day. It consists of around 5 points, enough for me to be able to do them all in a single day. It is important that these tasks are pretty small because I don’t want to be overwhelmed and it is more important that I complete all the tasks on the list rather than getting a lot of work done because we don’t want to burn out.
I just flipped a few pages in my notebook and here is an example for one of my days:
Setup NAS
Backup assets and videos to NAS.
Create 2-3 levels.
Remove pointer tool in editor.
Make release script save .pdb files.
These are not that difficult to do and can easily be done in maybe 1-2 hours of focused work, perhaps even less. Important however is to keep it short and sweet, after I complete all the 5 points I stop working and do other things instead.
For me it has also been very important that these lists are written with pen and paper because for some reason I have a much easier time to remember what I’ve written down if I physically do it with a pen instead of writing it on my phone or something. This helps me stay focused because my daily tasks are fresh in my head during the entire day. Once I finish a task I draw a line over it, this is also important because I physically mark one task as finished and I can see how my list grows smaller. I usually prepare this list before I go to bed the day before so I also have the chance to get ideas before falling asleep on how to solve them, thinking about it now maybe that is why I have trouble falling asleep.
While this approach is great for getting things done everyday it is also the best approach for scope creep. When making your new list it is super easy to add items that you don’t really need to do and I did end up doing this a lot. I think working like this is something I really need to do in order to stay productive but I need to develop a way where the daily tasks are decided based on something else, for example if I were to make the initial planning document a more living document I could build my daily list based on that together with the technical list of tasks in Github. Having the freedom to set up my workday based on how I feel was very important and if I am to keep making games I need to be able to continue doing this but at the same time it needs to be structured.
Splitting the project into parts
So I didn’t create a big list of things to do at day one of the project, instead the list of things to complete was built over time. How I did this was that I just started with the known things I needed to do, then with this I planned my releases in sprints basically. Each time I complete a set of tasks I would end up with a shippable working (but not complete) version of the game.
At first when I hade my initial plan completed I started with creating the smallest possible prototype that showcase the game’s main idea. After this most of the decisions of what to do and how to do them was take ad-hoc. Part of the reasoning behind this was that I was unsure of what I needed to do next because I didn’t plan too far ahead instead I did mostly keep my list of tasks, my daily plan and just the initial document I made. So when planning a new sprint what I did was an evaluation of where the game was currently and in which direction I wanted to take it next. In addition to this many decisions was also based on what I felt like working on.
In retrospect I would probably not want to do it this way in the future. I don’t think the tech suffered a lot from this but the game’s design and how long time it took to arrive at the currently released version of the game did take a big hit from this. Let’s take the initial prototype as an example, doing this there is no clear defitiniton of when the prototype is completed. This problem persistend for every single version of the game. I think this might be valuable at the last few sprints of a project where the project is only being adjusted based on player feedback but not like how I did it for the entire lifespan of the project.
For my next project I think I will try to keep what I used as an initial plan document for this game to be something more alive, if I change game direction I need to verify what other parts of the game has to change moving forward and plan accordingly, something I did not do with Brainroll. I want to have a clean plan ahead all the time, It is not super important for me that I am the most optimal everyday I work but that I make meaninful progress towards my intended goals and don’t allow myself to guess or make ad-hoc or project altering decisions on a daily basis.
Design
Shifting focus into how the design of the game took place I started with a simple idea that I wanted to make a game that was grid-based. Since one of the goals was to keep things simple I wanted to build off a core which I was very familiar with in programming which was to keep a simple array of tiles for the game state and mutate it when the player moves.
Looking around for ideas I found a game called Yopaz Icestar I don’t recall why this particular game caught my eye but after buying and playing it I thought that this is a simple enough game for me to make so I started to basically just copy ideas from this game and make my own version of it. Building the base game was very simple and along with the mechanics I wanted I was able to finish the core in about one month.
After sending this version of the game to some friends I got the feedback that the game was good and fun. When I personally played the game I didn’t have that much fun though and this prompted me to send a copy to someone outside of my friend circle and this proved to be very valuable because I got very different feedback compared to my group of friends. Ignoring all the technical feedback I will talk about some of the interesting game design feedback I received and my thoughts about it.
One of the main comments that I received from not only one person was that the levels were very trial and error and its not really a puzzle to solve as you can just pretty much brute force most levels. The basis of this feedback was that in the original game there was never any softlocks or game state that the player had to worry about. Every move you made was technically progression in the level and due to my choice of having a main mechanic where the player slides on ice the moves became more about trying to visually predict where you would end up in order to solve the level rather than think about what your next move should be. Combine this with close to no game state inside a level, the game idea was very and not interactive enough for a game.
This triggered me to reconstruct the entire game idea to make the game more into a Sokoban puzzle game but on ice which it is today. A big takeaway that I learned from from this was that I actually had an almost finished game but I then took that finished game and turned it into a completely different type of game. Maybe that’s normal in game development but I still feel like the old version could have had its own place somewhere as a standalone title, maybe as a free demo or something.
The puzzle version of Brainroll that I ended up with I think is better in almost every way than the old version but I don’t really like to compare them because the goal of the games were completely different. This is something important that I will take with me when developing future projects that don’t throw away stuff when you have to pivot between game ideas because the old stuff you had may have a place somewhere else, since games are so difficult and expensive to make you really should try to salvage every small piece you create.
When designing the puzzles in Brainroll I had a lot of trouble because it turns out that puzzles are really hard to make, especially if you want to make good puzzles. I did outline in another post how I went about creating the puzzles in Brainroll but I will take some time and expand further upon it.
Before I started making a single puzzle in Brainroll I wrote down all the mechanics on a piece of paper, then I alongside every mechanic wrote down how they relate to eachother. What I mean by this is for example:
The brain blocks in Brainroll has the mechanic of sticking to you and other brain blocks, what happens is that out of this one mechanic you have several gameplay mechanics that gets invented:
You can have the player arrange brain blocks in specific patterns.
You can have the player position a brain block at specific tiles.
Brain blocks can be used as a movable wall that you bring with you acting as an extra padding.
Finally if you use them as padding they offer the player the opportunity to sling themselves around a corner.
I’ve highlighted some words in bold. This became my level designing language. When creating a new level I tried to think of of a small story or phrase explaining what the goal is for the player, so for example I could have written down “I want the player to arrange blocks in the shape of a minus sign and then use them as padding to sling around a corner”. Then I would start making a level where you have to do those things in order to solve it.
I can’t talk much about how effective this strategy was because I am so new in puzzle design I simply don’t know a better way, I just did something that made sense to me. Something I can vouch for is that this technique is very effective when you’re very short on time because it is makes it so simple to note down ideas for new levels during the day when you don’t really have time to work on the game. Then when you’re sitting down and making new levels it is not so important that every single level turns out great since you’ll build up such a big backlog of ideas you can just throw it away and try the next one.
The final game when every level was complete ended up being pretty mixed in terms of puzzle quality, some levels were good and some bad. I think like with all games, some people enjoyed it and some people hated it. I have trouble judging the game myself so I just listen to the small control group of players I tried to appeal to and most of them enjoyed and this I found to be a great strategy for feedback when testing the game, find testers who loves the type of games that you’re making. Something I have not analyzed that much myself is how much the old version of the game relates to the negative feelings I have towards some of the puzzles in the final game.
Something I’ve learned is that puzzle games are incredibly difficult to make. I think that if I want to become good at making puzzle games I need to spend more time playing other puzzle games, not only digital ones but paper ones as well. I have not been doing anything like that and I believe it plays a big part in how many of the puzzles in Brainroll turned out. For my next project I will deffinately spend more time studying what I need to study to appeal more to the audience of the genre I’m building a game for.
If you like what you’ve read, please consider subscribing. Thank you for reading.
I have also released my game Brainroll on Steam, be sure to check it out!