ArtilleryEco: Determinism For Free

Determinism, abilities, threaded input processing, and state management primitives married to a core set of basic tools used to bind to a weapon, character, entity, effect, or actor in a compositional and elegant way. Artillery is at 0.3 and is not yet in pre-alpha. It provides, as of right now:

• Full support for the Jolt physics engine for game simulation through Barrage
• Direct "anywhere access" to attributes, relationships, and tags by safe key look-ups.
• Better debugging and tracking for attributes and tags!
• A designer-friendly and fully editor-native user experience
• fast. very very very fast. fast enough that you might not need to do any serious optimization for many games.
• Separation of game simulation ticks from frames
• Separation of game simulation ticks from the game thread
• Threaded input processing with support for strong timesync
• Locomotion state machine binding
• Initial integration with bristlecone for insanely fast networking
• fixed data-rate multiplayer primitives, with multiplayer support coming in .6
• LIMITED integration with GAS, primarily focused on Cues. the goal is that time spent learning gas should not feel wasted and porting should be easy.
• An abstract controls model that uses a three layer system of key bindings -> intents -> actions
• And finally, a collection of industry tricks in locomo and skeletonkey useful to most games.

Atypically, Artillery is designed to operate in a mixed model between input stream replication, network prediction, and interpolation. Bristlecone streams remote player input to all clients, allowing the remote player proxies to execute abilities and requiring the local client to fully simulate them. The obvious immediate implications are as follows...

• REQUIREMENT: CUES MUST BE COSMETIC ONLY. This is already the norm.
• REQUIREMENT: WE MUST HAVE A WAY TO ENSURE AT-MOST-ONCE EXECUTION OF GAMEPLAY CUES.
• REQUIREMENT: ATTRIBUTE STATE REPLICATION MUST BE RECONCILED, NOT JUST BLINDLY APPLIED.

By collating all input streams and using an underlying game simulation, we allow deterministic gameplay without requiring deterministic presentation. This is incredibly powerful, as it separates the concerns in a new way.

How does this fit together with the other plugins?

This monorepo includes all plugins required by Artillery, and all plugins that consume it. To understand the structure, it is important to know that Artillery depends on a number of other plugins maintained by Breach Dogs. These form a loosely coupled ecosystem that provides a powerful range of threading and simulation capabilities suitable for use with any UE5 game where control responsivity or multiplayer are a priority.

Dependency Map

Update Schedule

The next major public release is 2026-Q3 will include full support for multiplayer that doesn't ask you to draw the rest of the owl.

Solution Design

Unlike regular unreal, we have powerful time synchronization primitives built on shadow copies and a concept of subframe accuracy. This allows us to quickly compose updates by simply zipping them together using the timestamp. With the concept of zip-and-reconcile available to us, we have a way to do exact state recovery without needing true determinism OR a full gamestate transmission.

Final Architecture

By tracking the GAMEPLAY ABILITIES as EVENTS and then ZIPPING them together like this - effectively eventual consistency via event sourcing, a la kafka - we can determine if an ability or cue would be a double trigger easily within a very high margin of precision by combining Bristlecone cycle, Bristlecone time, and the event properties. From there, it's a small step to tracking inputs instead of individual events. If the events generated by a given input are consistent, then you can reduce your complexity enormously this way.

I intend to expand the conserved attribute to support timestamping its changes, allowing us to do a highly granular reconciliation with a very low actual bandwidth cost, assuming this reconciliation is delta compressed and occurs irregularly. Finally, conserved attributes will be extended even further to tackle the problem of floating point determinism in a general way, based on some tricks around frame boundary based quantization.

Networking

This plugin will:

• Disable replication and RPCs for all played or used abilities FROM CLIENT TO SERVER. Clients trigger Artillery abilities based on input and on replication from the server.
  • We are fully server authoritative AND clients do not push cues to the server.
  • HOWEVER clients do FULLY simulate all player characters down to their ability systems.
  • This is because the cloned input from bristlecone is used to literally control those actors, out of band from the replication system.
  • This means that MOST of the time, when attributes and transforms are replicated from the server, they represent no changes or imperceptible changes.
  • Attributes and tags are replicated FROM the server in the PUSH model using relevance, if needed, and only for resync or JIP.
  • Cues MUST only have cosmetic effects.
  • Cues that have attribute changes associated with them WILL cause bugs.
  • We will need to enforce an At-Most-Once rule for Cues triggering visual effects, as remote player input representing an action may arrive LONG before the cues it would generate.
• Accept push updates from the server. As a result, replication FROM the server must still work.
• Integrate with the reconciliation logic needed to do an eventually consistent server auth game. See 2.
• Prevent known issues around latency and cooldown misbehavior in the normal up-replication by offlining it entirely if needed.
• Ensure integration with Iris, which will be our replication provider for Lions.

Design

This plugin has five main design goals:

• All data is managed through Data-Driven Gameplay Elements, Registries or Configs. You can use data assets if you like, but personally, I try to avoid them for systems like this
• Abilities are kept small and atomic, intended for use by composition rather than as monolithic abilities.
• Map simply and elegantly to designs that could be found in ANY OR ALL OF: borderlands 2, Vampire Survivors, Destiny 2.
• Cleanly express weapon-centric design patterns AND character-centric design patterns. When picking, prefer weapons.
• Avoid tight coupling between characters, abilities, weapons, spawnables, and pickups. Failure to do this will be excruciating later.
• Where necessary, integrate with Thistle via a hard API boundary and use of Cues.

To meet these needs, we provide an impure ECS model with runtime type information available through SkeletonKeys. This, combined with a strict temporal separation between change generation and change application, allows a fairly natural paradigm.

So you want to use Artillery?

First, this is a pre-alpha prototype and should be considered highly experimental. Second, with that said, we expect only two major API changes. The first is that conserved attributes will likely lose the Remote value in favor of a timestamp stack for ticks that allows true rollback work to begin. The second is that Mass integration will continue apace, and this has some ramifications that should be largely invisible to users. We make no promises, however, and if it's a choice between an api change and a massive body of engineering work, at this stage, we will choose to make the API change. This philosophy will not persist, ultimately.

Second, I strongly recommend reviewing the ArtilleryBusyWorker thread. It offers a deep insight into the control flow of the system as a whole. Following that, familiarize yourself with the core concepts of simulation\presentation separation. Finally, the most important structures to understand are likely ArtilleryGuns, SkeletonKeys, Attributes, FBLets, and Ticklites. In particular, the IKeyedConcept interface is of tremendous value for maintaining consistency, and is a backbone that offers much insight into WHY we use a key-first system but do not commit to a pure ECS.

Reference Matter

Artillery will also serve to insulate our other tech from spaghetti usage of GAS, in case we do decide to use another tooling for ability and gun composing. This guide is a really useful place to start for understanding GAS. We're using it very differently, in a more composition oriented way that'll hopefully ease the dependency management and granularity issues.

• Data Driven Gameplay
• Data Registries
• Procedural Animation With Character - useful for missiles, turning turrets, etc.
• Momentum in Sonic - our goal is to make something like this easy.
• JUICE IT OR LOSE IT - really useful for thinking about iterating on feel.
• Tech Design In Animation