Should You Consider Making a Digital Version of Your Self-Published Board Game?
If you’re working on an indie board game, the idea of a digital version probably feels like one of two things:
a dream that could massively expand your audience, or
a distraction that could derail the thing you actually need to ship.
For Sylvan Tactics, I’m trying to thread the needle.
Why am I making a digital version of Sylvan Tactics?
Mostly, this is an experiment.
I consider the physical version of Sylvan Tactics to be the definitive way to play. It was designed around a shared table, real cards, and chess pieces you can physically pick up. But digital board games are very good at a few specific things that physical games struggle with:
They onboard new players through interactive tutorials.
They let players share a game instantly instead of coordinating schedules.
They reduce friction between curiosity and play.
The Work-in-Progress Digital Edition of Sylvan Tactics
With a Kickstarter campaign planned for the physical release, my hope is to launch a free digital version ahead of time and use it as a funnel to the prelaunch page. Will it work? I genuinely do not know.
Maybe players will decide the digital version is “good enough” and never feel the need to buy a physical copy. Maybe they’ll bounce off the game entirely. Or maybe it introduces thousands of people to a game they would never have discovered otherwise.
And honestly, that last possibility matters to me even if the rest fails.
I’ve invested a huge amount of time into the design, art, and playtesting of the original board game version of Sylvan Tactics. I would hate for all of that work to be permanently trapped inside a small physical print run. I do want the game to be profitable eventually, but if this project builds a community that supports the next game, that’s still a win. I’m in this for the long haul.
Why not just use Tabletop Simulator or Tabletopia?
I am using them. But they’re not enough on their own.
Visibility on those platforms is low, and the barrier to entry is high. Tabletop Simulator is a paid Steam application. Tabletopia requires accounts and a willingness to learn a specific interface. Even well-scripted mods still ask players to understand hotkeys, camera controls, and virtual physics before they ever engage with the game itself.
Sylvan Tactics on Tabletop Simulator
Those platforms are great for experienced hobbyists. They are much less effective for onboarding someone who just wants to click a couple buttons and start playing.
My goal is to make it as easy as possible for someone to try Sylvan Tactics. Tabletop simulators are approximations of a physical experience. I want something that feels purpose-built.
Is a digital version even feasible for an indie dev?
With traditional development workflows, probably not.
I do have experience building video games, but doing it the old-fashioned way would require months of work and a small team. That’s not realistic for an independent board game designer prior to a successful physical launch. Normally you have a decision to make between making a board game and making a video game. It’s nearly impossible to take on the effort of developing both simultaneously.
However, agentic coding is changing the game.
Using tools like GitHub Copilot and Claude Opus, I’m no longer spending most of my time writing code. I’m writing detailed requirements, reviewing implementations, and refining behavior. And it turns out that one of the best possible requirements documents for a digital board game is a well-edited, heavily playtested rulebook.
Choosing a tech stack that works with AI, not against it
Once I committed to the idea, my first task was architectural. I had three requirements:
A language with an enormous amount of training data
A workflow that minimizes manual setup and opaque tooling
A path to desktop builds and Steam integration
That immediately pushed me toward the web.
I chose TypeScript with React and basic CSS for rendering. I already work as a front-end developer, but more importantly, AI models are extremely fluent in web technologies. There are millions of examples of React components, drag-and-drop systems, state machines, and UI patterns in their training data.
Traditional game engines like Unity or Unreal are powerful, but they fight this workflow. They rely heavily on visual editors, scene files, serialized assets, and manual wiring that the AI can’t see or modify directly.
I needed a code-centric environment where the AI could reason about the whole system.
A clean separation: rules engine first, UI second
One of the best decisions I made was separating the game engine from the interface entirely.
The core of Sylvan Tactics Digital Edition is a pure TypeScript rules engine. It does not handle anything UI related or even have access to the DOM. It’s just deterministic functions that take a game state and return a new one.
Every move, attack, card play, or ability activation is represented as a serializable command. This has paid off in a bunch of ways:
The rules engine is trivial to unit test
Multiplayer synchronization becomes much simpler
Replays can be implemented by replaying actions
AI-assisted coding becomes dramatically more effective
When I describe a rule to Copilot, it can focus entirely on logic instead of UI concerns. In many cases it generates not just the implementation but also test cases that surface edge cases I hadn’t considered.
The React UI layer is intentionally “dumb.” It renders state and dispatches actions. That’s it.
Why Steam, and why Electron?
If the game is free, why not just host it as a web app?
Two reasons: visibility and multiplayer.
Steam is where players already are. Free games with achievements can have an incredibly long tail. I released a small free visual novel on Steam in 2017 (The Monster Inside), and it still sees 15 to 30 new players per day years later. That kind of passive discovery is hard to replicate elsewhere.
The second reason is multiplayer. Hosting servers, managing accounts, handling NAT traversal, and scaling infrastructure is expensive and complex. Steam has those problems solved.
By wrapping the web game in Electron and integrating Steamworks, I get:
Steam authentication
Peer-to-peer networking with relay fallback
Matchmaking and invites
Achievements and overlays
Zero server hosting costs
That tradeoff is worth it. Especially for a turn-based game, a well-polished web-based UI is more than sufficient.
What separates “vibe coding” from “AI slop”?
I love the speed of modern AI tools, but I also understand why people side-eye anything “made with AI.” A lot of what gets called AI slop isn’t about the tool. It’s about the absence of authorship.
For me, the line is simple:
The code is not the game. The game is the definition of rules that generate desired player behaviors.
The actual product is what the player experiences: the choices, the risks, the timing windows, the incentives, the ways the game rewards clever positioning and punishes overextension. Those behaviors were designed intentionally and refined through playtesting. AI didn’t invent them.
In that sense, AI is acting more like a translator than a designer. I describe the rules and constraints. It helps fill in the syntax. I review it, correct it, and make sure the behavior matches the rulebook and the feel of the physical game.
And honestly, this isn’t a radical idea. Most games are remixes. Almost every foundational mechanic in Sylvan Tactics has been coded by someone else before: grids, turns, adjacency checks, deck shuffling, action resolution, movement rules. The originality isn’t in reinventing those building blocks. It’s in how they’re combined, how they’re paced, and how they’re presented.
That’s where human authorship lives for me:
the design decisions that shape the experience
the taste that decides what belongs and what doesn’t
the playtesting and iteration that makes the rules resilient
the human-made artwork and aesthetics that gives it identity
So when I talk about avoiding AI slop, I’m not talking about avoiding AI. I’m talking about avoiding output without authorship. If I can’t explain why a rule exists, or justify an interaction, or maintain the system without the whole thing collapsing, then it doesn’t matter who typed the code. It’s not finished.
Vibe coding is great for moving fast. But the finished version still needs the same thing it always needed: a human being taking ownership of the result.
Human-authored art and design remain the heart of Sylvan Tactics
Takeaways: should you do it?
Here’s my current stance:
A digital version for your self-published board game is worth considering if:
your game has rules that can be cleanly encoded and enforced
you want a low-friction way for new players to learn and try the game
you have the time and energy to learn and do it yourself
A digital version is probably a mistake if:
you’re using it to avoid finishing the physical game
you can’t commit to ongoing maintenance
your “digital version” is secretly a full video game in disguise
Unfortunately, (unless you have buckets of cash and access to a dedicated team of developers) a digital version is probably out of reach without the use of AI coding tools. Some people have a firm moral objection to using any AI tools (which I can respect), but it’s important to be realistic about what is achievable as a small, self-published board game developer. Hopefully I’ve done a good job explaining why AI coding is not synonymous with “AI slop”.
For Sylvan Tactics, I’m betting that a free, polished, rules-enforced digital edition can act as an on-ramp: something people can try in minutes, fall in love with, and then choose to support when the physical Kickstarter goes live.
Will it work? I don’t know yet.
But if the digital version helps even a small number of players discover the game, learn it, and share it with a friend, it will have been worth building.
A quick note on AI-generated code and ownership: I’m not a lawyer, but my understanding is that copyright generally protects human-authored expression, not underlying game rules or systems. AI tools can speed up implementation, but they don’t automatically change who “owns” the game. The parts of Sylvan Tactics that are clearly mine (the rulebook text, the game’s design decisions, and the art direction and presentation) are still authored by me. For the software itself, the strongest claim comes from the work I do to specify behavior, review and refine implementations, and shape the final codebase into a cohesive, maintainable product. The legal landscape around AI-assisted work is also evolving, so it’s worth doing your own research before you build your workflow around these tools and being mindful of third-party code and licenses. And while I still treat my source code as valuable, I’m not losing sleep over it, because Sylvan Tactics as a game is bigger than any single implementation. The brand, the writing, the artwork, and the overall presentation are where most of its identity lives, and those are protected through more established forms of ownership.