Source-linked diagnosis
The case separates symptom, impact, reproduction, system ownership and root cause.
This library connects Studio 2.0 positioning to real production work. Every published case comes from an internal CONTRABAND incident documented with root cause, fix, validation and public-safe evidence.
Disclosure: these are Martinez AI Studios internal cases, not customer testimonials or client results. They are not presented as proof of every Studio 2.0 offer.
The case separates symptom, impact, reproduction, system ownership and root cause.
The solution is described by the necessary change, not by code volume or tool count.
Validation leaves a concrete way to check that the same failure does not silently return.
Each incident ends in a rule that can transfer to future systems, agents and pipelines.
This collection brings together published internal cases supported by evidence. Each links to the complete analysis in Academy.
Last Run taught a real Keros ↔ Belu warp. The return jump did not share the scripted near-dock pose.
System id is not pose. Two entry paths that share a label still need a shared placement contract. Mixing local and world spaces looks like a “warp bug” to the player and like a one-line vector add to an AI assistant. Own one arrival policy per intent (vista vs near-dock) and test metres, not only flags.
Flight wants the mouse captured. Choice buttons 1/2 need the mouse free. Those states collided in Last Run.
Capture modes are exclusive with clickable overlays. Own the transition: exit lock, tell the player how, and do not bind ESC to two verbs. Device-specific UI (hide the hint on gamepad) is part of correctness, not polish.
Shipyard, lock hologram, 3D map, hangar, and inventory each opened a GPU context. The flight canvas paid the bill.
GPU contexts are a shared budget, not a private field on a component. Lifecycle is pause vs destroy. An AI that “cleans up” with dispose() on every React-like unmount can take down the game view. Count live renderers; test reopen loops, not a single open.
Hull unlocks, kill pay, and ten difficulty profiles had to stay independent contracts.
Economy fields need names for each consumer (shop vs unlock vs repair). Shared += on credits is how duplicate rewards happen. Difficulty, loot, and progression are three knobs; coupling them in a prompt will “balance” the wrong one.
A Steam App ID on the store is not a substitute for a local gate that can fail.
Shipping is a checklist that can fail, not a screenshot of the store. Encode language, input, and persistence as cells. Never put Steamworks admin identity in educational write-ups. AI that “just uploads the build” skips the only tests that catch Last Run and cloud ordering.
Academy preserves the complete technical case. Studio 2.0 uses that evidence layer so a buyer can distinguish a commercial promise from a documented production practice.
EXPLORE ACADEMY CASES →For game production or creative systems, we can start with one bounded problem, define evidence and acceptance criteria, and build from there.
A useful case explains what failed, why the explanation fits the observations and how the fix was checked. Before borrowing a lesson, identify its scope: a rendering fix proves something about that rendering path, not every capability offered by the studio. The linked Academy cases preserve the longer technical analyses.
Imagine a fictional quest reward appearing twice after loading a saved game. A screenshot confirms the symptom, but not the cause. The investigation needs a repeatable sequence, the saved state before and after, and the code path responsible for granting the reward. Changing the visible text would not establish that the state was fixed.
A useful report separates the observation from the hypothesis, records the minimal correction and repeats the sequence with neighboring cases. That same reading method applies to the internal incidents listed here. The example above is explanatory; the linked case pages are the source for what actually happened in CONTRABAND.
| Evidence | Question to ask | What it does not prove |
|---|---|---|
| Reproduction | Can another person trigger the same failure from the stated starting point? | A screenshot alone does not identify the responsible subsystem. |
| Correction | Does the change address the cause and preserve the surrounding behavior? | More code or a different tool does not establish correctness. |
| Regression check | Does the check fail before the fix and pass after it? | One passing case does not cover all devices, states or future changes. |