A reflection on what happened when conditions forced me to make drastic decisions for my game and what I did to come out of it with a game I'm proud of.
Originally published on Zhiming's blog.
I just realised how dramatic that title sounds. I want to preface this by saying that this post isn't about some epic several year long struggle to emerge victorious against all odds. Although it is about what happened when conditions forced me to make drastic decisions for my game and what I did to come out of it with a game I'm proud of. First I'll need to establish some quick context.
I recently started my internship as a game developer at No Moss Co at the start of May 2017. It was a unique internship in that I was given the responsibility to lead the development of a game from scratch myself. I spent the last 3 years practising the craft of game development and despite having not shipped anything myself I was confident that I would be able to deliver a decent game. Now the tricky part was that the games team at No Moss were aiming to submit their games for the PAX Melbourne 2017 Indie Showcase competition, the deadline for submissions being on July 9th. With 3 months to get a game into beta the pressure was on. I jumped straight to work and Project Messenger was born. (You can still play the early prototype).
Prototype for Project Messenger
I was a month and a half into development when I realized the game was over scoped, way more complex than engaging and ultimately it evolved into something so convoluted that I just did not have the time to fix it. There were a string of reasons why the game was not working but I would say the root of the problems came from the core mechanics. It was essentially a math puzzle game with 3-4 ways of manipulating numbers. It was just way too complex compared to how much depth or engagement the mechanics created. My mistake was that I didn't detect this early enough in development. It was caused by a combination of biased playtesting (i.e. with myself or 'veteran' playtesters) or leaving it to "they just need a tutorial" or "they're an outlier/not my target audience".
By the time I came to this conclusion I had a month and a half to get my game to beta. Yes, the broken one.
There were 3 things I did which impacted the pivot in development the most.
Simplify
Brainstorm and bounce
Development mapping
Ah, simplify. One of those elusive treasure goblins of game design (at least for me). I often struggle with simplifying because I easily get caught up in development and allow my perspective of what is simple get warped (as mentioned earlier). So I had to purposely take a step back and meticulously break my game down into its atomic parts; even if this broke whatever dynamic I had before. This left me with the mechanic of adding numbers, 1 of the 4 ways players could manipulate numbers in my old game. It was hard to see at that time where the game would go after breaking it down too much. Looking back now I should have had more faith in simplifying the game because it definitely put me on the right track.
It's clearer now that the purpose of simplifying the game aligns with the ideas behind the System, Story, Mental model framework. Credit for the framework goes to Thomas Grip of Frictional Games whose blog post was where I learnt about it. The gist of the idea is that a game and the experience it creates can be divided into 3 sections; the System, the Story and the Mental model. The game's mechanics lie in the system section. How the mechanics are conveyed to the player, e.g. graphically or aurally, make up part of the story section. And the story then drives the building of the player's mental model while playing the game. The entire game is experienced within the confines of the player's mental model of the game.
The entire game.
That's it. That's the core of why Project Messenger did not work. I built the game with the system in mind. I kept working on the system without noticing that no matter what I did the story section of the game was either a mess or missing entirely. You can easily see when using the lens of the SSM framework that there was very little I could have done to improve the game because of all that was lacking in the story section. Simply put; no story section, no mental model, no game experience. With a simpler core mechanic, I could begin building up the lacking game experience.
When I first started designing Project Messenger I spent hours and hours brainstorming. I wrote ideas in a book, on a Google doc, even on white boards. My mistake was that, during the first week, I would end the day with tons of ideas and nothing else. No execution, only ideas in one medium or another. I was lucky to run across this article about taking ideas from game idea to game feature. There was one part in the article which I applied when simplifying the game, which was step 3: Brainstorming. The thing I found particularly useful was giving myself a time limit or time boxing my brainstorming.
What I liked about time boxing was that you are forced to stop, take a step back and assess everything. I borrowed from the Pomodoro technique and gave myself 25 minutes to brainstorm. I wrote down all the ideas and possibilities (in this case I made mind maps using pencil and paper) I could think of. Once 25 minutes was up I could either pick an idea I liked start working on it or go back to research and questioning mechanics/features for the game (as detailed in steps 1 and 2 in the article).
Research and asking questions was something I neglected when I first started development. I felt like taking a step back from brainstorming and spending time to fill in any gaps which might have resulted in the unsuccessful brainstorm was a lot more effective. Additionally, because I took the time to review ideas in between every brainstorm I quickly got my hands on a paper prototype which I could get feedback from. Which leads me to the other point, bouncing ideas.
One of the core mechanics currently in the game came from a playtest session I had with a friend. I was testing one of the paper prototypes with him and it naturally led to an impromptu brainstorm. After bouncing ideas back and forth he brought up an idea of tiles being presented in different layouts like in tetris. This idea has become a core part of the game. This was only one of many occasions where bouncing ideas with people helped me out of a creative rut and moving forward again. That was the other half of what made this brainstorming technique so impactful; the ability to rapidly create a prototype and use it as a platform to bounce ideas with other people.
The inception of ideas come from the individual mind but when an idea slows down it is important to bring the idea into reality and let it grow amidst the minds of others.
Every studio, developer and their grandma has their own way to organizing their development. I thought I had a pretty good grasp at keeping my development work organized. In past projects I could usually see the bigger picture, understand what needed to be done and how far away the project is from completion.
Looking back now, what I had was not good organization skills but rather the minimum understanding anyone working on a project should have. As the deadline for the PAX Melbourne indie submission grew closer, the management gurus at No Moss jumped in to give the games team a few tips on how to organize and manage our development. A workshop and some consultations later, a method which I'm going to call development mapping was taught to me. I'm planning on dedicating an entire blog post to this concept but in a nutshell it borrows heavily from an agile method known as User story mapping and re-appropriates it for game development.
It involves splitting your game into categories (i.e. mechanics, graphics, audio, feedback), filling out these categories with all the features you want in your complete game, then ranking them from most important category and most important feature. Here's an example of a development map I created:
Development Map done in Google sheets
The categories were denoted by the columns and each feature sat in rows under the category they belonged to. Priority from highest to lowest is denoted from left to right and top to bottom. In my example, a green highlight was for completed features and orange highlights were features I'm currently working on. I found that the main benefit of a development map was that it gives you vision of your short-term and long-term tasks at the same time.
With your entire game broken down into tasks this way one can work out the most pressing task by generally looking at the top left of the map and also tell how the task fits into the bigger picture just by comparing it to the rest of the map. As development progresses and changes occur you can review, add, remove and modify tasks/categories as you see fit.
I used the development map to help me facilitate the 80/20 rule into my game's development. I prioritized my tasks according to what would create the most value for the game for the least amount of work. To give a simple example; I prioritized the mechanics category first as the root of the game experience came from its mechanics. Next, under the mechanics column, I ranked it such that the features I absolutely need to create my first playable prototype was on top and highlighted to track it as the tasks I'm currently working on. Boom, I just organized my first iteration loop. This can be repeated after each iteration by updating the map according to the feedback gathered and focusing on the high priority tasks.
This method helped me stay on track and make the most out of every hour in the count down towards the deadline.
Monster Kitchen PAX Melbourne 2017 Indie Showcase submission
The result of all this gave rise to my current project Monster Kitchen. I took it from a game idea to something I would proudly present in 4 weeks. I still have plans for Monster Kitchen before releasing it. It's lacking in content and I intend to use what I currently have as a base game to expand on. I'm working towards a release sometime in October 2017.
It's now past the PAX Melbourne indie showcase deadline and things have been a bit less hectic since the submission (letting me do things like write blog posts). These are the lessons which emerged from the pressure of the past few months. I'll definitely hold them close as I continue on my game development journey. Writing this post has been a sort of 'mid-mortem' for me, helping me internalize my experiences. If it helps any developer out there learn something from my experience then that'll be pretty neat too.
Read more about:
BlogsYou May Also Like
