Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit) (+4)

Great work for a jam! I finished the game (one act right?) with the Samurai. Didn't try out other characters. (You made a roguelike and have three characters!)

This game offers a unique forging experience. Thinking about how best to combine the dice symbols and elements, the game really comes alive in the forging cells. I really would have liked to have the element reference during forging, so I took a screenshot next time around, and was using that.

The difficulty curve is pleasant to work with: I wasn't daunted by the initial battles, but the later ones became more challenging, so good job there.

Some of the mechanics didn't work the way I thought they would. For example, when an attack is blocked, the special effect, like Dream still goes through. And the attack also counts towards Critical even if it's blocked? Maybe these are ok (although I feel they should get fully blocked). Just that I didn't expect it.

The "Bug" element is really cool in particular. I started "holding" a dice even if the symbol didn't match, because it counted towards the "Bug" bonus. This suggests there's good potential in the core design for even more mechanics.

The rerolls are helpful. Is there a (planned) economy to them? Or I can simply keep rerolling each time?

The symbols. All I understood now was that you have to match them. Is there a pattern to them depending on the enemy? Maybe that's something to think about.

When there are multiple enemies there's more matching happening initially, which is great. But as the enemy count goes down, there are more idle turns where nothing matches. The forging should address that to some extent, but still.

Some improvements to UX would surely help. (Not counting this as a minus or anything for this jam. It's already quite good. Just notes for future.) (1) The element reference as mentioned above. (2) Once I forge a die it's frozen, which is sort of ok. But I can't view it again for reference during forging, which is a pain. (3) Being able to view the progress map during forging.

You guys certainly have something here. And I can see in the notes here you're planning to expand this further. Wish you the best for that!

(1 edit) (+2)

Thank you so much for the incredible feedback! We loved every bit of making this game! Lots of things slipped through the cracks during testing and development, and we had so many more ideas that we ran out of time to implement. One of those ideas was what we were referring to as "dice tray abilities," essentially things you could use the unconsumed dice for to help when you have incredibly bad RNG. I really wish we had been able to implement those, as we had so many ideas for them! We tried to have each enemy type correlate to the different symbols, but I ran out of time to properly balance it without drastically swinging the RNG even further. We definitely fell short on the UX a bit, and if we do continue this, we'll be focusing on the UX as a pillar of the design. Thank you again for playing!

In addition to Gamma's comment, I wanted to add that, as the Forge was my responsibility, I had a lot of trouble with how I'd originally coded the faces and the dice and stuff. Because of some issues with duplicating them (or not) when I needed to, what you saw with the Forge locking out the die after one change was due to one of those bugs, where if you selected the die a second time, it would not have the updated faces. That was found approximately five minutes before the end of the jam, and I was only barely able to upload a version with the lockout as a kind of fix. It was not fun. :P Of course, I also managed to upload an unrelated bug at the same time with a refactor I'd been doing, so we ended up having to fix that with a ticket to the admin team, because it was a showstopper at the time.


Thank you so much for the kind and thoughtful/constructive criticism. It is incredibly helpful to us, and inspiring. You may not always feel like it when giving a long response like that on the internet, but for many of us, it really does matter and really does help us try to do our best. Thanks again!

(+1)

No worries at all. Seeing the die unrolled flat in the forge with the forge UI really got me excited. With that bug, that was a cool fix. You have to make quick decisions like this in a jam, and atleast it works.

I actually played the Firefox version (since that's what I use), and am curious to know what the difference is to a "non-Firefox" version.

(1 edit)

There's a bug in Firefox (if you want to call it that) where they won't support "Shared Buffer Arrays." I think it's actually a decision on their part because Shared Buffer Arrays can be a bit sketchy in terms of security. Chrome, however, supports them. In Itch, the problem is that you can't tell it to selectively pick whether or not to support Shared Buffer Arrays: you have a project that either supports it or not. I could have just uploaded a version without support for Shared Buffer Arrays that works in both Chrome and Firefox, but I prefer the higher fidelity audio that you get in Chrome (which is what I use) due to the Shared Buffer Arrays, so I tend to upload two different projects.

The reason this happens is Godot itself has the ability to do multithreading and it's an option you check when exporting, but if you check it, you have to have the Shared Buffer Array support, or it won't run in your page. So I have two web exports: one for with Threading and one without, and then upload to two different pages. Multithreading in web exports is used to make the audio fidelity much higher, with less crackling.

I'm genuinely glad to know people are taking advantage of that, though! Maybe in the future Itch will give us the option to autodetect via the browser choice, and have two different uploads depending on which is found.

(+1)

Ah ok. Didn't know about this multi-threading and audio fidelity. I'll keep this in mind. Thanks! Also glad there are devs who care about Firefox users!