When I first started using Claude Code for BattleTabs, I was running it directly on my machine. It worked, but every session started with the same friction — making sure the right Node version was active, that Docker was running, that the database was up. And every time Claude needed to run a command, I’d get a permission prompt. Install a dependency? Approve. Run the test suite? Approve. Generate Prisma types? Approve. It adds up fast.

So I moved everything into a devcontainer — think of it like running a separate virtual PC inside your computer, isolated from the rest of your machine, pre-loaded with exactly the tools the project needs. And because the container is isolated, I can let Claude run freely inside it. No permission prompts. It can install packages, run builds, execute tests, reset the database — whatever it needs to do — and there’s zero risk to my host machine. The container is the sandbox.

Instead of babysitting every command, I give Claude a task and walk away. It figures out what to run, runs it, hits an error, fixes it, tries again — all without stopping to ask me. That autonomy is what makes the agent workflow actually work.

To make this seamless, I wrote a launcher script — ./dev. It checks that Docker and the databases are running, builds the container image if the Dockerfile changed, and launches Claude Code with --dangerously-skip-permissions inside it. One command to go from “I want to start working” to “Claude is ready.”

The container persists between sessions. Run ./dev once, and it creates the container with the repo mounted, environment variables set, ports forwarded. Run ./dev again in another terminal, and it execs into the same running container — instant startup. I can have four Claude instances running in parallel, all sharing the same container, the same node_modules, the same database.

./dev              # Start Claude Code (creates or reuses container)
./dev              # Second instance — execs into same container, instant
./dev rm           # Fresh start when needed
./dev status       # How many instances are running?

The Dockerfile itself installs Claude Code directly into the image, so there’s no “install Claude” step at startup. It also includes Chromium and a virtual display server for automated browser testing — I can have Claude take screenshots of the running game inside the container without a GPU or a real display. But I’ll cover that workflow in a later post.

This also means I don’t have to repeat setup when I spin up parallel agents. Every agent inherits the same ready-to-go environment. No redundant installs, no version mismatches. One container definition, consistent every time.

The next unlock was combining this with git worktrees (think of each worktree as a separate copy of the project folder, like duplicating your Unity project to try something experimental.)

BattleTabs is a monorepo (a single massive codebase containing all related apps), and I often want Claude working on multiple things at once — say, a backend fix and an unrelated UI change. Git worktrees let me have multiple checkouts of the same repo inside the same container. Each worktree is an independent working copy with its own branch, so I can have separate Claude sessions running in parallel without them stepping on each other’s changes.

/workspaces/battletabs              # main checkout
/workspaces/battletabs-feature-a    # worktree for feature A
/workspaces/battletabs-feature-b    # worktree for feature B

Each session gets its own space to work in. They can build and test independently. This becomes really important when I start using agent teams.

One more thing I didn’t think about initially: how do you share files with Claude when it’s running inside a container? You can’t just copy-paste a screenshot into a terminal in a devcontainer. Opening VS Code attached to the container and navigating to the right directory works, but it’s slow and clunky.

The trick I landed on is dead simple: run npx serve on a folder on your host machine — say, your Downloads folder — and it starts a local file server. From inside the container, Claude can access those files at http://host.docker.internal:3001/. I drop a screenshot into that folder, give Claude the URL, and it can see exactly what I see. No more trying to describe “the button is slightly off to the left” — I just show it.

# On your host machine
npx serve ~/Downloads -p 3001

# Claude (inside the container) can now fetch:
# http://host.docker.internal:3001/screenshot.png

One gotcha: Claude can’t always read from host.docker.internal URLs directly — sometimes its built-in web tools don’t resolve the hostname. But curl inside the container always works, so if Claude needs to grab a file, it can just curl it to disk and read it from there. Minor thing, but worth knowing so you don’t waste time debugging it.

BattleTabs runs on a fixed local port inside the container, so I can access the full game in my browser while Claude is making changes. Hot reload means I see changes almost instantly. This tight loop — Claude codes, I test, I screenshot what I see, Claude fetches it and adjusts — is really the core of how I work now.

Getting the devcontainer right took some effort upfront, but it's now an essential part of how I start every new project.

This is a learning project. I wanted to answer: How well do Claude Code and Godot work together for game development?

The experiment: Build a visual novel using Claude Code as the primary development interface — an autonomous collaborator that could analyze problems, build solutions, and create its own tools.

What I learned:

1. Headless-first tools enable AI autonomy — Godot’s CLI, GitHub Actions, and Docker made it possible for Claude to run the full development cycle without GUI intervention.

2. Claude Code builds tools for itself — Claude didn’t just write game code. It built development tools (visual editors, image processors) that it then used to work more effectively.

3. Personas as agents — A PM agent and target player persona helped Claude make autonomous decisions and evaluate its own work.

You can find the game here: https://gblab.itch.io/tidewater-cove

Note on AI Art: AI-generated content in games is controversial, and concerns about impact on artists are valid. This is a learning project focused on workflow and tooling. The AI-generated assets are placeholders to test the pipeline.

The Stack

A quick overview of how the project is set up:

• Godot 4.3 (headless) — Game engine with full CLI support—build, import, export without GUI

• Docker devcontainer — Reproducible environment with Godot, Python, Claude Code pre-installed

• Claude Code CLI — AI assistant with filesystem access, running inside the container

• GitHub CLI — Allows Claude to keep track of issues, create PRs and releases

