Pilotwings 2D Art Workspace (fly/flyman)

Edit on Github | Updated: 30th March 2026

The Nintendo Gigaleak preserves a separate Super Mario Kart art workspace under other/NEWS/テープリストア/NEWS_04/home/sugiyama/fly and home/sugiyama/flyman/, from Nintendo artist Tadashi Sugiyama.

These directories are almost entirely art-side production material from the Super Nintendo Pilotwings game.

At a Glance

The fly and flyman folders form a complete artist workspace pair with 817 files total and no subdirectories. That flat, two-folder structure makes the archive feel less like a cleaned release and more like a direct snapshot of one developer’s working branches copied at tape-restore time.

Despite the simple folder structure, the file families split into several clear production domains:

• Art and graphics - fly contains 102 CGX tile banks, 69 COL palettes, 78 SCR composition tests
• Disciplines - Pilotwings vocabulary: SKYDIVE, HANG, PARA, ROCKET, PLANE, HELI with lesson/layout variants
• Mode 7 system - 47 M7-prefixed files including terrain banks, 9 weather/condition palettes, HUD overlays
• Mission layout - flyman with 429 files organizing lessons into MAP1-8 core spine plus RACE, JUMP, BONUS, CHIKA branches
• Combat layer - BOSS progression, underground bosses (CHIKABOSS), UFO enemies, CORE targets, combat backdrops
• Iteration evidence - 276 BAK files showing sustained production iteration, not one-shot asset dump

The file type breakdown is stark:

This distribution shows a clean pipeline: fly produces reusable art components while flyman assembles mission layouts and progression structure. The presence of 276 backup files indicates this workspace captures an active iteration snapshot, not a frozen final export.

Glossary of Key Terms

If you are new to SNES art and layout production terminology, this glossary will help clarify the technical terms used throughout this page.

• fly - Art-side folder with tiles, palettes, and object graphics.
• flyman - Layout-side folder with mission and screen assembly files.
• Mode 7 - SNES background mode used for scaling and rotation effects.
• CGX - Tile graphics bank data.
• SCR - Screen layout composition data.
• COL - Palette data.
• OBJ - Object-side definitions.
• BAK - Local backup snapshot copy.
• Tadashi Sugiyama - Nintendo developer whose NEWS_04 home contains fly, flyman, CAR, SIM, MARIO, and FX2.

Executive summary

fly and flyman open on the same day (1989-10-13) and split cleanly into art production vs layout composition.

The branch contains strong Pilotwings discipline vocabulary and a large Mode 7 package.

It also contains explicit combat naming that extends beyond neutral training labels.

The best current reading is a branch where Pilotwings lesson content and combat-capable mission content coexisted, including material consistent with the helicopter combat lane seen in the shipped game.

Folder snapshot

The folders share origin timing but diverge in closure behavior.

flyman closes in 1991, while fly carries late 1994 timestamps likely influenced by tape restore handling.

Discipline matrix

The clearest evidence for Pilotwings-era identity is discipline naming.

This is a dense cluster of flight-discipline naming.

That concentration is hard to explain as generic flight tooling.

Combat matrix

The branch also preserves combat-oriented naming families.

Shipped Pilotwings does include combat in the final helicopter test, with projectile fire against ground targets.

The interesting question is not whether combat existed, but how broad and differently framed that combat content was during production.

Mode 7 architecture deep dive

The M7-* set looks like a modular terrain and condition system.

This pattern suggests a production workflow where a small set of geometry/tile bases could be re-skinned by palette and mission context.

That is efficient for memory-limited SNES workflows and consistent with late-1980s/early-1990s console production habits.

flyman layout grammar

flyman appears to encode lesson and mission progression as grouped screen families.

A practical reading is that fly supplied reusable art modules while flyman assembled stage-facing lesson screens and mission sequences.

Mode 7 composition and course variants

The M7-BG-C0/C00/C01 naming pattern deserves closer attention now that we have actual file presence data.

In fly these three tiles exist:

• M7-BG-C0.CGX, M7-BG-C0.CGX.BAK (dated Oct 13, 1989)
• M7-BG-C00.CGX, M7-BG-C00.CGX.BAK (dated Oct 13, 1989)
• M7-BG-C01.CGX, M7-BG-C01.CGX.BAK (dated Oct 13, 1989)

All three arrived on the same day with identical backup pairs. This is not random — it is three coordinated course base tiles.

Matching palette sets exist for each:

• M7-C0.COL (base palette for C0)
• M7-C00-A.COL, M7-C00-B.COL, M7-C00-C.COL, M7-C00-DAME.COL (four palette variants for C00)
• M7-C01.COL (palette for C01)

This suggests:

• C0 is a single-palette course variant
• C00 is a course with 4 distinct color schemes (possibly different times of day or difficulty modes)
• C01 is another single-palette variant

In practical gameplay terms: players could fly three different aerial courses (C0, C00, C01) using shared terrain code but distinct tile banks and multiple weather/time-of-day palettes.

The C prefix interpretation remains open (course, condition, context, or credential), but the systematic presence of three parallel course trees makes “course” more credible than ever.

Deeper Mode 7 condition-palette catalog

The M7-L-* palette family is larger and more structured than initially noted.

Complete catalog of weather/condition states in fly:

This gives 9 total condition palettes (8 named states plus 1 base), each with a backup pair.

Interpretation:

• Each condition likely represents a distinct atmospheric or environmental mood that could be swapped at runtime.
• The backup prevalence shows active iteration on color tuning for each state.
• A mission could select its own condition palette (e.g., RAIN for a storm-flight lesson, SUNSET for an evening race) independently of the tile bank.
• The range from generic (FINE, NIGHT) to specific (DESERT, ISLAND) suggests both universal moods and location-specific palettes.

This modular palette system is a hallmark of efficient SNES production: buy one set of terrain tiles, swap eight color schemes to generate 8 distinct-feeling environments.

File-level walkthrough

To go deeper than folder labels, it helps to look at how specific filename families appear to cooperate.

The pattern below is the clearest recurring structure in the workspace.

That three-part structure is exactly what you would expect from an efficient SNES pipeline.

It keeps expensive tile production reusable while moving variation into smaller palette and layout layers.

Representative family dossiers

These family snapshots are useful because they combine naming semantics with likely production intent.

The repeated base-plus-variant behavior across multiple discipline families is one of the strongest signs of deliberate content planning.

Combat footprint detail

The combat layer is not just a single odd token.

It spans objects, enemies, and environment sets.

For a reader, this is the key tension in the archive.

The same workspace that looks strongly Pilotwings-like also preserves a broader combat vocabulary than the final game surfaces outside its helicopter combat segment.

Notable filename evidence sets

If you want the shortest high-signal view of this archive, these are the most useful exemplar sets.

Each set groups names that, together, show one production behavior clearly.

The sets are easiest to read as one combined statement:

• discipline naming strongly anchors the branch to Pilotwings-era content
• Mode 7 naming shows a reusable rendering and condition system
• flyman grouping shows staged mission composition rather than flat asset storage
• combat naming confirms broader design experimentation inside the same workspace

Stem continuity test

One practical way to read these files is a stem-continuity check.

If a stem appears across graphics, palette, and screen families, it likely represents an implemented content thread rather than a discarded name stub.

This is a useful checkpoint because it connects archive naming to probable in-engine behavior.

flyman mission progression architecture

The flyman folder shows dense composition work organized by progression families.

Core progression spine:

Mission branch families (non-linear paths):

The cascade:

MAP1 (4 lessons) → MAP2 (4) → MAP3 (1) → [split]
                                       ├→ MAP4-6 (main path, 57 screens)
                                       ├→ RACE1 (side race, 4 screens)
                                       ├→ CHIKA (underground branch, 27 screens)
                                       ├→ JUMP (jump training, 37 screens)
                                       └→ [environment variants]
                                            └→ MAP7 (64-screen mega progression)
                                            └→ MAP8 (finale, 8 screens)

Data interpretation:

