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