• GitHub Actions — CI/CD pipeline: push to main → build → deploy to itch.io

• Python tools — Custom scripts for art generation, story editing, deployment

The key property: everything runs from the command line. No clicking, no GUI automation. Claude can execute the full workflow autonomously.

# The entire development cycle, scriptable
godot --headless --import              # Import assets
godot --headless --export-release ...  # Build for any platform
python3 tools/generate_character_sheet.py ...  # Generate art
gh pr create ...                       # Open pull request

The Devcontainer Setup

A Docker devcontainer makes this workflow possible. It provides a consistent, secure environment where Claude Code can operate with full autonomy.

What’s in the container: Godot 4.3 headless binary + export templates for all platforms, Python with image processing libraries (PIL), Claude Code CLI, Git and GitHub CLI

Why this matters:

1. Skip-permissions mode — Claude Code can run with --dangerously-skip-permissions inside the container. This means Claude can read files, write code, run builds, and execute scripts without asking permission for each action. The container itself is the security boundary.

2. Full autonomy — With skip-permissions enabled, Claude can execute multi-step workflows uninterrupted: generate art → import assets → build game → run tests.

Key Insight #1: Headless-First Tools Enable AI Autonomy

If Claude can’t run it from the command line, Claude can’t use it autonomously.

Why Godot works well:

Godot’s workflow is scriptable from the CLI:

godot --headless --import                          # Import all assets
godot                                              # Run the game

This means Claude can:

• Generate art → import it → verify it appears correctly

• Make code changes → build → catch errors

• Run the full pipeline without human intervention

Other engines like Unity support headless builds, but require additional setup—command-line flags not exposed in the editor, virtual framebuffers on Linux, and workarounds for systems without graphics capabilities. Godot was designed CLI-first, which makes it simpler to automate.

I plan on doing a few more experiments with Godot — I think this aspect of Godot might just make it one of the strongest contenders if you are working with Claude Code for game development.

Key Insight #2: Claude Code Builds Tools for Itself

Claude didn’t just write game code—it built development tools that it then used to work more effectively.

Tools Claude created:

• Visual Node Editor — Interactive HTML editor for story structure. Claude generates this to visualize branching narratives, then references it when making story changes.

• Character Sheet Generator — Generates expression grids, auto-crops to sprites. Claude runs this to create consistent character art, then imports the results.

• Screenshot Compositor — Composites game assets into promotional images. Claude creates marketing materials without launching the game.

The feedback loop: I describe a problem → Claude builds a tool to solve it → Claude uses that tool → Claude improves the tool when issues arise.

Example conversation:

Me: “It’s hard to see the story structure.”
Claude: builds visual node editor with drag-and-drop, undo/redo, auto-layout
Me: “Can you add the ability to see which nodes have choices?”
Claude: updates the tool, regenerates the visualization

Claude isn’t just a code generator. It’s a toolsmith that uses its own tools.

Custom tools — instead of researching which tool to buy or download, a custom one can be built for the specific need. This may impact the plugin ecosystem, particularly as tools increasingly need to be AI-accessible.

Key Insight #3: Personas as Agents

Beyond documentation, I created explicit personas that Claude could adopt or consult.

Morgan (PM Agent):

A product manager persona with explicit decision authority:

## PM Agent: Morgan

**Autonomous Authority:**
- Order and prioritize tasks
- Implement features within established guidelines
- Fix bugs without asking
- Make creative decisions that follow the art/story bibles

**Escalate to User:**
- Spending money (AI API costs)
- Major story changes
- Significant scope changes

**Never ask:** "Should I continue?" "What's next?" "Is this okay?"

This eliminated the friction of Claude asking permission for every small decision. Morgan checks the backlog, picks the next task, and executes.

Elena (Target Player Persona):

A detailed persona representing the target audience—a 29-year-old who reads cozy mysteries but has never played a visual novel. When testing, Claude can adopt Elena’s perspective:

“Play through Chapter 1 as Elena and provide feedback.”

Claude then evaluates pacing, identifies confusing moments, and flags anything that would alienate a visual novel newcomer. This provided useful feedback before involving real playtesters.

Domain Documentation as Experts:

The art bible, dialogue guide, and story bible serve as domain expertise. Claude consults these when making creative decisions—checking if a color palette matches the art bible, or if dialogue sounds right for a character’s voice.

What I Learned

The most surprising part was watching Claude build tools for itself. The visual node editor, the image processor—these emerged from conversations about problems, and then became part of Claude’s own toolkit.

The PM and player personas helped more than expected. Instead of asking “should I continue?”, Claude checks Morgan’s backlog. Instead of guessing what players want, Claude consults Elena’s preferences. Explicit decision authority reduced friction significantly.

I was also pleasantly surprised by how well Claude Code and Godot work together. I didn’t launch the editor once after initial setup. Godot’s CLI-first design made full autonomy possible. If you’re exploring AI-assisted game development, the combination is worth trying.

Since I had built a social media (bluesky) AI assistant before, I know that this could work much better with a hybrid approach inside an IDE. So I moved the task to Visual Studio Code + CLINE. I started a new project, added the Bluesky SDK to the folder, and used the chat interface (and the same model - Claude 3.7 Sonnet) to complete the tasks.

The difference is, instead of asking the agent to use the MCP itself, I asked it to write code using the SDK directly.

