Show HN: Boardzilla, a framework for making web-based board games

A new framework called Boardzilla aims to make it easier to build and host web-based board games, offering a TypeScript-based engine that runs shared game logic on both client and server. Commenters praise its focus on tabletop mechanics and prototyping but raise concerns about its nonstandard Commons Clause licensing, lack of Python support, reliance on React, and practical issues like documentation gaps, browser compatibility bugs, and overemphasis on Discord for support. There is also debate over intellectual property risks around the “-zilla” name and the difficulty of competing with Board Game Arena and Asmodee, leading some to see the main opportunity in indie games and publisher-focused tooling rather than mainstream titles.

Licensing and Open Source Issues

  • Core engine currently uses Commons Clause, which multiple commenters consider non–FOSS and problematic.
  • AGPLv3 is suggested as an alternative: still free/open, acceptable to Linux distros, but large companies avoid it, which some see as a feature.
  • Authors indicate they’ll revisit licensing and are reminded they can dual‑license commercially if needed.

Positioning vs Existing Platforms & Game Rights

  • Many compare it to Board Game Arena (BGA); this is positioned as “like BGA, not Tabletop Simulator.”
  • Concern: Asmodee’s ownership of BGA and many publishers makes licensing big titles difficult; suggestion to focus on indie publishers and prototypes.
  • Legal note: mechanics aren’t copyrightable, but art, names, and rules text are; community generally frowns on obvious clones.

Technology Choices & Architecture

  • Games are written once in TypeScript and run on both client and server; this is why there’s no separate Python backend.
  • React is used lightly, mainly for JSX; heavy animation is outside React. Some suggest leaner alternatives due to bundle size.
  • Abstractions: Piece, Player, Space, Game, Action, and a “flow” tree (phases, loops, everyPlayer for simultaneous actions).
  • Planned support for pluggable AI; a TestRunner class already exists for automated play.

Python, Lua, and Language Debate

  • Several users strongly wish for Python on the server, citing ecosystem and expressiveness.
  • Others argue TS is logical for shared client/server logic and that porting to Python isn’t “trivial” for the maintainer.
  • Side discussion on Lua’s popularity in games and whether its object‑oriented patterns are adequate.

Self‑Hosting and Deployment

  • Local development is supported; a clear self‑hosted “single‑game runner” is planned but not yet done.
  • Some nearly skipped the project because self‑hosting wasn’t highlighted on the landing page.

Bugs, Compatibility, and UX

  • Multiple reports of Object.hasOwn errors on older browsers/iOS; polyfills were added but needed iteration.
  • Minor issues noted: typo in credits, lack of email notification unsubscribe, and some in‑game rule bugs.
  • Commenters stress that long‑term success hinges on UI/UX and an active player base, not just engine quality.

Naming, Trademark, and Branding

  • Strong warnings about using “*zilla” due to aggressive Godzilla trademark enforcement and a similar‑looking logo; several advise renaming.

Docs, Onboarding, and Community Channels

  • General praise for the ambition, but repeated calls for step‑by‑step tutorials and clearer docs.
  • Landing page is criticized for leading with “join our Discord”; some dislike Discord as a quasi‑documentation channel and prefer searchable, static docs.