My Cooking Companion currently resides plugged in on my kitchen countertop. When I need to retrieve a recipe, I simply switch on the power, click the top "talk" button, and say, "get so and so recipe." After an admittedly long 5 to 12 seconds, it responds with the required ingredients, then the first step. To continue, I tap the side "next" button, and my sous chef moves on to the next step for me.

While relatively simple, and completely replaceable by a phone or Google Home, this device was quite fun to make. It started as an OpenClaw cooking chat bot about a month ago, and that OpenClaw instance gradually built a fork of itself with API endpoints for requesting recipes by voice, and a three.js frontend to simulate the hardware that would eventually use these endpoints. This laid the groundwork for an actual embedded device spec, physical prototype, and eventually an encased assembly.

While not the first DIY device I've ever 3D printed or assembled, this is the first I've designed from scratch. Because of this, I figured I would go through the process, key learnings, and pitfalls here. I'll keep it relatively short in this post, and I'll link to more detailed specs for anyone who wants to actually follow along.

How It Started

As mentioned above, this project started as someone else's OpenClaw cooking assistant agent, which they built as part of RaidGuild's April cohort. That original agent is here, but I should note that because of a cohort sponsorship, this agent is meant to be deployed through Pinata's Agent Templates.

For my own cohort project, I wanted to make something hardware-oriented, but within the constraints of the sponsorship. So I deployed the cooking assistant agent through Pinata, and began prompting it to fork its own original repo, and build off of itself. To do this I created a GitHub user for the bot, generated a temporary PAT, then had it cherry-pick all the relevant template code into a new template repo.

I began with the following features:

• SQLite-backed recipe, food-event, and voice-session persistence

• /query for JSON text / next-step requests

• /query-audio for multipart spoken queries and JSON next-step requests

• generated MP3 serving via /app/api/audio/[name]

• generated-audio cleanup script under workspace/scripts/prune-generated-audio.sh

I used query for initial text-based Postman testing, as well as what was to be hit when the "next" button was pushed. /query-audio was reserved for the "talk" button. The flow for /query-audio went like this:

• Client hits the endpoint with multipart data primarily containing some common type of audio file

• OpenAI's whisper-1 model is used to transcribe the audio

• OpenAI's gpt-4.1-nano is used to figure out intent, and general routing to retrieve the correct data

• OpenAI's gpt-4o-mini-tts is used to generate a response audio file

• The response audio file is stored temporarily in the agent workspace

• When the response gets to the client, the client finds the URL for the temporary audio file, downloads it, and plays it to the user

• All audio files are pruned daily

Once I got a bare-minimum working, I decided to create a simulated hardware page to test the UX. This may seem like overkill, but it actually did help quite a lot in improving the quality of responses, and for getting a feel for how I'd actually use the device. The first version (see image above) was completely made by OpenClaw, and to be honest, it was very time consuming and expensive. Remarkably, it was actually faster to learn how to use Tinkercad, and make my own 3D model from scratch.

The second attempt turned out much better, and as I realized midway through 3D modeling, it could be used as the file for the 3D printed case too. Something I realized through this process is that simulating things accurately early on saves you a lot of time later on. Planning for this to be the first of many of these types of projects, which means much more attention will be put on fast and accurate simulations in the future.

The Build

Warning: soldering is requiring to properly follow along

For those who don't want to use a Pinata Agent for the backend, I've since created a bare-minimum API on its own, which can be hosted anywhere.

Picking the Parts

Before I (OpenClaw) wrote my endpoints, case, and overall simulation, I actually already had all my parts picked out (important before simulating, of course). Three sets of parts were need: 3D printed pieces, electronic components, and miscellaneous things to connect everything together.

My 3D printed pieces were:

• Top enclosure

• Bottom enclosure

• "Talk" button parts

• "Next" button parts

My electronic components were:

• Microcontroller

• Mic

• Amp

• Speaker

• 2 buttons

• 1 LED light

• USB power cable

And miscellaneous parts were:

• Wires

• Breadboard for prototyping

• Perfboard for final assembly

You can find a reference for the exact electronic components I used here. Not including negligible parts that you can bulk-buy like wires, buttons, perfboard, and the LED, this only cost me $23.54.

Breadboarding