Because the execution is entirely done in code, it removes the uncertainty and any errors that pops up can be properly addressed. Also, since the code is saved onto the project, they can be picked up and reused with confidence.

And it is no more complex than using Claude directly. I am still chatting with the model directly. (note I do have memory bank set up for CLINE)

With agents, the IDE is quickly becoming my everything-app, not just my coding environment.

Two weeks ago, I was reading up on LÖVE, a lightweight 2D game framework that's come back to the spotlight thanks to it being used to build recent indie successes like Balatro, Arco, and Gravity Circuit, and Moonring. It being the valentine's day week, I thought it'd be fun to make a quick prototype with the LÖVE framework to test out how good an agentic coding IDE can be at building games.

As with my last project, I used Windsurf IDE (models: Claude 3.5 Sonnet + Cascade Base). The game design is fairly simple. Two players battle each other on a hexagon grid. Each turn, a player rolls 3 dice, and move the 3 dice into Movement, Attack, and Defend slots. The core decision for the player is deciding how to allocate the numbers they get from the dice rolls.

After getting a basic scene running with a dice rolling mechanism. I used this initial prompt to start with the basic game design:

...I now want this to be a 2 player game. Here's how it should work:  
  
- players are placed on a 6x6 hexagon grid board  
- the player can use the dice roll for movement, attack, or defence  
- there are 3 types of hexagon tiles. a normal tile that doesn't do anythin. an attack tile that doubles an attack if the player is standing on it. a defence tile that reduces an attack by half if the player is standing on it.  
- there are about the same number of the different types of tiles on the board  
- players start with 21 hit points  
- on each turn, the player rolls 3 dies  
- after they roll the dies, they can drag and drop each die into the movement, attack, and defend slots  
- they can move the number of tiles equal to the number on the dice in the movement slot  
- if they are next to the opponent after the move, they can attack the amount and apply the amount of damage to the opponent equal to the number of dice in the attack slot  
- if they are attacked by the opponent in the opponent's next turn, the damage they take is reduced by the number in the defense slot  
- not the attack and defense numbers are impacted by the tiles they stand on

I like using bullet lists in my prompts. It helps me organise my thinking, and anecdotally it's been more effective working with language models.

As before, I ask the agent to keep a running changelog for both me to remember what's been worked on, and for the agent to remember what's been done.

I set up a .windsurfrules file to guide the AI agent with rules and links to documentations.

# Windsurf Rules for Love Dice Game

### Code Style
- Make sure to remove any unnecessary extra `end` statement to avoid Syntax error: '<eof>' expected near 'end'
- Make sure to have enough `end` statement to avoid Error: Syntax error: 'end' expected near '<eof>'
- Make sure your code satisfy all requirements and only the requirements provided
- Review your code and ask yourself these questions:
   - Is this code efficient? 
   - Can you make it shorter? 
   - Are you able to make it more maintainable? 
   - Do we need all of the functions you have outlined?

### Memory Management
1. All memories must be saved in the /memory-bank/ folder
2. Use markdown format for all memory files
3. Update existing memory files when their content changes
4. Create new memory files for new categories of information
5. Memory files should follow the naming convention: descriptive_name.md
6. Each memory file should have:
   - Clear title and sections
   - Dated entries where relevant
   - Links to related memories if applicable

### Changelog Management
- Each release must have a new line after it
- Include release version and date for each entry
- Follow format: ## [VERSION] - YYYY-MM-DD

### Documentation Links
- Love2D documentation: https://www.love2d.org/wiki/Main_Page
- LUA: https://www.lua.org/manual/5.4/manual.html

I noticed it kept making the same syntax mistakes, perhaps due to lack of training on love2d projects or the lua language, so I added a few rules at the top of this file. Unfortunately it still keep making the same syntax mistakes more often than I'd like. It's usually a pretty quick fix once I point that out but annoying nonetheless.

I also started generating memory files (in markdown format) and saving them in a /memory-bank/ folder. I work on two different devices. The internal memories are not part of the repository, so to continue working on the project on a difference device, I needed the memories to be essentially exported and synchronised as part of the repository. This might reduce the need to keep a changelog - but for the time being I am doing both to have more context for the AI to understand the project.

I wanted this project to be small with a very narrow scope. My initial plan was to wrap it up in 2 days. It ended up taking more than double the amount of the time. Getting the core system up and working was fairly quick, but making the UI and control exactly how I designed took a lot longer. One key difference between this project and my browser extension project was the time it takes to test the app. The game has various states that a player can be in, and it takes time to get to those states once a game has started for me to test any changes. I should have written programmatic testing along the way. But even with that, sometimes you have to manually use the product to decide if certain UX works.

As with the last project, UI/UX work took up the majority of time. Windsurf IDE/Claude3.5 struggled with UI tweaks in the LÖVE framework quite a number of times and I had to find solutions myself before asking it to implement in multiple occasions.

And I definitely spent way too much time testing out different dice rolling mechanics and animations. At one point, trying to get them represented in 3D in a 2D framework! To be fair, the AI agent did a decent job calculating the necessary math to create 3D dice but had trouble managing the position/scale/rotation dots on the different faces in 3D.

Once I have the prototype working as intended, I playtested it and realised there's a dominant strategy for this 1v1 game where you are almost always better off using. If you are making a game, make sure you playtest early and playtest often. My player brain always outsmarts my designer brain!

I ended up adding a secondary objective into the game where players can pickup health potion to gives players another thing to consider when making decisions. This also added additional time to the project.

