SyncroMesh
Build and evaluate large-scale 2D simulations with interconnected boards and detachable rendering.
SyncroMesh is a runtime for large-scale 2D simulations, including RTS games and other connected worlds. You write behaviour in JavaScript ES modules. Independent simulation boards own physics and entities, exchange state over the network, and can be attached to a renderer when a view is needed. Linux and Windows runtime archives are available.
Upgrading an existing application? Read the 0.5.0 → 0.6.0 migration guide before replacing the runtime. Mouse/touch input APIs changed in 0.6.0; see the changelog.
Start here #
- Downloads & releases: select a runtime for your operating system and architecture.
- First simulation: run a complete example without graphics or external assets.
- Boards and execution: understand ownership, lifecycle, messaging, and renderer attachment.
- Connecting simulations: plan authority, replication, and client presentation.
The programming model #
| Context | Responsibility |
|---|---|
| Orchestrator | Starts the application, creates and stops boards, manages windows and input, and routes commands. |
| Authoritative board | Owns entities, physics, navigation, and authoritative gameplay logic. |
| Client board | Receives replicated entities and builds the local presentation. Client-only mode does not run server-only entity code. |
Each running board has its own simulation, networking state, and scripting context. A board can run without a window. Attaching or detaching its view does not start or stop the simulation. Use messages between contexts rather than sharing JavaScript objects or treating an entity ID as a process-wide handle.
Evaluating the engine #
The board architecture is useful when regions of a world need independent simulation and defined authority. Focused replication and entity ownership handoff provide building blocks for multiplayer. Your application still defines player commands, authentication policy, region connections, and when authority should move.
Measure your own workload before choosing a deployment layout: physics density, scripting work, replication frequency, and visible effects all affect capacity. Use the profiler to identify expensive phases. Board architecture alone does not specify a supported player count or guarantee automatic load balancing.
Runtime capabilities #
- Box2D physics, native locomotion, and navigation for simulated entities.
- Vulkan rendering for sprites, tile maps, text, particles, and Koya UI integration.
- Audio, asset mounting, and application packaging through runtime modules.
- Headless operation for simulation servers and automated tests.
Module names #
SyncroMesh includes modules named Syncromesh/* and Helix/*. These are literal JavaScript import paths. The Helix prefix is an internal naming convention retained by the runtime, not a separate product or platform to install. Koya is the UI product; its UI capabilities are integrated into SyncroMesh.
import * as Board from 'Syncromesh/Board';
import * as Event from 'Helix/Event';Most runtime operations return promises. Await them unless the reference explicitly describes a synchronous function. Keep bootstrap short: register handlers and schedule ongoing work, then return. See Boards and execution for exceptions and lifecycle rules.
Launching an application #
syncromesh -m ./assets -i index.js
syncromesh -m ./assets -i index.js --headless-m mounts application assets; repeat it for additional sources, with later mounts taking precedence. -i selects the bootstrap module under /rom. An archive appended to the executable is mounted automatically. See Assets and packaging for distribution and native module loading.