The water section was added fairly late in the development of the game, so I was probably a little fatigued, and given its size (22 rooms, each 7x7 tiles in size, but collision behaves poorly if bordering tiles don't match ground with ground and air/water with air/water, so really I've got a 6x6 area to work with) I simply didn't bother with adding generic landmarks that'd just make it harder to get through the solution, which ended up making it kind of impossible to map the area out in your head and build a sense of what's going on and how to navigate it. Sorry about all that.

The music is actually not composed by me- it was something copyright-free I found in the jam raft discord's resources channel (by the name of "8Bit Cave Loop", by "Wolfgang_"). I'm glad I didn't have to make any crummy programmer-music for the game, otherwise I would've been doomed (the sound effects, which are by me, certainly aren't groundbreaking)

The controller thing is a good point, which I hadn't considered before. The game wasn't made with controllers very strongly in mind (there was the real chance there would've been no way to interact with NPCs on a controller had I not thought "wouldn't it be cool if...")

If I make a post-jam version with feedback taken into account, controllers would get better support- using the second joystick to pan the camera as if it were the mouse, moving jumping onto space and one of the controller buttons (A or B, I don't know enough about controller accepted norms to know intuitively which one). Most of all, there's difficulty in maneuvering into 1-block-wide gaps which I really want to make special collision-cases for but definitely didn't have the time to hammer out during the jam period.

I'm confused on the camera part though. What about the camera isn't smooth...? It's locked to the pixel grid, so it can't exactly be perfectly smooth, but it's not disjointed anywhere (the non-euclidean approach made camera position-continuity non-trivial, so I've made sure of this much), and the movement of the camera is governed by a target point, which it moves some small % towards each frame, so it _should_ be as smooth as a 64x64 screen will allow...

Err, if you mean "I can't pan as much as expected", this is for an unfortunate reason. The way rendering works is rigid, deliberate, and not easily expandable. Theoretically the conceptual model I'm using to represent the world could be extended out infinitely, but there is no procedural aspect to the rendering, and each tile would have to be manually added to the queue (with more logic involved as more possibilities arise, like a tile being fully obscured by perspective lines, or being partly obscured but not by a perspective line starting at one of its corners). Right now, the tile the player is on, the four tiles adjacent to that tile (north, south, east, west), and the eight tiles which could be depicted as on the corners of that tile (northwest, northeast, southwest, southeast, westnorth, eastnorth, westsouth, eastsouth), are all rendered in whole or in part. Anything outside of that 3x3 grid is not rendered, so panning further than what the camera allows _now_ would reveal the edge of the tiles (and in some extreme cases, I think you can still just about see that edge anyways...)