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.

Darkness Dwells - Metrics and Research

During earlier blogs I have talked a bit about promotion and social media and I have talked a bunch about research, but I haven’t really concluded how it worked out for us or what we did with feedback that was provided to us. That is the purpose of this blog.  

On social media we very early on made a twitter and Facebook account that most members shared with their followers. On these social medias we kept posting pictures and teasers for the game, but most importantly, we used twitter polls. This allowed us to sort of gauge out what our audience enjoyed at the same time we were developing the game. It also allowed us to be more in contact with our audience and show them that we were interested in their opinions in order to make our game better.  

What we found out through the social media and out of assumption testing was that most people that enjoyed horror games enjoyed challenge with it. Making it a struggle for survival and getting the adrenaline pumping even harder. We decided to take this into consideration when making our game, hence why we added the radio and the use of the bed monster. The bed monster originally wasn’t supposed to be a threat during the entire game, but upon testing the game and having it feel to easy, we made it so that the player has to try and balance the bed monster with everything else happening in the game. On top of this, we added the radio, which makes all the monsters appear faster unless the player turns it off, adding a new layer of urgency and challenge.  

It is not a surprise that streamers and youtubers enjoy horror games, for the main purpose of overreacting to them. Somehow, it seems to attract a lot of views. views that we can guide to our page. The game was originally made with youtubers in mind, which is the whole reason why the game is based around jumpscares. Due to research made by a teammate of the project, we managed to find out that generally people do not care if there is a lot of jumpscares in a short amount of time. Naturally we used this to our advantage and based our game around this as part of our core mechanic.

I believe it is due to our research and interaction with the audience, that darkness dwells at this point is number 3 on most popular game on, and have been featured on the front page. Thank you for reading this short blog discussion.

Creating the Flybot!

Hey there! 

I do realize it's been a while since I've written anything, but I've been very busy with Uni work these past weeks, and just haven't found the time nor the energy to work on any side projects what so ever. That is, until tonight.

I'm currently writing this blog at 1:35 am, because I was just too worried that I might forget all this new information that I've discovered today if I slept, so I'm going to put it all here both as a reminder to myself and both as an update to what I am currently working on. So let's get right to it.

The Scrapbot

About 2 nights ago (yes nights, I can't work during days apparently) I started working on a robot model. I consider myself to be adequate with Autodesk Maya, but if there is anything I still struggle with, it is skin. The way it stretches along with weight painting is just too difficult for me, and something I will have to tackle another day. Therefore, robots and mechanical parts are way easier because you can use a method where you simply target all the vertices that you want, and tie them to a bone. No stretching involved. Because of all this, combined with a sudden inspiration surge to do some personal projects, I started to work on the robot I was about to call "The Scrapbot". I called it that because it feels like I can get away with not being a fully trained animator/3D artist by making scrappy stuff.

Either way, I immediately got to work, and I did feel like I made heaps of progress on it. In fact, after the second night had past I was completely done with both model, skeleton and animation. I was also fully aware I had completely skipped some of the key guidelines for modeling. One of them for example, is to combine every part of your robot so that they're not separate pieces. Even though I knew all this, I continued working (for some reason) possibly to experiment with what would happen.

I went from this, in Maya: 


To this in Unreal Engine 4:


Needless to say, something went horribly bad in the export. I already knew the skin stuff based on the amount of errors I got when exporting, however I was still very confused about the slow-mo running (more on this later). This had me drained of work energy so I went to sleep. Next day (today) I was determined to keep working on this model, however once I had the free time it just didn't click for me. I didn't want to start over with the rough animation and the rig. I decided that I had to make something even simpler, for the sake of time. Enter "The Flybot".

The Flybot

The flybot was my attempt at making something smaller that barely needed animating or skeleton. The first idea for the flybot was a little head on two legs that was running around. Then I went on to brainstorm a head with a propeller and a grappling arm. It ended up just being a head with a jaw and a propeller on top for simplicity's sake. I did everything all over again, even the things I missed last time like texturing and combining. I was ready to export. The first good sign was the error box, which turned out empty. I had my hopes up. I then hopped into Unreal Engine to start working, and behold there it was in all it's glory. No error messages, fully intact and textured, the flybot.

Now the fun part was about to start. I placed the animation inside the scene to have a look at my masterpiece and.... disappointment. The animation worked, sure, but it ran at 1/30th of it's original speed. Now, some of you might already have realized what is wrong. The key is in the number 30. Apparently (after some online research) Unreal needs Maya to have a playback speed of 30 fps instead of "Default" (which apparently is each frame). This also lead to me having to move keyframes spread out over 600 frames, down to about 90. It was a bit tricky, but hey it worked!


Some other things I learned in the process of Importing from Maya to UE4 was that UE4 requires your Maya scale settings to be set to centimeters instead of meters, unlike Unity which requires the opposite. Now my model was arguably a bit too big still, which I am currently working on solving.

Finally, I learned a helpful little trick that I might be able to use in the future. When making animations, you can make the run, jump and death animation in the same file, and when you import it into UE4 they will give you the option to import different frames separately. Important to note though is that only the first animation has to be imported with the mesh. The other animations are fine if you import the bones only.

That's all for now! The reason I didn't say what the game is yet is because I am still figuring it out and testing. I need it to be really simple because I just want it out there really. This whole modeling project I've been doing is partially just to prove to myself that I can do it, and so far it has worked, but the game is the final piece.

Anyways, thanks for reading! Until next time.