The ending was very abrupt (walking out into the void and falling). I enjoyed the use and method of timing in the last level; I haven't seen that before but I ought to have. I would hope you add more puzzles later, but it's sufficient for a prototype.
Donovan Block
Creator of
Recent community posts
This is much more of an arcade game than a puzzle game as it stands: it explicitly guides the player through figuring out each level, and it requires that because the game is vertical enough that it's hard to see anything, but most of the challenge is in making the specified movements correctly. (Did you mean to make the sides of blocks sticky? They certainly are, but you don't have a puzzle that uses that.)
The puzzles were a bit easy with the character's size only allowed to increase; it just suggests a strategy of "stay as small as possible while clearing gaps" that makes more reasoning unnecessary. The lighting was a bit dim. However, it was a clever idea and very solid execution, and I enjoyed playing.
I am very fond of your idea and its execution; I would echo the others' comments about the camera cutting off nearby objects and the angled play area interfering with motion. I noticed that some of the movable blocks have the shadows of other blocks on them; I'd like to see a puzzle involving moving into another object's shadow, though the current choice of puzzles worked very well for a demonstration.
The level needs a lot of precise steps in sequence; it could be a good puzzle, but the important parts are not clear from the outset (especially given the premise) so a lot of restarting is involved. It could be good in a later part of the game, but it would leave a sour impression on me if I knew it was just the first. Making the changes that the buttons cause clear beforehand would make the puzzles much easier to solve (which has good and bad parts, of course).
It's hard to tell what to do from within the game; the only way to know that there are 4 keys, rather than 3 or 6, is reading the instructions. Movement was a bit slow without sprinting and the mouse was running into the screen edges the first time I played it.
I don't mind having the cubes look like the rest of the objects; I would recommend that they be put a bit further away, to make the player have to move them to get the keys (and thereby realize that they can be moved).
I had to define filter, count, and delete. A variety of other issues I've since found:
- There is no inexact->exact, which means it has to be approximated with FFI when an exact integer is needed (i.e. in list-ref).
- Division of a float by an integer inexplicably winds up as positive infinity?
- I'm not sure that this is Hoot-specific, but having type predicates in define-typed-record would be nice, especially given that interactive debugging doesn't yet work.
I've been getting the below error when attempting to compile, despite having correct syntax (as checked by normal Guile) and not using the procedure fill-rect anywhere:
guild compile-wasm -L modules -o game.wasm game.scm
Backtrace:
In ice-9/read.scm:
231:26 19 (lp #\2)
231:26 18 (lp #\")
231:26 17 (lp #\c)
231:26 16 (lp #\")
231:26 15 (lp #\a)
231:26 14 (lp #\")
231:26 13 (lp #\a)
231:26 12 (lp #\")
231:26 11 (lp #\a)
231:26 10 (lp #\")
231:26 9 (lp #\a)
231:26 8 (lp #\")
231:26 7 (lp #\a)
231:26 6 (lp #\")
231:26 5 (lp #\a)
231:26 4 (lp #\")
231:26 3 (lp #\a)
231:26 2 (lp #\")
734:20 1 (lp #\#)
In unknown file:
0 (list->typed-array #{c1c"\x29;\xa;; }# 140 (# # # …))
ERROR: In procedure list->typed-array:
In procedure length: Wrong type argument in position 1: fill-rect
make: *** [Makefile:14: game.wasm] Error 1
Guile is version 3.0.9-0.3b76a30 and was updated yesterday through guix pull on a Debian 6.1.90-1 system.




