pith. machine review for the scientific record. sign in

arxiv: 2605.08319 · v1 · submitted 2026-05-08 · 💻 cs.SE · cs.AI

Recognition: no theorem link

Mazocarta: A Seeded Procedural Deckbuilder for Instrumented Game Development

Timothy C. Cogan

Authors on Pith no claims yet

Pith reviewed 2026-05-12 00:57 UTC · model grok-4.3

classification 💻 cs.SE cs.AI
keywords deckbuilderprocedural generationdeterministic simulationWebAssemblyplaytestingmultiplayerinstrumented developmentRust
0
0 comments X

The pith

One shared rules engine powers play, simulation, tests, save/load, and local multiplayer in Mazocarta.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper shows how a tactical deckbuilder can be built so that its core rules logic runs identically whether players interact in a browser, a command line simulator runs automated games, or tests and multiplayer sessions execute against the same code. This matters because separate implementations for each use case often drift and introduce bugs or inconsistencies that only appear late in development. By keeping everything on one deterministic Rust engine compiled to native and WebAssembly targets, the work creates a single source of truth that supports reproducible runs, regression checks, and balance experiments. The architecture includes seeded generation, a deterministic run model, and QR-based WebRTC pairing to enable local two-player sessions without external servers.

Core claim

Mazocarta is a seeded procedural tactical deckbuilder whose primary contribution is the construction of an instrumented game-development reference artifact: the same rules engine supports interactive play, native command-line simulation, automated end-to-end tests, save/load fixtures, and local-area multiplayer. An evaluation over 1,000 deterministic seeds produces reproducible signals, with single-player and two-player autoplay win rates of 36.1% and 34.9% respectively, offered as repeatable probes rather than final balance values. All listed interfaces exercise one shared production rules core.

What carries the argument

the shared production rules core written in Rust and compiled to both native executables and WebAssembly

If this is right

  • Deterministic regression checks can run against the production rules without maintaining duplicate logic.
  • Automated playtesting workflows and balance probes produce signals that match what occurs in interactive sessions.
  • Browser-native local multiplayer sessions exercise the same rules engine as single-player simulation.
  • Save and load fixtures allow state to transfer cleanly between command-line tools and browser play.
  • Reproducible seeds enable repeated measurement of mechanic changes across 1,000 runs.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Teams could reduce the maintenance burden of keeping simulation, testing, and live play in sync by adopting a single compiled core.
  • The deterministic model might extend to continuous integration pipelines that gate mechanic changes on regression-free seed batches.
  • Similar shared-core designs could help other genres maintain consistency when adding AI opponents or remote play features.
  • The QR-mediated pairing approach could be tested for low-latency local sessions in other WebAssembly games.

Load-bearing premise

A single shared rules core can practically support interactive play, native simulation, automated tests, save/load, and local multiplayer without hidden tradeoffs in performance, maintainability, or determinism across environments.

What would settle it

Executing the identical seed in the browser client and the native simulator and observing divergent game states or outcomes would disprove that one core supports all interfaces consistently.

Figures

Figures reproduced from arXiv: 2605.08319 by Timothy C. Cogan.

