Compare runtime environments

1267. Lesson identity

Module

3.11 — Desktop wrappers

Lesson

Compare runtime environments

Academic type

Workflow

Schema type

mixed

Order

Lesson 2 in the module

Estimated time

45–60 minutes, including practice

This lesson turns the wrapper boundary from the previous lesson into a verification workflow. You will compare browser, development desktop, and packaged desktop assumptions instead of treating packaging as a final copy of development.

1268. Learning objective

After this lesson, you can produce an environment matrix that records bounded runtime differences, expected and observed results for each environment, ownership decisions, verification status, and a justified first probe.

1269. Why this matters

A game can behave correctly in a browser or development desktop runtime while failing after packaging because paths, lifecycle events, storage behavior, permissions, or diagnostic visibility may differ. These differences are not automatically defects in game simulation, and they should not be addressed by scattering platform guesses through game rules.

A matrix makes each assumption visible. It also distinguishes a hypothesis from a verified result, gives AI a constrained analysis task, and records evidence for each environment independently. A shared statement such as “works in all environments” is not sufficient unless the result in each environment has actually been observed and recorded.

1270. Prior knowledge

You should have completed 3.11 L1 — The wrapper is an environment boundary. You should be able to distinguish game responsibilities from wrapper and packaging responsibilities. You also need a basic understanding of the project’s browser launch, development desktop launch, and packaging or packaged-preview procedures, where those procedures already exist.

1271. Core concept

An environment difference is useful only when it is expressed as a testable assumption.

Do not write:

“Packaged builds may be different.”

Write a bounded hypothesis instead:

“The packaged runtime may resolve boot assets from a different base than the browser and development desktop runtimes. Test the boot flow in each environment and record the result separately.”

The matrix connects five things:

1. Environment — where the game is running.
2. Assumption — what the game, wrapper, or packaging configuration expects.
3. Owner — which layer should contain the behavior or correction if the assumption fails.
4. Probe — the action or inspection that tests the assumption.
5. Evidence — the observable result that confirms, rejects, or leaves the assumption unresolved.

This five-part model remains the basis of the workflow. The matrix expands it by requiring an expected result and an observed result for each of the three environments. It also records whether the statement is a hypothesis or a verified fact, the current status, and a comparison conclusion.

1272. Mental model

Use the Environment → Assumption → Owner → Probe → Evidence model.

“Check packaging” is not a probe because it does not specify what to do or what to observe. “Works normally” is not evidence because another developer cannot determine what was inspected.

Compare all three required execution environments:

This is a comparison frame, not a claim that every project or wrapper behaves identically. Verify the actual behavior of the project and wrapper in all three environments.

1273. Matrix format

Use one row per bounded assumption. Do not combine all three environments into one evidence cell.

If an assumption does not apply to one environment, record not applicable and explain why. Do not leave the expected or observed field blank. A row is complete only when its conclusion states:

• what actually differed, or that no difference was observed;
• which layer owns the relevant rule or correction;
• whether the item is verified, failed, inconclusive, or still untested.

1274. Concrete example

Suppose the first screen needs a background image, a font, and a local configuration file.

A weak note says:

“It works in development, but packaging might break paths.”

That note omits the browser, does not separate expectations from observations, and does not identify an owner.

A usable row records all three environments:

This example tests the result in all three environments. It does not claim that the wrapper should decide how the game looks. Instead, it distinguishes the game’s presentation rule from wrapper or packaging conditions that may affect asset availability.

A lifecycle row uses the same structure. For example, compare browser closure or visibility change, development-window closure and relaunch, and packaged-window closure and relaunch. If browser tab closure cannot support the same observation, mark the field not applicable or inconclusive and explain the limitation rather than pretending that the lifecycle events are identical.

1275. AI-native workflow

Use AI as an assumption-auditing partner, not as a substitute for runtime evidence.

