Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

That looks great! Hope it works well in your interface, and I hope you're enjoying the game! I'm planning to work on another nonogram exploration game in the future. ๐Ÿ˜„ I'm so glad other folks have similar tastes as me!

(+1)

Now that I've solved 202 puzzles, wanted to drop by and communicate what an absolute joy it's been to pick my way through TFMoF slowly over the last month or so!

Since you mentioned you'll be working on a similar project in the future, wanted to sneak in a feature request, assuming the limitations of GBstudio empower you to consider it:

When holding down the Fill or X button and holding a direction to quickly mark a row or column, if the starting space was blank, consider not allowing it to overwrite existing fills or crosses on spaces the player has already marked. (this is especially effective when other info has already Filled the required clues in a row or column, as it lets you quickly X off all the remaining blanks without disrupting Fills!)

Thinking deeply about my preference for "efficiency" behaviors like the one above, and given my relative disdain for some of the more advanced "helper" features that modern mobile nonograms tend to have, (like highlighting clues to tell you which ones are being fulfilled) it occurs to me that almost all such requests are matters of preference that might cause a designer to have to implement tricky options menus and toggles; it's impossible to please everyone! So FWIW, I appreciated the old school functionality of TFMoF, (taking me all the way back to Mario's Picross on the Game Boy!) much MORE than I happened to be frustrated by held fills blizting across my previous deductions.

GG on completing all the puzzles, and I'm so happy to hear that you enjoyed it! ๐Ÿ˜„

I totally hear you about having the cursor not overwrite existing fills/Xs! It's a feature that I really appreciate in a nonogram game, and I can clearly envision the programming logic for it, but I'm worried about how I would implement it in a resource-efficient way. Sometimes there were things I thought would be really straightforward but ended up taxing the engine, and maybe now I'm kinda wary, lol. (For example, in the first TaiFab, I used to use a while loop to set up all the squares in the puzzle area, but it ended up being a bit slow to load puzzle scenes. I unraveled that loop, and the puzzle scenes loaded almost twice as fast!)

Surely, if I were writing these games in C and ASM, I would happily be able to fulfill your request. Maybe someday I'll get good enough to dig into the guts of the GB Studio engine and optimize it for my particular games' needs. ๐Ÿ™‚ (I have definitely made improvements to puzzle architecture in the second game, but most of that is useful for me as the developer. The major QOL update for players is larger puzzle sizes and the ability to cross out numbers.) At any rate, I really appreciate your feedback and thoughts. Thank you from the bottom of my heart for playing my game!