Siren Song, Devlog #2: Movement, Dive Computer, Oxygen and Exertion Systems
It’s been about a week and a half since I first wrote about Siren Song, the 2.5D platforming/survival game I’ve been working on. Since then I’ve accomplished quite a bit, including a full rewrite of the movement systems, implementing the dive computer, tracking and limiting oxygen use with an exertion system, and a whole lot of work on adding in hazards like sharks, octopuses, fire coral, sea urchins, and more.
I’ve also added a harpoon style drone, which will be your primary tool and weapon in the game to knock out hazards and obstacles, but I’ll write about that in a separate post once it’s a little more polished.
The original movement system bypassed the physics system and instead worked with direct movement of game objects by hard-coded amounts. For example, when you pressed the jump key you would always move exactly x units up over t seconds. This is quite a simple movement system to implement, which has the advantage of being quite precise. The player always knows exactly how far they’re going to move, and how long it’s going to take, meaning they’re able to perfectly predict the outcome of their action and are in full control of their character. There’s a lot to be said of games that go with this approach, and there’s certainly nothing wrong with it, but for this game it wasn’t the right approach.
When you’re diving, or underwater in general, you don’t have precise control over your movements as you do out of water. There are a myriad of factors that impact your movement underwater that don’t on land (or at least, we’re so accustomed to it that we don’t think about it) - currents, the density of water versus air, water temperature, salt versus fresh water, etc. - all of these serve to make movement underwater much different to movement on land. Seeing as how we as a species aren’t native to water, it’s understandable that these factors tend to make us less graceful underwater.
So back to the movement system - I want the player to have precise control, however I also don’t want them to forget that they’re underwater. Their jumps are going to be longer with more hang time, their fall speed is going to be slower, they’re going to be able to double, triple, quadruple jump using compressed air as a propellant, their running stop time isn’t going to be instant… and so on. All of these are certainly possible to implement with direct object movement, but you can probably tell that it’s heading into the realm of the physics engine anyways. Even more so when you consider that I want the materials the player interacts with to have an impact as well - running on wet steel is much different to running on sand.
Additionally, bypassing the physics system has a number of practical implications. For example, by skipping the physics engine’s update cycles you’ll end up moving objects through one another, and so you’ll begin developing a number of techniques to prevent this - raycasts to prevent moving when an object is in front or above the player, collision handlers to reset objects when they inadvertently move too far or are struck by a physics-enabled object, and so on. There’s already a wonderful engine in place to handle all these scenarios with better performance and higher accuracy (in most cases) than what you’re write yourself, so it’s best to just let it do it’s work.
So I re-wrote the movement systems using the standard Unity physics engine and the results are quite good. The game plays well, and I believe it does a really solid job of making you feel like you’re underwater. It takes a moment to build running momentum, and you get the feeling of buoyancy that you’d expect. Combined with some solid lighting, sound design that I’m really proud of (more on that when I figure out how to get Quicktime to record audio when screen recording), a (physics enabled) bubble particle system, and the subtle atmospheric particle system seen in the video above, and I’m quite happy to say that you really get the experience of being underwater!
To me, one of the key components of diving is the dive computer. Your computer (along with your air gauges and training, of course) is your guide underwater, tracking your depth, your dive time, your stop times, and more depending on the computer you use. There’s a lot to think about underwater even when everything is going according to plan, and any unexpected incidents or the onset of narcosis can throw you for a loop. Knowing that a few meters of depth can be the difference between a good dive and ending up in the hospital (or worse), you want to make sure you have these things under control.
Being an inexperienced diver myself, I’m probably checking my computer and gauges much more often than I should, but I’ve had this feeling in mind while developing Siren Song of what it’s like when you’re underwater looking at your computer, with your limited vision and over-active mind, and you almost get tunnel vision looking at your remaining air pressure or depth, and I wanted to bring that experience into the game.
The dive computer in Siren Song, much like in the real world, acts as your main HUD, with your health, remaining oxygen, present and maximum depth, and inventory presented on what’s intended to look like a real dive computer that you’d wear on your wrist. The UI is bulkier than I’d have designed for a normal HUD, but it’s not present by default. You have to actively hold the tab button to see the dive computer, and you sacrifice visibility to do so, but you’ll find yourself checking in on your vitals and sacrificing that visibility from time to time just as you would in real life.
Even the animation is even intended to give the feeling of your left wrist coming up to your mask. I’m still playing with the effect, and I might even introduce a slight screen blur or bloom effect while the dive computer is up, but there’s a fine line between a realistic effect and an annoying gameplay hindrance.
One thing you might notice under the PSI indicator is a little pixelated graph, which leads us right into the next section…
Oxygen and Exertion
So, obviously humans can’t breath underwater. I probably don’t need to point that out, but it’s something to consider when designing an underwater game. I knew from the start that I wanted you to have limited oxygen, but that’s a tough mechanic to make fun in a game.
One possibility would be to increase oxygen consumption as you descend, giving you more time closer to the surface and less time as you descend, which would be a good way to tune the difficulty curve. It also has the benefit of being real-life accurate.
Warning: This next bit is probably not that interesting unless you’re a diver, in which case you already know this. Feel free to skip to the following paragraph.
In real life, Boyle’s Law gives us the inconvenient limitation of consuming more air as our depth underwater increases. This is because of the increased pressure of water over air, where each 10 meters of depth you descend increases the pressure on your body (and in turn, your lungs) equivalent to one atmosphere (or, the amount of pressure you feel on the surface at sea level). One atmosphere is known as one bar, so at the surface you experience one bar of pressure, at a depth of 10 meters you experience two bars, at 20 meters you experience three bars, and so on. (As an aside to this aside, the increase from one to two bars going from the surface to 10 meters is the highest percentage rate of increase at a 100% increase in pressure, which is why it’s important to clear your sinus pressure right below the surface and frequently as you descend those first few meters, or you’re pretty much screwed for the rest of the dive.) When we inhale our lungs require a certain pressure rather than a certain volume of air, so even though we utilize a constant rate of oxygen regardless of depth, we require twice the volume to fill our lungs each time!
This is most likely something I’ll return to once more of the progression systems are in place, but for now I decided to skip Boyle’s Law and have you use a constant rate of air at all depths. The reason for that decision is that you’re limited in how you can resupply oxygen underwater in the game (though it can be done, more on this later), so it’s quite punishing to take away a limited resource as the player progresses deeper. It’s not something you can circumvent with skill, so it’s just a static limitation with no recourse for the player (again, until I’ve further developed the progression systems).
What I decided to go with, and why that little graph on the dive computer is important, is an exertion system where you expend more air the more you exert yourself. You start at a base exertion rate, 1x, where you inhale roughly every 4 to 6 seconds. Running, jumping, and taking damage all increase your exertion rate up to a maximum of 5x, where you consume air at five times faster!
This has some interesting gameplay implications where you want to more deliberate with your actions, timing your jumps and sticking with a plan for each dive. On top of that, there are a few optimizations that advanced players can make to further extend their dive times (and therefor, their depths). For instance, running and jumping increase your exertion modifier but falling doesn’t, so I’ve found myself rushing down as deep as I plan to go straight from the boat, avoiding all obstacles by guiding my fall, and therefor having no reason to run or jump on the descent. This strategy is dangerous as it’s easy to get hurt, but the payoff is you start your ascent with a near-full tank!
Breathing is such an important part of the game, that each breath your character takes is actually taking away oxygen from your tanks, and you can see this on your dive computer. As your exertion rate climbs, your character breathes more frequently, and the animations and sound effects reinforce this. Once your oxygen gets low enough, the dive computer starts alarming you, and when you finally run out - well, you drown.
On top of that, your double, triple, quadruple (and so on) jumps require a little boost of compressed air (conveniently) equivalent to one breath, so you want to use these sparingly and utilize the primary (non-oxygen assisted) jump where possible!
So far this mechanic has been a lot of fun to play with, and I’m really happy with this approach rather than simply increasing the oxygen requirements as you descend.
The area I’ve put the most effort into this last week has been the atmosphere of the game. It gets dark underwater really quickly, and the game uses that to give an intense mood almost akin to a thriller. I’ll do a proper write up on this later, but for now here are a couple videos showing a couple of octopuses hiding in the dark, control over the head-mounted flashlight using your mouse, and the use of flares to light up a deep pit before jumping in.
Hopefully this has been an interesting look at some of the design decisions behind Siren Song, and I plan to share more as development progresses. I’d love to get your feedback and potentially share an alpha build in the not-so-distant future, so hit me up on Twitter @kylewbanks or leave a comment below!