Going to have to spend a lot of time optimizing for the collision/rope behavior bit. Thankfully, performance hasn't been a huge issue with my approach; but that's not necessarily true for future iterations.

The inspiration for this game ran on like 500MHz computers, so I know it's possible. :)

And we can de-tangle ourselves now, too. (Collision and positioning need work, but one thing at a time...)

After some review, some decisions:

X-axis: right is positive
Y-axis: down is positive

This will keep things in-line with most 2D systems (against chipmunk.)

Player/game entities will be center-positioned. Other elements TBD. (Godot implements a hybrid approach with offsets—reasonable.)

I’m sure more popular engines (e.g., godot) keep this all very tidy. But why not live life in hard mode?

Anyway, we now have a utils/ directory for coordinate system conversions.

I have a colleague who likes to say, “There’s the first 80% of a project, and then afterwards comes the second 80%.”

Oh! Found a golang port. Nice work, @jakecoffman.com!

This is why it'd be wonderful if avatars were all balls... but if they're circles, it really undermines the illusion of some anthropomorphized being. (While I can assume spherical horses of uniform density while calculating inertia, it doesn't work when walking into walls...)

Anyway, bitmaps it is!

The challenge now is how I want to handle if the player is in a confined space as, I had originally intended, the avatar rotation (and its bounding box) is different when standing, walking, and on-rope. If the world would prevent the player from changing state, how do we handle that?

... and while I haven't designed any of the characters, I can't imagine scenarios where I can't represent them with a circle or a convex polygon as their bounding box.

Maybe some pixels are soft and disintegrate on player contact, but not rope contact, and the player can overwrite that part of the world. Maybe going through material slows them down. Either way, should be computationally efficient. Polygon-on-polygon collisions would be mostly between avatars—easy.

So, another approach: maybe just make the world a huge 1-bit bitmap for shape, and map on some additional properties (e.g., material).

Collision detection is now a question of "would an avatar's polygon next move overlap a pixel" and, if yes, decide what to do. (Pixels may be different materials.)

Further, much of the world (as it is played on and generated) has crevices and holes (read: concave polygons), it introduces additional collision detection issues.

While it's *somewhat* trivial to decompose concave polygons into attached convex ones, it doesn't solve the spline-based complexities.

The problem I've had with all low-/no-code tools is that once you learn them well enough to be functional, you're going to massively prefer a text editor/IDE and a command line.