Yeah, I see where that "available assets from around the web" vibe is coming from :D . When I checked your submissions I was at first really confused – me being mostly solely in the DIY state of mind, this project being my first gosu one to use some third-party stuff assets – why you spent spent so much of your limited time on creation of all those various assets...

ad physics: Thanks. I believe even  more "types" of jump can be set with the current model if the play area was bigger. One idea was to have some collectibles which upgrade your max momentum – thus making some sort of metroidvania with keys blocking  future area, allowing you to cross gaps you used to not be able to..

But I was outright scared switching to a smaller tilesize (say, half the current one) as I was unsure how well collision detection would fare if size of tile was odd. Also, block placement is via coords instead of having 2D char map which would be tiresome to convert to the new tilesize.

ad music: Yay for finally getting to adding music/sound into any gosu project. Next time it should thus not look like a such a hurdle and can be done much more quickly.

ad controls: Glad you liked it.  Actually, the original idea was for the jelly to autojump like every 2 seconds while player would be in  control only of x-movement. Using mouse instead of keyboard seemed then more appropriate to allow for ... hmm, let's call it "continuous control". When I moved away from teleporting to directional movement in one early commit I set it up again in the acceleration style akin to gravity in Crane Construction. The plan was to iterate to much tighter control scheme but I found I actually liked this "big momentum" way.

ad physics model: I guess the acceleration model is what connects this game with my submissions for the previous gosu jams. While I used some bits of old code as a base they were then heavily modified to fit the new use. I think the biggest help from previous project was knowing which pitfalls to look for in this area. E.g. I already knew it is good idea to regularly round coords or at least speed to prevent floating point operations to break the collision detection code, at least when dealing with static walls at integer coords. I am also trying to use static variables as much as possible – that way it is easy to change one constant up and down and immediately affect all parts of code while tweaking the "feel" of physics model.

Yes, I am looking forward to polishing it more once the jam. One such planned thing is to have the jelly squeeze/swoosh/rebounce a bit at the end of jump sequence so that it actually gets true to it s name.

ad portals: Yeah, due to time constraints I got to adding portals only in like the last two hours before the end of submission time. Adding them seemed important to convey where is player expected to go. But once they got added it seemed to me I can use the rest of time to either update the collisions so that touching the portal activates it and loads the next room or I can work on sound instead. Knowing there is that debug/cheat for skipping levels as a rudimentary way I opted for the second option. This is actually my first gosu project with any music/sound so it took such a "chunk" of develop time – next time (once the desired sound files get selected) the sound coding part should be extra fast as I won't have to consult documentation to find how it is actually done... :D

ad mouse: What's more the game kept updating even when I was trying to make screenshots for marketing purposes so making sure some nice state of game is there while the pointer is well placed took quite a few tries to capture. Having a pause feature would help I guess.

Thanks for the feedback, making the portals work is a top priority for after-jam development.