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)

Ah, interesting! That level is the first one that really tests the player to see if they "get" it yet, and it seems like we didn't do a good enough job at explaining because a couple of play testers got stuck on that same level.

The trick is to stand on the square, throw over the river, and then play as the other character, catch the box, and throw it back. Then you go back to the first character, throw the box over again, and then wait for the second character to throw it back.

The timer is an unfortunate necessity. We're storing 60 frames of input data each second for each player, and so we need to limit the number of seconds in order to not go crazy with memory. Those earlier levels could have more time though, you're right there.

Thanks for playing! :D

(-Joe)

We ran out of time before being able to do sound effects, only had two days instead of three thanks to us both being at work on Friday.

The box bug is a weird one, we saw it a few times but it's not consistent. Sometimes the box resets and sometime it stays in the players hands. I think in one instance the box WASN'T being held, then after the reset it was, which makes no sense at all...

ah well, bugs add variety to the experience ;)

Thanks for playing!

(-Joe)