Post-jam version design insight

Hey! Yesterday I made a post on the Ludum Dare page announcing this post-jam version, sharing some reasoning behind the design choices made to this new version.

I thought I would share that post here, along with some more extensive explanations that would have made the original post too long for my liking for the Ludum Dare site. This post is mainly focused on the main mechanical changes of the game.

This post contains more information than the original, but you can read the original here if you wish.

Note: this is a repost to migrate it from the temporal post-jam version project, since development will now continue on the original project page (this one).

Introduction

The main mechanic of my game is that the player can place "lab shapes" only while encasing their playing character (a slime) to try to solve puzzles and platform their way out of each level. The slime can only wall-jump using lab shapes, thus allowing more freedom of movement while limiting it at the same time.

Some levels use more than one shape (older shapes get replaced), some levels use different shapes (e.g. a triangle), and some of the puzzles require the player to "catch" the slime with a lab shape while the slime is mid-air.

New collisions, movement, and lab shape planning mechanic

While watching others play, I observed that they would often figure the right solution to a puzzle, but they couldn't execute it reliably because placing the shapes to "catch" the slime while falling or jumping was too hard.

This problem was caused by three main reasons I think:

Reason 1: The slime's collision check for shape placement was too strict.

Each shape has a single CollisionShape2D inside of it. The player's character has four, one on each orthogonal direction.

Old Collisions for shape placement:

The way I check to see if the slime is completely inside of the shape is by counting the number of player collisions with the shape's inside Area2D, if the number is 4, the player is inside. Note: I could have used a single point in the middle of the player's sprite to check, but I am also using the same collision boxes to do some checks while the slime slides on walls.

Originally I had setup these four CollisionShapes one pixel outside of the slime sprite's. This was done because, during playtesting during the jam, there was a way of placing the shape without the slime inside if the player flicked the mouse very fast while clicking.

Having all CollisionShapes outside of the slime alleviated the flicking problem, but I knew that it was not the solution (I also went overboard with the top collision, oops). The solution, implemented later during the jam, was to use a ShapeCast2D instead of an Area2D. Differing from Area2D, ShapeCast2D has a method to instantly check collisions with other PhysicsBody2D nodes.

This solved the problem with the flicking, but during the rush of the event I forgot to move the four collisions back to where they belonged, so they were still checking a pixel outside of the slime's sprite in the jam version.

The solution

The solution, obviously, was to move the colliders inside the slime sprite.

Below you can see a comparison of shape placement with the old(left) collision not allowing placement even if the slime is clearly inside the shape, and new(right) collision functioning as expected.

Reason 2: The player movement's accelerations were too high.

This was a very simple problem to identify, but complicated to correct. Acceleration for left and right movement were too high. This, combined with a very heavy gravity value, made it too hard to "catch" the slime in the air.

The movement in general felt bad in my opinion.

The solution

I decided to rewrite most of the movement code from scratch. The new code implements a lower gravity and accelerations, jump buffering, and coyote time. It also solves some bugs with animations during wall jumps.

These changes allow the player to have more control over their movement and the character. Also, the lower gravity gives players more reaction time to catch the slime if they try to do so.

Reason 3: A shape required the slime to be completely inside of its area to be placed.

So, this is probably the main cause of the original frustration with catching the slime mid-air. The problem is that, it is also the main mechanic of the game.

Being honest, during the jam, doing playtesting myself, I didn't really see catching the slime as such a difficult task that it would become a problem. I couldn't catch the slime 100% of the time, but it didn't feel as something so hard that would require fixing, so I kept it that way.

I started really noticing it as a problem as comments started to roll in after submission and I started doing playtesting with people of different skill levels.

Watching many people of different skill levels struggle with the shape placement, made me realize that, while they had figured the answer to the puzzle, their fun in solving it was being diminished by not being able to place the shape with a very strict timing. In conclusion: requiring the slime to be inside of the shape the moment the player clicks, was ruining the fun of my game on levels were "catching" was necessary.

Thankfully, I got the solution from feedback from the jam.

The solution

One of the comments I received from @mcbombadev(from ldjam.com) suggested that a shape could be placed in a "ghost state" anywhere on the level, and would later be completely placed once the player jumps in.

This ended up being the solution I went with. I think this solves the problem nicely without lowering the skill ceiling of the platforming aspect too much.

This, combined with the new more fluid and "floatier" movement, made the game more accessible and less frustrating for players.

Experimental grid assisted shape placement

Another point I noticed during playtesting was that, again, players would figure the solution, but would often place a lab shape a couple of pixels off, causing them to not be able to complete the level.

An experimental solution I am trying for this, is the use of a grid-assisted placement. Players can toggle it by pressing [tab].

While it is active, shapes follow an 8x8px invisible grid. This helps players place shapes correctly with less precision. If this change makes the game too easy, I can try making the grid 4x4px or 2x2px, thus requiring more precision from the player, before trying something else if necessary.

Implementing this does modify design decisions for the game a little bit. If I commit to use the grid as a permanent solution, I need to make sure that every level can be solved with this grid ON all the time. If I commit to keep the grid as a toggle, I need to make sure that every level can be solved both with the grid ON and OFF.

So far, it hasn't affected the current 3 levels, but, while working on new levels, I have identified some situations where platform walls may interfere with wall-jumps on shapes placed using the grid. Nothing really too major, but I do have to pay attention to that.

Internal playtesting results of this post-jam version

So far, internal playtesting with these changes has been positive. The game looks and feels more accessible now.

Using the planning mechanic, a friend of mine was able to find a way to finish the last level using only 2 of 3 lab shapes. This was already possible before introducing this new ability, but I guess being able to place shapes more reliably facilitates this kind of skill expression. His method is completely unintended by me, and looks like a speedrun strat, which I didn't think my game would have, but I love that it does. It was truly a proud moment for me to see it happen.

The only point that has been made is that players expected to be able to just click a planned lab shape (before its placed) to "pick it up" again to be able to plan it or place it somewhere else. This is something that I plan to add on a later version.

Future versions

In a new post-jam version, I have already reworked all levels, and added a couple to have a (hopefully) smoother difficulty curve. I hope to upload this new version soon. After that, I am thinking about expanding and polishing this game further into a full release. I already have many ideas on new mechanics to add to the game.

I hope this insight on the changes made to the post-jam version of my game were useful or at least interesting to read.

Thank you for reading!