Hey everyone and welcome back! Through this blog post, I want to shed some light on how we pre-produce levels and mechanics for RITE of ILK. Pre-production isn’t filled with just rainbows, green sceneries, a pot of gold, and happy-go-lucky unicorns – pre-production is making tough choices and often means throwing away ideas you really like. Sometimes your idea simply doesn’t work or doesn’t fit in the game, forcing you to kill one of your darling ideas.
Death of a level
The image below showcases one of the earliest level designs for RITE of ILK, or as the project was known at the time, Project Bound. During that phase in development, level design was split up in two categories: paths and sandboxes. The paths were designed to be tight, narrow, linear-transaction experiences to guide players from one sandbox to the next. The sandboxes were meant to be large playing fields that would allow the players lots of freedom.
Image: Early level design
A primary problem with this design was the scope. Players would often find themselves lost because the sandboxes were really huge. From a development view, this was also a very costly idea since our artists had to set dress gigantic landscapes! The paths, on the other hand, guided the players much more while still feeling really open.
When confronted with the facts, the team, and myself in particular, had to make a tough decision. We decided that we wanted to step away from sandboxes, forcing me to throw away a lot of work and/or redesign and iterate on lots of previous sandbox work.
To salvage from the deadweight sandboxes, we took the puzzles and mechanics that worked and incorporated these in paths. We wanted to step away from sandboxes while maintaining the feeling of freedom and open exploration that the sandboxes initially provided. To accomplish this feat, we decided to broaden the paths and offer multiple routes to our players.
In the image below, you can see a level blocking where this change was happening. We had already cut away quite some content and focused more on broad paths. We still had a sandbox at this point in time, but in later iterations, the sandbox slimmed down to essentially become an expansive and broad path.
Image: The initial level blockout as it was being trimmed down. At this point,
almost all of sandbox #1 and all of path #2 and #3 were removed.
Yes, I had to throw away a lot of work. But the big takeaway here is that we foresaw that our level design was way too large for our team, gameplay, and target audience. Because we level blocked these early on and played with them, we could make the harsh decision to trim down our level. I recently came across a really good video that also goes into this subject; it’s from the designers of Firewatch and I highly recommend it: http://www.gdcvault.com/play/1022108/Designing-for-Exploration-and-Choice!
Death of a mechanic
The same principles apply when designing and testing gameplay mechanics. To give the players the time to be bewildered and make them more aware of our beautiful environments, I came up with a little mechanic called the “telescope.” Locked behind a simple and fun mini game, the telescope offers a cool or gorgeous intended shot of our environment to the players. In the mini game, as seen in the image below, the players have to match their unfocused blotch to the other player’s blotch to unlock a clear and wider image.
I sketch mechanics out to communicate them to the team. Here you can see a short storyboard of the telescope mechanic.
I was completely in love with the idea of the players being able to take a breather by letting them play a small mini game and have them be rewarded with a cool or interesting shot of our world. Although the mechanic worked pretty well during playtests, it caused confusion amongst players. Most of them were under the impression that the image we showed them was their goal or a place they needed to go to, which, most of the time, wasn’t true at all! In fact, more often than not, the place was actually impossible to reach and solely functioned to show a gorgeous landscape. Obviously this caused a lot of frustration to the players and after a couple of iterations, it became clear to me that the mechanic was simply interruptive to the gameplay flow. Sadly enough, I had to remove it from the game.
Although the telescope mechanic had been removed from the game, I’m still looking for opportunities to bring the mechanic back. Perhaps only as an additional guidance to tell the players where to go… or perhaps in another game altogether.
Sometimes you have to throw some work away because it simply doesn’t work. This is an iron rule that is super important for a game designer! It’s the reason we sketch out levels and take our levels for a test run, and it’s the reason we prototype our mechanics. In the end, by us failing, throwing away work, and re-iterating, it saves your team from a lot of unnecessary development time to code, implement, and making it look pretty. The big picture here? Don’t be scared to occasionally kill your darlings.
Until next time,