liambigelow

Thanks! And thanks for the great feedback — the tutorial is indeed long, but that just means more (fun) iteration to go!

> Why did my opponent place qxa to begin with?

Much like us, the NPC can be plagued with a simply terrible hand ;)

Again, appreciate the notes!

Thanks! I can't say I disagree — we hoped to structure the tutorial as a sequence of rules, but the explanations tend to grow. A concise reference would indeed be good.

> This desperately needs a attack result preview

Not too hard, just waiting for all the feedback to roll in before deciding either way. If we stay sitting on the fence, it might make its way in as a "tutor" mode :)

Our current base list is the intersection of Wordnik's games wordlist and the SCOWL spellchecker — words in both are a definite yes, and SCOWL's capitalization helps us filter out acronyms and proper nouns.

We have done some manual massaging beyond that, but not much. Waiting for more feedback like this! You can see the current tranches of dictionary massaging here: https://github.com/TruncateGame/Truncate/tree/main/dict_buil...

Interesting! This might be our Scrabble bias showing through. Yes, when we say "word" I suppose we're meaning "something that a player has claimed to be a word" by placing contiguous tiles. I'll look at somewhere to clarify language in the tutorial.

Thanks for the examples, I'll note them. We did intentionally scale back from the classic wordgame dictionaries (looking at you, Scrabble) due to an overabundance of archaic words that the NPC can play against you — but it does push us into the unfortunate role of dictionary moderators!

I'd like to add a button to the dictionary to report words that should be included. For now, we erred on the side of a smaller dictionary since it's less jarring to add words than remove them :)

(stere / steres is especially regrettable, sorry!)

Thanks! Great notes

In battles, weak words compromise all of their letters. "TOUR" would be safe, but the "FT" ruins the "T" by making it part of an invalid word — and an invalid word that loses is removed in its entirety.

Thanks for pointing it out! It's something we have had come up before, and the sort of thing we keep iterating the tutorial toward explaining better, so we'll take another crack at it!

Thank you! Yes, for the puzzles we would up having to constrain the board to a size that wasn't too egregious when sharing emojis... The classic single player has a bit more room to breathe :)

(Thanks for pointing out the font — I do have an issue for that (https://github.com/TruncateGame/Truncate/issues/111) so it's nice to get validation on its importance)

Darn. I do believe lockdown mode fully disables WebAssembly, so that makes sense. I don't think there are any significant roadblocks to packaging the game as a native app, so that might be a good push to do so.

aha they totally are, that's more than a nitpick! Will fix, thanks for pointing that out.

Forgot to mention — it's fully open source at https://github.com/TruncateGame/Truncate for anyone who likes poking their digital nose around :)

I wrote out an explainer recently on HN answering exactly that: https://news.ycombinator.com/item?id=32172290

That is, in essence, what Pagefind is doing under the hood — but Pagefind also addresses the other reply in that it can combine these results when you search multiple words (among many other search benefits)

Oh hey, this is my project. What sort of comparison are you looking for? I can maybe shed some light.

The giant difference between the two is that Algolia is a hosted search platform, so there exists a server that you send an API request to that can return the search results. This is pretty quick — they'll probably have a lot of the search data sitting in memory already (which is what you're paying for).

Pagefind isn't a platform, everything required to search a site is static along with the site. As a result, to search through a site you need to load some amount of it into the browser and then query it. Other javascript search libraries load everything up front and give you instant search, but Pagefind prioritizes bandwidth over search — on large sites the existing libraries can take a few MB of bandwidth up front to initialize their data.

With Pagefind, very little is loaded until you type in a search term. Once you start typing, a chunk of the search index is loaded containing your search word(s) and is then queried. This is what drives the performance you're seeing, which is predominantly the time for the data to load after you start typing — the query step itself is near-instant.

The goal is sites that are currently limited to paying for a platform like Algolia now have a path to add search without any infrastructure, but without burdening the end-user with enormous network requests.

If there's anything specific that you're wondering I'm happy to elaborate