Roadmap

What the fork builds next on game_rework, what it leaves alone, and why. The order of what's next is where we're leaning, not a commitment, and it changes as we learn. How each piece gets built and checked is on the guide pages.

The idea

In short

Build server behaviour on the parts of game_rework nobody upstream is rebuilding, cheapest to verify first, and check every feature against the game's own tables and in game before it reaches stable. Leave everything upstream is rebuilding to the branch that's rebuilding it.

Why

On game_rework, the wire is nearly mapped: 927 of the 943 named opcodes have a packet model. Behaviour is the thin part. About half of what a client can send gets handled, and a dozen whole features have complete packet models and no server code at all. So the open work is behaviour on a known wire format, not new layouts.

Gameplay is thin on game_rework on purpose. Upstream is rebuilding it on another branch, and that shapes everything below.

Decisions

Locked

Stay out of what upstream is rebuilding.

Area	Why
Spells and effects, damage, crowd control, AI, movement, prerequisites, public events, death and resurrection, creature templates	Upstream is rebuilding these on expedition-evil-from-the-ether, which replaces those folders nearly wholesale. Work on them here would be thrown away at the merge
Loot	Being rebuilt on loot-rework
Upstream's infrastructure rework: static managers to dependency injection, the packet path, sockets, the event queue, database repositories, the command system	On the maintainer's own list. Outside fixes there tend to be redone their way

Build on open ground. Open ground is a feature with a known wire format, no server behaviour yet, no dependency on combat, and nobody upstream working on it. Every idea gets routed the same way:

flowchart TD
    IDEA(["A gap or an idea"]) --> L{"Layout known?"}
    L -- no --> MAP["Map the layout first"]
    L -- yes --> B{"Upstream branch on it?"}
    B -- yes --> LEAVE["Leave it to that branch"]
    B -- no --> C{"Needs combat?"}
    C -- yes --> WAIT["Wait for combat"]
    C -- no --> R{"On the rework list?"}
    R -- yes --> RAISE["Raise it upstream first"]
    R -- no --> OPEN["Open ground: ours"]

Loading

What's open today:

• Player-to-player trading
• Crafting and tradeskills
• The marketplace: auctions and commodities
• The CREDD exchange
• Housing neighbours and plugs
• Instance settings and resets
• Reward tracks and rotations
• Add-on channels
• Leaderboards
• Support tickets
• The fortune card game

Duels, PvP flags, challenges, hazards and most path missions have the same shape, but they need combat to mean anything, so they wait until the expedition branch merges back.

Check a feature's packet models before building on them. The archive's models were complete and carefully commented, and still wrong by a field width.

Verify against the tables, then in game. Every feature goes through Verifying a feature before it reaches stable.

Open

The order of what's next. Within open ground, two things decide it:

• How cheap it is to verify. A single-player, table-driven feature can be checked against a prediction from the tables. Anything that needs two characters online needs two clients, and anything with no source in play yet needs a GM command to feed it.
• What it unlocks. Tradeskills feed the two largest kinds of quest objective that nothing on the server drives yet.

Where we're leaning:

1. Player-to-player trading. Complete packet models, no server code, no table work and no combat. With the base entitlements in place, the client already opens the trade window and sends the first request. Two clients run side by side on one machine, so it can be checked locally. Built and waiting on its in-game test: Trading design.
2. Reward tracks. About the archive's size, and checkable the same way, though nothing in play earns track points yet.
3. Tradeskills and crafting. The big one, and the one with the largest effect on content.

Rejected

Idea	Why not
Building combat, AI or spells on game_rework	The expedition branch replaces those folders; the work would be discarded at the merge
Fixing what's on upstream's rework list	Outside fixes there tend to be closed and redone the maintainer's way
Trusting a packet model because it's complete	The archive's complete models were wrong by a field width

Where it stands

Done

Feature	Upstream
Galactic Archive
Web console commands as a character
Account entitlements

In progress

Feature	State
Trading design	Built on its own branches, not yet run in game or on stable

Verification status

Claim	Basis
Opcode and handler counts	Counted from the built assemblies of game_rework @ f9bb26ef
The stay-out list	Read from the expedition and loot branches' diffs against game_rework, 2026-10-13
Open ground	Packet models with no references in the server code, checked against upstream's open pull requests
Trading reaches the client's first request	Seen in game, 2026-10-14
Trading itself	Built and compiled, not yet run
Reward tracks' size	Scoped from the code and tables, not built

Open questions

• When the expedition branch merges back into game_rework, the stay-out list dissolves, and this page needs rewriting.

Upstream surface

Every feature here lands on game_rework, so the next upstream merge is the risk: a feature that touches a file upstream reworks will conflict. The open-ground features were picked partly because nothing upstream is touching their files today. The expedition branch merging back is the large one, and it lands on everything on the stay-out list at once.

One shipped change already sits on the rework list: #589 extends the command system. It's small and stands on its own, but it may come back redone when upstream reworks commands.