Show HN: Huewords, a Word and Logic Puzzle (huewords.snellman.net)
The effort allocation was pretty different from what I've done in the past.
The game design snapped together very quickly: I had the initial idea, played a couple of games on a spreadsheet to get a feel for the idea, and made one change based on those plays. After that everything felt just right through multiple rounds of playtesting. Likewise the puzzle generation is nowhere near as elaborate as in my previous game, fairly simple methods worked well and provided good variety.
Instead I ended up spending silly amounts of time on curating the word list (including using LLMs to guide the curation) and on iterating on the UI. The basic UI concept never changed, but the details basically never survived for very long after starting a new playtest round.
45 comments
[ 2.9 ms ] story [ 45.9 ms ] threadI thought color would be assigned automatically as soon as possible. So if there was an ABCD block and a ABEF block, then you could place an uncolored B, and as soon as you placed an F in the same block that block would get ABEF color.
Wanting to just type and have the game do the right thing is a very reasonable expectation, and auto-assignment is an interesting idea. It might need to be a one-way street to avoid unpredictable cascades though, such that you can go from "any letter A" to a "concrete letter A in that specific group" automatically, but not from a "concrete A" to "any A".
I think the biggest issue with group assignment is the fact that you just can't type while the wrong group is selected. I don't care what tools you have for narrowing down letters, if I see a solution in my mind, I should be able to type it out like I could on a piece of paper. Assignment feels more like adding flags in minesweeper (optional, helpful) than part of the solution.
On mouse, right-click or drag it off the board.
On touch, drag it off the board.
(I've updated the instructions.)
I did find one small bug while playing: if you drag a letter off the grid, it doesn't properly update the squares on the grid for that group. The space where you removed the letter stays blank, and the remaining places don't show the recently removed letter as a possibility. I noticed that it works as expected when right-clicking to remove the letter, however.
I couldn't reproduce the bug on three different browsers, so there's probably some kind of an additional constraint for just what triggers the bug. Based on the description there should be an exception printed in the the JS console. If this happens again, I'd appreciate seeing the top of the stacktrace.
(And in the meanwhile, this is is an object lesson that exception reporting to the server has to be included even in an MVP. Anything that one player reports, dozens of others must have seen and not reported.)
I'm using Firefox on Linux which could very well be the culprit here -- I recall an issue with drag and drop that was fixed in a recent changelog. I'll reach out if I run into the issue again.
The instructions were very terse to start with, due to a misguided attempt to keep them to one page even on tiny screens for aesthetic reasons. I gave up on that, but maybe didn't take enough advantage of the now infinite available space.
I was trying to fit right-to-left in some cases initially.
There's a guarantee that at least one solution exists, but not that it's unique. There's no guarantee on exactly what kind of process you can use to find that solution.
Sometimes it leans more into logic, sometimes into pattern matching, sometimes into reasoning about what kind of n-grams appear in English, and some times playing the odds a little bit. I've played hundreds of levels of this, and not yet seen a level that felt like brute force was the only option.
This is the kind of thing I meant when saying in the description that the puzzle generation isn't as elaborate as normal. It'd be easy enough to for example guarantee unique solutions (assuming the dictionary is static), or to make guarantees about exactly how many positions the first word can be in, but that also reduces the variety, and I don't know for sure yet what kind of levels end up being the most fun.
The hints are really there to allow players to self-balance the difficulty, and to allow for an escape valve if the puzzle is/feels unfair.
I noticed a small bug: I asked for a hint, when I went back to the menu and then visited the large puzzle again, the hint was gone, but when I clicked "hint" again, it appeared twice.
Basically if you allow deep-linking into the daily, they kind of stop being a daily puzzle. They'll also confuse new players following the link, because they'll be thrown into a more complex puzzle than most are prepared to tackle without doing the tutorial and a small puzzle or two. Hence the link to the main menu.
While for the non-daily puzzles, playtesters from were requesting the ability to deep-link into specific puzzles to share them from very early on. And it makes sense for those links to be long-lived, because those puzzles are not being presented as being time-limited unlike the dailies. So the link has a fairly different use case.
[1]: https://www.fiddlebrix.com/
One of the words I had to solve was a plural ending in S.
Wordle-type games don’t use these words, generally, and I have played so many of those that I found this oddly jarring, perhaps because your grid is 5x5.
One question, and I think you partly already answered it - are the boards generated manually?
The underlying board layouts were generated manually, and are reused. They can get flipped for more variety though. Everything else about a puzzle (splitting the chosen board to areas, placement of words on the board, choosing the hints) is automated.
On the other hand, automation might explain how I got one grid involving BHAJI (a food I'm not familiar with — I thought maybe you expected it to be familiar to your readers, but now I suspect it was put in by an uncaring computer). The word list knows BHAJI but not KEFIR.
I also got a grid involving TEATS, which doesn't pass the breakfast test. That made the grid somewhat unfair: I've internalized that I can prune search branches involving e.g. STOAS in favor of STOAT, and I expect to be able to prune branches involving e.g. PENIS in favor of PERIL. If it turns out that the only viable solution depends on exploring one of those seemingly-signposted-as-prunable branches, well, that's frustrating. So you may want to take another pass over the word list.
Kudos on a very well-crafted game! Again, it's really impressive that you managed to create so many rewarding puzzles — and even more so (basically incredible) that you managed to come up with an algorithm to auto-generate them!
It's just the word layout that's automated. The word list (about 4k words) is entirely hand-curated. I had some tooling to make it easier, but every word was selected by me rather than automation. But obviously it's impossible for any single person to be propely calibrated, mistakes can happen, and I'm not a native speaker so there are some odd blind spots in my vocabulary.
"Bhaji" was a word I personally thought was fairly common. If I had to name three Indian dishes, it'd be one of the three. But it might be too regional; when it was brought up in a playtest group, a person from UK thought it was basically in daily use while continental Europeans insisted they had never heard of it. So it'll probably go the next time I revisit the word list.
Re: "breakfast test", I'd not heard it phrased that way before, but immediately know what you mean :) My intended policy was no slurs, genitals, or sexual violence, and no vulgar words for bodily functions or body parts. This doesn't match the classic exclusion list exactly, but is at least similar in spirit. I expected "teats" to be fine, since to my mind it's only used for animals and human constructs (like baby bottles), not humans. But removing borderline words is cheap, offending some players is expensive :)
Note that the game does make a distinction between words that are accepted and words that can appear in puzzles. I mostly move words from the latter to the former rather than remove them entirely, so if you go probing for controversial words, you might find a handful of other examples. But the intent is definitely for there to be a "voice" in the word selection, such that entire categories of words are predictably in or predictably out in a way that the player can get an intuition for.
I'll definitely make another pass once I've internalized the player expectations better.
Re the two word lists — sure, a "legal" word list and a "target" word list, like Wordle. (I enjoy how Huewords manages to combine mechanics from Wordle, crosswords, and sudoku!) But I imagine that the larger your "legal" word list gets, the more difficult it is to generate a puzzle that has only one solution, right?
My mother got a puzzle containing HAVES (as in the opposite of "have-nots," I guess!). I think that's not a word; at least it shouldn't be in the answer wordlist.
My wife once clicked "Skip" basically by accident — thinking that it would skip to the next square, or word, or something — and found that what it means is "Skip to the next puzzle," with (AFAIK) no way to get back your progress on the puzzle you just skipped. Which was disconcerting. But that mistake happens only once per player... unless they happen to fat-finger "Skip" when they meant "Hint", I guess! Maybe "Skip" should pop up a modal dialog, both explaining what it's proposing to do ("Give up and skip to the next puzzle? Yes / No") and also giving the player a fatter target for their next tap in case they tapped "Skip" by accident.
Another thing I've noticed myself having trouble with is when a group of letters contains duplicates: if the group is like "LLSS" and I want to fill them all in quickly, I find it most natural to double-tap "L" then double-tap "S", as opposed to tapping the first "L", the second "L", the first "S", the second "S". Right now, double-tapping doesn't work; it will put the first "L" in the first cell, then undo that and put the first "L" into the second cell instead. I think it should be able to figure out what I mean.
Similarly, if I've tapped the first "L" and the second "S" to fill the first two cells, and then for the third cell I tap the first "L" again, I think it should be smart enough to act as if I'd tapped the second "L". Because obviously I don't actually care which of the two "L"s fills that cell — equal letters are fungible as far as the player is concerned.
Oh, and it occurred to me to wonder: Is it possible by random chance that one of the letter-groups displayed at the bottom of the puzzle will happen to spell out something vulgar? (If you bother thinking about that issue at all, then I think you could address it by blacklisting certain letter-groups, i.e. shipping a blacklist of anagrams (or even partial anagrams) of vulgar words, instead of a list of vulgar words itself. Or if you sort each letter-group as "consonants first, then vowels," it probably never visibly forms a word.)
The double letter problem is less clear. I've made that same mistake myself, but the the fix of using the other identical letter only works unambiguously when the other letter is unassigned. There will be an inconsistency when double-tapping a letter when its duplicate is already assigned. Might still be a worthwhile tradeoff, but not a slam dunk.
My intended rule was to not include anything used only as part of some well known phrase but never standalone. So yeah, "haves" probably should not have made the cut, even if I do think it's a word :)
Re: offensive words formed randomly from the letters, I'm not too worried about it. The letters are already sorted alphabetically within each group, which limits the options a lot. (I guess it's just "ass" and "bint".)
Nice game :)