Two of my biggest takeaways are:

1. Focus on the core — this is the advice I tell people whenever they start a new project. Focus on what matters. But it's easier to give advice than to follow them. I spent way too much time on dice animations when I was working on this when in the end a simple visual effect was all I needed

2. Refactor early and often, especially when working with AI — because the project was meant to be small and quick, I didn't spend any time structuring the code or refactoring it. By the time I realised there are too many sub-systems and states to all be in one file, it had become too large of a file for AI agents to easily refactor. A few attempts yielded disappointing results when I ask the agent to refactor the code.

Again, you can find the files and the executables here:

• Github Repo: https://github.com/theBrandonWu/love-dice-game

• Itch.io (download): https://thebrandonwu.itch.io/die-die-dice

On the gameplay side, I think there's something interesting here where there's an element of luck and a strategic element, which makes for a fun and interesting multiplayer setup. It's a game design I'd like to keep working on, but most likely going to a framework or game engine I am more familiar with.

Idea - Gaming Deals in a New Tab

I had an idea to create a browser extension that shows the latest gaming giveaways, discounts from major stores (Steam, itch.io, Epic Games Store, GOG, Humble Store), and gaming news from notable gaming websites. Inspired by OperaGX's original GX Corner (before they added too many sections that cluttered the UI), I wanted this to be in the new tab, giving users a quick glance at newly available free games and great gaming deals.

You can check it out here: PixelDrop

Why

There are a few reasons why I wanted to do this idea:

1. I like browsing gaming deals and claiming free games, especially from Epic Games or Steam. Epic is consistently making great games free to claim for a short period of time, and Steam constantly has sales on. But I often forget to check these platforms.

2. I like to read industry news, but have not found RSS readers or following social accounts of gaming news sources to be a great experience.. I like the "Recommended stories" section in Firefox's new tab, which shows me interesting stories whenever I open up a new tab - it's an invitation to read without commitment or interruption

3. I also want this to become a space where gamers can discover new games that they might like. While the majority of gaming attention is on Fornite, Roblox, Minecraft, and massive F2P games like Marvel Rivals and CoD, a gaming hub where people can discover new games can help diversify what people play — having discounts is a great way to get attention.

4. If this becomes useful to enough people, I want to introduce a submission and voting mechanism for people to add games and vote on the deals.

5. And add a section for people to discover upcoming new indie titles

Choosing the Right AI Tools

I decided to use Windsurf for this project. I’ve been using it for the past couple of months, and the results have been solid, especially when paired with Claude 3.5 Sonnet. I also have a set of custom instructions from previous projects that make the process smoother.

Planning with AI

Before diving into implementation, I needed a reasoning model (something like ChatGPT-o1 or DeepSeek-R1) to think through the requirements and generate an architecture, file structure, tech stack, and general setup. Windsurf doesn’t yet have a "plan" and "act" mode—where one model handles planning while another handles execution—so I did this manually. I used ChatGPT's o1 model as my "architect." With just one simple prompt, I generated a structured project plan:

"I'd like to create a new tab browser extension for Chrome. The extension will show gaming deals at the top section and gaming news in the second section. Create an architecture and plan for this project. Include technology frameworks to use and break down the folder and file structures that I can pass onto a junior developer to implement."

With the project plan ready, I passed it on to Windsurf for implementation. The plan was detailed and specific, and Windsurf quickly set up the development environment, created the files as outlined, and even recommended APIs to use for the deals. (I ended up using different data sources, but this was still very cool.)

Overcoming Development Challenges

One issue I ran into was with Manifest v3, where the tool assumed I had icon images in place. It was an easy fix, but dealing with Manifest v3 was a constant source of frustration throughout the process. Having built browser extensions before, I knew that wrestling with Manifest files is just part of the journey.

Despite these small roadblocks, within a few steps, I had a working prototype. It had the three sections (giveaways, deals, and news) and was pulling in real-time data. However, just like every project I’ve worked on, even with AI, the last 20% of refinement, polishing, and tweaking still takes 80% of the total development time.

At least for now, humans are still needed to decide what feels right. As a product person, I appreciate this human-in-the-loop process where I can experiment with different UI/UX ideas, have AI implement them within minutes, and then review and make final design decisions. Taste is something AI hasn’t fully mastered yet, and I believe this will continue to be a key differentiator for software.

Publishing on the Chrome Web Store

Once the product was ready, it was time to publish it on the Chrome Web Store. The process of creating screenshots and graphic assets for the store is still manual. I’m sure AI tools exist for this, but I haven’t explored them yet.

As part of the submission process, Chrome Web Store requires developers to explain why certain permissions (cookies, storage, etc.) are needed. Since Windsurf knew the code, I asked it to fill this out for me. It provided solid answers, but it was also overly zealous—justifying permissions I didn’t actually need. This led to my extension being rejected on the first attempt.

You can check out the release here: PixelDrop

Key Takeaways

• Agentic IDEs can dramatically accelerate development – Going from idea to working product in a few days, even without deep familiarity with the underlying tech stack, is now possible.

• Using AI models for planning and execution is a game-changer – A reasoning model as an architect and an AI capable of tool calling for coding makes rapid prototyping seamless. I had a functional MVP within 30 minutes.

• Human taste and iteration still matter – AI can generate code and implement features, but defining how a product should feel and work still requires human judgment.

  • Notably, this is also one of the most time-consuming parts of development.

