while(motivation <= 0)

3. Extracting Original Bitmaps from the NE Executable

The game's artwork lives inside SCW.EXE and SCWTIT.DLL as NE resources. The complication: Windows NE DIB resources are stored without the 14-byte BITMAPFILEHEADER that modern tools expect. We wrote a parser in assets.py that walks the NE resource table directly:

1. Read the NE header offset from the MZ stub at byte 0x3c.
2. Follow the resource table pointer inside the NE header.
3. Find entries of type 0x8002 (RT_BITMAP).
4. Apply the alignment shift from the resource table header to get the true file offset and length.
5. Prepend a synthesised BITMAPFILEHEADER (calculating the pixel-data offset as 14 + hdr_size + palette_entries × 4).
6. Load the result via pygame.image.load(io.BytesIO(header + dib_data)).

Star sprites are stored as white-on-black 15×15 bitmaps, which made tinting trivial: pygame.BLEND_RGB_MULT multiplies each pixel by the player's faction colour, turning white into any desired hue. The title screen art (288×360) is pulled from SCWTIT.DLL and shown in the About dialog when the DLL is present; the dialog degrades gracefully to text-only otherwise.

# assets.py — tinting a white sprite to player colour
surf = base_sprite.copy()
tint = pygame.Surface(surf.get_size())
tint.fill(player_colour)
surf.blit(tint, (0, 0), special_flags=pygame.BLEND_RGB_MULT)
return surf

4. Game Engine

The engine lives under second_conflict/engine/ and is deliberately stateless — every function takes the GameState dataclass and mutates it in place, matching the original's single shared-memory model.

Combat

The original game resolves combat as multiple rounds of attrition between the attacking warships (any fleet arriving at an enemy star) and the defending warships (always the star's current owner's garrison). Each round a random fraction of each side is destroyed — the exact formula derived from the decompiled _attrition function.

Combat produces a CombatRecord dataclass — attacker/defender factions, initial and final ship counts, a list of per-round (atk_hit, def_hit) tuples, and the winning faction. turn_runner.py returns these records alongside the event log so the UI can animate them.

Ship types

The original game has seven ship types. One caused confusion during RE: planet type 'S' in the scenario file was initially labelled "Scout" in our model. Cross-referencing the production dialog switch-case (offset +0x55 in the star record) with the scout-launch code revealed that offset stores StealthShip counts — so planet type S produces StealthShips, not scouts. Probe ships fill the scout role.

5. The UI — Translating Windows Dialogs to pygame

The original game is a classic Windows 3.x dialog-heavy application. Every interaction — viewing your planets, dispatching a fleet, reading combat results — happens in a modal dialog box. We translated each WNDPROC into a Python class inheriting from BaseDialog, which handles the common pattern of: draw a bordered panel, render text rows, handle mouse hover/click on buttons, close with a return value.

Combat animation

CombatAnimation is the most complex dialog. It replays a full CombatRecord visually: ship dots (using extracted sprites, tinted to each faction's colour) are scattered across a split battle area, and each combat round plays out as a phase sequence:

def _build_phases(self):
    phases = [('scatter', 600)]          # ships fly to positions
    for r in range(len(self.record.rounds)):
        phases += [
            (f'r{r}_red',    500),       # casualties highlighted red
            (f'r{r}_yellow', 350),       # dying ships turn yellow
            (f'r{r}_clear',  300),       # dead ships removed
        ]
    phases.append(('result', 0))         # outcome — wait for click
    return phases

Dots are drawn as alive (tinted sprite), dying (yellow rect), or simply absent. The state machine advances automatically on a timer, pausing at 'result' until the player clicks.

6. AI Players

Two AI layers exist. The Empire AI controls the neutral Empire faction — a standing enemy that pressures all players throughout the game. The Player AI handles CPU-controlled player factions in single-player games, making fleet dispatch and production decisions each turn based on heuristics derived from the original's behaviour.

7. Project Structure

The model and engine layers have no pygame dependency at all, which kept testing straightforward and would allow a headless server mode.

8. Lessons Learned

• Trust the binary, not assumptions. Several fields were initially wrong because we assumed typical game layouts. The decompilation always won arguments.
• NE resources are not PE resources. The 16-bit Windows NE format predates the PE format and has a completely different resource table structure. DIB bitmaps stored inside it lack the file header that modern tools expect — synthesising it from the DIB's own info header is the only way to load them.
• White sprites are a tinting gift. If the original artist drew ship and star sprites in white-on-black, BLEND_RGB_MULT gives you faction colouring for free. No palette hacks required.
• Stateless engine functions pay off. Keeping all game logic as pure functions over a serialisable state dataclass made save/load trivial and prevented entire classes of bugs where UI and model drifted out of sync.
• Name things from the source. Using the original dialog IDs (ADMVIEWDLG, REINFVIEWDLG, etc.) as class-level docstring references meant that whenever something looked wrong, there was an unambiguous pointer back to the relevant decompiled function.

What's Next

The remaining work is mostly filling in edges: fog-of-war is not yet implemented (currently all stars are visible to all players), the diplomacy system is stubbed out, and a few of the original's more obscure mechanics — missile fleet speed bonuses, troopship boarding combat — are approximated rather than exact. The save-file round-trip is complete, which means existing original scenario files load and play correctly.

Source Code