1. Provide the three environments, the wrapper boundary from the previous lesson, and only the launch or packaging procedures you actually know.
2. Ask for no more than five bounded differences that could affect the game.
3. Require an owner, a repeatable probe, and expected evidence for each environment.
4. Require unknown project-specific statements to be labeled as hypotheses.
5. Reject vague rows, invented wrapper APIs, undocumented project history, and suggestions that move game rules into the wrapper without justification.
6. Run the probes yourself and record the observed result for each environment independently.
7. Write a comparison conclusion that identifies the actual difference, its owner, and its status.

A useful prompt is:

“Compare browser, development desktop, and packaged desktop runtime assumptions for this desktop game. Propose up to five bounded matrix rows. For each row, provide an assumption, owner, verification probe, and expected result for each environment. Mark project-specific claims as hypotheses. Do not invent wrapper APIs, packaging behavior, project history, or observed results.”

AI can help identify questions and structure the matrix. Only direct observation can establish a project-specific result.

1276. Common mistakes

The first common mistake is treating the packaged runtime as a deployment detail that can be checked only after game work is complete. This produces broad warnings and late fixes in the wrong layer.

The second is using one sequence such as “browser → development desktop → packaged desktop” in a single environment cell and then writing one shared evidence statement. That structure can conceal an independent failure. Record expected and observed results separately for each environment.

The third is confusing a hypothesis with evidence. “The packaged runtime uses another asset base” remains a hypothesis until a probe produces evidence. Record not tested rather than presenting an assumption as fact.

The fourth is assigning every difference to the wrapper. Game rules remain in the game or application layer. The wrapper owns boundary behavior, while packaging configuration owns artifact assembly and inclusion decisions.

1277. Guided practice

Draft a four-row environment matrix using the required format. Cover:

1. Boot assets or application entry.
2. A local file or configuration dependency.
3. Diagnostics and error visibility.
4. Window, tab, close, relaunch, visibility, or another lifecycle boundary.

For each row:

1. Write one bounded assumption.
2. Assign an owner: game/application, wrapper boundary, or packaging configuration. Use more than one owner only when their responsibilities are clearly separated.
3. Define a repeatable probe.
4. Record an expected result for browser, development desktop, and packaged desktop.
5. Record an observed result for each environment, or explicitly mark it not tested, not applicable, or inconclusive with a reason.
6. Mark the statement as a hypothesis or verified fact.
7. Assign the result status: not tested, verified, failed, or inconclusive.
8. Write a comparison conclusion naming the actual difference, its owner, and whether action remains open.

Then choose the highest-risk row and justify why its probe should run first. Priority may come from blocking boot, hiding failures, corrupting a session decision, or preventing reliable diagnosis. Do not prioritize a row merely because it sounds platform-specific.

Submit the completed matrix through the practical assessment attached to this lesson. The quiz remains a supporting knowledge check; it does not replace the matrix.

1278. Validation and evidence

The matrix is valid when it includes:

• exactly four or more bounded rows covering the four required areas;
• browser, development desktop, and packaged desktop fields in every row;
• separate expected and observed results for each environment;
• an explicit explanation for every not-applicable or inconclusive entry;
• an assumption, owner, repeatable probe, knowledge status, and result status in every row;
• a comparison conclusion naming the observed difference or stating that no difference was observed, plus the owner and open or resolved status;
• a clear distinction between hypotheses and verified facts;
• a justified first-probe priority.

A list of risks, wrapper features, or implementation tasks is not an environment matrix. The artifact must support a repeatable verification session and reveal whether one environment failed independently.

1279. Key takeaways

• Browser, development desktop, and packaged desktop are three distinct execution environments that require explicit comparison.
• The five-part model is Environment → Assumption → Owner → Probe → Evidence.
• Expected and observed results must be recorded separately for each environment.
• Every conclusion should identify the actual difference, its owner, and its current status.
• Platform differences should remain bounded at the wrapper or packaging boundary when they do not belong to game rules.
• AI can organize hypotheses, but direct runtime probes establish project-specific evidence.

1280. Next lesson

Continue to 3.12 — Steam integration. The next lesson will use this matrix and its ownership conclusions to distinguish game, wrapper, store-client, and packaging responsibilities by boundary. This lesson does not assume or teach any store-client implementation details.

1281. Knowledge check