This project was my first time using a breadboard, and as I'm sure anyone who does maker stuff will point it, it's an absolutely must-have for anything you are designing from scratch. Using a breadboard is relatively intuitive, but I found this video useful for filling in my mental gaps. I also took a 1-week detour to go through all tutorials in the starter kit my breadboard came with (the ELEGOO UNO Project Super Starter Kit).

Some extra bits I did and learned from this process:

• You can flash your program to the ESP32 using most common languages. I used Arduino's IDE, and so flashed .ino files. You can see the exact code I used here

• This may seem obvious, but you should solder on all the component headers before using the breadboard; I spent well over an hour wondering why my speaker wasn't working due to my loose-fitting amp headers

• Make sure you wire the GPIO and GND on opposite sides (diagonally) and across the breadboard gap when connecting the buttons

Printing the Case

3D modeling and printing the enclosure turned out to be surprisingly laborious. In the first place, I had to freshen up on how to actually use 3D modeling software. I used Tinkercad, which seems to have handled my simple needs, but I can also see moving on to Blender for any future designs that are relatively complicated.

Once I got the handle of the software, a lot of things came down to trial and error. I had the original design that I made of the hardware simulator, but the measurements, hole placements, and whole sizes turned out to not be accurate. I also realized a bottom piece of the enclosure was needed to hold the ESP32 in place.

The final count for design iterations was 40. Another seemingly obvious thing I learned while going along is that I could design each enclosure component separately (speaker hole, buttons, mic holder/shelf, bottom enclosure, etc.), then piece them together at the end. Unfortunately, even at the end, fitting all the components together in the 3D modeling software took multiple iterations to get right as well.

For those building along, I've hosted my final enclosure 3D model here, at the cost of $1 (charging mainly as an experiment with x402).

Final Assembly

At long last, I reached the final stage of assembly. This meant upgrading from a breadboard to a perfboard (a perforated board board meant for prototyping or simple assembly; basically, the middle-ground between breadboard and custom printed circuit board), soldering numerous wires between board and components, and shoving everything into the newly minted enclosure.

Incidentally, this was the easiest bit of the entire project. The only false starts came from trying to balance a few of the components in place while also shoving everything into the case. As you can see below, I ended up using Scotch Tape to hold the buttons and LED in place, while I shoved the wires in and clicked the bottom piece into position.

Biggest Takeaways

To wrap things up, I've compiled a short list of biggest takeaways from this project:

• Simulations are important; not only for ensuring your endpoints and design work together, but also for ensuring the entire UX actually makes sense in the way you want to use the device in day-to-day life

• For large 3D models, break it down into small parts. And once they all fit correctly composite them together

• Before you start on any kind of soldering, breadboard your prototype first. You want to make sure that specific parts and wiring work together, as well as your firmware software, before you commit to soldering

• Test at all stages as often as possible. You just added the amp to your breadboard? Make sure it is receiving current. You added the speaker? Write a quick timed beep program first before you move on to a button trigger. Testing often saves you a lot of time and confusion when you inevitably make a mistake

New Features

• Ability to update your username

• Ability to transfer your account to a separate EOA

• Have player 1 go 2nd each round, rather than 1st

  • This allows player 1 to actually react to their opponent, rather than guessing what they will do

• End stale battles that have not finished within 24 hours

New Minor Improvements

• Handle for comments in Solidity patent code

• Add footer

• Improve visibility of Battery Details button during tutorial

• Darken tower color when it has been modified

Bug Fixes

• Better indicators for when session wallet balance is low

• Hide battle control buttons when battle is over or user is not player 1

You can enter the playtest now at autotowerdefense.com.

For support, questions, or ideas, reach out to RaidGuild Forge via the RaidGuild DAO Discord: https://discord.gg/AWHGb8Fs

This blog is also dedicated to sharing upcoming games by RaidGuild Forge, and feature updates for Auto Tower Defense, so subscribe if you want to stay up-to-date. ⚔

Instead of fighting off continuous waves of AI enemies, you battle waves of other async players on a chess-like board. Your top battles are also saved permanently at the end of your run, and at the level you lost at, allowing other players to face you as part of their continuous wave of player-enemy encounters.

You can also earn royalties (in electricity), which can later be sold for USDC. These royalty fees are divvied out when someone wins a battle using a tower component that you engineered and patented. Many patents may never get used, but if you strike on something incredibly useful, you'll find yourself earning a fair amount of electricity asynchronously.

With these two twists, the hope is to showcase mechanics that RaidGuild Forge plans to use in all its upcoming mini-games.

