liambigelow

CAA records including an accounturi already expose the account identity in the same manner, so I feel like that ship has already sailed somewhat (and I would prefer that the CAA and persist record formats match).

Serious answer: For some, they do change semi-often and don't feel compelled to declare stability. In other cases, it's a stable + widely used 0.x package, and bumping it to 1.0 usually implies _some_ kind of breaking change. (I don't know if that _should_ be the case, but I know that if I see a dependency has bumped from 0.x to 1.0 I'm going to be cautious and wait to update it until I have more time).

In general: People usually aren't too concerned about it.

[https://truncate.town/](https://truncate.town/) is all egui (after the main menu)

Yeah I agree, and do the same. Likewise some config gets complex and can only be reasonably set through config. I prefer when I have a system with one base configuration struct where certain fields can be tagged as available on the command line, another subset in the environment, etc.

Ah nice, will peep — in the interest of sharing here is my latest "template" that gets copied from project to project: https://github.com/CloudCannon/toolproof/blob/main/toolproof...

Looks nice! I like the approach.

My holy grail will still be landing on a good multi-layer configuration setup for Rust CLIs. Ideally CLI flags merged over top of environment variables merged over top of configuration files.

Twelf [0] was close in unifying things, but I had some friction. Lately I've been using Schematic [1] to handle the environment + config layers, and then just a manual implementation of Clap arguments layered on top.

[0] https://github.com/bnjjj/twelf.

[1] https://github.com/moonrepo/schematic

I prefer Tidal’s UI and album management. Tidal also has a good notification system for new releases, and otherwise gets out of the way. I moved to Tidal from Apple Music, but would move back if I had to over any other options.

Also, Tidal has been working on opening up more of an API which is hopefully a project that doesn’t die with this announcement.

There can be more of a difference than you might expect. In static site generators, Eleventy is about as fast as you can get in the JavaScript world, and is still 2-3x the time for Hugo in Go [1]. A couple orders of magnitude more than <10ms in this test which is predominantly markdown parsing.

Anecdotally, for large or extra large sites, the build performance gap between even Eleventy and Hugo can be quite large. And the gap from either of those to the newer JavaScript tools like Next.js is enormous.

1: https://www.11ty.dev/docs/performance/#build-performance

Thanks for the kind words!

Many good notes, we'll look into a lot of that. And yes currently it's deliberate, but I think we can squeeze some AI swaps in!

Good ideas! Thanks for the notes :)

Yes dictionary is a tough thing to nail down perfectly — to start with we're going to highlight existing words on the board that are invalid, but have a similar line of thinking around the "commit" tap after placing, at least behind some learning setting. There'll be a changelog screen for when things like that make it in :)

Not at the moment, but it's only a question of finding good dictionaries to expand the language support :)

Amazing! Thanks for the detailed notes, and the insight.

Dictionary does still need work — especially around some words like soiree which got culled by our dictionary builder. We'll iterate on building it out (without adding "garbage" words

Interesting re: weakest link rule. Agreed that can be unintuitive when learning the game, but it's one of those rules that balances the game well overall. Possibly we just need to be better at explaining it.

Re: the end game — the current computer is just not-very-good, so a future NPC might play better there.

And good things to mull over re: undo buttons / highlighting tiles / letter distribution.

Thanks again for the detailed feedback, really really appreciated

Yeah that's probably the best solution.

Great suggestions, thanks!

Thanks for the kind words!

On 1. — this is definitely the most common piece of feedback so far, so we'll certainly look into it.

On 2. — the battles rules are the most complex part of the game, since they have evolved through the play testing and battle analogies. Our intuition has been that an invalid attacker "sabotages" the battle, and makes the whole attack fail (i.e. an ineffective army rushing a position will often lose in its entirety). And a short-but-valid word is a competent soldier who just isn't strong enough to win on their own :) Possibly something for us to explain more in one of the tutorial/lore/explanation areas.

On 3. — defenders aren't even evaluated if the attacker fails, so the attacking invalid word is removed.

Thanks again, great feedback :)

Thanks for the comment — we'll take another crack at clarifying the starting position :)

Thanks for the feedback — it's looking like we'll have to find some solution for showing valid words, based on the comments.

(Also, will fix the dictionary, thanks!)

Interesting suggestions, and thanks for the kind words! Definitely things to ponder :)

Good ideas, will check out the queens gambit game :)

Nice! We've had this on the list for a while so this is great validation for building it :)

Thanks for the great notes!

Agree on all front re: the dictionary ergonomics. We'll look at smoothing that out (mobile is currently the blocker there, but everything is solvable :)

Re: visualizations, you make great points. Definitely something for us to mull over, and I do think some amount of this will make it into the game (at least behind an option, which defaults to on).

Thanks again!

Oh good note thanks, my mistake. It should be MIT, I'll add the license today.

Amazing, thanks for the feedback!

> edit: seems like the board editing in multiplayer mode doesn't work

oops, will get onto fixing that

Ah, 2am reading comprehension on my part. Yes, if we ever remove rather than add to the dictionary in the future I might look to axe it.

Oh! Yes, this is an interesting case. Towns actually slot into the battle as one-letter words, so this case FEN is long enough. It doesn't come up much, but it might deserve elaboration in an "advanced" tutorial since it's unexpected.

We source the definitions from Wiktionary, but have a much higher bar for words to count as valid in the game. ST comes up often, as I agree it's one of the iffier words, but even Cambridge claims to to be so: https://dictionary.cambridge.org/dictionary/english/st

Good notes on both fronts, so thanks!

We have been on the fence about this (and still are!). One option is to add this kind of UI in a "tutor" mode that starts on, and can be opt-out at some point. Not sold on it yet, but mulling it over.

Good point, I think we discussed this in the past and it shouldn't be — which we promptly forgot! Will amend. (and thanks!)

Amazing! Thanks for the detailed thoughts.

Yes, we once posited that you were trying to deliver soup to the other town haha. The current language is really in lieu of figuring out what the best lore for the game is, and these are great suggestions we can mull over :)