Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Donovan Block

12
Posts
1
Followers
2
Following
A member registered Apr 18, 2024 · View creator page →

Creator of

Recent community posts

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.

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 restart button was holding spacebar; it was mentioned in the instructions, but it's also easy to assume that something in the instructions isn't actually implemented here - or to not read the instructions (which I am guilty of myself). The movement code was just very rushed.

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).

This isn't the first game of this genre I've seen, but it's very well executed; I especially liked how using the sphere's shape became important on the third level. It could benefit from some more visual interest or background music.

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).

Thanks! Vehicle controls are hard to tune; ideally I'd have different positions for the front and back, but I barely had time to get this code working. Solving the puzzle takes fine-grained control over the speed and angle, since you're supposed to turn on the platform; I haven't managed it either.

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.

There actually was a syntax error, but one that Guile and my syntax highlighter failed to report: I was missing a double quote. (A variety of other errors, the result of Hoot not having full list and string support just yet, could not have helped.)

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.