• MAP4 through MAP6 each hit double-digit screen counts, suggesting complex multistage missions rather than single-screen challenges.
• MAP7’s 64-screen count is extraordinary. This could represent:
  • one massive free-roam course
  • 64 individual challenge variations of the same mission
  • a progression grid (8×8 or similar) of tiered difficulty/feature unlocks
• The presence of B-variants (MAP5-2B, MAP5-4B, CHIKA-B*, etc.) alongside main lanes suggests parallel design iteration — not just backups, but deliberate alternate routes tested in parallel.
• Heavy backup presence in MAP4 and MAP6 is evidence of sustained iteration, not final polish.

This architecture is consistent with a flight-training game where:

• early lessons (MAP1-3) teach basics progressively
• mid-lessons (MAP4-6) build difficulty
• optional branches (RACE, CHIKA, JUMP) offer style variants
• MAP7 represents peak challenge or comprehensive integration
• MAP8 wraps up with finale content

The filename evidence supports a compact mission assembly sequence:

flowchart TD
  A["<b>Discipline and environment tiles</b><br>CGX banks in fly"] --> B["<b>Condition palettes</b><br>M7-L weather/time variants"]
  B --> C["<b>Stage composition</b><br>MAP and mission SCR families in flyman"]
  C --> D["<b>HUD and meter overlays</b><br>M7-METER SCR layer"]
  D --> E["<b>Final lesson scene</b><br>discipline mission runtime"]

This model is consistent with the extension split and token grammar already visible in the folders.

Low-level decoding guide (without raw files)

You can understand most of the technical structure in this workspace directly from naming and extension patterns.

The key practical model is that this archive preserves a layered SNES workflow:

• art banks define reusable visual pieces
• palettes define runtime mood and condition changes
• screen maps assemble final mission scenes
• object families attach actor and gameplay-side behavior cues

That is enough to reconstruct a credible low-level production picture without opening the original binary files.

Pilotwings-specific format findings beyond the generic SNES profile

The generic SNES format page explains what SCR, CGX, COL, and OBJ are across projects.

Pilotwings adds branch-specific detail about how those formats were used in day-to-day production.

SCR format behavior is extremely consistent across both folders

All SCR files in both folders are exactly 8,960 bytes:

• fly: 78 of 78 files at 8,960
• flyman: 286 of 286 files at 8,960

That is strong evidence of one stable editor-side layout container shared across both art testing (fly) and mission composition (flyman).

Pilotwings SCR files show multiple opening-pattern classes

The first 16-bit words split into a few recurring behaviors.

This gives a stronger practical model than just “SCR holds layout”: the format supports both blank templates and pre-seeded composition blocks under the same fixed container size.

Variant pairs show two different editing styles

Comparing close variant pairs reveals two distinct workflows.

So Pilotwings does not use only one edit pattern.

Some families are cloned early into separate branches, while others keep a shared front block and diverge later.

File-type distribution also exposes a small layout-side helper bank

Unlike a purely SCR folder, flyman keeps a tiny graphics and palette support set:

• BG.CGX
• MYSHIP.CGX
• OBJ.CGX
• 1.COL

This is useful format evidence: mission composition in Pilotwings was not strictly tilemap-only.

The layout branch retained a minimal local graphics and palette payload for composition and preview work.

Deep dive on under-documented format families

The two highest-value remaining format families are MET* and LICENSE*.

Both families preserve cross-file evidence (SCR, CGX, COL) and clear variant behavior.

MET family structure and variant behavior

The MET* set is broader than the earlier meter discussion and appears to encode several HUD or mission-meter modes.

The opening words show four distinct meter-template classes:

• M7-METER and METER families open with repeated 0x0080
• METERC00 family opens with repeated 0x0030
• METERC01 family opens with repeated 0x002D before switching later
• MET/MET-PARA family opens with repeated 0x0029

This means the meter system was not one template with small edits.

It was a small cluster of related layout templates tuned for different course or discipline contexts.

Pairwise diff evidence reinforces that reading:

