Very polished, Teebz! The general aesthetic with the music and artwork I think worked well together, and I particularly liked the animations for the blue creatures attacking, which...happened to me a lot because it turns out I am not great at this game hahaha.
Two suggestions, both control-related. First, the title screen should probably make it clear to press space to proceed: the "start" looks like a button to click, and my second guess was to press enter...and so I thought it was still loading and just waited for like ten minutes lmao. Unfortunately, since it's a browser game, the game window obscures the controls: in game you do a good job of making the controls clear, but on the start screen they are not.
Second, it may be useful to have some set of controls that make it easier to play for folks without mice (like myself). I'm not sure what that'd necessarily look like (if you're limited to just a keyboard, maybe two buttons to rotate clockwise/counterclockwise would work?). Even if I had a mouse, an arrow showing the current direction I am facing would make it a lot easier to aim. I'm not sure how useful a suggestion this is given how little I play these types of games (probably because I don't own a mouse lol), but if you make another one of these in the future it might be something to think about.
Baguette
Creator of
Recent community posts
I really like the idea of this--I've never seen procedurally generated Sokoban, and that feels like something interesting to build. It'd be unfair to judge the game in this state, but there are two issues I found that you probably aren't aware of, so I'll still raise them:
- The compressed archive should probably unpack to its own directory. The number of times I've unpacked a random tarball from itch.io without thinking and gotten my home directory full of game files...
- I unfortunately can't run the Linux version, as it depends on libFLAC at a lower version than what I have (8 instead of 12). Bundling more of the dependencies would hopefully make the game more future-proof.
Good luck on future progress with your engine!
This is a really nice game: great art style, a nice take on the theme, and pretty fun. It's kind of like breakout/pong, but if you had multiple paddles and the music was also generated on the fly (no pun intended).
This is probably a symptom of being a laptop gamer, but one thing I'd like to see are keyboard controls: something like left/right to move the lilypads and up/down to select between them might work.
While pretty short, this is a pretty good sandbox for exploring this type of system. As you said during development, you needed to strike a balance between historical realism and freedom to explore, and going in blind I did find myself just wandering around trying things, which I really liked. I'd imagine playing a more fleshed-out version of this game would be really fun.
The only suggestion I'd give is that I think it might work better as a unix-only game: I could imagine that one could set up a sandboxed shell environment with an entire filesystem to explore, and then you would be able to take advantage of commands that are already implemented by the user's operating system (ls, cat, grep, man, etc.), as well as shell features like tab completion (yeah, probably not historically accurate) and history. In particular, the ability to "ls -R" during the time when I was pretty lost at the second part would have been nice, as would a more fleshed-out manual system (explaining where log files are, for example). The fact that history was preserved between different servers, and didn't care about which user I was logged in as, was also confusing (...and also having the ability to log in as different people was pretty funny).
...I beat this game, once, but I don't think I can get past the second stage again. I really like the idea, and also the chaos that is created on every loop. The few issues I had were mainly with controls: I'm not used to controlling the orientation of my character with the mouse, and it didn't help that I was using a touchpad. Some indication of orientation on the screen, as well as an indication of the length of the cooldown on taking shots, would help with this I think.
Unironically my favorite part was clipping through the floor, finding a ton of enemies down there, and not being sure if that was actually the goal this whole time.
In all seriousness, I really liked how the platforms were generated, along with the music. If this game has a sequel I'd definitely be waiting for it!
As a fellow person who writes their own engine for these things, I sympathize with the feeling of not having enough time to make more than a tech demo. I can't wait to see what you manage to make out of it in the future! The two-level shadow is neat, in particular.
Oh, and you probably know about this bug, but it seems that whenever you move in a direction that's not forward, the forward-facing sprite briefly shows up before switching to the correct one.
...so, unfortunately, this game manages to hit two different pet peeves of mine: first, when making an archive (like a zip file), as a courtesy to your users, make sure that it creates its own directory (with all of its files) upon unpacking, as otherwise blindly unpacking will fill up your current working directory with files that are then annoying to sort out. Second, a lot of modern RPGMaker games do this, but invisible barriers at the edge of the map are pretty annoying. Being able to see the directions from which one can exit a room is very important, although in this game there are not enough areas that it was very frustrating.
In any case, I feel like making this type of mystery game in a game jam is pretty ambitious, and I feel that it could have benefited from more time: more puzzles, a more intricate plot, etc. I think it does get across the idea of what it was going for. While the focus mode was a bit frustrating to use, I think most of the issue was from technical limitations: a way to turn it on without going into the menu and an indication that it was on (instead of a message when it turned off) would have gone a long way.
Thanks for the feedback! I experimented with making it possible to avoid taking any damage, but I couldn't think of a good way to do it that wasn't incredibly obvious (though, as the puzzle designer, what's obvious to me is probably not obvious to other people). I'd be interested in seeing if anyone can end the game with more than 1 HP, but I don't think it's possible...
Thanks for the feedback! As for the health system, the realistic answer was that implementing spikes/fire was the first thing I did because it was an easy sanity check to make sure the level worked, and then I just kept it in the game because why not. I think I did see a similar type of system in a puzzle book, once:
https://caravelgames.com/Articles/Games_2/TLP.html
(although not a sokoban game).
Hi, sorry that it didn't seem to work--it seems that something is up with Konsole, and that was one of the terminal emulators that I did not check (as I don't have a system with KDE installed). From looking at your stream, it seems that the problem was something I ran into when running on the linux console, which was related to the fact that bold background colors are handled differently than other terminal emulators (for example, xterm). I currently have a workaround that does the right thing on the linux console, so could you try running "TERM=linux ./ion_duct.sh" (which will fool my code) and see if it fixes it?
...huh, I mean, in a certain sense I'm not sure how it could have happened in the first place (I'll get to that below), but I'm glad it's working for now.
As for what was happening, the code that was hitting the bug was the part that reads back characters that have already been printed to the terminal (the reason why the code does this is so that it can join the two corners of windows together, like it does on the bottom left and bottom right, in order to make it look like they're connected). However, somehow when it read back the character, it found neither a line-drawing character nor a valid unicode symbol, which is bizarre since those are the only two things that should have been sent to the terminal already. Actually, the really bizarre thing is that the result from curses is already bitwise anded with 0x4000ff, which means that the argument to chr() couldn't possibly have been what the above error indicates that it was.
In any case, if I ever reproduce (and fix) this I'll be sure to add an explanation of what happened in this thread.