• Bringing a product to market still involves manual work – Publishing on the Chrome Web Store required filling out forms, setting up accounts, and verifying company details—things future AI “operator” tools might help with.

• Image generation tools are powerful, but gaps remain – While there are great AI tools for App Store and Google Play mockups, I couldn’t find one tailored for Chrome Web Store asset creation. Maybe that’s my next project?

• Expect hidden time costs – The actual build time is often only half the effort. Refinements, debugging, and market-readiness tasks (screenshots, descriptions, approvals) take at least as long as the core development. If estimating a project timeline, double your initial build estimate to be realistic.

This experience reinforced that while AI is a powerful tool, human creativity, taste, and decision-making are still critical for crafting great products. And for now, the AI + human hybrid workflow remains the best approach to shipping high-quality software fast.

I like the simplicity of the library - perfect for getting started creating agents (AIs that can take actions). Documentation is easy to understand and comes with plenty of bite-sized examples. I also like how it integrates with Hugging Face, meaning you can have your agents use publicly available Spaces as tools from the hugely popular platform.

To test this out, I built a social media agent that

1. comes up with an image prompt with a pre-defined theme (in this case, I wanted pictures of dogs on the beach)

2. uses a text-to-image tool to generate an image

3. comes up with a caption for social media posting

4. uses a custom tool to post to Bluesky

Here is my setup:

• AI Model: a locally hosted Qwen2.5(I am using the 14b coder tool model), using Ollama (quick how-to guide)

• Tools:

  • An image Generation Tool from Hugging Face Spaces: https://huggingface.co/black-forest-labs/FLUX.1-schnell

  • a custom tool the AI agent can use to post to Bluesky

Code

Here’s the code for creating the agent. As you can see, it is very straightforward and easy to understand.

# define the LLM model used for the agent
model = OpenAIServerModel(
    model_id="hhao/qwen2.5-coder-tools:14b",
    api_base="http://localhost:11434/v1",
    api_key="ollama",
)

# text to image tool directly from Hugging Face
image_generation_tool = Tool.from_space(
    "black-forest-labs/FLUX.1-schnell",
    name="image_generator",
    description="Generate an image from a prompt"
)

# tool to post to Bluesky
bluesky_image_poster_tool = BlueSkyImagePoster()

# creating the agent
agent = CodeAgent(
    tools=[image_generation_tool, bluesky_image_poster_tool], 
    model=model, 
    add_base_tools=True
)

# running the agent
result = agent.run(
    """
    Could you generate an image of a sunny beach with dogs in it? Include between 1 to 5 dogs. Feel free to include scenaries or landscapes or other objects/animals or people. use detailed and specific prompt for the FLUX model. Use industry best practices for the prompt. High-end photography, award-winning photos, still life photography, and/or cinematic photography. choose between different photography styles, lighting, weather, seasons, and time of the day in the images. 
    
    Once the image is generated, generate a fun, engaging social media caption for this dog beach image and post it to Bluesky.
    
    Consider the following guidelines:
    - Use emotive and playful language
    - Include relevant hashtags, always include #dogsonthebeach #petlife #dogsofbluesky
    - Keep it concise (under 280 characters)
    - Capture the joy and energy of dogs on a beach
    """
)

Notes and Learnings

• For the AI model, use one that can read/write code. This gives me the best result, which makes sense as I am using code agents from the library (CodeAgent class) which need to write actions in code.

  • Note that Smolagents also supports the standard way of writing actions in JSON with the ToolCallingAgent class.

• Agents CAN fail to execute the task sometimes. Unlike programming directly, which gives you predictable and deterministic outcome, working with agents can be unpredictable. How the agent decides to use the tools will vary, and the LLM model used for the agent will have an impact.

• On the official documentation, to use model on Ollama you'd go through LiteLLM. Alternatively you can use the OpenAIServerModel class as below:

from smolagents import OpenAIServerModel

model = OpenAIServerModel(
	model_id="hhao/qwen2.5-coder-tools:14b",
	api_base="http://localhost:11434/v1",
	api_key="ollama",
)

• When creating a tool, note that "output_type" supports most built-in types but not all of them. It didn't support dict which was what I was originally using

• I published my Bluesky posting tool to a Hugging Face space. Although in the documentation it should be pretty straightforward, I did struggle for a couple of hours to make it work - there are validation checks that the tool need to pass (rightfully so) and other restrictions and I had to make changes to the tool. I have published the tool to https://huggingface.co/spaces/thebrandonwu/bluesky-poster but will need to clean it up before making it public for others to use. (also waiting for this issue to get resolved)

Thoughts

Smolagents impressed me with its balance of simplicity and flexibility, making it an excellent choice for building AI agents, especially for beginners or iterative projects. Below are some specific insights from my experience:

I was able to build an agent and a custom tool with smolagents relatively quickly with my intermediary level of Python knowledge. It is certainly a library I'd continue to build with for the easy of use, and therefore the frequency I can iterate my project with it. I think it is a brilliant tool for anyone, especially those just starting to build with AI agents, to start building with.

Although it isn't necessary to have an agentic setup for this particular use-case — you could have easily generate an image prompt by, feed it into an image model, then generate a caption and post to a social platform via its SDK, using an agent is a fundamentally different setup and approach.

