If I do nothing, then nothing will happen
This is a phrase that became my personal motto after GDC 2014. I came back to school because not long ago I was not living the life I wanted. Due to a radical change in lifestyle four years ago, I decided that I’m not going to fuck around anymore by waiting for something to happen, I’m just doing it. The following blog post is very long, but I want to document everything my team and I are doing to make this thing great. Buckle up, there is no TL:DR.
After an amazing weekend of emotional breakdown, life course reevaluation, a metaphysical slap in the face, and recharged self-motivation, I realized we needed some process help with the game. We have done so many iterations of the game without knowing what the game is, but every time we are just going in circles because there’s no clear definition. What we needed for the game is to know what we are trying to do with it and what we want the player to experience. But how?! I started thinking about how I approach design in the broad sense.
All design solves a problem. For example, when I start to design a poster, the first thing I do is establish who the poster is for and what the poster needs to tell the viewer. From there I start to drill downward to get more and more specific details until I find an interesting and informative design.
Monday we decided to have an all hands design meeting. Most of the team was there, and they came prepared to work. Instead of pitching new versions of the complete game, I led everyone in an atomic design process. I asked them to scrap everything we had done up until this point, and we will just focus on what our game is about – the ability gives the player information.
The first panel, where we defined what kinds of things we wanted the ability to reveal. This was just throwing things out and seeing what stuck.
We talked about what kinds of information we wanted to give our player. Everyone called out anything and every kind of information we could give our player. From there, we chose three things – safety, hazards, and action points.
Second panel, in which we detail out what specifically about the three things the ability reveals
We began brainstorming what these three things could mean in game. Each category had about 8-10 items that we were interested in exploring as mechanics. We narrowed those items down into two items per category – Safety – fast lanes and forward launch, Hazard – slow lanes and backward launch, action points – checkpoints and switches (a broad term we are using for anything that involves a separate set of skills besides running and jumping to accomplish).
More drilldown into what our decided mechanics are and the natural progression outward into enemy and level design
From this data it seemed that everyone was on board with the idea of this being a runner. Which was good news because one of the things we didn’t know about the game was what kind of game it was. We then debated about having it be time trial or pressure from behind and it was decided we liked the idea of an enemy chasing the player. Which then spawned a great conversation about levels, checkpoints, and puzzles.
The purpose of this exercise was to get everyone on the same page regarding the game. Prior to that day we had just been tossing out gameplay scenarios without really understanding what we were trying to accomplish with this whole thing. I wanted everyone to walk out of this meeting knowing what we are building and why we are building it, but also to feel like it’s something they would play. Because what’s the point of all of this if we make a game no one wants to play?!
So the game is thus – the player uses the ability to reveal certain things about the level. The level has visible death areas (pits), and non-visible safe and hazardous areas. When the ability is used, the player can see the fast and slow lanes, forward and backward launch, as well as special action points where they will have to perform a specific action. The goal is to reach the end of the level without falling in the pit or being captured/eaten/whatever by the enemy.
To help clarify what all that could possibly mean, I put together a metric table listing out all of the mechanics in a fluff, easy, medium, hard, and impossible difficulties. Tony, James, and I started throwing in ideas as to what those different things might mean. The idea is that we can then take those metics, test them, and eventually shuffle them around to create new and interesting level designs. It’s a super useful tool I learned from Andrew (the Ubisoft guy).
Tuesday we had a couple design meetings regarding the enemy and levels, and we got to work. I talked to Joe and Cory about they game, and they were still unclear as to the game is, which was an indicator to me that more work needed to be done on getting everyone on the same page. Together we came up with a ridiculously wonderful razor – our game is Temple Run with Mario cart powerups and obstacles that are reveled by using Eagle Vision from Assassins Creed. But more than that we needed some kind of visual representation for what that means. So I created a concept screenshot for our game. Initial reactions were that this was very helpful.
Green = fast lane, red = slow lane, black = pit (instadeath), blue = launch forward, orange = launch backward. Purple line represents the ability boarder
After class I went to go talk to our resident production bad ass Amy about how to further motivate our team. She had some very good suggestions that included creating a detailed alpha checklist as a kind of goal for the team to work toward. She said having a concrete goal (beyond “IGF submission deadline) can help rally the team and give us purpose. The other thing she suggested was to create an aesthetic style guide for the team to reference. This is the emotional story behind the game, what the player is supposed to feel while playing, skills they need to play, what the visuals can tell the player, etc. I already had the screenshot concept, so I solicited help from Tina to write the player story and create the new razor and the rest of the stylesheet items.
Brenton set the alpha checklist meeting for Thursday, and we are planning to feature lock the following Tuesday. Feature locking will provide the structure for the race to the end of October. I mentioned to Brenton that we should also choose someone to be the official megaphone of the game and the team so we avoid situations like what happened the Friday before. I nominated Tina, because she is already in the business of talking about our game to everyone, and she is a damn fine presenter.
Thursday rolled around and we hammered out the Alpha checklist. I had one more design change that I wanted to propose before we nailed it all down. I talked with Tony the night before about changing the camera of the game to first person. When I was putting together my alpha wish list, I listed out all of the different animations that we’d need for the IGF submission, and it seemed like a lot. This got me thinking about why we chose the third person camera, which initially was so the player could see the enemy chase them. But why would the player need to see the monster all the time, it should only be when the player is about to die that they should see the monster. Also it would be interesting to be able to convey proximity to the player by not showing the enemy, but instead having it effect the player’s ability to see the safe and unsafe areas. He didn’t hate the idea, and mentioned that it would solve many of the problems that we were currently having with the camera, also first person runners aren’t really a thing.
So we pitched it to the group. There was some pushback, and rightly so, this was a major change and it deserved discussion. Some concerns were that it’s not enough time to prototype, it changes the players relationship to the PC, and that the player may get bored with so little happening on screen. One of my biggest concerns was that it basically took out all of the animation in the game, leaving Kyle with not much to do on the animation front and therefore not much for his portfolio, which is a bummer and needs to be addressed.
Today we are in a good place. Level design is happening quickly, Tony created a mechanic test box so we can play with the different difficulty levels per mechanic, Cory and Joe have a kitbash going, the engineers are working their magic, Kyle designed the main character, the backlog is filling up, and we are kicking trash on the social media front. I am so so proud of my team right now, we were all so discouraged last friday, and we have a complete game a week later. It’s been rough, it’s been aggressive, but I feel like it was the only way to create this game and not disband this team. But I believe in us, and I believe we can make a unique, super fun game, and we are finally underway!