Finish the Runtime Contract

Before calling a Palladium World playable, prove that the GM can resolve and persist the state that changes during play. Craft does not supply a hidden universal combat, injury, inventory, or encounter engine.

Configure the Rules Profile

Fill the World Rules Profile's procedures for initiative, perception, damage routing, recovery, conditions, resource spending/recovery, equipment/ammunition, encounter flow, and end-of-combat reset. Add referenced Rule modules for detailed procedures and optional rules. Do not leave a blank procedure and expect the GM to borrow one from a different Palladium title.

Define conditions that actually matter

Create Condition records for persistent statuses the World uses: injuries, diseases, poisons, fatigue, stun, paralysis, unconsciousness, mental/emotional effects, magic/psionic effects, and setting-specific conditions. Give each a stable key, duration model, saving/resistance guidance, recovery/removal procedure, and structured modifiers where arithmetic can safely be automated.

Use Character.activeConditions for individual applications and Encounter.sceneConditions for scene-wide applications. Keep the simple Character.conditions string list only for lightweight labels that do not need structured rules.

Make equipment operational

For weapons and tools, populate structured attack/use modes when useful: action cost, damage, scale, range, rate of fire, payload cost, area effect, conditions, and special notes. Define payload capacity/reload guidance when the World tracks ammunition or charges. Armor and protective gear should say how damage is routed and repaired.

Character.inventory is instance state. It should hold current payload, charges, S.D.C./M.D.C., status, loaded ammunition, and repair notes. Never write those changing values into Equipment definitions.

Make vehicles operational

Vehicle Model defines shared specifications. Use stable keys for damage locations, weapon mounts, and structured systems. Character.vehicleInstances (or a World-specific vehicle-instance type if the game needs more depth) stores current main durability, location state, payload state, system status, and ownership/access.

Use Encounter when order matters

Create an Encounter for combats or other scenes whose round/turn state must persist. Store participants and initiative there; keep each Character's personal remaining actions/action debt in Character.combatState. Resolve the Encounter only after aftermath state has been written back to Characters and instances.

Context setup in Craft

In the finished World, pin Palladium Core GM Instructions. Keep deep catalogs searchable. Make live Encounter/party trackers pinned or partial when they must stay fresh. Configure Palladium Runtime State Instructions and Palladium Encounter Instructions as searchable or narrow triggered instructions as appropriate. Visibility and trigger metadata are app-managed and do not travel in ordinary CDF workspace files.

Final vertical-slice test

Before bulk importing content, create one real World character and run: character creation → skill check → perception/save → initiative → several combat actions → ammunition/resource spend → damage to character/armor/vehicle → an ongoing condition → treatment/recovery → encounter close → XP award → level-up eligibility. Reopen every file and verify the state survived. If any step depends on memory instead of a writable field and a rule, the World is not finished.