The practical implication is a two-layer meter pipeline:

• shared meter base templates for broad HUD structure
• per-course and per-discipline branches for mission-specific tuning

LICENSE family and localization behavior

The LICENSE* family is one of the clearest UI/localization format clusters in the branch.

All four SCR files begin with repeated 0x0CB2, which suggests a shared screen template skeleton.

But they are not duplicates:

Revision depth is also visible in the graphics backups:

• LICENSE.CGX vs LICENSE.CGX.BAK first diff at byte 4,746
• LICENSE-ENG.CGX vs LICENSE-ENG.CGX.BAK first diff at byte 10,259

That combination suggests the family was maintained as a deliberate localization pipeline:

• common template base
• language-specific layout divergence at stable offsets
• dedicated localized graphics banks with their own revision history

This is stronger than a one-off translated screen and looks like a proper reusable front-end localization workflow.

Timestamp forensics

Date behavior in NEWS_04 needs caution.

Why this matters:

• If 1994-03-18 is mostly restore-touch behavior, true active design likely ended much earlier.
• If some files were genuinely accessed or revised at restore time, late timestamps may represent archival edits, not gameplay-system iteration.

Competing hypotheses and confidence

Current best fit remains the first hypothesis, with the second still plausible.

Synthesis: what the data tells us

Now that we have examined actual file evidence in depth, several conclusions are stronger than before:

Curriculum structure: The presence of a 64-file TEST grid (created in a single batch on day 1) plus the MAP1-8 + branches system in flyman points to deliberate curriculum design. This was not improvisation; it was planned lesson progression.

Environmental branching: The symmetric structure of CHIKA across both folders (palette states in fly, layout progression in flyman, dedicated object-level boss graphics) proves that underground missions were a full content branch, not stray test content.

Modular rendering: Nine weather/condition palettes (FINE, RAIN, SNOW, SUNSET, NIGHT, DESERT, GRASS, ISLAND) each with backup pairs shows runtime state-switching was a design principle, not an afterthought. Every mission could change mood.

Course variety: The C0/C00/C01 course triplet, each with multiple palette variants, suggests at least 3-4 distinct aerial courses with selectable weather. This aligns with Pilotwings’ known course roster but possibly implies more variety in design than the final game shipped.

Combat integration: The presence of:

• BOSS-1/2/3 boss progression
• CHIKABOSS underground-specific boss
• UFO enemy craft
• CORE target objects
• OBJ-BOMB weapons
• BG-FORTRESS, BG-ENEMYSHIP, BG-BASESHIP combat backdrops

…across object, palette, and background layers means combat was not a single experiment or discarded branch — it was integrated into the same mission assembly pipeline as the flight lessons. It reached object level and environment level, suggesting structured gameplay intent.

Production velocity: Heavy backup presence in MAP4, MAP6, CHIKA-B*, JUMP* variants suggests these were actively iterated, not frozen designs. The workspace captures an in-flight development snapshot, not just a final asset dump.

These are the main unresolved points that would most improve confidence if answered:

• Build a filename-frequency matrix for discipline and combat tokens, then compare by timestamp band.
• Cluster M7-* files by palette suffix and mission prefix to estimate state transitions.
• Cross-check BGBG-* and mission family prefixes against other Sugiyama branches for reuse patterns.
• Compare byte-level headers for key CGX, SCR, and COL variants to identify export/tool lineage.
• Compare ROKETMAN, HELI, and PLANE sprite dimensions against known Pilotwings ROM assets.

Production pipeline reconstruction

The current file evidence supports a three-lane pipeline:

Why this matters:

• It explains why fly is extension-diverse while flyman is layout-heavy.
• It explains why mission naming appears in both places but with different granularity.
• It gives a clean mechanism for discipline-focused lessons and alternate visual conditions.

Mission topology

A likely mission graph can be inferred from naming density:

• Core lesson spine: MAP1 to MAP8.
• Environment branches: POOL*, DESERT*, CHIKA-*.
• Skill branches: JUMP*, RACE*.
• Optional branch: BONUS*.