You write the tools an agent can decide to use in order to accomplish a task. The agent has, well, agency to decide how the task is accomplished. The ability to make decisions is a valuable difference. For instance, when generating and posting images, the agent can autonomously select the most relevant tools and handled the sequence of operations, reducing the need for direct intervention. This decision-making capability allowed it to adapt dynamically and perform tasks more efficiently, mimicking a human's ability to reason and prioritize. You could add more tools to its arsenal for it to do more down the line. If I were to continue working on this particular agent, I might add memory to it so that it remembers what had been posted before, visual recognition models for it to analyse image outputs before deciding to post, or have it generate content based on the performances of the posts.

Running LLM Models Locally

I want to try running LLM models on my local machine. I have a Mac Studio (Apple M2 Max, 32GB RAM). It’s not the most powerful machine you can build to run AI models, but I wanted to know how capable a typical computer you might find on your desk can be. I have found these local models to be sufficiently capable in most instances for the typical writing related tasks, idea generation, and analysis.

Setting Up

The easiest way I found is to simply use Ollama, which is a desktop platform that allows you to run and interact with AI models locally on your device.

Once installed, you run commands through its terminal interface to install models and manage them. (Use Terminal app on the Mac, and Command Prompt or PowerShell on Windows). You can simply type in “ollama run [model name]” to run the model. Here’s the list of commands.

You can find the list of models available on their Models page, which also has commands you can copy and paste into the terminal to run them.

After experimenting with a few different models with different parameters/sizes, I am now running

• llama3.2:latest (3b) for general purpose use

• hhao/qwen2.5-coder-tools:14b for coding agents. (and experimenting with the larger 32b model)

Larger models I’ve tried have been too slow to be very useful. For example, I got a Llama3.3 model (70b-instruct-q2_K) to work on my device but it was painfully slow. Note I have not done any optimisations with them so you might be able to find larger models that work on a computer with a similar spec.

Once you have model ready to go, you can chat with it in the terminal, or use a desktop app that talks to your local model if you prefer a more typical chat interface. Enchanted is the one I use on MacOS, and I will next try Open WebUI for its extensibility. Here’s a list of apps that you can use with Ollama.

What’s even more important perhaps is that these models are now available in a whole suite of apps and tools running on your desktop. Let’s start with a personal notes assistant tool as an example. I’ll write about using Local LLM AI Models with Personal Notes with Obsidian and Smart Connections in another post.

Part 2: Micro — Collectibles, Value, and Game Design

(also on mirror.xyz)

Now that we've explored crypto gaming on a macro level to the ecosystem around our games, let's take a closer look at how crypto assets differ from non-crypto assets in games, where their value comes from, and how that might change the way we design them.

Collectibles

Collectibles is an exciting new dimension enabled by way of NFTs.

Collectibles have existed in games before, but it is an entirely different beast when the underlying assets are tokenised. With higher utility and optionality, they are inherently more valuable than off-chain collectibles.

Ex. One would pay less for a bar of gold that cannot be used as a collateral for a loan than a bar of gold that can.

NFTs are unique, so even when their representations in games are identical, they can be valued differently. With the same item, people place higher values on NFTs with an earlier serial / mint ID. This is similar to collectible toys where even with the same toy, the ones with lower serial numbers (produced earlier) are valued higher than the ones with a higher number.

Additionally, provenance can also become a factor in the value of collectibles. An NFT that was previously held by Snoop Dog will have a higher value than other ones from the same collection.

The in-game assets we create for games are no longer considered to have infinite supply. I believe this is one reason why we are seeing crypto assets with very high prices. In-game assets have gone from having infinite supply to having scarcity.

Therefore when we think about tokenising assets in games, we should consider designing them as collectibles. I am of the opinion that not all traditional “unlock-able” items should be tokenised.

Balancing NFT items in games

Thinking in ways of collectibles helped us answer a question related to game design for crypto games: what happens when we make an in-game item less powerful for balancing reasons? Ex. If we nerf a card in a collectible card game, will its value drop - angering people who own the card?

When a physical Pokemon card is nerfed and banned from competitive play, its value actually increases. Even though you can only use it in casual play, players value it more because it will no longer be reproduced - increasing its scarcity.

I also found an example of this in the crypto game Splinterlands - you can find my notes here. If anyone has more examples of this please let me know!)

When items can be collectibles, their value is no longer only from their utilities in games. This is a new frontier of player psychology for games.

Value of In-game Items

The value of an asset comes from Utility and Collectibility.

A retired Pokemon card is low in Utility but now high in Collectibility (you can no longer buy it from source).

• For someone who plays the game (Player), this asset has no (Utility) value as you can’t play with it as you used to.

• For someone who collects Pokemon cards (Collector), this asset now has a high value - other collectors can no longer buy it directly, only a limited number of them exist, and an even smaller number of them are available for secondary sale.

Crypto enables us to explore serving the second group of people (Collectors). The motivations for Collectors are very different from those of Players. Collectors of physical toys don’t take the toys out of the box. The utility value of these toys to them is 0 and they value toys purely based on their Collectibility value. I think this is relatively new to games - and it introduces a new persona for whom we’ll have to design for.

Play-to-Earn and Where the Money Comes From

Play-to-Earn (P2E) is a phenomenon hugely amplified by crypto. I believe a sustainable game economy will require a healthy in-flow of money from players who are paying for the experience itself* - a balance between Play-to-Earn participants and the traditional, Pay-for-Fun players.

