Build With Arcanex
The Timeless 4D Engine is being built to let developers create online worlds without rebuilding the hardest multiplayer infrastructure from scratch.
The developer platform is not public yet. Arcanex is proving the engine first, then maturing the tooling, SDK, documentation, and operating model for external teams.
If the missing multiplayer layer has kept your game too expensive, too risky, or too limited to build, we want to hear from you.
What Developers Could Build
Developers should be able to build worlds without rebuilding the world engine.
The Timeless 4D Engine is not limited to one genre.
Persistent worlds are the hardest proof case, but the same foundation can support smaller multiplayer experiences and other online games.
Persistent worlds need the full stack. Smaller games can use the parts they need.
Potential formats include persistent worlds, online RPGs, survival games, strategy games, social worlds, dynamic arenas, co-op worlds, session-based multiplayer games, online single-player experiences that benefit from server-backed state or generation, and experimental multiplayer formats that are difficult to build with traditional tools.
The Missing Multiplayer Layer
Most developers do not want to rebuild multiplayer infrastructure.
They want to build worlds, mechanics, systems, content, communities, and player experiences.
Arcanex aims to provide the shared state and world infrastructure underneath the client so teams can spend less time rebuilding the same multiplayer foundation for every project.
The client presents the world. Arcanex manages the shared reality.
The future developer platform is intended to expose the engine’s state, content, simulation, replay, permission, perception, and capacity layer.
Blueprint-Driven Content
Blueprint-driven generation lets developers turn design intent into reusable world logic.
Developers could eventually use designer-controlled blueprints to create regions, maps, arenas, scenarios, routes, resource spaces, encounter layouts, and dynamic multiplayer spaces faster.
This is not random generation and not voxel sprawl.
Designers define the logic. The engine turns it into scalable content.
Replay, History, Permission, And Perception
The engine’s replay, history, permission, and perception systems are intended to become platform capabilities, not just technical concepts.
Permission helps decide who can act, own, build, trade, enter, modify, or interact.
Perception helps decide what state each player, client, region, or service needs to receive.
Replayable history can support debugging, moderation, analytics, live viewing, spectator-style features, marketing capture, and player-facing replays.
A world that remembers can power features, tools, and operations.
Capacity-Based Infrastructure
Developers will eventually be able to plan around supported concurrency as the infrastructure unit.
Developers choose how players pay. Arcanex charges for supported capacity.
For developer-operated worlds, Arcanex currently models infrastructure-only pricing around a target of $1 per supported concurrent player per month.
These are planning targets, not finalized public prices. They may change as infrastructure costs, service levels, partner requirements, and market conditions evolve.
The important point is the model: developers can choose the player-facing business model while planning around the capacity they want to support.
Platform Not Public Yet
The developer platform is not public yet.
Arcanex is proving the engine and tooling before opening a developer-facing SDK or platform.
The platform comes after proof, not before it.
Developers can express interest now, but public SDK access is not available today.
The most useful early conversations are specific. Bring the world type, infrastructure blocker, content problem, team shape, or platform question you want to explore.
Who Should Reach Out
This page is for small studios interested in persistent worlds, technical founders building online games, developers exploring dynamic multiplayer maps, teams with strong client-side game ideas but weak backend capacity, creators who want persistent ownership or world history, studios interested in future SDK access, and developers interested in early technical conversations.
If the missing layer is what has kept your multiplayer idea too expensive, we should talk.
The most useful conversations are specific. Bring the world type, infrastructure blocker, content problem, team shape, or platform question you want to explore.
Where to Go Next
Use these pages when you want more technical depth or want to understand what still needs to be built.