Updated my game so poor cat no longer getting stack and you don’t t have to mash a spacebar to unstack it. Also fixed a graphical glitch at the end screen.
Changelog v.1.01:
-Fixed a bug, where cat would get stack after unlocking the door with key and then trying to pick up an item or pressing action button.
-Fixed a bug where level by level times would duplicate at a final screen after beating game more than one time.
First of all thanks everybody who played and rated my silly little water cat game. And I especially grateful for the comments, the feedback was really positive and very motivational!
Now I want to share some lessons I learned during this Jam. First day of the Jam I dedicated to conceptualizing how mechanics would work and how to design puzzles around them and also I sketched some level designs on paper, the rest of the day I spend coding the movement and physics system. While the GameMaker studio (that this game is created in and that also that sponsoring this Jam, thank you GameMaker) has a good inbuilt physics engine I had no idea how to implement buoyancy with it and also I deduced that coding system that predict throw trajectories with it would be outside of this project scope and timeframe. So I built a very primitive physics system from scratch. Unfortunately, despite primitivity, the code was junky and had bugs. 😔
And it lead to some time being waisted in trying to polish system and fix bugs. The thing that helped me, despite my initial stubbornness, was writing a bedbug system for visualizing collisions and applied forces. While I was sure that I didn’t need it, in actuality it was immensely useful and helped to quickly fix my physics system.
Early gameplay prototype.
You can see how the white collision lines are visible on this key:
So the lesson learned - when you have a slightest problem with your systems - write a tool to bedbug and visualize them, even if you are sure you understand how everything work and you don't need such tools.
And for the reference, the final gameplay and physics look like this:
Next part sometime next week. I will talk about level design in that one.
This time I want to write about things I learned about level design and communication while doing my game for this jam - Water Cat. I will spoil some levels and solutions for my game!
So I welcome you to PLAY IT and beat my game if you haven’t yet for better understanding of this post, it’s a short puzzle-platformer, takes 5-10 minutes it seems, according to comments. Thanks everybody who left comments and ratings! Well without further delay here we go:
Important mechanic and basis for puzzles of my game is buoyancy and changing water level in the rooms. And while I explained controls and basic mechanics in text, buoyancy is actually never expertly explained in text! * It’s only demonstrated to player through level/puzzle design.* The fact that keys float is the key (pun intended) to solving puzzles and is firstly demonstrated to the player early in game on this level:
And the knowledge that key float is not exactly needed to solve this puzzle, but to beat this level player need to rise the water level and this makes key float and this information is once again demonstrated shortly after even more explicitly.
And the player gains understanding of this mechanics almost on an automatic level.
So the lesson is it’s possible to communicate gameplay ideas/rules (that have some complexity) through level design alone without pointing to it with text or interface. And people have a very good ability to pick on it in almost subconscious way. I think I underestimated this in this project and slightly overdone repetition of information in level design, so some people felt (rightly so) that the puzzle design is slightly repetitive as the result. So don’t underestimate the ability of player to pick up on rules through puzzle design, I will try not to next time!
Us a counter example the information that boxes sink is also important, but I actually failed to communicate it properly on a first try. The level where this information was important was design this way:
And it’s frustrating if you don’t know difference between boxes and keys.
So I added a pillar below the switches rising part of level, it solved some other problems, but most importantly now player is observed that box doesn’t float when water level rises as one of the first actions. And this gives this needed knowledge to the player! The level in the final game:
So I guess lesson is don't forget to show player the information you try to communicate. And also small changes in level design can have a huge consequences!
Maybe this information is quite obvious, but for me it was something that I learned during this jam and I am sharing it. Firstly I wanted to explain all mechanics through text, but it was unnecessary and explaining through level design is more effective and more fun at lest this is what is my conclusion.
That is it. Thank you for reading!
PART ONE is here if you are interested.
Congratulations to the winners and thank you, everybody who rated and commented my game!
