THE TECHNOLOGY BEHIND THE GAMES

.enginefeatures

ArcadePotion is our deliberately focused C11 engine for responsive arcade games, portable runtimes, and fast content iteration.

  • C11
  • SDL3
  • CMake
  • GPU + CPU
  • Data driven

BUILT FOR THE WORK

A studio engine, not a side project

ArcadePotion exists to help us finish games. It keeps platform code, rendering, audio, input, assets, and packaging behind stable boundaries while each game remains focused on its own rules and personality.

It is developed alongside playable projects that exercise the engine under real arcade workloads. Features are added when a game needs them, then made portable, measurable, and reusable.

CAPABILITIES

What it does

01

Portable game modules

Games use a stable C interface instead of owning the platform loop. The same game code can target macOS, iOS, Android, and Web builds without game-specific platform forks.

02

Replaceable rendering backends

The default SDL GPU path handles 3D transforms, depth testing, shaders, and post-process bloom. A compact CPU renderer remains available as a fallback and reference implementation.

03

Data-driven authoring

INI content defines assets, scenes, entities, behaviours, projectiles, weapons, bosses, cameras, HUD layouts, events, effects, input, audio, and difficulty. Much of a game can change without recompiling the engine.

04

Asset authority + virtual filesystem

Games refer to logical asset IDs rather than scattered filenames. The same loaders read desktop files, iOS bundles, compressed Android assets, and persistent save locations through asset:// and save:// paths.

05

Arcade-scale simulation

Shuffle & Seek uses deterministic shuffles, responsive touch input, animated 3D tokens, multiple play modes, local statistics, trophies, and accessibility-minded presentation.

06

Validation before launch

ap_tool validate loads every subsystem, resolves referenced assets, discovers scenes, and instantiates content to catch path and schema failures before a build is shipped.

07

Reproducible packaging

The packer follows declared dependencies, copies only referenced content and required libraries, records CRC-32 and byte size in a package manifest, and can produce relocatable ZIP distributions.

08

One build workflow

A unified build driver handles engine and game builds, tests, packaging, installation, and launch across supported targets. Platform checks are part of the workflow rather than an end-of-project surprise.

PORTABILITY

One core, four active paths

macOS
Native development, GPU and CPU rendering, automated game builds and tests.
iOS
Device and Simulator packaging with portable game modules and bundled assets.
Android
Native APK builds, Vulkan shaders, SDL lifecycle integration, and renderer fallback.
Web
Installable static Wasm/WebGL2 packages with browser testing and adaptive rendering.

PROOF, NOT PROMISES

Measured as we build

Tests, content validation, packaging checks, benchmarks, and physical-device runs are treated as engine features. The goal is predictable game behaviour and repeatable releases—not the longest possible feature list.

./tools/ap_build.sh \
  --platform ios \
  --game NeonShellGame3D \
  --run

./build/ap_tool validate \
  NeonShellGame3D/assets/game.ini

./build/ap_tool benchmark

DEVELOPED IN THE OPEN

Technology shaped by games

ArcadePotion is internal studio technology, built around the games Memset Games wants to make. Follow the implementation, documentation, and platform work on GitHub.

Explore ArcadePotion on GitHub ↗