itch.io

Neat idea for a game
I would adjust your wording in your instructions from "Turn Off Gravity" to "Toggle Gravity" though. I actually didn't realize that gravity could be turned back on until the final stage where it was actually impossible to complete without doing so. I suspected the other black holes could be used similarly, but when they killed me on impact, I started avoiding them as well as the rocks

I tried a few playthroughs, and it seems like the randomness of the rock positions is more a deciding factor on success than my reactions. In one case, I got unlucky on the 2nd wave and every single position had a rock, so there was no way to dodge. In the future, I'd make sure to put a limit on the number of positions that can be filled with rocks and maybe have the number gradually increase over the course of the game.

Also, without using the speed up ability constantly, I don't think there is enough reaction time to dodge the incoming rocks in time depending on their position since the ship doesn't move very fast without it, but the spinning background actually made me a bit dizzy when I did this. I recognize that this is the method that makes it appear the player is moving since the ship is actually stationary, but I'd recommend keeping the stars as they are, and rotating the player around a center point instead to avoid visual over-stimulation. Giving the ship a bit faster movement in its base state and limiting/discouraging constant use of speed up is a an example of a way to provide better risk/reward mechanism so the player doesn't just choose to only go fast or slow (which will make the mechanic self defeating)

Might be a bug, or might be something I misunderstood, but I wasn't able to repair the ship several times after collecting more than enough resources of all types. If I had to guess, it has something to do with storing the items after arriving back at the ship, because the first time I played, I didn't return until the backpack was full, and I could repair it that one time. Since I knew there was a capacity limitation, I started returning often to unload, and I was never able to repair then or in my subsequent playthroughs.

I actually didn't realize that the ship was taking damage over time, so I didn't repair on purpose since I was thinking of saving up for a hook/backpack upgrade instead. Then I got the in game warning, but I still could not repair unfortunately.

I really like the game idea though, and other than the situation I encountered, I think the presentation is pretty good. Similar to ocaviobia's comment, I'd suggest making it clearer if the hook should reach a target or not and/or make the upgrade for it cheaper so it can be acquired more quickly. Grouping the craters at distances that are easy to tell at a glance if the player can reach would help with route planning so you don't have to grapple to a location only to realize you are at a dead end and have to go back

A lot of other comments already covered some of the constructive feedback I was going to give, but I'd also say that the pacing could probably be improved by limiting the amount of cores needed from 10 down to something like 3, or increasing the rate that you would acquire them by having multiple boss stars appear together after you've collected a few cores already.

Also, having unavoidable attacks is a tricky kind of mechanic, because it punishes the player for not playing well enough in the past, rather than for how they are doing in the present. Pairing the helper stars with some kind of skill or ability to dodge/defend the attacks might be a better way to balance the amount of control the player has. I saw in another comment you mentioned wanting to include other abilities/drops. That sounds like a good opportunity to provide this kind of mechanic if the game gets expanded in the future.

Overall, I like the general idea though. Made me think of something like Slither.io with the constant collection and goal of growing larger

5☆ x4

My only complaint is that the game ended
Very well done

A lot of other comments here mentioned some of the feedback I was planning to, so I won't go into them too much.
For gravity flipping, having hazards that completely cover one side could be a way to incentivize the flip. Alternatively, requiring the player to collect items that are mid air

Having indication of where attacks are coming from a little before they show would be helpful as well. The first time I was killed by arrows from the bottom, I instantly died since I was on top of them, so I didn't even see the arrow until I retried and then figured out that's what had happened. Same thing happened with the ball a few times near the corner of the screen.

The soundtrack was very nice.
Also, that's a lot of cookies ◉_◉

As an endless runner, it's quite simple. Some things I can think of that would keep it more engaging for longer is to have hazards come in bursts. As it is, the only the decision the player has is up or down, and about 50% of the time, not moving is the correct choice. Also, increasing the speed of the gravity flip to go along with faster enemy movement would feel pretty good. Allowing the player to flip gravity midair and having airborne hazards is another idea.

Not sure if it will work well given that you had a mobile implementation, but I would have also liked to see the ability to jump alongside the gravity flip. That would give the player more options to respond to what could be coming ahead if there are hazards on both sides

I liked the sneaky spike. Gave me "I Wanna Be the Guy" vibes

I definitely had to play the windows version so I could hear the music. It sounded really good and worked with the the sound effects. The download version also appears to play and control faster/tighter

The visual style was very well done and unique. My constructive feedback on it is that I think it can create some difficulty/ambiguity in determining the location of objects in the distance. Having the grid lines help, but I noticed the barriers were not always lined up with them on the left/right side, which might help when you are going very fast. If there are more improvements in the future, creating simpler versions of objects that are far away that will render better and then swapping them out to the more detailed variant up close might also be something to consider.

For the speed up ability, I enjoyed going as fast as possible, but I felt like it was more punishing to do so as it just made it more likely I would crash. Having something like a ramp that lets you jump obstacles or long pits that can be overcome a high speed jump might be something that could make it feel more rewarding to go faster depending on the routing

