
NAUTILUS
June 2024 | Independent Project
Exploration and resource management game made for a a weekend long game jam. You must explore underwater to find the ultimate treasure! Use items such as flashlights to your advantage, but watch out for sharks...
​​
I was the main game designer, programmer and level designer for this project.

Background
This game was made over the course of a single weekend for the Mehu game jam. I developed it in collaboration with 3 other people. This was my first time developing and programming inside the Godot engine and the results were quite good!
​
Never having developed for Godot, it was quite an exhausting weekend on top of the stress that naturally comes with game jams. Luckily, I was able to translate my C# knowledge into GDScript; it also helped that one of my collaborators was very familiar with the engine already so she was able to show me the ropes. Nonetheless, I tried my best to do things on my own rather than rely on her, which means there was still a lot of learning I had to do throughout the weekend.
GAME DESIGN
The theme for this jam was "Endless/Ocean". This immediately got the gears turning in my head because I am tremendously afraid of the deep ocean. Me and the team spent some time brainstorming ideas that were within scope for the jam.
​​
Original pitch
I pitch this idea of a cage diver who becomes stuck, suspended in the middle of a seemingly infinite ocean. A shark comes and circles the cage every once in a while, then leaves, waiting for the player to leave the cage. Eventually, you manage to communicate with the people on the surface who tell you they are unable to raise the cage due to a defect, they periodically send resources down to you and the player must risk leaving the safety of the cage to collect them. An oxygen meter keeps players on their toes and encourages them to make riskier decisions. This is what that original gameplay look would've looked like:
Final Design
As the jam progressed and scope increased the game's focus shifted more towards exploration. Now the starting point and end point are the cage, but you're not really going back to it until the end of the game. With the shift to exploration, we decided to give the player one singular item they needed to find to end the game, that being a giant golden glowing egg.

Since players were now exploring bigger areas, we needed a more present threat as well, I decided we should add more sharks which patrol around specific areas of the map, these would now put the player in danger constantly, but also served as indicators for players to know they're going in the right direction. If the player gets too close to them, they will start to chase them, triggering a game over if they reach the player.

Camera Control
Since the game takes place underwater, I wanted to have a completely unrestricted first-person motion. In most first-person games, your camera ​will have some constraints when looking up or down, but here you can perform a full 360° spin both horizontally and vertically.

Due to how dim and empty some of the spaces you explore in this game are, in combination with the unrestricted camera control, it's hard to tell which way you're looking. To combat this, I thought it would be a good idea to add inputs which move you up or down in world space regardless of the player's orientation, these serve as absolute references the player can use to navigate the environment, they also allow for more fluid movement which improves gameplay in its own way.
​
Additional Aids
If the player doesn't have any terrain to base themselves off of it can be much harder to orient yourself, to solve this made some additional reference points which don't require any additional context to be understood. Firstly, there are bubbles all over the ocean which always float upwards toward the surface; these can't really be seen when moving around, but when the player stands still (potentially looking where to go) they become very noticeable.

Secondly, a few seconds after items are dropped, they will naturally float down to the bottom of the ocean. This means players can strategically drop items to see which direction they float towards and get a reference of where up and down are.

Items
Items were also added to the game as scope grew. I knew I didn't want to have an inventory system since we wanted minimal UI in the game, so I landed on a system where the player can grab 2 items at a time, one in each hand. This created more opportunities for the player to improvise since now they had to make quick decision on which items they wanted to take based on their current state. I ended up adding 3 items into the game, all of which support some crucial pillar of my design:
-
Flashlight
-
Oxygen tank
-
Knife
To make the ocean really seem terrifying we knew the game had to be dark, this way players wouldn't know where a shark might be lurking, and to make the ocean truly seem never-ending. This obviously presents the issue of visibility, this is why I decided to add flashlights as an item you could find while exploring. These can be seen from a distance since they are turned on by default, illuminating the path forward even before you grab them, but once you do they're on a limited battery.​

The addition of the oxygen tank allowed us to make the base oxygen meter a lot smaller. Even though in total you now get a lot more oxygen to explore, the looming threat of drowning produces a lot more stress than if they just had one big bar. This then creates a constant cycle between panic and relief based on the state of the oxygen meter.

The knife is there to provide both a defensive option for players who get caught by a shark, while also allowing for a more offensive playstyle for those who prefer to play that way.

PROGRAMMING
As I mentioned earlier this was my first time programming using GDScript which means I had to learn a lot since I was also the main gameplay programmer. The first day of the jam was really challenging, I was trying to set up the locomotion system and it took me ages to get a simple 1st person controller working which was initially somewhat demotivating. That first day can pretty much be boiled down to these few lines of code, but the result was actually quite good:
func _physics_process(delta):
#Handle movement
var input_dir = Input.get_vector("Left", "Right", "Forward", "Back")
var verticalInput = Input.get_axis("Swim Down", "Swim Up")
#Get desired velocity and direction
var dir_vector = (input_dir.y * cam.global_transform.basis.z) + (input_dir.x * global_transform.basis.x)
dir_vector.y += verticalInput
var desired_velocity = _currentSpeed * dir_vector
#Transition to desired velocity
if input_dir != Vector2() || verticalInput != 0:
_velocity = lerp(_velocity, desired_velocity, 0.1)
else:
_velocity *= .97
move_and_slide()

