GOBI

I set my sights on another game jam. GOBI is the result of my efforts. I've had lots of fun coding the rope physics, the main gameplay element.

The theme for this year's H-BRS Game Jam, a game jam organized by a university near Cologne, was "It's all connected!".

Since I am writing this way after the fact, I don't remember my exact thought process, but at some point my mind must have made a connection to ropes or cables fitting the theme.

Over time, this manifested into the idea of a game where you are tasked with connecting ancient monoliths using a physically simulated rope. This also gave me guidance on the look and feel of the game.

Coding Realistic Tension into Rope Physics

The core gameplay loop of GOBI lies in solving a series of physics-based puzzles. These require you to be able to drag a rope behind you, while always pulling back from the rope source, keeping the rope under tension.

Additionally, the rope needs to collide with certain objects, not phase through them on a whim. Doing this turned out to be a bit more tricky than anticipated at first.

The first pain point was easily solved. We can model a rope as a series of points tugging at each other. Below you can see this represented with my debug mode. I always suggest creating some tooling to handle larger gameplay elements like this. It always helps a whole bunch when trying to find bugs.

All we have to do is scale the force applied according to the distance of adjacent points:

var force_magnitude: float = pow(2.5, distance_to_next_node - node_target_distance) - (node_target_distance / distance_to_next_node) cable_nodes[c].apply_central_impulse(direction_to_next_node * min(force_magnitude, 20) * 5)

From this code snippet we can already see how I ended up solving problem number two. I solved this by instantiating every point as a RigidBody3D, which prevents them from passing through solid objects.

At first, I tried completely simulating the points, calculating their positions in code using the forces, saving their velocity and using Newton's laws to accelerate them. But this way I get that and collisions in one.

The next problem I faced was the cable still phasing through slim rigid objects. You can imagine why, but just for clarity I used my amazing paint skills to help with understanding:

Remedying this problem was rather tricky.

In a desperate attempt i started upping the spawn rate, by increasing the force between points and reducing the distance from the spawn, at which a new point would be spawned.

But this wouldn't solve the problem reliably. The core problem remained that the new points would have trouble reaching the sparse parts of the rope in time.

After some fooling around I finally came to the realization that new points wouldn't have to originate from the spawn point, but could be spawned between any two points that were too far apart.

This ended up fixing the problem of phasing through objects. While this caused the rope to slack at times, it was quickly solved by adjusting the forces again.

Struggling with Level Design

People keep saying that with a good puzzle game the puzzles design themselves.

The process of designing the gameplay [...] was more like discovering things that already exist, than [...] creating something new and arbitrary. ~ Jonathan Blow, GDC 2011 - Truth in Game Design

This means either my game idea wasn't very good, or I just suck at finding what's already there.

Creating interesting puzzles just by blocking off direct pathways proved rather difficult. Playing level 2 for yourself you might discover the first interesting aspect of this physics based game:

The direction - clockwise or counter-clockwise - in which you wrap around an obstacle matters, because it determines where exactly you will stand after connecting the monolith, possibly blocking off a pathway to certain positions.

To me this sounded like an interesting, diegetic result of the gameplay elements' interaction. The problem was, after this I found it very hard to come up with further ideas to expand upon this.

Level 3 essentially offers nothing new mechanic-wise; it just makes the pathway more convoluted. That is where the demo ends.

I thought of adding moving monoliths or platforms, varying elevations and other environmental changes, but failed to do so.

Style and Polish

I tend to spend a lot of time on technicalities and gameplay, oftentimes resulting in a lack of polish. This time I planned for some level of polish ahead of time, and with my mental blockage concerning level design this gave me some space to make some improvements.

I added sounds, some of which I stole off the internet, some self-made from old projects. I am happy I had time to add footstep sounds, which elevated the game feel a bunch.

While most materials I used were taken from MaterialMakers Asset Library the meshes were not. I had time to turn the blockouts into proper geometry in Blender.

End of Jam

After 72 hours of jammin' the game jam ended and it was time for the judges to rate our games.

I would have loved to add more levels, overcoming the struggles I had with that, maybe also adding a tool that allows me to generate the walls around a level, something that took a lot of time using Blender.

I ended up placing 3rd (results were not published on itch.io), a placement I am genuinely happy about. The judges even provided us with some critique, mine being that the game was a bit short, but also complimenting me on the mechanics and setting.

I am looking forward to competing in the next H-BRS Jam in a year,

Best regards, Max!

written on 24.02.2026