Overall, I enjoyed it a lot, and look forward to seeing your future entries

Thank you for playing
Unfortunately, the game has no ending, so giving up was the right decision
I grew up in the 90s, so this style was pretty familiar to me. I also played through Pseudoregalia recently, and that lead to some of influence on visual simplicity.
Also, as a team of one, something was going to have to give :)

Thank you for the feedback.
I also was unsatisfied with the camera implementation, but I left it in to get feedback. The rotation is what lead to the aiming problem, as the aiming coordinates were originally based on a fixed angle camera, and then the issue was introduced when the rotation was added. The fix should be pretty easy as you said, but I didn't discover this until late into the project, so I wasn't able to fix it before release

I also have some ideas for larger levels, and actually designing the layout of the levels is something that can be done very quickly, but I wanted to have a more robust camera system in place before doing that

Thank you for the feedback.
Believe me, I jumped off the end as well. :)
I almost considered adding that into the game intentionally, but I wanted to focus on getting the platforming right first. Thinking about it now along with some of the other feedback I've been getting, jumping off the end as a level transition seems like a neat idea, so I might add that feature in the future if I continue working on this one beyond the game jam.

Also, glad you liked the camera effect. After I implemented it, I thought up a better way to design levels where there are multiple camera positions, so I'll definitely be using that technique more in the future

I agree the limitation implementation is weak in this entry. In this case, it's just that the player never stops moving, but it doesn't affect the gameplay too much as it is in the current state. I intended to add some hazards that required avoidance, but they ended up getting cut for time.

Thank you for playing and giving feedback

I feel the same way. It was hard to make good trade offs on time, but I ended up deciding to go with getting feedback on the core systems I implemented over more/complete content, even if they had flaws.

The shooting issue is likely caused from a bug due to the camera rotating as you move further in the stage. This made the firing angle much more inaccurate as you move to the right. I did find a solution to the problem, and I plan to implement the fix in the future, but the control was "good enough" to get feedback on since a player could still adjust the angle to compensate

Thank you for playing and for the feedback.
Unfortunately, that's all there is to it for now. With the limited time, I opted to get the control and movement working as nicely as possible in order to get feedback there over game completeness.

The normal endings 😭

It was a cute, short story. Well done

Maybe I'd make a bad older sibling, but I found leaving the brother behind in a "safe" place and then rushing the levels was the best way to progress. To be fair, he seemed to have quite a death wish, especially around pits. Having some mechanics in the future that require both brothers to be present in order to proceed would make sense to avoid that. It's possible that was in the game, but I got stuck on the stage with the yellow bars because the instruction text was behind the trees, and I couldn't figure out what it was supposed to say.

Overall, I do like the idea of escorting an innocent, helpless character to safety. Reminded me of ICO

Cute design
A lot of the improvements I'd suggest are already documented as known bugs. I think it'd also be nice to allow bigger purchases once the waves start getting bigger (resource consumed faster, block produces more units, etc). Also, it'd be interesting if there was some way to control units better (waypoints?) since they often ended up in sub optimal positions. I did explore a lot of the map for fun during one wave, and it got me thinking it'd be interesting if you were required to send units to fight structures, or place additional resources out in the field to collect, or something similar to give an incentive to explore more. Otherwise, you'd just stick near the very start area.

Very nice game overall

I didn't realize there was a mechanic for color attunement until I was about halfway through the game. I like the idea of it though. I noticed that enemies seem to spawn based on player location, and that lead to some of the archers being out of bounds sometimes.

I like that there are different abilities. Shield was my favorite. Energy use for abilities seems like it could be tuned a bit. I only tried the dash a few times, because it drained energy so quickly. Same with the projectile attack.

I felt bad for the golem being constantly berated :(

Overall, good theming and mechanics

The procedural generation aspect is neat, but if it wasn't mentioned, I wouldn't have known it was happening (until I played a 2nd time). For long load times, having a progress indicator would be helpful to indicate why the wait is occurring. The art itself looked nice and had a good theme.

Gameplaywise, having enemies move a bit faster, but also die faster might keep it a bit more engaging. I might just be a fast clicker, but I was often waiting for enemies to appear. I also found you could run into enemies to kill them at the cost of 5 ammo (but none regained after), which might be worth mentioning in the game description if it is intentional. I also found that my ammo could get into the negatives, so I wasn't actually limited by it. Might be an opportunity to consider a future mechanic for the situation when the player runs  out of ammo, but is still alive.

Thank you for playing, and for the feedback.

Actually, there is a bug that causes the attacks to not always start when they should once the enemies start speeding up. That may be part of the randomness. It would actually probably be harder if I fixed it without changing anything else, because the attacks would come much more frequently.

I originally wanted enemies to come and go, which I think could signal jumps in difficulty better. I do have some framework to support more complex behaviors, but a lot got cut for time. I might consider starting with a single shield and work up to two to give the player a chance to learn the mechanics (right now, you get thrown in the deep in instantly). Also, I wonder if having enemies only attack from one side would help reduce the multitasking burden early on.