Interaction System
I needed to code a system in which the player could grab, release or use an item on either hand. Grabbing works simply by taking the grab input, then checking if an item is already in your hand, if an item is already is in your hands let it go, if not, check if there are any items in range and grab them.
//Attempt interaction
if(Input.is_action_just_pressed("ItemGrab_Right")):
var itemInHand : Node3D = CheckHandStatus(_rightHand)
if(itemInHand == null):
TryGetItem(_rightHand)
else:
LetItemGo(itemInHand)
Items have similar code structures where they will have an OnItemUse() and OnCancelUse(). This means that the player script can ambiguously call these functions without worrying about what they actually do.
//Attempt to use item
func TryUseItem(hand):
var item = CheckHandStatus(hand)
if(item != null):
item.OnItemUse()
//Attempt to cancel item
func TryCancelItem(hand):
var item = CheckHandStatus(hand)
if(item != null):
item.OnCancelUse()
The flashlight can be toggled on and off with the press of a button, so this is how that looks like in code:
//Use flashlight
func OnItemUse():
if(_currentBattery <= 0):
Active = false
return
Active = !Active
SetFlashlightState(Active)
All in all the system works extremely well, and if we decided to continue this project it would be very easy to make additions to the interaction system without having to jump through many hoops.
LEVEL DESIGN
Designing the level for this game was a very interesting experience. I had to guide players through an environment where their visibility was severely limited, while they weren't really aware of where the end goal even was. Since the ocean had to appear never ending there was also the problem of players straying too far from the play area, at which point it is very hard to return if you don't have a flashlight. There were some major obstacles I needed to tackle to make a successful level work within the design I set up for myself, but I think I managed it well.

Guiding Players
Within all the challenges that this project presented I was able to come up with a few key ways of guiding players, and reassuring them that they were on the right track.
​
Going Deeper
Even though players don't know where their end goal is at first, I am constantly guiding them deeper and deeper into the ocean floor. This means that progress can be felt as you play, put simply, if you are going lower, you are getting closer to the objective. I really saw the effect of this when, during an early playtest, I had players swim slightly upwards to progress, this immediately felt wrong to players, who then proceeded to swim around this same area looking for alternative paths thinking they had taken a wrong turn somewhere.

Item Placement & Lighting
Items were a fantastic way of telling players, "Yes, you're still on the main path". As I was designing the level, I thought it would be a good idea to give all items a subtle glow around them which can be seen from a distance. Not only did this make them more visible, but they work as very natural way points because players are instinctively attracted to them.

Flashlights were particularly good in this regard. I made the choice to have them turned on by default, meaning they created really strong light sources in generally dark areas. This was great for attracting players, sure, but an even cooler benefit was how they contextualized far away terrain through contrast and shadow, creating gorgeous imagery with very simple geometry.

Sharks
Sharks are used all over the map to keep players on their toes. They will often swim above where the players are expected to be looking and will then show up on their peripheral vision unexpectedly when looking around. These sharks are never be placed in such a way were they will unexpectedly attack the player, but they keep tensions high at all times because you never know where they might be hiding. Some will be placed directly on the path that players are expected to go through, in these cases their path goes in the opposite way the player is moving towards. This means that there is only ever one contact point with that specific shark, and even then, they can be seen ahead of time, meaning players have some time to get away or prepare their knife.
​
Let's look at the following area which I call the "Sand Canyon".

Here, the player is expected to go along a canyon in a very linear fashion, however, we can see that a shark patrols directly on this path

The shark can be seen easily with a flashlight, which I have provided players with right before entering this area. Now the player can choose to fight it off or swim away, a knife was also provided shortly before this area so players are quite likely to have it on hand, meaning both approaches are viable.

End Goal
Players are never told that they've found their goal, but it they can instantly tell when they find it. After the sand canyon, players are greeted to an area that is illuminated with a bright gold light which turns the blue of the ocean into a sinister burgundy. Approaching the area, the familiar rock and sand turn into this dark obsidian like material. Reaching the light source, players see a strange looking egg which screams significance.

Players must then carry the egg back to the beginning of the level. The glow of the egg is much brighter than that of the flashlight, meaning players see more, but the yellow glow of the egg means you must also carry the sinister energy of the place from where you found it. In this trek back to the cage players must rely on their own memory, assisted by some of the items they've left behind during their trip

Working Within Limitations
Unfortunately, I am not a 3D modeler, meaning I completely relied on Godot's terrain tools to create the playable area for this game. Originally, I had planned on having incredibly distinct areas for the player to explore, with more memorable landmarks the player could use to guide themselves, especially for the return to the cage. As a substitute for that I decided instead to divide the map into 5 distinct areas.
-
The cage​
-
Starting area
-
Stalagmite area
-
Sand canyon
-
Ocean floor
These all have a distinct feel. The starting area for example has lots of grass and sand, and is comparatively well lit. By comparison, the stalagmite area has the distinct geographical feature of being made up of mostly stalagmites and rock; this area is also particularly infested by sharks. The sand canyon is way more closed off than the rest of the areas, and is made entirely out of sand. The ocean floor is distinct simply by the fact that it is the lowest point in the entire map, it also contains the glowing egg which I already talked about in the previous section.
​
I would say despite all the challenges I faced while designing this level, I was able to create something quite compelling which succeeded in guiding players to their destinations while remaining entertaining through clever use of the game mechanics I established for this game.