Making of "The Other Side"


INTRODUCTION

This is written for people that are curious about what went into the making of The Other Side. I’ll be talking a bit about the decisions I made, the design and  minor changes throughout development, as well as some major features that came only a few days before release. 

STORY

The Other Side started off as a vivid vision of this makeshift drill standing in front of a wall in a cramped room, where the player is then operating the drill and fixing it before finally breaking through. During the first week of development I had no clear idea on what would be on the other side of the wall. I left the topic open though, as the drilling mechanics would stay the same regardless of what’s behind the wall. The only reason I would have to come up with the story quickly was because whatever is on the other side also has to correlate with the first room, like say if The Other Side was instead a bank vault, then the starting room would also have to be in a bank, not a rusty storage room. I could work on the mechanics of fixing the drill, but not really the graphics until I had a clear idea of what would be on The Other Side. 

Finally I came up with the idea of escaping a fallout shelter. The story on the game page as well as the start of the game in my eyes gives a clear motive for the protagonist on why they’re trying to escape and why they’re doing it so secretly. I saw a lot of people talking about how the story doesn’t really make sense, since to keep people in a bunker away from all the spiders and monstrosities you would have to show them exactly what’s behind the other side of the wall. Now in a story perspective sure, this makes complete sense. But part of the horror in The Other Side is the unknown, sure you know you’re escaping a bunker but you have no idea what’s on the other side, making it all the more interesting. If the story at the start of the game was something like “They keep us here away from the spiders and monstrosities that lurk the outside, for our safety”, and then it shows some images of the outside with monsters in them, then it would be kind of boring to drill through the wall when you already know what’s out there.

THE DRILL

The original drill design was made with this exact vision in mind. The drill would’ve been locked in this sort of maintenance position where you would swap batteries, oil and drill bits etc. before you would press a button. After that it would lower down into rails and go to a home position, where it would then start drilling through the wall until an error occurred before finally coming back to the home position. After a brief discussion with a friend, on how I would go about coding the drill movement with this type of rail configuration, we sort of went on a tangent on other drill configurations.

Finally we reached the final drill design. Instead of the drill being permanently mounted to the railing, it would instead be placed in a casing that is mounted onto the rail itself, which would move the drill. I do believe that the first drill design is a lot more intuitive from a player’s perspective. Looking at playthroughs of this game the biggest obstacle seems to be figuring out how to insert the drill into the casing from the vice. Though from a developer’s perspective it is a lot easier to set up, as the drill movement is literally a looping animation going around the wall, and to make the drill stop you would set the animation speed to 0.

This final drill design meant a new piece of equipment had to be made for the maintenance part, which is of course the vice. The reason the player has to close the vice for each interaction is just to tell the code that the player can’t pick up the drill anymore, allowing for interactions like battery removals and latch openings without accidentally picking up the drill.

FIXING THE DRILL

When it comes to the mechanics of fixing the drill, not a lot got scrapped. I knew from the start that I didn’t want to go too crazy with how many things you have to fix, I kept the scope small and that way I had to cut less stuff out later. There are two things that didn’t make in the game when it comes to the drill mechanics - one small thing was using a sort of oil tool thingy to lubricate the drill bit, which I just didn’t really find that interesting. A bigger thing however was how you use the computer. Initially what I had in mind was an entire command prompt type of deal, where the player would have to type in commands in order to start the drilling process and run diagnostics. Along with that I had planned floppy disks that could serve different purposes - like a disk for showing how to fix the drill, or a diagnostics floppy disk as well as some lore disks.

None of these made it into the game of course, since by the time I got to working on the computer I was already 2 weeks into the project, with the deadline being 1 month. The easiest solution for the computer was to make it work with just one button press, cutting down dev time by a considerable amount.

ENDING

When you finish drilling the first layer, the security alert starts and you have 5 minutes to do everything again, except this time with a time limit and with multiple errors. The second layer and security alert got added into the game only a few days before it was ready for release. This is because originally it was just drilling through one layer and then you would break through the wall, beating the game. However, the playtesters were quick to mention that drilling through the wall was nowhere near as exciting as the game set it up to be, in fact it was super anti-climactic.

Think of it this way, you drill through the first layer and you beat the game. Up until this point you’ve essentially been learning how to fix everything - the battery, the drill bit, the diagnostic system, oil levels and coolant levels and once you have learned everything - the game just ends. It’s like the end of the tutorial is the end of the game. Realising how crap the game was, when I was so close to finishing it was really demotivating. I could’ve easily ignored the feedback and released it anyway. It would’ve been an okay game, but I knew that if I went the extra mile and designed a second phase then it would make the game way more intense. 

In short I hated the last few days of making the game, just because of how annoying I found it to develop the second phase, when I had basically planned to release the game a few days prior.  It's easy to ignore valuable criticism from people and just make the game how you seem fit. But as much as I make these games for myself, I also want other people to have a good time, so I caved in. I furiously pounded the keyboard until the second layer, security alert and checkpoint system was done. 

Was this a good decision? I believe so. For me, the game starts at the second phase. The protagonist built the drill themselves, knowing how to fix every component and operate each piece of equipment. The player knows none of this, until the second phase starts where the player can then operate the drill under a time limit, knowing exactly what needs to be fixed and how. There are no tricks or surprises apart from multiple errors occurring at once.

Finally, the game was done. I released it and people enjoyed it. If you've made it this far, then thanks for reading. If you played the game, then even bigger thanks for playing. I really do appreciate it! If you have any questions, leave them below or send me an e-mail at mikeklubnika@gmail.com, until next time!

Get The Other Side

Download NowName your own price

Comments

Log in with itch.io to leave a comment.

Very interesting, reading about your process. I'm so happy you took the feedback to heart; it turned a good game into a great game!

(+2)

Loved the game, good 15 or so minutes of fun! 

The atmosphere was on point and the drill fixing was surprisingly enjoyable and also tense when the the second phase came about!

Thanks! :)

(+1)

Very interesting to see those last minute changes that modify the experience completely!

The command prompts would've been a nice feature, adding a layer of complexity, but having the core mechanics for release has more priority as you say.
I'm curious, what was the hardest part of coding the second phase?

(+2)

I think loading the checkpoint was the hardest part, since the code I had written up until that point was not designed for a scene reload, or saving & loading. It was supposed to be a game you just run through and not die in the middle, so when it came time to make the checkpoint I just sat there for about an hour trying to figure out what to do.

But yeah I essentially botched it and got it working. When the security grabs you and you load the checkpoint, the game basically restarts. The player spawn is moved to the computer, the toolbox is silently opened, the light goes red, the controls pop-up trigger gets removed and all of the first phase drill break triggers are removed, before the security alert starts again.

You'll notice that the drill isn't in the casing anymore & all the previous drilling lines are gone. Putting them back to the original position is almost impossible with how messy the code is.

(+1)

I see! When a checkpoint system is not planned, trying to fit it to an existing code is quite hard. 

Even with your solution, the restart is smooth and the player will not notice.

Congrats again for the game! Keep it up.