rpg-munchers

This project is a playable Number Munchers game for the IBM i green screen. It is a reimplementation of the classic MECC edutainment game. The game uses RPG and DDS. It runs over the 5250 protocol through the zelnet client. The project is a "crowd-pleaser" showcase for the ibmi-rpg pipeline. The pipeline compiles the game on a real IBM i host (pub400) over the zelnet Host Server client. It also tests the greenscreen game headless with zelnet --play.

How it plays

• Move across a 6x5 grid with F5/F6/F7/F8: up/down/left/right.
• Press Enter to eat the current number. Correct numbers score 10 points. Eat all targets to clear the level and score a 50-point bonus.
• Complete 15 levels: multiples, factors, primes, equalities, and inequalities. Practice can start at any lesson; arcade starts at level 1.
• A wrong number or contact with an enemy costs one life. You start with three.
• Select practice or arcade, then easy, normal, or hard. In practice, each accepted action advances one tick. Arcade advances one tick per second. Enemies move every three, two, or one ticks.
• F9 pauses. F10 opens help. F3 leaves. The terminal cursor cannot move the player or select a remote number to eat.

What it is

• Greenscreen: QDDSSRC/MUNCHD.dspf holds the GRID, start, help, and end-game records. It shows the header, score, lives, and level, plus 30 named cells C01 through C30. It uses CSRLOC(SETR SETC) to park the cursor on the Muncher. Cursor feedback does not control game state. Option indicators condition each cell's reverse-image color. Indicator 30 plus the cell number gives Troggle red. Indicator 60 plus the cell number gives Muncher green. An ENDGAME record follows.
• Program: QRPGLESRC/MUNCHERS.rpgle handles the screen. The NMSTATE and NMENGINE copy members contain explicit game state and deterministic rules. PARM('DEMO ') retains the fixed first board for the existing reels. Native RPG and CL engine checks run before the screen program compiles.
• Older components: QRPGSRC/NMRULE.rpg is OPM RPG for number rules. QRPGLESRC/NMSCORE.rpgle is fixed-format RPG IV for score limits. The engine calls both programs during play. Their native parameter interfaces are tested across 14256 rule cases before the game compiles.

See the expansion record for the interfaces, released foundation, and remaining campaign and classroom work.

Build / test / play

• Run bash scripts/deploy.sh to compile the DSPF -> RPG chain on pub400. Compiler severity above SEVMAX (default 10) or a failed engine check stops the build.
• Run bash test-1-munch-a-multiple.sh, bash test-2-troggle-chase.sh, and bash test-3-clear-the-level.sh to drive the seeded demo grid headless with zelnet --play. Each test records its own greenscreen reel.
• Run bash test-4-arcade-clock.sh to check real clock updates, pause, help, and resume. This suite requires Zelnet v0.10.11 and the compiled Linux qualification helper supplied by the pipeline recipe. Set MUNCHERS_QUALIFICATION to use a separately built helper.
• Run tests 5 through 8 for factors, primes, comparisons, completion, and game over with restart. Each test records a separate reel.
• Run bash extract.sh to pull the source members off the box and back into Git. This is the import round-trip.

Play it interactively: run zelnet term pub400.com, then CALL SOMEARA1/MUNCHERS. Press F3 to quit.

Controlled source loss

make loss-plan, make loss-apply, make loss-status, and make loss-restore prepare the SOMEARA1 application for a source-recovery exercise. The standard profile removes the NMRULE and NMPERSIST source members and removes supported observability from NMPERSIST. It retains the programs and database. Keep the plan and private restore package outside this repository. The exact boundary is in recovery/loss-profile.json.

See the operator procedure. Pub400 currently denies RSTOBJ. The restore gate therefore blocks loss; no active loss marker is set.

Native Binjovi delivery

Open a feature PR to trunk. Request its release through Binjovi after the Build passes. Do not merge the PR directly in Forgejo.

• Build compiles the exact PR revision in SOMEARA1 with the pinned ibmi-builder image and its installed zelnet client.
• Release tests the combined revision in SOMEARA2. It publishes a save file, the object manifest, recordings, MP4 reels, and JPEG previews with digests.
• Deploy copies the verified release objects to SOMEARAB and rejects a changed staging object set.

Release also saves compiled-objects.txt. Deploy checks the program, bound module, and display-source metadata before and after the copy. A missing or different record fails the Deploy. This is compiler/source metadata proof, not a binary hash.

All phases use native Binjovi agents in the cluster. Shared IBM i work is serialized. Media rendering runs separately. The recipe is in sean/binjovi-plans, under recipes/ibmi-rpg and recipes/rpg-munchers. Recipe changes do not require a Binjovi server deployment. trunk holds released revisions only. Historical release artifacts remain available. See docs/pub400.md for the IBM i connection.

Native pipeline timing

Native agents coordinate the Build, Release, and pub400-rpg Deploy. Media rendering is separate from the serialized IBM i work. Host profiles do not include remote IBM i syscalls.

Open the project dashboard and expand an execution attempt for the task timeline and available CPU, off-CPU, and syscall profiles. Cached BuildKit steps still appear as cached work; a missing sample does not prove that a task used no CPU.

Select an exact successful Build with binjovictl release rpg-munchers --build BUILD_ID --wait. Then use binjovictl status rpg-munchers to check its release and any configured deployment. Telemetry explains time spent; immutable artifact and revision evidence establish completion.

Controlled source loss

Every Binjovi deployment of this application ends with a routine source loss, so the box always carries a decades-old simulation: the routine targets of recovery/loss-profile.json (NMRULE, NMPERSIST, MUNCHERS, MUNCHD) lose their source members in SOMEARA1, and NMPERSIST and MUNCHERS lose their observability in SOMEARAB and SOMEARA1. Staging (SOMEARA2) is never touched. The originals stay in Git; the next Build re-adds the members and recompiles. The release stage stages the profile as loss-profile.json in the release repository, and the deploy applies that staged copy with the pipeline's own engine (ibmi-rpg-source-loss), which has the same semantics as scripts/source-loss.sh routine here. The loss report is in the deploy log (ibmi-source-loss-report.v3). The twin repository named by the profile's output_repository (rpg-munchers-tng) recovers deployable text from that state.