Play-to-Earn players participate in the ecosystem through value-adding activities (ex. grinding for rare items), while Pay-for-Fun players spend money to enhance their experience in the game, purchasing better equipment, levelling up cards, or simply having one more go.

We can even think of ourselves (game developers) as Play-to-Earn participants in the ecosystem. We play the game of game development (which is incredibly fun if you ask me), and we earn a living out of it.

It’s incredibly intriguing to think about what types of systems we can build to create a healthy P2E economy — where does value come from, who is adding value, and how are they rewarded for it?

• there are other sustainable modals where the cash inflow isn't from Pay-for-Fun players, particularly if the games have staking/rewards systems, eSports components, or sponsors/advertisers - the cash into the economy can be from any of the new categories of participants.

Game Design

A crypto game designer needs to not only consider retention of and monetisation from players, but also juggle all the demands and motivations from all parties involved, maintaining a sustainable economy, and fostering a thriving community.

Additionally, when releasing new games (creating new economies), the impact of transitioning players/participants in and out of different games ecosystems needs to be carefully considered as well.

Game design is evolving from an understanding of psychology to now including a lot more social science - game theory, economics, organisational behaviour, political science...etc. It wouldn't surprise me if this becomes its own field of study with unique thought leaders and experts, with some of the learnings applicable to other, IRL social issues.

This will be a HARD and highly sought after position.

Speculation

Speculation is a concern for us. We are careful about how it could impact game design, the larger community, and long-term sustainability, especially considering players with less capital and free players who are contributing to the community in other ways.

The games and the community have to come first. Play-to-earn requires a sense of play (otherwise it’d just be work-to-earn). Both the community and the collectible aspects of crypto have the potential to change the fundamentals of games.

When we can monetise effectively from community engagement and collectibles (monetising the fandom), then games can potentially be designed with a strong focus on maximising fun, and away from F2P Skinner box mechanics and design.

On the other hand, speculation is also an opportunity. There's a lot to consider here - regulation, audience, social responsibility, but speculation is a strong motivation, arguably one that has contributed hugely to the advancement of web3 technology, that we should not ignore or overlook how it can be leveraged.

Considerations

Crypto gaming is still a relatively new field. Some of the things we are still exploring:

• How much of the game should be on-chain?

• What relationships should be built between developer and players, and among different groups of participants, across multiple games?

• Are oligarchs a problem? If so, how do we prevent it?

• How much control can we give to the community while protecting the community from exploitation?

No doubt there are a lot more questions to be answered.

Conclusion

Mobile and social games brought a huge number of people into gaming. I believe crypto gaming can do the same, bringing different categories of participants who might not consider themselves gamers to engage with our games.

It’s also a HUGE design challenge - all these different categories of people now need to be designed for. Managing their different motivations, designing emotions for these new participants, while juggling the economics of everything involved is no easy feat.

I am excited about what’s coming to this new frontier. We have a few projects in the works that incorporate some of these ideas, and I am excited to share more with you soon.

Resources

• a16z NFT Canon

• NFTs, Ultima Online, and player-run game economies

Thanks

Special thanks to these wonderful people who’d given me great feedback on the draft (in no particular order): Laura Pepper, Tom Kail, Mike Cann, Robin Ji, Kabir Hemrajani, George Sequeira, Sam Barberie, Charlie Graham, Evgeny Pasenyants, Jon Walch, Brandon Martinez.

Share

Part 1: Macro — New Participants, Permission-less Opportunities, and Communities

(also on mirror.xyz)

In the past few months, I’ve spoken to people up and down the ecosystem of crypto gaming - from game directors, designers, investors, blockchain operators, to platform builders, to understand what it is, and what the future holds.

I’ve had questions about crypto currencies in the past. Adding gaming and a huge hype cycle to the mix, it was tricky to sort out the signals from the noise. I hope this article helps clarify and strengthen our understanding of crypto gaming. It's also the beginning of a conversation and I welcome your comments and thoughts (find me @theBrandonWu)

I've split this into two parts. In part 1, let's look at crypto's impact on the macro level around the games we build. In part 2, we'll take a closer look at crypto assets themselves on a micro level.

Firstly: I am assuming you have a basic understanding of NFTs and the concept of digital scarcity, and have had some exposure to blockchain gaming.

New Categories of Participants around Games

Let's start with the thing that I am most excited about - the ability to bring in new categories of participants to the ecosystems in and around games, each with new value-adding activities.

Games have long had two main categories of participants - players and developers. Developers create a fun experience for players to purchase and enjoy.

Now with tokens and new ownership models, there can be collectors, community organisers, landlords, traders, promoters, creators…etc. New categories of participants can get involved and participate in the economics around the games efficiently.

You can be a landlord who rent out the property you've beautifully created in game, a trader who analyses the market of in-game items to find arbitrage opportunities, or a collector who enjoys the thrill of hunting for valuable assets and completing sets of collections. You can also be a marketer who takes on tasks set out by the community to earn tokens. (More on this in the community section below)

