3. Laying Out Luna

With the revised story established, the next step is not necessarily to define the finished quest and journal structure. First, we can put the physical pieces in place, connect a minimal playable flow, and learn what works in the game.

Ghost in the Machine uses three existing Luna bunkers and three exterior recovery sites. One exterior site contains the vanilla crashed probe. The other two use otherwise isolated rocket-turret locations, giving those encounters a purpose within the revised assignment.

The initial layout should establish:

• three exterior recovery sites;
• one recoverable module at each site;
• three bunker installation points;
• module installation in any order;
• visible gameplay effects from installed modules; and
• a final location containing Hannibal's housing.

This can be developed incrementally. A temporary message, existing plot state, or small Kismet branch may be enough to prove that one interaction leads to the next. The formal quest stages and journal text can be added after the physical progression is understandable and testable.

Build the flow before formalizing it

Plot infrastructure records the quest's state, but it does not determine whether the quest is enjoyable or comprehensible. Before defining the complete state model, test questions such as:

• Can the player find the recovery sites without excessive direction?
• Is it clear that something recovered outside can be used inside a bunker?
• Can modules be installed in any order without breaking progression?
• Does each installed capability have a noticeable effect?
• Can the player reach the final Hannibal encounter without tedious backtracking?

Answering these questions may change the required plot variables. Defining every variable and journal stage first would make ordinary design revisions more expensive.

Use general world facts where possible

The vanilla Luna probe already records its recovery with:

Debris_1_Found
Plot bool 6635

The two additional recovery sites should follow the same convention:

Debris_2_Found
Debris_3_Found

These variables mean only that Shepard recovered the corresponding debris site. They should not be named after Hannibal, a particular module, or Ghost in the Machine's interpretation of the recovered objects.

This separation makes the state more reusable. Ghost in the Machine can interpret the recovered objects as Hannibal's modules, while another DLC can use the same stable facts for a different compatible purpose.

Labels help developers understand the variables, but runtime compatibility depends on their numeric plot IDs. Once IDs are allocated for Debris_2_Found and Debris_3_Found, the project should document and preserve them as part of its public compatibility surface.

Quest-specific facts still need quest-specific variables. Module installation, restored capabilities, Hannibal's activation, and Shepard's final decision belong to Ghost in the Machine. General facts about exploring Luna should remain general.

Test incomplete implementations deliberately

A development save does not need to reproduce every preceding gameplay action. Trilogy Save Editor can toggle known plot variables so individual states can be tested repeatedly.

For example, changing bool 6635 allows the same Luna save to represent either an unlooted or looted original probe. This is useful for testing Kismet that reacts to Debris_1_Found, but it does not replace testing the probe interaction itself. The actual interaction must also be verified to execute its transition and set the bool normally.

Once the physical flow works, the next tutorials can formalize it through plot variables, transitions, conditionals, quest records, and journal stages.