Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Thanks for the detailed feedback!

1. I’m planning to add an in-game glossary soon. I’ll consider the mouse over feature if I end up doing a UI rework.

2. There is a math formula that can convert haste to equivalent CDR, so it should be a simple visual change. I try to avoid extra calculation to save frames, but I’ll see what I can do!

3. I’m thinking about adding a 'Fast Forward' upgrade that just speeds up the whole game. It wouldn’t affect game balance, just make things faster.

4. That’s a good idea. Maybe an indicator for when a node disables another one too.

5. The biggest hurdle right now is probably the save system. There’s a save file that gets wiped every time players reincarnate, which I change frequently since it’s “safe” to do so. There’s also another separate persistent save file that I avoid modifying because it’s kinda permanent. On top of that, there’s the queue system. Players will probably want to queue nodes they’ve seen before, so it has to work with that as well.

6. Are you using Alt-Tab to switch between windows? I do that a lot and noticed that the single/loop mode switches on its own as well.

I want to implement all of these player suggestions and polish up a bit before releasing a Steam demo, but it’s definitely on the way. Thanks a lot!

(1 edit) (+1)

When you say 'saving frames' are you saying that you are running the 'haste' calculation every single frame? That calculation should only ever need to be done whenever you complete an activity that alters haste.

I don't think that alt-tabbing is the issue as I don't recall alt tabbing before it happened. What happens is I manually swap the mode to 'single' by clicking it, and the symbol reflects that, however nodes still loop even though the symbol is displaying single (i was not using queueing either so that wouldn't do it).

Thanks to your comment, I went back and cached the haste calculation. Before it was just simple multiplication so I didn’t bother, but now it uses a square root, so this should avoid those more expensive operations. I also made it show the exact time needed now.

As for the mode swap issue, I wasn’t able to reproduce that, but I’ll keep an eye on it!

(2 edits)

Even if they calculated every single frame this really shouldn't impact performance unless the optimization is terrible. Maybe it's just a language thing, but I could perform the square root of 7727 a million times in just 4635428 nanoseconds (~1/216 of a second) with a Java loop. That's far more than needed and they should indeed only be updating it when there's an actual change.

Although speaking of optimization I wonder why there's a stutter when saving. Not that I mind considering it makes identifying when the game saves easier.

(+1)

Please ensure the original time remains visible somehow to ease calculations. It'd be a pain to subtract all my modifiers so I can start doing math.