Part of RaidGuild Forge

RaidGuild Forge is a web3 gaming venture from RaidGuild DAO. You can read much more about it here, but suffice it to say that we'll be running mini-game experiments--like Auto Tower Defense--from now through the end of the year.

The goal is to apply our 3 Personas mechanic to different genres until we strike on something that works really well.

Game Mechanics

The 3 Personas

As RaidGuild Forge's first mini-game, Auto Tower Defense will apply the 3 Personas mechanic with the following persona instantiations.

1. Component Engineer: the player who uses the game's Digital Physics constraints to engineer tower components (components could include projectile launchers, wheels, and shields)

2. Tower Assembler: the player who assembles pre-engineered components into a full tower (towers can be offensive, defensive, or a hybrid)

3. Battler: the player who uses pre-assembled towers to battle

A single player can of course be all 3 personas, or just 1, if they so choose.

Part of the 3 Personas mechanic is also how it relates to patent-royalty stacking.

Engineers and Assemblers have the opportunity to patent their work for others to use, and when a Battler earns stake from their win, a portion of that stake gets distributed to the patentees of all towers and components that the battler used. As the game grows, the list of components and towers grows; as that list grows, the battle meta changes; and as the meta changes, demand for which components and towers are needed changes. The goal is for this dynamic to always be in flux.

⚠ Note, however, that during the initial alpha playtests, the Tower Assembler persona will not be available.

Async Battles

A mechanic that may end up being unique to the Auto Tower Defense mini-game is the idea of async battles. As mentioned above, a player's best battle in a run is saved at that level in order for other players to face in their own continuous wave of async player-enemy encounters. The way this works is relatively straightforward:

1. Every turn is broken into discrete actions

2. Actions are saved into a replay-able “Saved Battle”

3. Once you lose your run, the Saved Battle with the highest level in that run is saved permanently at that level

4. When another player reaches that level, there is a random chance of running into your Saved Battle

5. If this happens, the saved actions are replayed against that player

6. As your Saved Game wins battles, it accumulates and divvies electricity:

   • Half goes to you and the patentees of your towers/components

   • The other half stays with your Saved Game and becomes a reward for the next player who defeats it

The idea is to let the game evolve continuously—as more players join, the catalog of enemy encounters grows organically. There is also the appeal of creating an amazing Saved Battle that earns you electricity while you sleep.

Playtest Schedule

This is a very early alpha playtest, primarily to test out the patent-royalty economy. There are currently only 2 tower types, and 1 component type, but more will be added throughout the playtest. We also only included 2 personas for now: Component Engineer and Battler. The Tower Assembler persona is being worked on, though, and should be included in later rounds of the alpha playtest.

There will be 5 rounds, starting on June 30th and going until September 7th:

1. Round 1: starts June 30th

2. Round 2: starts July 21st

3. Round 3: starts August 4th

4. Round 4: starts August 18th

5. Round 5: starts September 1st

Every round will last 1 week, leaving the week after dedicated to bug fixes and new features. Each round will also be loaded up with around 100 USDC in winnings in order to incentivize people to play what is frankly a fairly incomplete game right now. As time goes on, people may decide to purchase electricity from the Solar Farm, which will introduce more money into the economy. Finally, these playtest rounds will start with only 100 open player slots, so if you want to play, create an account early!

How to Participate

You can enter the playtest now at autotowerdefense.com.

For support, questions, or ideas, reach out to RaidGuild Forge via the RaidGuild DAO Discord: https://discord.gg/AWHGb8Fs

This blog is also dedicated to sharing upcoming games by RaidGuild Forge, and feature updates for Auto Tower Defense, so subscribe if you want to stay up-to-date. ⚔

The RaidGuild DAO is a network of developers that has collectively provided services to companies and protocols for over 5 years. Starting as the world's first DevShop DAO in 2019, it's weathered the many ups and downs of the web3 ecosystem. Along the way, we've worked with over 150 clients, shipped over 200 projects, and grown to over 140 members. But we've stuck primarily with building products for others.

Today, we announce our first "venture" as a DAO: RaidGuild Forge. A venture for RaidGuild is a concentrated experiment in a particular sector to see if it can add value, and ultimately, a full product. For Forge, we will focus on niche mini-games and go through 3 stylized phases over the next 6 months (from June to December, 2025).You've

1. Prospecting: early public launches of mini-game experiments

2. Mining: fast iteration on experiments that have traction

