Scrapbot Dev Diary #1 - Level Design and Early Choices

Hello and welcome to the first non-forced blog in quite a while! This one is all about a personal project of mine, that I have been working on to and from for a few weeks now (trying to relax on a break and still work is a bit hard for me still). In this blog I will be discussing the main idea, then talk a bit about some design choices i’ve made, and then finally talk a bunch about the level design, as that has been the main focus these last few weeks.

So let’s start talking about the idea itself. What I wanted to go for when making the game was a Mario 64 or Banjo Kazooie feel. Kind of an open world platformer where you collect items in order to progress. I wanted to make something that didn’t use many difficult programming elements, as I had decided to make the game in Unreal Engine 4, rather than Unity which I am used to working in. My game had two characters. Two different robots that the player could switch between in order to complete puzzles and challenges. The original idea was that the player could collect three different types of currencies that would be used to construct different tools (like launch-pads) to assist the player further. The main goal of the game was to help a third robot (NPC) to go to space in a massive rocket that is located in the middle of the map. As for the map itself, it was split up into four different areas that I would lock off and release over time as I developed this project. This was the original Idea for the game, however below I will talk about some design choices and issues I encountered that changed the game slightly.

First off is my choice to remove character swapping and two characters. In a game world as “open” as mine, it would be tedious to only move one character at a time to move across the map. It is probably countered through the level design itself by moving the characters in small increments, but it didn’t correspond with what I wanted for the game.

First iteration on level. one part of several massive quadrants that would progressively be released after game release by me.

First iteration on level. one part of several massive quadrants that would progressively be released after game release by me.

The second issue was the map size. I liked the thought of having different zones, but I eventually realized that I probably won’t want to work on this for another few months to fill out all areas with unique ideas and content, so I removed the zones and decreased the overall map size. Because of that I also had to decide what activities I wanted to include in the game. I started off with trying to come up with four different activities, one for each quadrant. However I ended up changing it to four jumping puzzles instead, as I wanted to focus on the level design and platforming aspects of the game, rather than amount of mechanics. So the final decision became four jumping puzzles starting in or being located in, the different quadrants.

New iteration on the level design. This iteration features a significantly smaller level with objectives all around.

New iteration on the level design. This iteration features a significantly smaller level with objectives all around.

Upper Left Quadrant of the new level. Here I have mapped out a jumping puzzle and all it's possible paths as well as locations of bolts.

Upper Left Quadrant of the new level. Here I have mapped out a jumping puzzle and all it's possible paths as well as locations of bolts.

Next up was some smaller changes that I had implemented, but then decided to remove completely. One of them being the three currencies. I had nuts, bolts and springs that all were made for the player to collect. However, none of them had any specific purpose at all, so I removed two of them, keeping the bolts. The reason for keeping the bolts was partially because I feel like bolts do more good than nuts, but also because the internet has ruined me and I didn’t want to keep writing nuts in my documentation. The second issue I had was the mechanic to carry items. Originally in a very early idea I wanted the player to be able to have to place boxes on pressure plates to move through puzzles, but since this became a jumping puzzle based game instead, I decided to remove the functionality completely.

Since I have one of the quadrants ready for grey-boxing, I wanted to dive in to unreal engine and start mapping out the area and test the size of the level, as well as get used to exporting from maya to UE4. The first step was to create a cylinder that would cover the size of the level. Since I had made the level smaller from the start, I decided to make the radius of the level 50 metres, rather than 80. This however, was incredibly far, and it could take me as much as 3 minutes to reach the end of the level, which was way too far. I tried changing it over and over again, and eventually ended up at 15 meters. It's around this point that I figured out that since 1 unreal unit is equal to 1 centimeter, that means that 10 unreal units is 1 meter, meaning that my "50" meters actually were around 500 meters. So my 15 meter radius made more sense as a 150 meter radius. This 150 meter radius was a pretty good size since it didn't feel too long nor too short. I played around as well with the size of the crater the map is in, and the size of the rocket in the middle. I wanted the rocket to be a very clear center-point so I needed it to be visible from everywhere.

Level design test, with final size iteration of 150 meter radius

Level design test, with final size iteration of 150 meter radius

Previously in my degree one of my weaknesses was to ask “why” questions. Why do I implement X, what purpose does it have? Does it add to the game experience? If the questions were no, then there is no reason to have it in the game. For this project I think I have evolved in that field significantly, and I believe my game will turn out better for that.

Robin B. Goode Goes Robin B. Bad

During week 11 we had a playtest for the final project of our cohort. The capstone project of our time here at SAE. During that, we learned a whole bunch about our game that we didn't know before, but we also learned that sometimes a heavy pivot is necessary for the sake of the project and the sanity of the team. For those that do not know, Beat Burglar was a rhythm stealth game where the player had to move to the beat in order to stay hidden.

There were three main issues we encountered, and I will discuss all of them in this post, as well as talk about our solution.

Issue #1 - Mushy Movement

The first issue was that the movement wasn't crisp enough. We were going heavily for a "Crypt of the Necrodancer (CoTN)" type of movement. We even read the blog post that the developers wrote in order to get as close as possible. Unfortunately we wanted the game to be more punishing when missing the beat, and this caused the game to not feel well. What CoTN did was shape the beat around how the player was moving, making it a tailored experience for whomever was playing the game.

One of our solutions to try and fix this was to implement "snake-like" movement. That is, the player moves forward automatically and the player steers left and right. This would have the player constantly be on their guard, observing where their character is heading and assess the situations to try and make the best of it.

Issue #2 - No Urgency

The second issue was urgency. In CoTN (which was our greatest inspiration) all enemies come for you, and if the song ends the level ends and the player get's sent to a small room with tonnes of enemies. It works as a kind of punishment, but if you complete the extra challenge you get loot and can continue to play the next level. In our game, guards didn't move towards you, they patrolled. When the song ended, it looped instead of kick you into a challenge.

For this issue, the snake movement would have been useful as well. The urgency of assessing the situations ahead of you and planning on the go would have possibly solved the issue of non-existent urgency. We even had counter-measures for the player actively trying to walk into walls to stand still (bump them off in the opposite direction).

Issue #3 - Tediousness

The third and final issue, Tediousness. We gave the player no direction on what to do and where to go. The levels were massive and empty and the movement was too sluggish to enjoy moving through the levels. 

I believe that snake movement would only have made it worse. Sure, you don't have to press every single beat, but given how empty the levels were you'd be able to press the turn-button once and then wait for a few seconds until pressing again.

Possible solutions include a more proper tutorial, carefully explaining to the player what they need to do. The stills are beautiful, but it leaves the player hanging where they might need to know the most. Other than that, Decreasing level size or Increasing guard population may need plausible solutions here.


I've mentioned at least one solution to all these issues, but there is one I haven't mentioned yet. Today, we pitched these solutions to our cohort and lecturers, and we were given the greenlight (kind of) again on this solution.

In order to increase interactivity, increase the overall feel-good of the game and to give the player a chance to experience all our environments close up, we decided to switch this top-down rhythm stealth game to a third-person beat 'em up game. The thought is that the player can create combos while fighting off guards, and the higher the combo the more of the main music layers on, creating an amazing feeling of being powerful.

From the start of this project, all we wanted was a game that met everyone's needs and felt amazing to play. Thanks to us sitting down and pondering on the feedback we were given, we were able to pivot this idea to something that we all want to work on, for real this time.

We will have to change the narrative slightly, as we decided to fully switch over to EDM music instead of the original choice of electro-swing, mainly because it's our audio students main choice of music and they make amazing EDM music.

Thank you very much for reading this blog post, expect to see more updates both here and on twitter.