Thank you for saying so! I did my best to make it as great as it could be!
Zwataketa
Creator of
Recent community posts
I FIGURED IT OUT! So the save file should be tracking the deaths properly, but I messed up on the order of the characters in the ending screen. So the game knows you've gotten the ending where Yoshiki is the only dead character, but it's listing as though you have the ending where only Ayumi dies in its place. So the ending you're ACTUALLY missing is the one where Ayumi is the only death.
I'll make a quick patch to fix this, but you should be able to just kill Ayumi in the Science Lab and complete that ending list. Sorry for the confusion, and again, thank you for bringing this to my attention! Feedback like this helps us solo devs improve our games!
Fun you should mention that, most of the code in this project was taken from another project I'm working on. That said, I used this project as a chance to further along some things I needed to do anyway for that project. Basically, I'm definitely going to continue working on this. Thanks for the compliments!
(major reason the controls ended up so awkward was that the initial project wasn't designed with mobile controls in mind ^^')
This is an interesting game with tricky gameplay. With some refinement, I can see this type of game going places. Perhaps a bit more leeway could be given, such as making the lizard's body hitbox a little smaller and the hand hitboxes bigger (for grabbing the wall). As well, make it so the player is clamped to the sides of the screen, perhaps?
Immediately, the UI is pretty basic. Aside from that, this game's visuals look decent. Animations look well done and give ample feedback, tho particle effects upon clearing runes would help. The lack of sounds of any kind makes the experience a little ... underwhelming? I'd also argue that it would be wise to try and speed up the game a bit. I also noticed that you can move pieces while they're still falling, which at first I thought was a cool combo mechanic ... until it glitched the game into leaving blank spots on the board and completely changing others. Maybe should add more checks there.
Overall, an interesting system with potential if you turn glitches into mechanics, but it definitely needs some more work to be a solid game.
Also, I was able to score extra points while the results screen was happening, so that happened.
Not gonna lie, it was difficult to discern the instructions due to the colors of the text of the background. A panel behind the text would help.
The rocket not being animated in the slightest looks strange. Could help to animate the flame a tiny bit. Even mirroring that part for the second frame could help. I also had to force-close the game to escape the tutorial ...
The minimap was a nice touch, even if a tad unoptimized. I think rotating the rocket according to the direction it's moving would have helped a lot in making this game look more cleanly programmed.
Red background for hardmode. Nice.
If you were to iterate off this, I'd say adding a radar that detects things a certain distance away from the player would go a long way.
The title goes behind the buttons, might want to move it further up.
Levels are very open, yet condensed enough that getting lost isn't an issue.
I ... think I accidentally found a button to skip levels tho while in the help screen. So there's that.
The music was well made and bouncy. Fits the game well. But why does it cut out when you get a powerup?
The sawblade was a little fast. Was surprised to learn it was an enemy by accident, tho.
More lives or a health system would have helped the game, as well as being able to replay the level directly, without needing to restart the game.
This has potential. Would be interesting to see a game like this with a larger open map split into sections, kinda like a Metroidvania-lite. Just give more mercy mechanics and more actions to the player, and you've got a solid foundation.
The artwork looks pretty sweet (pun not intended). It's clear you put a lot of charm into this game's presentation!
I was confused at first by how to play the game, and wondering why the attack key wasn't working, until I played for a bit (on my second summon) and realized the attacks happened in "phases". It would have helped to be more clear on that front, as well as potentially adding some visual feedback for when the attack phase will trigger.
The gameplay works, but it's pretty basic overall. All it is is dodging cherries and then tapping the screen every now and then. I feel like more can be done to spice things up.
The gameplay loop, however, I can see being addicting if the gameplay is fleshed out with more features and mechanics.
The color switcher seemed unresponsive at times. It's also not really clear how battles are meant to be triggered. The description says they're supposed to be available when you have 10+ items, but I've been able to trigger battles with less items, and also been unable to trigger battles with more ... actually, that has me curious if you have a greater-than/less-than in the code that needed to be reversed.
It's admittedly annoying having no influence over the battle going on. Ie, berries are pointless to get and just waste a turn if you have none, so they probably shouldn't appear when you have no berries. on that note, using berries at full health is wasteful, so perhaps make it so no berries are used if the player is at full health.
Excuse me, I'm trying to apply this to my project, but I would like to make it only affect the background and tiles, if possible, not sprites. How would I change the code to accomplish this?
For the record, I have gotten it to work automatically, and with timers I've made it so it only shifts the hue a certain amount back and forth, it's just I don't know how to make it discriminate between sprites and background/tilesets. That's what I need help with.