Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit) (+1)

5/5, the art is so detailed, the audio is good, the game has a normal difficulty curve, you truly made an amazing job!

I loved the level design of the first levels, but I was a bit disappointed on the last ones (level 10 and 11): in level 10 you can complete the level without using a character (which is a bit weird if you ask me), and in level 11 there are some bridges that are useless. I don't know if that was intended, but I think that trying to "confuse" the player by adding objects that are not required to solve a level is not the key to make a good puzzle level (I made my opinion after watching this video of Game Maker's Toolkit:

I think level 7 is a perfect example of a good puzzle level: my first plan was "ok, I distract the monster with this buddy, and then I collect the stars with the other one". But then you realize you don't have the time to do that, and after trying multiple times you understand that is not the solution, and you have to rethink your strategy. Believe it or not, for me solving that level was more satisfying than solving level 10 and 11!

P.S. As a unity programmer, I'm really curios about the way you record the movement of the players (in other words I have no idea how you made that), can you explain that to me? :)

(1 edit)

So much love for Snakebird! (That game was inspiration for me to make two mobile games)

The later levels were put in very late on, and so there was an intended solution, and then it turned out it could be done with less players and we didn't have time to adjust. I agree that having red herring puzzle elements just for the sake of it is mostly just frustrating to the player. 

Implying a wrong solution? Fair game.
Putting in elements that actually don't need to be used? Less great.

As for the input recording? I thought we'd need a really clever solution due to memory constraints, but it turned out to not be an issue. Basically we're just recording the joystick vector and the state of the action button every single frame, and storing it in an array that is as long as the time you have for the level. (10 seconds = 600 frames = new FrameInput[600])


Then, each frame we increment the frame number by one. If the player is being controlled, that input data is stored to the array. If the player is not being controlled, the data is read from the array and used as the input for that frame instead. We used an integer for button state so we could tell the difference between button down, and button hold.

If we really needed it to be memory efficient, we could have instead stored the four directional buttons as bitflags, and then stored all five buttons in a single byte. 600 frames of data would then be 600 bytes. But premature optimisation is the root of all evil and all that, turns out we didn't run into any problems for this gamejam doing it like this.

Hope that made sense! If there's anything else you'd like to know just ask! ^_^

(-Joe)

(And here's the code to record/read input)


I see, I thought you used some weird function of Unity, but that's a pretty simple and clever solution!