2023-12-26

• I’ve been talking with a friend about his LLM-based game startup. He sent me a book recommendation for this book called “A Theory of Fun for Game Design”. His recommendation got me very interested because he said “this book reminds me of Finite and Infinite Games,” which currently holds the top spot on my “Most Impactful Books Ever” list. So, I could not resist picking it up. I started reading it last night. It’s quite good, though does not resonate quite as strongly as FIG. It’s currently an 8 to FIG’s 10, so quite good, but falls short of revolutionary. Still, it does contain some absolute gems of ideas. It draws a strong connection between successful games and learning. I think that’s broadly a good connection to make. I think it answers some of why Anki is interesting to me and less so to others. But, most importantly for this stream of consciousness blog post, it highlights why certain Anki cards/decks are great while others are just ok and others are straight up not enjoyable. And it comes down to learning. Good decks will make learning enjoyable, they contain interesting information and are well structured. The best decks not only make learning enjoyable, but they make me excited to learn more, and in particular they make me excited to do something with the knowledge. My recently created music cards have this quality, as do cards related to art that I made a few years ago. For the art cards, not only were the cards interesting and well structured, they made me excited to go to museums for the first time in my life. They opened a whole new world to explore, and made me eager to look deeper. The music cards have a similar quality. On their own, they are just solid cards. They contain atomic information with one clear, correct answer, they exhibit a good use of images, and they’re structured in a web where early pieces build on later pieces to some degree. But in the course of studying the cards, I also see new connections (e.g. “ohhhh the relative minor of a major chord can be obtained by moving the 5th up two intervals!”). These realizations make me want to get back on the keyboard and test out this information, to learn how the knowledge “feels” musically, to see how it can help me play songs more easily/faster. It’s awesome! And then I think back to this book I’m reading and I realize, “ohhhh this is what great game design feels like.” There’s one level of game design competence where a player learns the necessary mechanics/rules and works to achieve a goal and the process is generally enjoyable. And then there’s a whole other level of game design where learning the mechanics and rules makes the player excited not just to achieve intermediate, in-game goals, but to explore previously unknown areas, to learn more mechanics and rules almost as an end in themselves, where it becomes about discovery as much as it is about winning the game. Connecting this game idea to Anki is a really fun framing for Anki that I hadn’t used before. Love when this kind of thing happens.
  
• The creator of Ruby on Rails compared costs between Heroku and Hetzner + Kamal (the tool he wrote to make deploying to VPS’ easy). Heroku is particularly egregious on pricing, so the difference is like 50x. But even against DO and Render, it’s like 10x cheaper or more to go with Kamal + Hetzner. This is consistent with my own experience migrating away from Render. So far, I have been very happy with the switch (but it is still early days). Commenters on the tweet note correctly that scaling will be more challenging with Hetzner. But what they often fail to account for is that vertical scaling is not as complicated as horizontal scaling, Hetzner + Kamal makes vertical scaling very manageable, and the reduced costs make vertical scaling compelling up to a pretty large level of usage. The cost differential means you will get ~an order of magnitude of extra vertical scaling before you need to look into a cloud provider to handle the explosive growth of your project. Of course, if you structure your application well, Kamal can make horizontal scaling pretty easy too (mostly just adding the IPs of the new web servers or job servers you have to a yaml). Now, there will be a point at which cloud offerings are the way to go. But if you are a small team working on a new project that doesn’t yet have massive usage, you don’t gain that much by going with Render/DO/Heroku at that stage. If Render was 2x the cost of Hetzner + Kamal, that’s about the tipping point where it makes sense to just have it managed. But at 10x the cost, it doesn’t make much sense. Another factor is whether you have particularly complicated infra needs. If you really think you need a special vector DB and Kafka and Mongo and Postgres and Redis to make things go, then it likely makes sense to go hosted. But most apps won’t need that. And those that do almost certainly wont need it on day 1. If you can make it work with Postgres, Redis, and Python web servers, Kamal + Hetzner are a great option. Good chance a big enough computer doing those things will get you where you want to go.

---

---

---