Play game
Jelly with Attractive Momentum's itch.io pageResults
| Criteria | Rank | Score* | Raw Score |
| Creativity | #2 | 3.400 | 3.400 |
| Concept | #2 | 3.800 | 3.800 |
| Enjoyment | #4 | 3.400 | 3.400 |
| Adherence to the Theme | #4 | 4.600 | 4.600 |
| Audio | #4 | 3.600 | 3.600 |
| Game Design | #5 | 3.000 | 3.000 |
| Overall | #5 | 3.400 | 3.400 |
| Presentation | #7 | 2.000 | 2.000 |
Ranked from 5 ratings. Score is adjusted from raw score by the median number of ratings per game in the jam.
Leave a comment
Log in with itch.io to leave a comment.
Comments
Great work with the physics and control scheme - it felt pretty new and different! The visual assets were rather spartan - it would be awesome to see how the game looks and feels after some polish with some freely available assets from around the web :)
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...
I can see you spent quite some time in the physics, it's really precise and well done!
It took me a bit of time to reach the end of the level, I like the fact it's a bit different to usual platformers, this is a really interesting attempt for something new thanks to the controls. There is a lot of cool ideas than can be added to this concept if you want to push it a bit further after the jam!
Oh and cool 8-bit music!
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.
Cool concept, I don't think I've ever played something with a control scheme quite like this :D
The physics for jumping and the "attraction" towards your cursor feel really natural, which is an impressive achievement in a bare-bones engine like Gosu. That meant that, when I fell off, it felt like my fault, rather than the game's fault, which means it's rewarding when I managed to complete a level.
With some more polish outside of the time constraints of the jam (e.g. moving onto the next level automatically), I could see this being really excellent!
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.
The concept is interesting. It's quite frustrating to have to validate ourselves that the goal is reached (which seems quite easy to implement since your collisions seem to work really ok). The game really must be played fullscreen because the mouse is not constrained inside the screen.
But I really wanted to clear every level and quite enjoyed it. Nice work !
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.