3. Ore Processing: building out a mini-game with traction into a full game

Of course, if the venture ever loses steam it could wind down at any of these phases.

The Forge Venture

The Forge Venture is spinning up specifically to prospect the area of Digital Physics (or Autonomous Worlds) in web3 games. A handful of studios have investigated these grounds before: particularly, Dust (formerly Biomes) and CCP Games with EVE Frontier are exploring them. However, Forge will specifically focus on patent-royalty stacking in games with Digital Physics. Our prospecting will focus on building experimental mini-games with 4 core mechanics.

1. Patented Components: engineered parts that can be used in the machines of assemblers; requires low-level skills

2. Patented Machines: structures that are assembled as one of the core items of multiplayer battles; requires mid-level skills

3. Multi-player Battles: contests between players using assembled machines; requires high-level skills

4. Royalty Splits: rewards that go to the winner of a battle, as well as both the assemblers of machines and engineers of components that were used to win the battle

While the patent-royalty mechanics will remain relatively fixed between mini-games, the battle types will differ for each release. For instance, our first mini-game will center around 2D Tower Defense battles, but future games could center around RoboCup, kart racing, or even FPS games (the respective machines being robot fighters, karts, and weapons).

To illustrate this further, let's take the example of a kart racing mini-game, where our 4 mechanics form 3 player personas.

1. The Battler: the player driving the pre-assembled karts in races

2. The Assembler: the player who builds unique karts using pre-engineered components

3. The Engineer: the player who creates and optimizes components (like wheels, frames, and engines) based on the constraints of the game's digital physics

Players can focus on 1 persona, or dabble with all 3. Our goal will be to find an initial battle style that's both fun and easily illustrates these 3 personas and underlying patent-royalty system.

MUD and Redstone

To keep as much on-chain as possible, we'll be building all initial mini-games on MUD and deploying on Redstone, which allows for extremely cheap transactions and eventually 7ms latency through Quarry. However, for in-game payments--in order to start the flow of royalties--we will be using Base USDC, given how easy it is for users to purchase.

Our Niche and RaidGuild's Advantage

Because of high gas costs and slow block speeds many of these games are forced to move most of the data off-chain, reducing them to somewhat unsophisticated and overly traditional versions of what they could be. While web3 games have improved quite a bit in the last few years, they are still not far off from the flash games of 20 years ago (think addictinggames.com circa 2008). At the same time, high-quality web2 games are continuing to dabble with web3 features, but generally not beyond introducing NFTs into already existing franchises. There has been a strong increase in web3 games released in the last couple years, but clearly there are plenty of areas that are untapped.

As is no surprise, we believe the real magic of web3 games comes when most of the data is on-chain and Digital Physics is built into it from the beginning. While traditional games focus on 1 type of player (The Battler), our games will focus on 3 types of players: The Battler, The Assembler, and The Engineer. Each plays a role in driving what's possible in the game and even changing the meta for the entire player base. A new component is introduced that changes what assemblers use, a new machine is introduced that changes the strategy of battlers, or a new battle style changes what components and machines are most in demand. Once a fair patent-royalty framework is solidified, it will be exciting to see this dynamic applied to many different genres.

Since the beginning, RaidGuild has straddled the world of role-playing and work. In our DAO, each contract is a raid, our main meeting is a RoundTable, and every internal role has an associated class (e.g., solidity engineers are wizards). Thus, building games that straddle these worlds is a natural inclination. RaidGuild's very existence illustrates the power of pseudonymous players around the world voluntarily coming together to make a living through role-play. RaidGuild Forge is an attempt to make this possible for those beyond our 140 member base.

What we've always lacked, though, is an automated way of attributing value and distributing rewards based on it. Numerous projects have tried to crack this nut: SourceCred notably tried until it dissolved in 2022, and Tea Protocol is attempting to do it now for open source software. Building out a patent-royalty system for Autonomous Worlds is perhaps another attempt at doing this, albeit narrowly focused. But if successful, it will not only change what players come to expect from their games, but potentially what sovereign workers expect for making a living.

In its final form, I want the console to be cheap (less than $125 in parts), handheld, and fully dedicated to web3.

Early Dabbling

Earlier this year, I put together a couple pre-designed kits for Retropie consoles built around the Raspberry Pi Zero W 2. The first was a PiGRRL Zero by Adafruit, and cost me $92.26 in parts. It took a fair amount soldering, 3D printing, and wire wrangling, and still resulted in a device that technically worked, but was still very clunky.

