The PineTime [1] is the cheapest programmable option I'm aware of - it does need Gadgetbridge on Android, and the heartrate sensor didn't quite work for me, but otherwise it might be worth a look?

[1] https://pine64.org/devices/pinetime/

Richard Williams' The Animator's Survival Kit [1] is the standard recommendation, I believe - I've also seen animation courses recommend Preston Blair's Cartoon Animation [2]

[1] https://www.amazon.com/Animators-Survival-Kit-Principles-Cla...

[2] https://www.amazon.com/exec/obidos/ASIN/1560100842/

Should the title be the other way around? It's starting with the 20B model and pruning it to different parameter counts

Video game opponents are absolutely AI in the "good old fashioned AI" (GOFAI) sense - they have very clearly defined objectives and action spaces, and algorithms like A* pathfinding [1] and Goal Oriented Action Planning [2] which perform planning over a space of possible sequences of actions to achieve a specific goal. The Game AI Pro [3] articles online give a good picture of the kind of implementation decisions which go into game AI.

The problem is that a lot of the time, bruteforce search can beat the snot out of any human player, but the real game design objective isn't "beat the player", it's "give the player enough of a challenge to make beating the AI fun".

In Civ's case, it might be theoretically optimal play for the computer to capitalize on rushing players with warriors before they have a chance to establish defenses, but it is also a great recipe for players to angrily request refunds after the tenth consecutive round of being crushed by Gandhi in turn 5. A lot of game AI development time goes into tweaking action probabilities or giving the player advantages to counteract the AI advantage - the reluctance to build military units you saw could have been the result of such a tweak.

As for why LLMs typically aren't applied as game opponents:

* They are quite compute intense, which is tricky when players expect at most 16 ms latency per frame (for 60 FPS), and get ornery if they have to wait more than a few seconds, but also do not like having always-online requirements imposed by cloud compute (or subscription costs to fund running LLMs for every player)

* The bridge between tokens and actions also means it's hard to tweak probabilities directly - while A* can let you specify that a certain path should be taken approx. 20% of the time, implementing this in an agent-LLM approach means you have to actively select and weight token probabilities during the beam search, which is a bit of a hassle, to put it mildly

* The issues with long-term coherence in LLMs, famously demonstrated by Vending-Bench [4], makes reliability and debugging harder

[1] https://en.wikipedia.org/wiki/A*_search_algorithm

[2] https://www.gamedeveloper.com/design/building-the-ai-of-f-e-...

[3] https://www.gameaipro.com/

[4] https://arxiv.org/abs/2502.15840