Thanks for reporting this! If you see it again, can you grab a save-state and let me know what emulator was being used?
I'm in the process of improving my collision detection to allow for better physics, and catching bugs like this is part of it.
jwrayth
Creator of
Recent community posts
It made me think of modern games by Hazelight Studios such as Split Fiction or It Takes Two. Neither of those had a dynamic split-screen to my knowledge, but both are excellent co-op games that benefit from exploring separately together. I'm more engineer than game designer, but I'd be interested to see where this could go on retro hardware!
Loved the visual aesthetic on this. The game was a lot of fun to play even though my times were pretty bad. The religious vibe isn't really my thing as an atheist, but from reading your devlog I really appreciate how much it means for you and I'm glad you were able to reconcile your faith and your desire to participate. Your work really shines, and the community is richer for your participation.
I played the 1.1 version as I tried to play the initial submit everyone made. I only had three real problems with it;
- The camera gets glitchy when at the bottom extent and you try to fly up. It looks like clamping logic gone awry, and is visually unpleasing
- The solid black text for the menu and tutorials has poor contrast and could do with an outline. You can see this on the right side of the title menu credits, or in gameplay when the tutorial text scrolls over a vine. Particularly apparent when playing composite on a CRT
- Very little animation during gameplay. Without animating things like the hungry dudes, my brain switched almost entirely to puzzle solving mode and it felt very functional and lost some of the intended charm
Outside of that though the gameplay was easy to understand, and the levels slowly introduce the layers of complexity available for puzzle designers. You should be very proud, this was a lot of fun to play!
I'm envious! You clearly delivered on the scope for your project, and there is so much present! Clearly I need to take some notes from your production process as I lacked focus.
I agree that a visual overhaul would make it more engaging, but the core mechanics are solid and fun. I hope you get some time to do further polish and this project could really shine bright :)
I scooped up all the initial submits everyone made, so I only played your first version. There wasn't much game there at that point unfortunately!
I think the concept of the game is difficult to get across without the external links you added, making it a bit out of scope for pick-up and play. I hope you finish it up, and maybe integrate some more tutorialization into the final build!
I unashamedly love Celeste, and I think this is a great port/demake/refactor for the SNES. I struggled with the controls a bit, but as feedback for my own game shows it appears I'm the outlier for how platform games should map controls on SNES.
It's a shame audio didn't make the cut as that really seals the deal on the vibe for this game, but I think you were wise to focus your efforts where you did and hopefully add audio after the jam!
I found this one a lot of fun, and only had to stop playing to make sure I had time to play all the other titles. Graphically, it could do with making better use of the SNES hardware as visually it looks more 8-bit than 16-bit.
Though I appreciate your visuals were a consistent aesthetic throughout.
I was immediately worried when I saw your submission go in, as what are the chances 2 participants both have carrots as protagonists? Fortunately we picked very different gameplay styles, which was then an immediate relief!
I lacked someone to test this with properly, but I played a couple of solo rounds just to get a feel for it. The concept was fun, but it feels like there are very repeatable strategies to win. I think adding some more power-ups like Bomberman to vary the choices the player has could really up the desire to replay.
Very polished and complete delivery of your idea. I was surprised you didn't revise it further since you submited way ahead of the deadline unlike some of us!
Reading your comments that you lost interest once at the "content" phase is a shame. Adding some basic enemy AI, and maybe one other enemy variant would expand the fun a lot. But it is a complete experience, unlike my game, so who am I to comment! :D
I couldn't really experience this one properly as I didn't have anyone to test it with. I struggled with the shooting controls a bit, but I think because I was just testing it solo I didn't really have the opportunity to get into the gameplay loop and have it all "click".
I'll be sure to give it a proper go when I have people around to help me test it properly!
I had been working on my tool-chain and engine for some time, albeit only in an on-and-off manner. This gave me a lot of confidence at the outset, which is why I budgeted so much of my time to the Mode7 work.
Outside of the UI library and the asset decompression, pretty much everything else had lots of bugs in it as my test roms simply weren't robust enough and when I tried to push systems (or use them together) lots of issues became apparent.
The ones that stick out;
- My VRAM allocator for sprites would occasionally re-use slots due to an aliased ZP variable I had accidentally introduced, corrupting VFX seemingly at random
- I crammed too much code into Bank 0 early on being lazy, and had to stop and de-tangling things and group/split logic between 0 and 1, to avoid long-jumping all over the place
- My player state handling was too rigid, and made it difficult to introduce the platform mechanics I wanted, so I had to stop and re-write it to make the movement feel good (though I heard loud and clear that input mapping was still not what people expected!)
- My toolchain for palette quantization/optimization has some bugs when animating palettes, which would cause palettes to not coalesce correctly, resulting in bad (or missing) colours. I ended up swapping some animations to be blitting instead
- My engine incorrectly set some VBLANK only registers ouside of VBLANK, which worked fine in emulators and hardware on my test-roms, but caused issues once enough real logic was occurring each frame. So I had to refactor and buffer them correctly
You get the idea! For every feature I added to the very short game, I spent far more time just bug-fixing systems I thought were ready for use already. Add into that a fulltime job, Wife and Kids, and all the other things real-life throws at you I just simply did not have the time I thought I would have for forward progress.
Pretty much all my time for level design, music, etc... which got crunched down into the last 5 days of the jam to polish what I had. Which is why the music has short loops, menu SFX are missing, the levels are short, some jumps are not possible, and tutorial text/NPCs were dropped.
Lesson learned, humble pie very much eaten :D And at least I have all these fixes integrated back into the engine/tools for any future projects now!
Thanks for playing!
The game is unfortunately very short as delivered. There are two grasslands rooms, and the entrance to the underground tower. I sunk a lot of time trying to make my mode infinite runner bonus level, and that didn't pan out in the end.
I opted to focus on bug fixing with the time I haf, which meant cutting back on broken content. I do plan to fix all the busted stuff post-Jam, but I just ran out of time!
Thanks for taking the time to play, and all the kind feedback!
I've taken a little break for this first week as I crunched quite hard at the end, but my first order of business is to re-write my input processing so I can more easily change the input mappings, and hopefully make it so the user can pick between simple preset mappings. That should make it easier to test different configs, and I'd also like to add some accessibility features to the inputs too!
I'm going to look at the wall-slide state too, and use that to allow for instant jumps. And also have that as the indicator for surfaces that can be grabbed (i.e. if you don't enter the wall-slide state/animation, then the grab is not possible). Though my physics don't currently mark up if vertical surfaces can be grabbed or not, so they are all grabbable. Another feature for the list, along with correctly marking inclination on surfaces so I can adjust speed on uphill/downhill traversal!
Thanks for taking the time to play!
I think it feels particularly difficult on Emulator.js on keyboard. Something seems slightly off making the wall grab much harder there.
Feedback elsewhere about the wall grab on shoulder was similar. I think fluidity would be improved by allowing hold DPAD in the wall direction to do a wall slide, and then L is reserved for a wall-grab, to hold in place. That ties in with the desire to have a projectile power-up that you can aim when wall-grabbing (so hold L to stay in place, and use D-PAD to aim)
A cut feature was to be able to pull items as well as push them, and L is intended for that too. I got the physics working (which if you go left from Player start you can see, if you haven't tried that!).
Thanks for taking the time to play, and to give feedback!
A theme is emerging that the controls aren't quite what people expected. I fully admit that the only tester was myself, which hardly makes for a diverse set of perspectives! I originally had a wider move set, but with the features I cut I agree that putting run on both Y and A, and then B for jump would make for a more comfortable experience.
I based the wall grab off of the controls in Celeste, as I personally found that very intuitive. I do lack the intermediary wall-slide they have though allowing for a quicker wall jump, which is perhaps the key to making everything more fluid!
I'll be sure to fold this in to post-jam revisions I'd like to make :)
Thanks for taking the time to give feedback! The wall-jumping is much easier with a pad than using key-bindings. Emulator.js seems to also make it harder somehow, and I have to admit I didn't test on that until after I submitted.
The jump height changed many times across the jam! You can hold A to jump higher, but perhaps the additional impulse is too weak. I intended to re-tune it once I had more of my level layout implemented, but ultimately my time management was poor. There is actually an unfinished "high-jump", but more than half the time it glitches the player into the ground, so on the cutting room floor it went for the sake of the jam.
After the jam, I think I can probably address your two concerns
- See if I can introduce some coyote-frames into the wall-grab, to make it easier for playing on emulators
- Finish implementing the high-jump, and rebalance the level geometry to match the player athletics, along with tuning the normal jump.
