Skip to main content

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

I noticed that you don’t want to implement a hint checker, and I’m curious why that is, as checking that the hints are satisfied isn’t overly complicated or bad for performance. You’re already doing most of the work if you’re marking the row and column hints complete while the player is playing.

I’m actually not marking hints complete as they are playing, either.

These aren’t choices aren’t due to implementation complexity or performance, either. This whole game is written in C with no libraries outside the bare minimum needed on the playdate side to get the current frame buffer, get input state, handle files, and pushing audio to the device. Everything else is done on my own, so I’ve already crossed more complex tasks and everything is very performant.

Really, the main concern is just getting the game to a good playable state, then worrying about working through the Quality of Life features in the backlog. I’ve gotta make more puzzles, prize art and blurbs, and do the audio.

It could also be due to the fact that, as a player, I don’t really care much about the hints being crossed off. I think what I like more, which will cause it to bubble up the backlog, is when the current run of marked cells are tallied up and shown.

To get more specific and show a minimal proof, here is an example of a nonogram that generates ambiguous hints:

x o o x

When the hints are rendered out, you’ll have 1 and 1 in the columns and 1 and 1 on the rows. Now look at this alternate solution: o x x o

Yeah! That’s exactly what is described here.

I hope you'll at least implement manual flagging, so the player can flag hints themselves.