ge-arena development

ge-arena is a separate MajorBBS module built from the same source tree as ge-next. It is a compile-time variant, not a second copy of GE's movement, combat, scanning, and database code. This page describes how the variant is built and where its implementation diverges. For match rules and the five modes, see ge-arena.

One source tree, two module builds

Most C files belong to both games: GEMAIN.C provides module entry points and recurring callbacks; GECMDS.C handles command dispatch; GEFUNCS.C, GESCAN.C, GEPLANET.C, GECYBS.C, and GELIB.C provide shared game mechanics. Arena-only lobby, match, spawn, scoring, and cleanup routines live chiefly in GEARENA.C. Standard ge-next never links that file. Conversely, the current arena build omits GEDROIDS.C, which belongs to standard ge-next's Droid behavior.

The 16-bit MPOGA.MAK compiles the shared C files with -DGE_ARENA into a separate gaobj object directory. MPOGA.LNK links those objects with GEARENA.C into MPOGA.DLL. The standard MPOGEMP.MAK/MPOGEMP.LNK build omits the define, uses its own object directory, links GEDROIDS.C, and produces MPOGEMP.DLL. Separate object directories are important: one variant must not accidentally link an object compiled for the other.

For the 16-bit toolchain setup and the exact command to build MPOGA.DLL, see Building ge-arena.

The 32-bit source likewise has two Visual Studio projects. mpoga.vcxproj defines GE_ARENA and includes GEARENA.C, while mpogemp.vcxproj does not define it and includes GEDROIDS.C. Both projects compile their other game files from the shared ge-next source. The project files replace the 16-bit make/link files as the build selection mechanism; they do not represent separate gameplay forks. See Source code for a file map and Porting Galactic Empire for architecture considerations.

What the build flag selects

#ifdef GE_ARENA and #ifndef GE_ARENA mark genuine compile-time differences in shared files. In GEMAIN.H they select the project identity, arena state constants, generated message headers, and module resource names. In GEMAIN.C they select the MajorBBS module block, menu/input states, database handles, startup and cleanup paths, and arena hooks. Other shared files use the same flag at boundaries such as disabled persistent-game commands, arena planets and pickups, NPC behavior, scanning, and ship destruction. Code that only makes sense for one game can therefore be excluded from the other binary rather than left as a runtime branch.

The flag is not intended to produce two wholly separate engines. Common fixes to movement, geometry, ordnance, damage, and other shared mechanics normally reach both builds. A change to a shared routine still needs review in both configurations, because an arena-only condition in the caller or callee may change when it runs or what state it sees. The 16-bit and 32-bit versions should also retain equivalent behavior despite different build systems. See Game timing and Game execution flow for the shared callback model.

Separate resources and saved state

The builds use distinct file prefixes so they can be installed together. Standard ge-next uses MPOGEMP/MPOGE module and data resources; ge-arena uses MPOGA. Arena's main, help, and ship-class sources are MPOGAMSG.MSG, MPOGAHLP.MSG, and MPOGASHP.MSG. The 16-bit arena makefile generates matching message headers from these files, and GEMAIN.H includes those headers instead of the MPOGE versions. The module loads the corresponding compiled message resources and MPOGA.MDF. Messages and class tables cannot be swapped across variants merely because the C code is shared. See Configuring Galactic Empire and Ship class configuration.

Arena opens its own user and planet databases, MPOGAUSR.DAT and MPOGAPLT.DAT. It has no persistent ship, mail, or team database. User records retain account settings and mode-specific wins, with the total wins used as the roster's score key. ARENAPLAYER entries in memory track each connected player's current lobby or match state and scores. Ships and the generated galaxy are disposable match state; match startup and ending reset the world instead of running standard ge-next's long-lived colonization cycle. The arena build preserves the required record sizes while using arena-specific fields in shared structures. See Database files and Data structures for storage details.

Runtime handoff

MajorBBS still enters the shared module's startup, input, scheduled, logoff, and hangup paths. In an arena build, those paths hand off at defined points to GEARENA.C: for example, entry reaches arena_enter_lobby(), the recurring update calls arena_tick(), and ship destruction invokes arena-specific player or Cybertron handling. The arena file owns match transitions and scoring, while shared ship and sector code continues to do the ordinary simulation work. This is why an arena change may require a small conditional branch in a common routine without relocating that entire routine into GEARENA.C.

Adding or changing a mode

The arena ship-class table groups eligible user and NPC classes by mode and stores starting shields, phasers, inventory, and normal class capabilities with each class. Spawn text is generated from the table so the displayed loadout follows the configured values. A new mode may also need objective state, status fields and sorting, winner and tie scoring, planet/drop behavior, persistent win storage, help text, DATA output, and cleanup. It should use the existing lobby, tiebreaker, and match lifecycle paths where possible, and be checked in both architecture builds. These are developer touchpoints rather than additional player rules; see ge-arena for the current modes.