how a real-time simulated machine ended up with a turn based gameplay


In this devlog I'd like to detail the (painful) process that went into making Nauticrawl a transparently turn based crawling game, while not sacrificing the immersive experience of piloting a machine in real time.
Before getting into the nitty geeky details of how the system ends up looking from the player's perspective, I'll need to give you some context on how the game looked up until recently, it won't be long, hopefully not boring either.
Here it goes.

Nauticrawl is a rather unique breed of dungeon crawling mashed with a simulated machine, learning the thing is a puzzle about pressing buttons, pulling levers and experiencing the outcome. Which is, most often, your permanent death.
In my mind this game was always meant to be played as a clunky, fragile and slow machine.

As time passed though, I inevitably got very efficient at playing my own game (really? no kidding genius), and ended up crafting a world that was very fast and harsh in killing pretty much anyone. 
Once I realized (got told) the frenetic real-time crawling was not leaving any time to experiment with the controls, read the outcome on the monitors and engage with a story, I realized I had a problem with the death rate of my roguelike, roguelite, or whatever you want to call it, it was way too deadly.


I needed to slow down the crawling part without ever blocking the player like in  a classic turn-based game.
Interestingly enough, the inner workings of this machine and the lore of this game, all set a good ground for a turn-based system that would not feel out of place and that would blend-in transparently.
As I’ll detail later, the transparency factor also ended up being an issue.
Yes, it is a complicated job.

A pressurized machine crawling in a desolated ocean
In order to move a Nauticrawl, the player has to figure out how accumulate pressure into the engine, only then this pressure can be released and generate lift for a brief amount of time.
Imagine it like a massive locomotive, one that has to push an impossibly heavy atmosphere, and therefore needs some time to recover back enough pressure before the next move.


This system was there from the start, but the world around you couldn’t care less, everything in the Forbidden Surface was trying to kill the player, all the time.
This landscape was long abandoned, there’s wild life and for some mysterious reason there are also machines trying to stop you.
So, if in this world nothing moves most of the time, it makes sense for the enemies to preserve their energies and only chase a poor bastard when he does something that attracts attention.
All I had to do was reprogram the world to be reactive, rather than proactive.
Finally the player had all the time to experiment with the controls, to check the cost of every action before committing to a strategy and to discover the lore of this foreign world through scraps of text and interactions.
User dictated pacing, without a big banner that says “YOUR TURN!”.


But, a nicely blended system might as well become invisible to the player, leading to confusion.
Not everyone might realize that by standing still, nothing is going to attack, unless an action is performed without providing enough energy to the stealth device, in which case you get  fried.
I could just tell the player about all that and be done with it, but giving clues to the player in a game where the player is supposed to be stealing the machine that should give him the clues, is kind of a clusterf*.

Helping without helping
Nauticrawl is full of subtleties and tricks, but finding out about them takes experience, and not everyone has that time to invest on a game. The common and easy solution to this, is usually to employ a guiding entity that will explain the ropes to the player, without breaking suspension of disbelief necessarily but annoying the hell out of  him.
I didn’t want an AI or a friendly yet suspicious voice from the radio telling you how to steal this machine and escape.
Instead, I decided to turn tips into puzzles, and smartly activate them when the player gets stuck somewhere.


Hopefully, these little expedients should spare me some rage and some refunds from the impatient players, while still leaving the stubborn crawlers entertained.
Game design is tough, I'm getting this printed on a t-shirt.

Comments

Log in with itch.io to leave a comment.

Really enjoying following your progress! It seems like your alterations towards a "turn" basis are one of those game design moments that helps a lot of things click into place. Those moments are gold.

Indeed, that was the exact feeling, it helped the game become what was intended from the start. It's really surprising how iterations just need to be handled one after the other to iron it all out. Thanks for checking by!