Figure 1
Figure 1. Figure 1: Responsive tile-based combat surface. On narrow screens, Mazocarta keeps combat state [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Instrumentation loop. Reproducible inputs enter one production Rust rules core; the [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: QR-mediated WebRTC pairing. Mazocarta uses QR frames or manual paste only for [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Autoplay win-rate signal over 1000 deterministic seeds. The chart is intended as a [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
read the original abstract

Mazocarta is a seeded procedural tactical deckbuilder implemented in Rust, compiled to WebAssembly for browser play, and executable natively for simulation. Its primary technical contribution is not the invention of a new deckbuilding genre, but the construction of an instrumented game-development reference artifact: the same rules engine supports interactive play, native command-line simulation, automated end-to-end tests, save/load fixtures, and local-area multiplayer. This paper describes Mazocarta's architecture, deterministic run model, reproducible balance probes, and QR-mediated WebRTC pairing for local multiplayer. An evaluation snapshot over 1,000 deterministic seeds shows that the simulation pipeline can produce reproducible development signals. In the evaluated configuration, single-player and two-player autoplay win rates were 36.1% and 34.9% over 1,000 deterministic seeds, respectively. These rates are not presented as final player-facing balance metrics, but as repeatable probes for future balance shifts and regressions. Mazocarta is positioned as a playable open-source reference artifact for instrumented game development: deterministic regression checks, automated playtesting workflows, balance probes for game mechanics, and browser-native local multiplayer all exercise one shared production rules core.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The manuscript presents Mazocarta, a seeded procedural tactical deckbuilder written in Rust and compiled to WebAssembly. Its primary contribution is an architecture in which a single shared rules engine supports interactive browser-based play, native command-line simulation, automated end-to-end tests, save/load fixtures, and WebRTC local-area multiplayer. The paper describes the deterministic run model, QR-mediated pairing mechanism, and reports an evaluation snapshot over 1,000 deterministic seeds that yields reproducible win rates of 36.1% (single-player) and 34.9% (two-player) under autoplay; these rates are framed as repeatable probes for balance shifts and regressions rather than final metrics.

Significance. If the shared-rules claim holds, the work supplies a concrete, open-source reference artifact for instrumented game development. The ability to exercise the identical production rules core across interactive, simulation, testing, and multiplayer interfaces, together with the fixed-seed reproducibility data, offers a practical template for deterministic regression checks and automated playtesting workflows. The explicit positioning as a playable artifact rather than a new game genre is a strength.

major comments (2)
  1. [Architecture] Architecture section: the claim that a single rules engine can be shared across interactive, simulation, test, and multiplayer interfaces without material tradeoffs in determinism or maintainability is central but supported only at a high level. No quantitative measurements (e.g., execution-time overhead, memory footprint, or test-maintenance effort) are provided for the native versus WASM targets, leaving the absence of prohibitive costs asserted rather than demonstrated.
  2. [Evaluation] Evaluation section: the 1,000-seed win-rate results (36.1% and 34.9%) are presented as direct evidence of reproducible simulation signals, yet the manuscript supplies neither the autoplay policy details nor the precise seed-generation procedure. Without these, independent reproduction of the reported signals cannot be verified from the text alone.
minor comments (2)
  1. [Architecture] The description of QR-mediated WebRTC pairing is mentioned in the abstract and architecture but lacks a step-by-step account or diagram showing how pairing occurs and how game state is synchronized.
  2. The paper would benefit from a short related-work paragraph situating the deterministic Rust/WASM approach against existing game-engine instrumentation efforts (e.g., other Rust game frameworks or WASM-based simulation platforms).

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the positive summary and recommendation for minor revision. The comments identify clear opportunities to strengthen the manuscript's claims on architecture and reproducibility. We address each point below and will incorporate the requested details in the revised version.

read point-by-point responses

  1. Referee: [Architecture] Architecture section: the claim that a single rules engine can be shared across interactive, simulation, test, and multiplayer interfaces without material tradeoffs in determinism or maintainability is central but supported only at a high level. No quantitative measurements (e.g., execution-time overhead, memory footprint, or test-maintenance effort) are provided for the native versus WASM targets, leaving the absence of prohibitive costs asserted rather than demonstrated.

    Authors: We agree that the architecture claim would be more convincing with quantitative support. In the revised manuscript we will add a dedicated subsection under Architecture that reports benchmark measurements of execution-time overhead and memory footprint for equivalent simulation workloads on native Rust versus the WebAssembly target. These will be collected using standard tools (e.g., criterion for timing and heaptrack for memory) on representative 1,000-seed runs. We will also briefly note our observed maintainability experience with the single shared rules crate. revision: yes

  2. Referee: [Evaluation] Evaluation section: the 1,000-seed win-rate results (36.1% and 34.9%) are presented as direct evidence of reproducible simulation signals, yet the manuscript supplies neither the autoplay policy details nor the precise seed-generation procedure. Without these, independent reproduction of the reported signals cannot be verified from the text alone.

    Authors: We accept that the current text does not supply sufficient detail for independent reproduction. The revised Evaluation section will describe the autoplay policy (the exact decision heuristic and any tie-breaking rules) and the deterministic seed-generation procedure (including the PRNG and how the 1,000 seeds are derived). In addition, the full seed list and the policy implementation will be committed to the open-source repository so that readers can exactly replicate the reported win rates. revision: yes

Circularity Check

0 steps flagged

No significant circularity

full rationale

The manuscript presents an implementation artifact (Rust rules engine compiled to native and WASM) together with direct empirical outputs from running that engine over 1,000 deterministic seeds. No equations, first-principles derivations, fitted parameters, or predictions are introduced whose results could be shown to equal their own inputs by construction. The reported win-rate probes (36.1 % and 34.9 %) are simply the measured outcomes of executing the shared core under the stated conditions; reproducibility across interfaces is demonstrated by construction of the artifact itself rather than by any self-referential reduction.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The paper relies on standard assumptions about software determinism and the feasibility of a shared rules core for multiple interfaces.

axioms (2)
  • domain assumption Rust's seeded random number generation produces identical results across platforms and runs
    Required for the deterministic simulation and reproducible probes to hold
  • ad hoc to paper A single rules engine can be shared across interactive, simulation, test, and multiplayer interfaces without prohibitive complexity or performance costs
    Central load-bearing assumption for the instrumented reference artifact claim

pith-pipeline@v0.9.0 · 5505 in / 1537 out tokens · 66695 ms · 2026-05-12T00:57:35.083995+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages

  1. [1]

    The Rust Programming Language.https://www.rust-lang.org/, 2026

    Rust Team. The Rust Programming Language.https://www.rust-lang.org/, 2026. Project website, accessed 1 May 2026

    work page 2026

  2. [2]

    WebAssembly Core Specification

    World Wide Web Consortium. WebAssembly Core Specification. https://www.w3.org/TR/wasm-core-1/, 2019. W3C Recommendation, 5 December 2019

    work page 2019

  3. [3]

    Bringing the web up to speed with webassembly

    Andreas Haas, Andreas Rossberg, Derek L Schuff, Ben L Titzer, Michael Holman, Dan Gohman, Luke Wagner, Alon Zakai, and Jean-François Bastien. Bringing the web up to speed with webassembly. In Proceedings of the 38th ACM SIGPLAN conference on programming language design and implementation, pages 185–200, 2017

    work page 2017

  4. [4]

    Mazocarta (GitHub).https://github.com/timcogan/mazocarta, 2026

    Timothy Cogan. Mazocarta (GitHub).https://github.com/timcogan/mazocarta, 2026. Software repository, accessed 6 May 2026

    work page 2026

  5. [5]

    Springer, 2018

    Georgios N Yannakakis and Julian Togelius.Artificial intelligence and games, volume 2. Springer, 2018

    work page 2018

  6. [6]

    Automated Playtesting with Procedural Personas through MCTS with Evolved Heuristics.IEEE Transactions on Games, 11(4):352–362, 2018

    Christoffer Holmgård, Michael Cerny Green, Antonios Liapis, and Julian Togelius. Automated Playtesting with Procedural Personas through MCTS with Evolved Heuristics.IEEE Transactions on Games, 11(4):352–362, 2018

    work page 2018

  7. [7]

    Alexander Zook, Eric Fruchter, and Mark O. Riedl. Automatic Playtesting for Game Parameter Tuning via Active Learning.arXiv preprint arXiv:1908.01417, 2019. https://arxiv.org/abs/1908.01417

    work page arXiv 1908

  8. [8]

    Local-first software: you own your data, in spite of the cloud

    Martin Kleppmann, Adam Wiggins, Peter Van Hardenberg, and Mark McGranaghan. Local-first software: you own your data, in spite of the cloud. InProceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, pages 154–178, 2019. 8

    work page 2019

  9. [9]

    WebRTC: Real-Time Communication in Browsers

    World Wide Web Consortium. WebRTC: Real-Time Communication in Browsers. https://www.w3.org/TR/webrtc/, 2025. W3C Recommendation, 13 March 2025

    work page 2025

  10. [10]

    Keranen, C

    A. Keranen, C. Holmberg, and J. Rosenberg. Interactive Connectivity Establishment (ICE): A protocol for NAT traversal. RFC 8445, Internet Engineering Task Force, 2018. https://www.rfc-editor.org/rfc/rfc8445

    work page 2018

  11. [11]

    Getting Started with Peer Connections

    WebRTC Project. Getting Started with Peer Connections. https://webrtc.org/getting-started/peer-connections, 2026. Documentation, accessed 1 May 2026

    work page 2026

  12. [12]

    WebRTC Connectivity

    MDN Web Docs. WebRTC Connectivity. https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity, 2026. Documentation, accessed 1 May 2026

    work page 2026

  13. [13]

    AI-Driven Autoplay Agents for Prelaunch Game Tuning

    Igor Borovikov. AI-Driven Autoplay Agents for Prelaunch Game Tuning. In Steve Rabin, editor, Game AI Pro: Online Edition 2021, chapter 10. Game AI Pro, 2021. https://www.gameaipro.com/GameAIProOnlineEdition2021/GameAIProOnlineEdition2021_ Chapter10_AI-Driven_Autoplay_Agents_for_Prelaunch_Game_Tuning.pdf

    work page 2021

  14. [14]

    Search-based procedural content generation: A taxonomy and survey.IEEE Transactions on Computational Intelligence and AI in Games, 3(3):172–186, 2011

    Julian Togelius, Georgios N Yannakakis, Kenneth O Stanley, and Cameron Browne. Search-based procedural content generation: A taxonomy and survey.IEEE Transactions on Computational Intelligence and AI in Games, 3(3):172–186, 2011

    work page 2011

  15. [15]

    Nelson.Procedural Content Generation in Games

    Noor Shaker, Julian Togelius, and Mark J. Nelson.Procedural Content Generation in Games. Springer Cham, Cham, Switzerland, 2016.https://doi.org/10.1007/978-3-319-42716-4

    work page doi:10.1007/978-3-319-42716-4 2016

  16. [16]

    WebRTC without a signaling server

    Chris Ball. WebRTC without a signaling server. https://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/, 2013. Blog post

    work page 2013

  17. [17]

    serverless-webrtc-qrcode.https://github.com/fta2012/serverless-webrtc-qrcode,

    fta2012. serverless-webrtc-qrcode.https://github.com/fta2012/serverless-webrtc-qrcode,

    work page

  18. [18]

    Software demo, accessed 8 May 2026. 9

    work page 2026