Project description

This game is about a squid's lonely journey towards the unknown.
We chose to make a game about an adventurous squid.
When pondering the theme of "Duality", we came up with the idea of how different their life is in water and on land.
From this idea, we created a gameplay mechanic where the squid can move quickly and freely in water but is heavily restricted on land.

Programmer: (me) Maximiliam Rosén
Game/Level Designer: Markus Bergström
Audio Designer: Samuel Eklund
Game Artist: Kaan Şen

So why is the game so short?

The level building was heavily postponed because of some weird transparency of the tiles. Next game jam that is tilebased I will help with the tilesets or verify so the level designer can implement the level earlier. For this project, I had as a goal to work as a programmer only. I still helped with anything inside Unity and worked as a teammate but I made sure that the vision each member had of their part of the game was achieved. In earlier game projects I have often taken the game designer role as well as the programmer. I wanted to see how different the project would be if I only worked as the programmer and listen closely to the Game Designer. As the programmer, I limited the scope of the project and gave input on wanted mechanics for the game but I made sure that I didn't have the last word in any game design choices. This experience helped me limit myself and include each member in their role.

First time using state transitions in a StateMachine

For this game jam, I for the first time prepared myself by creating some basic systems that all games have in common. I created a basic UI where the user can change the volume and settings like fullscreen and resolution. I also implemented a simple data management system that can store encrypted data and in this case store the settings for the game. I also made some research about how to create a stable and usable state machine because I have never really been happy with my state management of things in games and finally figured out that state transitions can be saved in the state machine itself. By storing each transition between states in the state machine itself it becomes much easier to read what happens and hen the state can change compared to if the change happend inside each state itself making the code almost impossible to follow.
You can read more about my template I created for this game jam !!! here !!!!

_stateMachine.AddTransition(air, _deathState, () => _isGrounded && WaterLevel <= 0f);
_stateMachine.AddTransition(ground, _deathState, () => _isGrounded && WaterLevel <= 0f);
_stateMachine.AddAnyTransition(_squirt, CanWaterSquirt);
_stateMachine.AddTransition(_squirt, air, () => !_isGrounded && !_isUnderwater);
_stateMachine.AddTransition(_squirt, _underwater, () => !_isGrounded && _isUnderwater);
_stateMachine.AddTransition(_squirt, ground, () => _isGrounded && !_isUnderwater);
_stateMachine.AddTransition(ground, air, () => !_isGrounded && !_isUnderwater);
_stateMachine.AddTransition(air, ground, () => _isGrounded && !_isUnderwater);
_stateMachine.AddTransition(_underwater, leavingWater, () => !_isUnderwater && !_isGrounded);
_stateMachine.AddTransition(leavingWater, air, () => true);
_stateMachine.AddTransition(air, _underwater, () => _isUnderwater);
_stateMachine.SetState(_underwater);