It has been a while since the last post. Not that anyone is looking yet, but a lot of work has happened in the gap.
The most visible change is the name. Ariadne DM is now Sylvia GM. The reasons for that deserve a separate post, so I will leave them there for now.
Most of my time has gone into rebuilding Sylvia for its public Alpha and finalising a second ruleset that I want to ship with it. The ruleset is called Trigger Discipline. It is built for grounded tactical shooter combat in modern-day and near-future settings.
I started Trigger Discipline because I wanted to make it. That was reason enough.
Once I did, it confirmed that Sylvia needs a proper spatial combat tracker and raycaster now, not later. Trigger Discipline needs exact positions, lines of fire, physical cover, magazines with their own state, and networks whose topology matters.
A hot-swappable spatial system capable of that can handle the looser maps D&D needs without much trouble. A D&D-shaped tracker would be much harder to stretch into the game I want Trigger Discipline to run.
The map has to matter
Trigger Discipline now has its first proper grid map system and a raycaster.
When someone fires a shot, the rules do not jump directly from attack roll to damage. Sylvia traces the shot through the scene and returns the intersections in order. If a concrete barrier is between the muzzle and the target, the barrier is encountered first. The shot then has to stop, lose energy, or penetrate before it can continue toward anything behind it.
That sounds obvious, but rules engines often reduce cover to a status effect attached to a character. Trigger Discipline treats it as part of the scene. Its protection depends on where the shooter is, where the target is, the angle between them, the target's stance, and what the cover is made from. Moving two squares can change the answer.
The same spatial model handles movement paths, range, exposure, areas, prepared firing zones, and line of sight. Theatre of the mind is still possible, but the GM has to maintain an approximate version of that spatial truth. The rules cannot decide that a filing cabinet exists in one moment and forget it in the next because a roll would be more convenient.
The foundation is working, although the loop is not completely closed. Sylvia can query the grid, calculate paths and exposure, and cast ordered rays through a scene. I still need host-level map operations so movement, destructible cover, and the changing geometry of sequential shots can update the rendered scene cleanly. That work belongs in Sylvia rather than Trigger Discipline. Finding that boundary is part of the reason for building a second ruleset now.
Hacking has a map as well
Trigger Discipline also includes a node-based network map for hacking.
A network is represented as connected nodes and links. A node might be a camera, a workstation, a router, a door controller, a server, a turret, or a drone dock. Links describe the real routes between them. Compromising one machine does not grant magical access to every electronic object in the building.
To reach something remotely, there has to be a route. The operator needs a foothold, enough privilege, and a function that the target device genuinely exposes. A camera can show its feed if that function exists. A door controller can unlock a door if it controls that door. Neither one has a generic pool of cyber hit points that can be depleted until the whole network gives up.
Network devices can also be bound to objects on the physical grid. Cutting power to a device should matter to the network. Opening a door remotely should matter to movement and line of sight. Some of that cross-map mutation still needs host support, but the information is no longer trapped in the GM's notes.
I wanted the consequences of hacking to stay local and understandable. Getting into one camera is useful. Finding a route from that camera's segment to a security controller is a different problem. Being detected is another problem again. The GM can build an actual network instead of attaching one hacking difficulty to an entire building.
What happens to the old magazine?
And yes, all of this means gun simulation mechanics. The hard part has been deciding which details Sylvia should remember and which ones the player should have to operate directly.
Reloading is a good example.
At the table, a player can still say that they reload. They do not need to issue a separate command for every finger movement. Underneath that action, however, the weapon goes through real state changes.
The magazine and the chamber are separate. A magazine is a persistent object with its own remaining ammunition, including ammunition order when that matters. If a player removes a magazine with twelve rounds left, those twelve rounds do not dissolve into a shared ammunition counter.
The player also has to decide whether the old magazine is retained or dropped. Retaining it keeps the partial magazine in inventory and costs the time needed to put it somewhere. Dropping it is faster, but the magazine becomes an object on the ground at the character's current position. Recovering it later depends on getting back to it.
The replacement magazine comes from the character's carried equipment. Inserting it does not automatically rewrite the chamber. If a live round was already chambered, it remains there. If the chamber was empty, a self-loading weapon can feed a round as part of the appropriate operation. A pump, bolt, or lever action may need to be cycled manually.
The implemented detachable-magazine reload already tracks the important parts of this. Partial magazines remain partial. Retained magazines stay with the character. Dropped magazines stay in the scene. The chamber does not become an extension of whichever magazine is currently fitted.
The rules are written so an interrupted reload leaves the weapon in the state it had actually reached. The old magazine might be out, the new one might not be seated, or the chamber might still contain the last live round. The current detachable-magazine tool resolves a reload as one action, so interrupting it midway is still unfinished work. The underlying model does not need to be replaced when I add that support.
The rules also describe tube-fed weapons being loaded one shell at a time, although that path is not part of the executable slice yet. General weapon handling, such as some ready and stow operations, still needs more implementation as well.
The goal is not to make the player perform a reload through a control panel. A reload command is a wrapper around the physical operations. Sylvia remembers those operations because they can affect later decisions. Training can make the sequence faster or overlap compatible movements, but it does not make the old magazine disappear or quietly refill it.
That is roughly the balance I want for the rest of the firearm system. Track a detail when it can change the situation. Keep it behind a sensible action when it cannot.
Why build this now?
Sylvia is open source and will keep changing. I do not expect the engine to anticipate every edge case a future ruleset author will find. They can open an issue or submit a pull request when the host needs a new capability. That is how I want the engine to grow.
The Trigger Discipline package can now be installed and selected in Sylvia, and the core grid, ray, firearm, and network concepts are present. It has exposed unfinished host work around scene mutation and map interaction. Some rules remain GM judgement rather than compiled tools. It needs much more play at the table before I know whether the pacing feels right.
I still want it in the public Alpha. I am not calling it finished.
The next useful test is a real session. Sylvia can keep track of the half-empty magazine and tell me what the bullet struck first. I do not yet know whether the pace survives contact with players.