This implies a curriculum-like progression with detachable side tracks.

That structure fits a training-game design better than a pure action campaign.

The combat tokens likely represent either:

• removed branch content, or
• an early mission flavor that was softened before release.

Evidence-weighted interpretation

Net reading:

• The Pilotwings relationship is strongly supported.
• The exact reason for combat material remains unresolved.
• Timestamp tails should not be over-interpreted without per-file clustering.

File-type breakdown by extension

The physical composition of each folder reveals different production roles.

Reading:

• fly is mixed: tile banks (CGX), palettes (COL), and screen-level compositions (SCR) for testing, plus some object-side content (OBJ).
• flyman is composition-heavy: most files are .SCR layout maps, with a tiny helper bank set (BG.CGX, MYSHIP.CGX, OBJ.CGX) and one palette file (1.COL).
• The ratio imbalance is exactly what you would expect if fly produced reusable components while flyman assembled scenes.

Percentage breakdown inside fly:

• CGX (graphics banks): 26.3%
• COL (palettes): 17.8%
• SCR (layout/testing): 20.1%
• BAK (backups): ~35% (mixed across families)

This composition shows a folder balancing asset creation with intermediate composition testing, not a raw graphics dump.

Asset token census

This section provides a conservative token census from currently confirmed values and naming families.

Known quantitative anchors:

• fly total files: 388
• flyman total files: 429
• combined workspace files: 817
• M7-* files in fly: 47

Derived ratios:

• M7 share inside fly: $47 / 388 \approx 12.11\%$
• M7 share against combined workspace: $47 / 817 \approx 5.75\%$

Interpretation:

• A double-digit M7 share inside fly is substantial and supports a system-level rendering role, not a minor side experiment.
• The lower combined-share value is expected because flyman is layout-heavy and naturally dilutes graphics-bank ratios.

Token families currently evidenced:

Important caveat:

• These are family-level counts, not raw per-token file frequencies.
• A full filename inventory is still needed for exact per-token counts.

What could change this interpretation

The current hypothesis should be rejected or downgraded if any of the following become true:

• BOSS/UFO/FORTRESS assets are proven to be copied in bulk from another project branch.
• M7-* naming maps to a different title’s known internal naming scheme.
• flyman mission groups do not correlate with fly asset families when compared by prefix and date clusters.

If these checks fail, the branch may be a mixed workspace rather than a coherent Pilotwings-predecessor line.

High-value extraction targets

For future binary-level analysis, prioritize:

• one representative file from each discipline family (SKYDIVE, HANG, PARA, ROCKET, HELI, PLANE)
• one representative file from each combat family (BOSS, UFO, CORE, OBJ-BOMB)
• one representative file from each M7 condition class (FINE, RAIN, SNOW, NIGHT, SUNSET)
• paired files with same stem across CGX/COL/SCR when available

This minimizes extraction effort while maximizing comparative signal.

Filename grammar and what it implies

A useful next-pass signal is naming grammar, not just naming presence.

Observed grammar patterns:

Interpretation:

• The naming is structured like a production taxonomy, not ad-hoc artist scratch naming.
• State suffixes strongly suggest runtime switching behavior.
• Shared environment namespaces across fly and flyman imply coordinated asset-layout handoff.

Branch-phase model

This workspace can be modeled as phases, each with different evidence strength.

Why this helps:

• It separates design-history interpretation from raw file presence.
• It gives a framework for testing whether combat content was early, late, or mixed.

Restore-artifact heuristics

Because NEWS_04 appears tape-restored, timestamp interpretation needs guardrails.

Use these heuristics before making historical claims:

• Prefer cluster behavior over isolated outlier timestamps.
• Treat same-day mass touch events as possible restore-time metadata effects.
• Prioritize relative ordering inside a tightly related stem family.
• Downgrade confidence if a claim depends on one late outlier file.

Practical rule:

• Historical claims should be tagged High confidence only when both naming semantics and timestamp clusters align.

How to verify these conclusions

To strengthen attribution confidence, use this protocol:

• Build a full filename inventory for fly and flyman.
• Compute exact token frequencies for discipline, combat, environment, and system prefixes.
• Generate per-token first/last-seen timestamp windows.
• Compare stem overlaps between CGX, COL, and SCR families.
• Score each hypothesis using a fixed rubric:
  • semantic match score
  • temporal coherence score
  • cross-folder consistency score

Suggested reporting format:

• One compact table per hypothesis with a normalized score out of 100.
• One short note identifying the strongest disconfirming evidence.

This keeps the analysis reproducible and easier to audit.

Signal summary by subsystem

After the narrative sections, this table provides one compact index of the strongest technical signals.

Cross-folder handoff model

The strongest operational explanation is a staged handoff from art production to mission composition.

Runtime scene assembly model

flowchart LR
  A["<b>fly assets</b><br>CGX/COL and object families"] --> B["<b>themed banks</b><br>discipline + environment variants"]
  B --> C["<b>M7 condition layer</b><br>day/night/weather palettes"]
  C --> D["<b>flyman composition</b><br>MAP and mission groups"]
  D --> E["<b>HUD overlays</b><br>M7-METER and mission UI"]
  E --> F["<b>lesson runtime scene</b><br>flight discipline or branch mission"]

This model is consistent with the folder split and naming grammar.

It also explains why flyman is composition-heavy while fly carries most bank and palette complexity.

Evidence ledger for historical claims

This table summarizes where the current interpretation is strongest and where uncertainty still remains.

Unpacked filename families

These are the most interesting unresolved groups in fly and flyman, unpacked in one place.

M7-BG-C0, M7-BG-C00, M7-BG-C01

The C0/C00/C01 variation is unlikely to be random naming.

The most practical interpretations are:

• sibling course sets within one mission family
• iterative revisions where one stem was duplicated and modified
• region or difficulty-tuned map variants sharing a common base

Given how compact SNES memory budgets were, a small cluster of closely named Mode 7 banks usually means planned variation rather than abandoned scraps.

M7-METER and M7-METER-B

This pair likely represents HUD composition variants that were selected by mission context.

Possible split logic:

• discipline-specific meter layouts
• normal vs alternate mission mode
• layout A/B pass where one survived for a subset of scenes

Because both are .SCR-style composition-facing names, they are more likely to encode placement/structure differences than raw graphics differences.

M7-CHIKA and M7-FORTRESS

This is one of the strongest links between the flight-discipline and combat layers.

CHIKA (underground) and FORTRESS tokens appear as environment contexts, not only object labels.

In fly:

• M7-CHIKA.COL - palette for underground Mode 7 context
• M7-CHIKA-B.COL, M7-CHIKA-B1.COL through M7-CHIKA-B4.COL - four variants of the B branch
• M7-CHIKA-C1.COL through M7-CHIKA-C1.COL.BAK - C variant series with backups

In flyman:

• CHIKA.SCR - base underground screen
• CHIKA-0 through CHIKA-4.SCR - main progression lane (5 screens)
• CHIKA-B0 through CHIKA-B4.SCR - B variant lane (5 screens) with heavy backup presence
• CHIKA-C0 through CHIKA-C4.SCR - C variant lane (5 screens) with selective backups
• CHIKA1.SCR, CHIKA2.SCR - alternate numbering variants

Also in fly:

• CHIKABOSS-01.OBJ, CHIKABOSS-02.OBJ - Underground boss character forms

This is far more systematic than a single loose token. It shows:

• Multiple underground palette states (base, B-variants 1-4, C-variants)
• Matching layout progression (same A/B/C branching structure in flyman)
• Dedicated boss representation at object level

The symmetry across palettes, screens, and object-side assets strongly implies an implemented underground mission branch with distinct visual mood and combat encounters. This was not test clutter; it was coordinated multi-system content.

-L discipline variants (HANG-L, PARA-L)

The -L suffix appears repeatedly in discipline families and likely marks a systematic subtype.

Evidence from actual files:

The best current candidates are:

• lesson-state or layout-state variant
• left/right or local variant naming from tool export conventions
• late-stage variant branch retained beside the base stem

The clearer answer comes from flyman where L1 and L2 groups appear at top level (9 files each), suggesting -L variants map to distinct lesson sequences or layout modes, not just graphical tweaks.

Because -L appears in more than one discipline family, it reads as a naming rule, not a one-off exception.

BGBG-* composites in flyman

BGBG-* is likely a composition convention for layered background-over-background screens.

This is important because it points to authored staging behavior in flyman:

• background layers were assembled as reusable composites
• mission screens could swap layers without re-authoring all source art
• environment and UI overlays could be integrated on the composition side

This helps explain why flyman is large despite being extension-light.

Early TEST grid layout evidence

One of the clearest production artifacts is the TEST-* family in fly.

The pattern is highly structured:

• File count: 64 files total
• Naming scheme: TEST-{1-16}{A,B,C,D}.SCR
• Timestamp: All dated 1989-10-13 (same day as project origin)
• File size: 8.8 KB uniform (identical sizes suggest templated composition)

The grid structure is telling:

This is not random test clutter. It is a systematic 16×4 layout test grid — likely representing:

• 16 lessons or courses
• 4 screen variants per lesson (A/B/C/D might be tutorial steps, difficulty modes, or input method variants)

The uniform timestamp and file size suggest:

• These were created in a single session or template batch
• They use consistent baseline geometry/tiling
• They represent a planned curriculum structure with 64 baseline compositions

This directly supports the flyman evidence of numbered progression (MAP1 to MAP8) — the TEST grid may have been early scaffolding before the final MAP/RACE/JUMP/BONUS branching structure was locked in.

The best current candidates are:

• lesson-state or layout-state variant
• left/right or local variant naming from tool export conventions
• late-stage variant branch retained beside the base stem

Because -L appears in more than one discipline family, it reads as a naming rule, not a one-off exception.

ROKETMAN actor-side signal

ROKETMAN is especially useful because it sounds like a rider/actor naming form rather than a pure course token.

That makes it a bridge between:

• mission-side names (ROCKET discipline context)
• character/object-side representation (the pilot/actor entity)

If future stem continuity checks find ROKETMAN tied to object and screen layers, this would strongly support a complete implemented gameplay thread.

BOSS-1/2/3 and CHIKABOSS progression

The numbering pattern implies progression structure.

Combined with CHIKABOSS, the data suggests:

• a general boss sequence (BOSS-1/2/3)
• a branch-specific underground boss track

This is more structured than a stray enemy test bank.

It looks like a mission design lane that likely overlaps with the shipped helicopter combat test, while also preserving broader variants that may have been trimmed or reorganized.

.BAK clusters and chronology

.BAK files are not glamorous, but they are often the best historical evidence in this kind of archive.

When grouped by stem, they can show:

• which families were iterated most heavily
• where variant branching occurred
• which timestamps are likely true edits vs restore-touch artifacts

For this workspace, .BAK clustering is the best path to tighten timeline confidence around the late 1994 tail.

Additional on-disk families worth documenting

After checking the files directly on disk, several families stand out as meaningful production signals that were not previously unpacked in detail.

One additional cross-folder detail is especially useful for pipeline reconstruction.

The same non-backup filename appears in both folders for only four names:

• CHIKA.SCR
• M7-METER.SCR
• M7-METER-B.SCR
• MYSHIP.CGX

That overlap is small but high-value. It suggests intentional handoff checkpoints where the same artifact name was kept stable between art-side production (fly) and composition-side assembly (flyman).

If you want to take this further

To move from broad inference to stronger attribution, extract one compact batch with strict pairing rules:

• one stem family that exists in both mission and environment contexts
• one discipline family with both base and -L variants
• one M7 family with at least two condition suffixes
• one combat family with both object and background forms

Then validate three checks:

• stem continuity across CGX, COL, and SCR
• timestamp clustering within each family
• cross-reference appearance inside flyman mission groups

If all three checks hold for multiple families, the current branch-phase model should be upgraded.