Slime Climb is a casual little infinite climber game developed for the Sacramento Dev Collective's Voyager Jam. The game was designed with mobile in mind so I could use this as a starting point to bring a small-scope project across the finish line onto app stores. Though the game is far from finished, it has most of the elements I envisioned at inception and is much more complete than my previous solo jam submissions. This post-mortem will address what went right/wrong in the context of the jam, even though the game is still in progress.

The Design
The theme for the Voyager Jam was "lifeform". Usually, ideas start to pour out when I look at a theme but I felt pretty well and truly stumped on this one. I knew I wanted to do something will small scope, likely for mobile, but had troubles tying in the theme. I ended up returning to an old idea I had for a game design course about a person who had become a test subject in a military facility and was turned into a gelatinous lifeform and had to escape the facility. The original idea was a narrative-driven stealth game, but I thought the idea of a gel-like lifeform escaping a facility was pretty engaging. I settled on infinite climbing for the gameplay loop, because I had some practice with platformers and infinite runners, and because it fits really well with the narrative of escaping the facility. I jotted down my idea as "Ooze Escape" and started diving into the mechanics, starting with the Player character.

The Mechanics
I wanted to start with the player movement because that was the largest driver of player experience in the gameplay loop. I felt if the player controls felt good, then the whole game should feel pretty good. I went with a click-and-drag input to create a direction and force vector for the player's jump. In essence, the player launched their character in the same way a player launches birds in Angry Birds. Except instead of birds launching from a slingshot, the slime jumps in that direction. This felt pretty good, and I thought it would translate well to mobile down the line, so I kept it. It wouldn't make sense for the slime to be able to launch itself over and over so I made the jump ability usable once, then recharge when impacting a wall or the ground. Now, the player could jump wall to wall as high as they could.

Now that I had a prototype, it was time to add some challenge to turn it from a toy into a game. The simplest way to do that quickly in my opinion was to make an obstacle that would destroy the player immediately on contact. I settled on an electrified obstacle and gave it some behavior to destroy the player, end the game, and cycle whether it's dangerous or not on a timed cycle. I found when I was playing it was difficult to avoid, or at least not clear it was dangerous so I spent a bit of extra time making up a lightning effect and some art to make my new electric ball look menacing. I tried a few placement configurations to test how they could be used in levels and then got to work on the system to populate the game with obstacles and continuously generate more levels.

Going Infinite
So I had a player object and some obstacles for a level but had to make the game infinite. Some quick code that would track the player to adjust the camera and spawn/destroy levels as needed took care of the level generation, but I had trouble with the walls. Spawning new walls with every level felt like extra work, but moving a sprite with the camera made the walls appear static like the player wasn't climbing at all. Unity's SpriteShape object addressed this super easily. SpriteShape has an option to use world space coordinates for the repeating texture of the object, meaning even when the object moves the texture will stay in place. The result is very similar to a moving window looking at an infinitely large background. So now I could parent the walls to the camera to make them follow the player, but have it look like the game has infinitely tall walls. I did the same thing with the game background and suddenly had an infinite climber on my hands! 

Fun fact: it was also around this point that I had an epiphany while falling asleep and scribbled down a much better name in my notes, "SLIME CLIMB".

Polishing and UI
At this point in the process, I had planned on working on a soft-body physics simulation to add some dimension to the player character and give a unique feel, but I had completely run out of time. Luckily, I found a 2D jelly sprite system in the asset store which saved the day! It was really easy to use. I had to modify the included scripts a little bit to make the multiple colliders play nicely with my player controller, but after an hour or two things seemed to be hooked up and the player was nice and gelatinous. 

As tends to happen when I do game jams, I left the menus for last. Luckily the programmer in me had the foresight to code the core mechanics classes with different menu states in mind, so it was really just a matter of making prefabs, hooking up event listeners, and scaling the UI. Scaling the UI turned out to be the hardest part. I threw everything together in a static, non-scaling canvas to make the menus quickly, but did so on the wrong reference resolution. When I went to change the resolution for building, I had to redo most of the prefab placement and scaling. Keeping everything in a single scene and handling menus and state in the code was a much easier approach than Unity Scenes though, and at runtime, it's nice not having to load any new scenes.

What went well

• Priority management: I think I picked the right features to focus my time on and was able to "Find the fun" fairly quickly
• Code organization: having a little bit more experience with game programming patterns allowed me to organize the systems in a more modular way which really saved my bacon when it came down to putting everything together quickly. Specifically, the observer pattern really did a lot of work in this project. For example, all of the menus use a single common component that listens to the core game loop's state changes and activates/deactivates accordingly.
• Particle effects: armed with some new experience, I was able to make particle effects that really enhanced the gameplay. Particularly, the death particles and lightning particles add a lot to the game's feel. I definitely want to add more juicy effects like this.

What could have gone better

• UI Scaling: leaving menus for last tends to leave me working on UI when I am super time-pressured and mashing out the finishing touches, so UI scaling tends to get missed. But it really enhances the experience (kind of unbeknownst to the user) when you open a game on any device, adjust to your preferred position and scale, and it just works. I want to practice designing and building my UI with this in mind from the start so that it doesn't fall by the wayside in time-pressured projects like this one.
• Game art: I'd like to chalk it up to lack of experience, but I have trouble making sprites that look crisp on the screen. This was my first time making non-pixel art sprites, and they still look sort of low resolution/pixelated. I want to study up on art asset creation a bit so I can add that extra professional touch to my games, even when I'm not working with an artist.

That's all for this one. I have a goal of releasing a version of the game to a mobile app store by the end of the year, so I'm still workin'. Keep an eye out for Slime Climb on your app store of choice and until then, happy climbing!