itch.io

o_0

A cooldown on turrets would not make much sense as you can just look at the turrets when you first enter the room, you can see how fast each is shooting and how fast the bullets are, they are all very predictable, so a timer on that would be completely redundant and just be unnecessary clutter, how do you imagine all those UI elements would look when there would be multiple turrets next to one another. I don't really understand your point about being able to only see bullets that are about to hit you i'm assuming? All the turrets shoot in the exact same pattern that they start at and they can only go in a straight line. Similar to when you walk into a room you look at all the elements of a puzzle the same way you can look at all the lines of fire and their properties. It is up to the player to discover their own limits of what they can do with the tools they were given, with the level design giving opportunites for the player to do so. As for the delay in switching, when the player first gets the Philosopher's stone, they're immediately faced with a green turret that they have to get past using the stone. It was a green turret on purpose, as it being green forces the player to cycle through the elements at least twice and discover that there is a delay when switching. Same with the room afterwards there are green floor traps where the player has a chance to make that connection again. The same way there is weight and delay to pushing blocks, the Philosopher's stone shares that same property and is not unprecedented. I don't think it's a great idea to design mechanics around the player immediately doubting the way they are being used. All of the puzzles are designed around the delay and are completable as such, so i don't think there is much I can do about a player coming to a conclusion that something is an oversight before trying to think of ways that it might be intended. If there was no delay, I'd argue it would have much bigger consequences on clarity, as a player who sees that they can at any moment protect themselves from any element, might try to brute force puzzles that had more moving parts than using purely reactionary gameplay.

Yes, when switching between elements the delay is on purpose, it is quite important for a lot of the puzzle design. Once again it's the case of it not always being "Can I react to something in time?" but "Will i have the opportunity to react something in time" and is part of the puzzle itself and not purely a reactionary mechanic. Also, you are able to switch elements and move at the same time, so I'm not sure what you are talking about.

Thanks for the lengthy feedback, I'll try to share some of my thoughts on the issues you brought up.

The clash: The delay when pushing boxes was an intentional decision and it was not only to give the player weight to their actions, but also as a tool to create puzzles. The emitters (or sentries as i will call them from now on) do not exist purely as an obstacle to be avoided or dodged. They are there to be interacted with and are a part of the puzzle themselves. Making them exist completely within their own bubble as to not disrupt you when you're trying to solve a puzzle would completely undermine their point. They are supposed to exert pressure on the player while solving regular puzzles, and it's something i wanted to achieve with the game from the start. The question these sentries pose should not always be "Am I fast enough to react to them accordingly?" but also "Will i have the opportunity to react accordingly?". They require more than pure reactionary gameplay but also planning through interacting with other puzzle elements (such as pushing boxes). Though not every single room will require that of the player, as some rooms are purely about dodging while some rooms are more about solving a puzzle, but I tried to get a mix of both while making the levels. There might not be enough of the game yet to solidify this concept and get used to this sort of relationship as a player, but I believe with more mechanics and different adjustments, the path to getting familiar with it could be a lot smoother.

The progression: I agree, more rooms to introduce certain mechanics and play around with them more would be great, but unfortunately, game jams just end up being like that where you never get to do fully what you wanted (btw this game had no testing outside of me done up until the last 4 hours before the deadline lol). Every single mechanic did have at least one room where it gets taught to the player but I did plan to make more than just one. As for the example with the button and traps, I agree I could've done one more room right before it with just a simpler version with only traps, though i do not think it is a major problem, since while the level may look intimidating, it is rather easy in execution and the mechanics of each trap would be rather quickly understood by the player. I understand the sentiment that you should assume your player knows nothing about your game, but this game was made in mind with a very specific audience in mind, as well as the difficulty (especially in the later rooms) sets some minimum expectations that I kept in mind while designing those early levels. Also to talk, a little about THAT room that you had trouble with. I agree, I should've made a room right before it that played around with those mechanics in a bit more clear way. But i have to mention that every single mechanic that room expects of you, the game did teach in an earlier room. For example, there was a room where the only way to progress was to block out a stream of bullets from a green sentry just enough as to make a bubble of space further down the stream to walk down it and have enough time to cycle through your elements. That was one of the lessons that one room used, and the other one was simply weaving through openings in the bullet streams, which is a mechanic present throughout the entire game. The trickiest part of it was going through multiple streams of bullets and switching elements while doing so which i admit, I could've introduced in a room before, a little bit better.

The death screen: This one is a bit strange as this is the first time I've heard someone actually complain about the death screen. The death screen, in my opinion, is very quick and seamless and puts you right back at the start of the room. When you die, the thing that killed you also gets highlighted on the death screen, as to let you know what killed you, so next time you can be more aware of it. This is the first time someone thought it was too slow or annoying, as most people specifically commented on it being very satisfying and "fun to die", so I'm not sure as to what to make of this (btw if you spam z you can speed it up).

The text: I agree. These text options were unironically extremely hard to work with, and we didn't think putting more effort into them was worth it, as reading text didn't comprise that much of the game.

Thanks for the feedback. The delay between switching elements is intentional as it gives room to design puzzles around it. There was an idea for an upgrade to it that the player would get later on where the delay would be reduced and the player would be able to switch freely between all elements but we didn't end up doing it.

Very interesting idea. The game ran very poorly for me though with constant freezes but i'd imagine it's because these types of games are usually cpu intensive. The intro cutscene was pretty buggy with text switching back and forth. The movement feels like you're on ice and i think the inclusion of precision platforming in some of the levels only exaggerates the issues with it. I do see the potential for some very creative puzzles and mechanics though.

Thanks for your feedback. As for the early levels, it would be hard to make them easier without defeating their purpose. They teach the player important lessons that will be required to solve the much harder puzzles later. All the puzzles before the first item you obtain are still very doable by someone who isn't very good at this type of game. Though the later ones are definitely aimed at more "hardcore" sokoban players. As for the music i'm not sure what you mean, there is music, if you think it's very simple and not attention grabbing, that was the point as we wanted the focus to lie on the puzzles more. Though there is a second track in the later part of the game that is much better and i think you'd like.

Thanks for giving it a try

I can't replicate the issue. The R key works fine everywhere, as well as everyone that played the game before did not notice any issues with it.

Thank you! Multiple enemy types were actually planned but we decided against it as we didn't think we could manage to add them properly in time, although some of the ideas for different enemy types are in the game but they're cosmetic.