itch.io

> Does this game not have music?

No music. I usually mute music in other games, so I haven't even thought about adding music here.

> One suggestion is that if the level becomes impossible (you used all your bombs and can't reach the exit), the game should tell you that. 

Thanks, I'll consider it.

> Another suggestion is to tell the player something like "press any key to stop generating walls", otherwise they wouldn't know what to do at the start. 

It already does that:

And when you move through the maze, there (at the bottom of the game), you can see what other buttons you can press, and some general information.

> Sort of annoying when the maze turns impossible

But that's the point of the game. Without it, you would always just wait until the max amount of walls, i.e. the first part of the game (wall generation) would be useless.

Thank you for the insightful comment!

> Further improve the controls, sometimes it is hard to hit an exact spot

That's my constant battle against the library I'm using — out of the box it doesn't support constant moving when you're holding a key, so this is my (3rd version of a) workaround around that limitation. It is hard to hit the sweet spot between "hard to move one place" and "feels laggy".

> The maze goes rather quickly from super easy (~800) to impossible (~1000). Maybe you could ease that out a bit.

Thanks for the idea. I'll explore it for future versions.

> One idea could be to allow infite bombs, but make them more expensive every time (maybe -10, -20, -30, ...).

I haven't thought of that. That will allow for every maze to be solvable — I'll have to see if that would make the first part of the game (stopping at the right time) less interesting/important.

> This IS  a very interesing and inventive simple idea!

Thanks! :)

> "your piece moves like a knight in a chess board"

Now that is a wild idea! I'll think about it, and maybe it comes in some future version of the game.

...and now I released a version 2 of the game, with an improved wall-generation algorithm and a slightly smaller maze size, making possible scores significantly lower — your 1301 will remain as the highest score ever :)

But maybe you can set the record for the v2 too? Let me know how you like the new version....

> maybe each devlog is considered valid?

Yeah, I'm not sure either. That's why I'd like to hear officially if it is ok or not.

"Devlog links that are not valid will be disqualified. This includes any link that doesn't outline the improvements to your entry (...)"

I have submitted a link to the game devlog (this one), which already contains two devlog entries, and I plan to write one or two more. Is this considered a valid devlog link, or should I link to just one devlog entry? If the latter, I'll probably have to condense the planned 3 or 4 entries into one that contains all the content of those separate entries.

Thanks for playing, glad to hear I'm not the only one who's competitive with oneself :)

As far as I know, you are the first player ever to break the 1300 barrier. Congrats!!

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.

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.

> 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:

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

I haven't played all games in this jam, but out of those that I did — GostHop is probably my favorite! Very nice idea!

> 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:

• There's no challenge in a maze-building phase. If you stop early, it is too easy to go through it. Basically, you'll just wait till the end, making that game phase uninteresting and unnecessary.
• Dropping bombs is not as effective/rewarding as in the current version of the 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.

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.

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.

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.

Thanks for the link and the example! I will take a look, and try to implement it this way.

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

As far as I know, this is a new all-time-high! Congrats!

Before you it was 1271, then 1259 and 1219.

This is how my first fight went:

:')

> Great idea, I enjoy this game very much. 

Thanks!

> the reactivity of movement

Can you please explain what you mean by this?

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

My first game ever. Written in Clojure(Script), using Quil. It is "create your own maze before travelling through it".

I'm almost done and might publish it today. (And no, I didn't say that at least 7 times in the last 2 days, shut up!)

Clojure{,Script}'s data structures

Maps. Maps everywhere. :)

Thanks for the idea about "q/key-pressed? and q/key-as-keyword inside the update function" — I've just tried it and I can make it work!

The only problem I need to work-around is the frame rate. If the frame rate is too high (and even 30 fps is), then even a short key press will be counted multiple times. On the other hand, if the frame rate is too low (and even 10 fps can be), then a (very) short key press will not be recognized at all.

I'm a bit late, but I hope you'll see this comment....

When I saw you used ClojureScript and Quil, it inspired me to make my own game for Spring Lisp Game Jam 2024.

I took a look at your code, and there are some nice concepts I didn't know before, e.g. using multimethods for handling different screens — I'll be using them too.

----

Since you seem experienced with Quil, maybe you can help me with the problem I'm having, and it is a situation you didn't have in your own game. Is it possible to register multiple key-presses with one long press-and-hold of a key? Currently no matter how long I hold some key, it is the same as a single short press.

Here I tried to explain it in a bit more detail: https://github.com/quil/quil/issues/413

Thank you in advance!