My second build was the Null 2 by Ampersand, which cost me $99.38 in parts. While still requiring some soldering, and multiple failed 3D case prints, the result was super compact and enjoyable to use. In fact, I still play on it a couple times a week. My conclusion is that attaching all major components to a large, pre-designed PCB is the way to go (less wires to wrangle).

These 2 previous builds exclusively ran old Retropie games, though. To make a console that works exclusively with web3 games, I'll need a handful of additional features.

• Web3 game launcher that opens at startup (this will house the players library of web3 games)

• A web2 game engine that can build around on-chain data storage and syncing (like Unreal, Unity, or Godot)

• A web3 game engine that will handle the on-chain data storage and syncing (like MUD)

• A board powerful enough to run modern 2D games (and maybe 3D games), while making heavy use of network calls

• A built-in hardware wallet that permanently links gameplay to a particular device

Potential Parts of This Series

The continuation of this series primarily depends on if a MUD plugin can be made to work with Godot 4 (MUD is an on-chain game engine built by Lattice, and Godot 4 is an open source traditional game engine). But assuming all goes well, I can see there being at least 4 parts.

1. Testing the waters with Godot and cheap DIY components (this post)

2. Adding a MUD plugin to make my Godot game on-chain

3. Designing my own console and web3 Godot game

4. Adding a hardware wallet to my console

Testing with Godot and Cheap DIY Components

The Hardware

I wanted a board that was as cheap as I could go, while still being capable of displaying a 2D game on a 3 inch screen, and while also having decent support/documentation/community for when things go wrong. For the third quality, Raspberry Pi seemed like the obvious choice. There's a huge and friendly community for Raspberry Pi, and plenty of solid documentation. For the first two qualities, I narrowed it down even further to the Raspberry Pi 3 B+, which cost me $48 before taxes and shipping.

The screen was a bit more persnickety. My first choice was a $14 Waveshare 240x320 IPS LCD Display. However, because it used an IPS connection, a fair amount of driver installation and configuration was required. As it turned out, one of the drivers (FBCP) is deprecated in the latest Raspberry Pi OS (Bookworm). And the older OS (Bullseye) didn't have OpenGL 3, which my Godot game required. So I moved on to another screen.

My second choice was a $33 Osoyoo 480x320 HDMI LCD Display. While a little pricier, I at least didn't have to install any drivers, and it's likely that the HDMI connection will look smoother given its faster responsiveness. It also means no soldering! I may change back to IPS in the future, if I need something that is more compact, but I'll return to that in a later post.

My remaining bits of hardware are a 5v micro USB power cable, a cheap Logitech game controller, and a wireless keyboard and mouse to launch the game (in the future I'll have the game launch at startup).

The Software

As mentioned earlier, I'm using the latest full Raspberry Pi OS as my operating system. This may be overkill for a device that is purely dedicated to launching a game on startup, but it seemed the easiest to go with for testing.

On the game side, I'm beginning with the Godot engine--it's open source, growing in popularity, and doesn't include the pricing hikes that Unity recently introduced. 7 years ago, I dabbled with Unreal for a music VR project, but didn't get far. Already, though, getting up and running with Godot is much easier (based on my memory of Unreal): the download file is tiny, and going from their website's splash page to loading your first project takes about 2 minutes.

Given that I've never created a game in Godot, I started with a beginner tutorial. This one seemed good:

A couple hours later, and the demo was ready to test. While running perfectly smoothly on my MacBook, the game moved at glacier speeds on the Pi. As it turned out, my 1GB of RAM was no match for the HD resolution I exported at, and the default resolution the OS ran on. I found that exporting the game at 640x480 and downgrading the Raspberry Pi OS' resolution to the lowest setting was the winning combination to get things running smoothly. The result is just enough to feel like I'm cutting my teeth on what constraints will look like throughout the project.

As much as I'd like to jump into designing a full minigame, PCB, and 3D printed housing, I first need to make sure that the web3 plugin will work. The next post will primarily deal with trying to get a MUD-ified version of this demo working.

Next Steps

• Get a MUD plugin working in Godot

• Add on-chain components to my demo game (each coin picked up is stored on-chain)

• Ensure MUD-ified game can be exported and played on the current demo device

• Launch game at startup and play in kiosk mode

• Add a safe power shut down when user quits game