The team speeds forward to our inevitable meeting with the alpha date at the beginning of October, and we couldn’t be more excited. In fact, we’re moving right along – the game is officially feature locked as of Tuesday the 9th. We leveled up!
That might seem a little early, considering our IGF submission deadline is October 31st, but we really want time to take the core of our game and make it shine. Last week, we tackled the big design questions that needed to be answered. Now that we have feature lock, we know that our mechanics are going to remain (relatively) unchanged and can focus on filling out the levels that utilize the mechanic in different ways. We also started play testing, which revealed a few issues with our existing test levels: where was the player going? Was our game a runner or an acrobatic game? Was the game about running as fast as you could or playing on a giant playground? The team saw that things needed adjusting and our levels needed an overhaul. So how does that process work?
It starts with a story. We hadn’t spent much time designing a narrative or any kind of story up until this point because we were so focused on the mechanics, but when it came time to implement those mechanics the team was having trouble envisioning the progression of levels. Up until this point, as Tony puts it, “We were just throwing things at the wall and seeing what stuck.” We held a meeting last week to finally address our overall story and came up with a good one – but that’s a different blog post. From there, Tony grabbed the story and wrangled it into a narrative guideline for the levels, with the hopes that giving a guideline of what the player should theoretically experience (story-wise) during each level would give us a framework to build on instead of just relying on trial and error. It gave each of the five planned levels a specific question to answer with its design.
After that was laid out, we made a spreadsheet. We asked ourselves what mechanics we wanted, how we wanted the level to play out (runner? playground?), how did the player win, how long we wanted it to last, and many other things. It was important for us to outline these specific details so we could design towards the goals, rather than create a level and realize we’d never thought about.
So now we know the mechanic, we know there’s fun in our game, and we know that we want to encourage the player to experience as they progress through the level. Things continue with a sketch on paper of what the layout might look like:
Graph paper is helpful because our mechanic is tile-based, and the grid allows for easy marking of which tile type goes in what place. This is one of the cleaner sketches of a level, though you can see all the notes that Tony has added about raised platforms, level features, and so forth. After the level designer has found a layout that they think will work, they block it out in our engine and start running through it. Here’s an overview of a tiny test level in Unreal 4 where you can see the tile placements (with red outlines). Each tile has a poorly scrawled MS paint indicator over it to show the designer which tile they’ve put down – fast, slow, forward launch, etc.
After that, they commit the level to the build and ask the rest of the team to play through and provide input. We do this in order to get different perspectives and make adjustments, because sometimes the level has some parts that are easy for the designer and very difficult for everyone else. It also gives us an average playthrough time so the team can see which levels need additional content and which need to be trimmed down. Once the level’s been tweaked and bent into proper shape, it’s ready for everyone else to play and provide feedback. How convenient for us, since next week will see our first official build sent out into the wild. Eep. Stay tuned for our adventures in playtesting.