Just as eSports introduced spectators and sponsors to competitive gaming (many of whom don't play the games themselves), crypto is allowing more people to engage and participate in the activities around games without necessarily being a player.

This opens up new opportunities for shared interactive experiences.

It’s the meta meta game. I believe it will make gaming an even bigger market than we know it today, blurring the line between games and our digital lives.

Products for New Participants

All of these new categories of participants need to be considered and designed for if we are to maximise the value of blockchain for games. I believe the most successful crypto games will be ones that figure out how best to design around all the different incentives and motivations in the ecosystem around the games.

We will also see different products being built (by the developers or the communities) for different categories of participants, all integrated to the same game world. They will have different interfaces and interactions to suit the needs of each category of participants.

The interface for in-game asset day-traders will have more charts and fewer particle effects. The interface for landlords will look more like Shopify’s dashboard and less like SimCity.

The products can be a collection of desktop apps, browser extensions, Discord/Twitch add-ons…etc. Different apps connecting to the same game world.

These client side interfaces all interact with the same game, but they offer different utilities, and provide different values from the game itself.

Permission-less Opportunities

The new categories of participants are possible because of the new, crypto-enabled, ownership model of digital assets.

When assets are owned by players, they are no longer locked inside individual games. Anyone can build on top of them, and opportunities outside of the games themselves start to emerge. You can use high-value in-game NFTs as collaterals for loans, or rent out items you own to other players.

Bundling is one of my favourite permission-less opportunities. When in-game items are NFTs owned by players, they can bundle up items from different games and sell them as a single package, without having to get every single developer behind all of the games to work together to create the bundling.

Without NFTs, all it takes is a single developer disallowing the bundle to break the whole package; the permission-less nature of NFTs make this a feasible idea. With NFTs, you will be able to bundle up assets from a thousand different games, and list the bundle up for sale within a few clicks without months of negotiation.

Side-note on Bundling

Bundling is a powerful tool to create win-wins for both buyers and sellers. Quick Example:

• A market has one Seller who has 2 apples and 2 oranges to sell, and two potential Buyers.

• Buyer A is willing to pay $5 for 1 apple and $1 for 1 orange

• Buyer B is willing to pay $1 for 1 apple and $5 for 1 orange

No Bundling:

• Selling apples at $5 and oranges at $5 => Seller gets $10

• Buyer A buys 1 apple at $5 and 0 orange, Buyer B buys 0 apple and 1 orange at $5

With Bundling:

• Selling bundles of 1 apple and 1 orange at $6 per bundle => Seller gets $12.

• The bundle is attractive to both Buyer A and Buyer B, as they are both willing to pay $6 for 1 apple + 1 orange.

With bundling, the seller makes $2 more, and the buyers each save $4 (they would have had to spend $10 to get 1 apple + 1 orange without the bundle)

With non-player participants now in the ecosystem, bundles can have more value by appealing to these new group of people. Players place little value on items from games they don't play in a bundle. On the other hand, a trader might see a bundle as an arbitrage opportunity if they consider some of the items in a bundle to be hidden gems that will go up in value. The inclusion of new participants opens the door for new value creation opportunities.

The bundling idea came when we started discussing the value of Steam cards, particularly, what do you do with all the low value cards? There is a lot of wasted value in digital assets at the moment. Bundling is a powerful tool that can better extract value from digital assets. This gets even more interesting when we started thinking about bundling with raffles.

Bundling is just one example. With crypto, the efficiency gain isn’t necessarily on performance (how fast things can be done), or scale (how big it can get), but on how fast consensus can be reached (in the bundling example above, the only consensus needed is between the buyer and the seller).

We have increased the efficiency of machines to a point where the biggest speed bumps are now us humans. With crypto, we can increase the efficiency of humans. With permission-less-ness (composability), we increase the efficiency of human collaboration.

Community

The community of all the aforementioned new categories of participants will be the most valuable part of a crypto gaming project.

With 13k members on our Discord server, members help us with testing, moderating, hosting events, helping new players, creating content and tools...etc. And so far we've been rewarding their effort with Discord roles and in-game badges. These are good tools but also very limiting. The more "roles" you accumulate, the less meaningful they start to become.

The idea of leveraging tokens to encourage community activities is very compelling - a great tool for incentivising content creators & community volunteers (e.g.. tournament hosts). Having been a community builder in the past when I started the Seattle Unity User Group, I've seen first hand how a strong community can lead to value creation - creative collaborations, knowledge sharing, not to mention enhanced social well-being and the launching of new careers for many.

Modding, Creators, and User Generated Content

Crypto offers an efficient way to distribute value created by the community by way of tokens.

Crypto-enabled communities, Decentralised Autonomous Organisations (DAOs) in particular, can supercharge community and creative activities around the games. DAOs introduce a way for you to be rewarded for contributing to a project. As long as there are interests in the project, the development of a fan project can continue. There have been many times I was excited about upcoming mods (modifications to games) but disappointed when the people behind the mod decided to stop. There aren't a lot of incentives for someone else to continue the development. An efficient way to reward and attribute contribution is a huge benefit that allows us to embrace an open and transparent creative/modding scene around our games.(See Gitcoin)

—

More on DAOs:

• Peter Yang “What is a DAO?”

• David Phelps “13 WAYS OF LOOKING AT A DAO 👇”

• Packy McCormick “The Dao of DAOs”

• @Cooopahtroopa “DAO Landscape”

—

Can this lead to games being completely open-sourced and sustained by both the communities and the developers? When I first moved to the UK 6 years ago, I was intrigued by one of its prominent business institutions, John Lewis, one of UK’s largest department stores. John Lewis embraces a structure of strong employee ownership with an aligned goal. I believe DAOs could enable us to do the same with our communities.

Next Up

Now that we've explored how crypto changes the ecosystems and communities around games, let's take a closer look at NFT assets, their value, and their impact on game design in part 2.

Share