Play game
aMAZE's itch.io pageResults
| Criteria | Rank | Score* | Raw Score |
| Entertainment - how enjoyable is it? | #9 | 3.450 | 3.450 |
| Overall | #15 | 3.133 | 3.133 |
| Creativity - how original is the idea? | #16 | 3.400 | 3.400 |
| Presentation - how does it look/feel? | #29 | 2.550 | 2.550 |
Ranked from 20 ratings. Score is adjusted from raw score by the median number of ratings per game in the jam.
Leave a comment
Log in with itch.io to leave a comment.
Comments
Love the minimalistic style!
Neat game. I liked how I could ramp up my own difficulty and the little summary of your game.
Had fun with this one! I found that bombs were essential because the maze generation algorithm can generate mazes that can't be completed otherwise. Likewise I also saw gold placed in inaccessible (without bombs) areas. It would be cool if the mazes were always proper mazes and the bombs could be used for strategic shortcuts.
Thanks for playing! I've added bombs for exactly the reason you mentioned :)
> It would be cool if the mazes were always proper mazes
I already have a new version of the game, where I use a proper maze-generating algorithm, but uploading new versions is not permitted at the moment.... It'll be a completely reworked version (let's call it a v2), with better walls, less tiles overall, less bombs allowed, better controls (much improved handling of multiple buttons pressed), etc.
Neat idea, I had fun choosing my own difficulty with the maze generation. Simple and effective risk/reward, great work :).
Thanks!
"choosing my own difficulty" is exactly what I was aiming for. And for competitive players to try to find an optimum between too easy (less points) and too hard (or even impossible so solve with limited amount of bombs) when generating a maze.
I already have several improvements based on other comments here, but (since new uploads are forbidden in the voting phase) that will come in some future v2 of the game.
Cool idea! I’d say increase the block size somewhat so that the maps aren’t so big and tighten up the controls (as others have suggested). The idea has a lot of potential!
I had a version with larger blocks and a smaller map, but it seemed too easy to play, so I experimented a bit with different sizes, and the current one is something that looked optimal to me. I might revisit the smaller map idea if/when I implement a better maze-generating algorithm.
Regarding the controls, this WAS a limitation because of the library used, but in another comment I received an idea how to work around it, so it shouldn't be the problem anymore. As we are in the voting phase, currently I cannot upload the new version, but if you would like to try it, you can do it on this link.
> I’d say increase the block size somewhat so that the maps aren’t so big and tighten up the controls
I've managed to create a more of "real maze" wall-generating algorithm, and combine it with increased block size and smaller map. As the map is smaller and walls are "smarter", you have less bombs at your disposal, and there are some other changes which I'm currently tweaking and fine-tuning to make it (more) interesting to play — so, it is not yet available online to play, but here's a sneak peek how the maze now looks:
Quite addicting. Good job! One thing that can be improved is the movement. If you hold right, then tap down, then release down, holding right the entire time, I expect to move down only once then continue moving right. But currently you will keep going down for as long as right is held. It makes it quite hard when you're trying to get a good score on time
> Quite addicting. Good job!
Thanks!
> If you hold right, then tap down, then release down, holding right the entire time, I expect to move down only once then continue moving right. But currently you will keep going down for as long as right is held.
Unfortunately, this is a limitation with Quil/JavaScript (e.g. see the official Quil example which exhibits a similar behavior when you press/hold multiple keys and release one by one: link) and I was unable to work around it. You will experience similar misbehavior even if you press/hold some completely unrelated (unused) key.
If somebody reading this know if there's a solution for this problem, I'm eager to hear it.
Hi, it is related to my previous comment:
your post in aMAZE jam comments
There is a solution. You save pressed keys into the state and then you reduce on top of them.
You can see the implementation in this framework based on top of Quill.
https://github.com/Kimbsy/quip/blob/master/src/quip/input.clj
(defn key-pressed "Reduce applying a handler function: (f state e) accross the collection of `:key-pressed-fns` in the current scene." [{:keys [input-enabled? scenes current-scene] :as state} e] (if input-enabled? (let [default-handled-state (default-key-pressed state e) scene-handlers (get-in scenes [current-scene :key-pressed-fns])] (reduce (fn [acc-state f] (f acc-state e)) default-handled-state scene-handlers)) state)) (defn key-released "Reduce applying a handler function: (f state e) accross the collection of `:key-released-fns` in the current scene." [{:keys [input-enabled? scenes current-scene] :as state} e] (if input-enabled? (let [default-handled-state (default-key-released state e) scene-handlers (get-in scenes [current-scene :key-released-fns])] (reduce (fn [acc-state f] (f acc-state e)) default-handled-state scene-handlers)) state))Thanks for the link and the example! I will take a look, and try to implement it this way.
The "set of held keys + reduce" idea worked like a charm! Thank you very much!
As we are in the voting phase, I cannot upload the new version, but if you would like to try it, you can do it on this link.
UPDATE: Thanks to the idea from @fwsuperhero, I was able to overcome the limitation of Quil.
As we are in the voting phase, I cannot upload the new version, but if you would like to try it, you can do it on this link.
Great idea, I enjoy this game very much.
My only complaints are - as already mentioned - better randomization would be nice. And also the reactivity of movement, now it's a bit random - but I understand that in quill you don't get it for free :-).
> Great idea, I enjoy this game very much.
Thanks!
> the reactivity of movement
Can you please explain what you mean by this?
When i release an arrow the character is still moving sometimes.
More info here: 1 second ago
I used to be autistic about mazes. Mazes with bombs is a brilliant idea. I wish I had this 10 years ago, it seems like it could keep me entertained for hours. Only complaint is I wish the generation algorithm was more interesting then a random fill - the mazes don’t end up being very maze-like this way.
Thanks for playing!
The bombs were my addition when I realized there were some easy-looking unsolvable mazes (thanks to the "random with some slight additions" algorithm used for maze generation). I haven't explored "true" maze-generating algorithms. Maybe in some future version.... :)
As for entertainment — if you have some competitive friends, this easily turns into who can score a higher score. Speaking from the experience :D
> Only complaint is I wish the generation algorithm was more interesting then a random fill - the mazes don’t end up being very maze-like this way.
Yesterday I implemented a "real" maze generation, which creates mazes like this one:
While it looks more like a maze you would expect, it basically destroys the uniqueness of this game:
I'll see if, for some future version of the game, I can maybe make some combination of the generation algorithms to make it both interesting to play and maze-like looking.
Yep, I think a combination would work well. Maybe a system that alternates between placing tiles in a maze formation with and placing tiles randomly?
> Maybe a system that alternates between placing tiles in a maze formation with and placing tiles randomly?
I think I managed to find a combination that works.
It is not yet online to play, as it is a significantly different game (the maze is a bit smaller, you have less bombs at your disposal, etc.) and I'm trying to fine-tune it before publishing it to public.