Making ‘Shrink’ — Ludum Dare 38

A few friends and I recently tossed our hats into the ring for the Ludum Dare Game Jam competition. None of us came from a gaming background or ever made a game before so this was quite a challenge to make something in 72 hours. I was the programmer on the team. I have played around with Unity3D in the past and mostly program websites and digital comics during my day job, but I’ve never really made a game before. In fact before my current job I was a doctor working in the NHS.

After getting the theme (a small world) the team brainstormed a range of ideas. Ultimately we settled on the idea of a shrinking mechanic to move between the regular sized world and small sized world to solve puzzles.

TLDR

Play the game here — https://raudaschl.itch.io/shrink

Setting Up The player

First I had to decide how the user was going to interact in this world. Luckily Unity has a package called ‘Standard Assets’ filled with prefabs of third and first person cameras, as well as a bunch of smart tracking cameras. I played around with these for a good hour trying to work out what approach to take and made some good progress until I started added the shrink mechanic.

As this point I couldn’t make anything work due to some weird collision bugs, so instead I opted just to build a first person camera perspective (no character modelling!) from scratch which was pretty straight forward. After getting shrinking working I started to realise why shrinking may not be a common game mechanic. Having a small high speed player in the regular sized world is a nightmare for collision detection (can’t have players breaking through walls now). I played around with a variety of collision shapes and settled on a cube collision object with ‘continuous collision’ selected — this solved the majority of problems (no time to worry about performance right now).

Our game designer was busy working away on a range of puzzles. Before I knew it he had sketched up environments requiring moving boxes, platforms, enemies that chase you down, oh and of course subtitles to tell our story. Ignorance was definitely a useful tool in this case, and I started work without giving much of a second thought.

Mechanics

Portal served as inspiration for much of the mechanics, and I felt trying to emulate that would help save time (this worked out quite nicely).

List of things needed

  • Areas where you able to resize
  • Indicator to show when you can resize (I don’t think anyone ever saw this)
  • Areas that would automatically turn you back to normal size
  • Jumping
  • Enemies that could find and kill you
  • Movable boxes
  • Subtitles with audio
  • Whole bunch of trigger variables to keep track of how much of each puzzle was completed
  • Death management (automatically respawn after death)
  • Music, sfx
  • Tutorial stuff
  • Title screens, credits etc

I’ll go over few of these.

Asethetic

To keep things simple I thought setting up each room like a modern gallery would be simplest. I felt the White Cube in London would be a good starting point and would help keep development time focused on mechanics.

While the puzzles were being modelled up I got started on a test room to get all the mechanics working. This later proved invaluable as I generated prefabs from all the objects and was able to mock up game rooms really quickly later.

Level Management

To manage the level I used a single script attached to a gameobject to keep track of all the variables such as what room the player was in and what events they has triggered. The code is not elegant, but understandable and functional. It made it easy to script out events like text appearing, instantiating enemies or respawning the player if they fell out of bounds and i’m sure saved loads of time in development.

Enemies

Two puzzles required enemies to chase you. Thankfully Unity has a great navigation feature baked in which made it really easy to get started. When I first played through using the shrink mechanic to hide under the door we knew we had something fun.

Subtitles

I was dreading this the most. For some reason I couldn’t find any resources on the unity asset store that allow subtitles synced audio. Luckily last year I had coded up a subtitle system for part of a game. It’s a fairly cool system with where you can write dialogue in xml and then simply call them as a function in unity. It automatically changes the volume of music and sound effects to ensure the optimal listening experience, and the best feature — it has a broadcast event to let my controller know when dialogue has finished playing making scene setup much easier to time. If I didn’t have this I’m pretty sure we would have had to find an alternative way of narrating.

Teamwork Tools

To maximise our time we set up a whiteboard divided into three columns — ‘To do’, ‘In progress’ and ‘Done. Using post-it notes we wrote down tasks and then prioritised them on the board. We could have achieved something similar with Trello, but there is something satisfying about moving a post-it note from ‘Progress’ to ‘Done’, that’s more enjoyable a digital alternative.

While I was working away on features, my friend was going through a crash course in unity to put levels together (he plans to write up something about this in future). Everything was designed in the unity editor, and we used git to help ensure we could both work on the project at the same time. Multiple merges and the use of prefabs helped ensure we were both using the latest interactive game objects and code base, so levels could be designed appropriately to match the game mechanics, and bugs could be reported and patched quickly.

Ultimately this helped create an environment where everyone could experience the game progressing in real-time and I think really helped with motivation.

Pulling It All Together

With a few hours to go everything was in place — the levels, triggers, narrative, title screen etc and better yet we thought it was great. Luckily however, my friend has arranged some external playtesting.

Play Testing

In our game jam bubble everything worked exactly as we imagined. But as soon as we shared it with other people that’s when we realised there were tons of bugs.

People played the game in ways I never imagined, and even managed to break it jumping from room to room somehow without finishing puzzles. Additionally we realised we needed to provide more instructions to get the player started. Oh crap.

Thankfully because of the single scene controller script, adding in additional prompts and tutorials was straightforward, but I had to engineer a lot of hacks to limit the amount the player could break things. It was hell, but ultimately made the game a better experience. Since finishing the jam I have shown it to some non-gamer friends, and watching them complete it unprompted was hugely satisfying.

Next Steps

Right now I’m really excited to hear back from the community on what they thought of the game. If you haven’t played it already head to — https://raudaschl.itch.io/shrink to download the file or play in the browser (I recommend downloading, or if playing in the browser be sure to play in fullscreen mode). It was such a rush taking part and we learned so much doing it. If you want to check out the code be sure to look at the github repo. Who knows what the future holds.

Download The Game — https://raudaschl.itch.io/shrink

WebGL Version — https://raudaschl.itch.io/shrink-demo-ludum-dare-38-webgl

GitHub Repo — https://github.com/Raudaschl/smallworldgame

Physician turned product manager working in the world of academic research and health. https://www.linkedin.com/in/adrian-raudaschl/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store