ge-next development

ge-next continues classic Galactic Empire as a persistent MajorBBS game. Its 16-bit module and MajorBBS V10 port aim to expose the same game rules while using different host interfaces and, where necessary, different internal representations. This page describes the project's implementation and maintenance boundaries. For the player-facing version history and features, see ge-next.

Source lineage and organization

The 16-bit project develops the published classic C code rather than wrapping a classic binary. The 32-bit port is maintained in a separate source tree for MajorBBS V10; it was built with Elwynor Technologies' port of classic GE as a guide. The two ge-next editions are intended to track the same gameplay, but their source files and build products are not interchangeable. A change made in one tree must be reviewed and carried across deliberately. See Versions of Galactic Empire, Source code, and Porting Galactic Empire for lineage and file-level orientation.

GEMAIN.C owns the module's host entry points, menus, startup, recurring work, and database lifecycle. GECMDS.C handles game commands; GEFUNCS.C contains much of the ship and combat machinery; GECYBS.C and GEDROIDS.C handle automated ships; GEPLANET.C handles planetary records and updates; GELIB.C supplies geometry and utilities. ge-next also has GESCAN.C for scans and reports, which was not a separate file in classic GE. GEMAIN.H, GEGLOBAL.H, and GEPROTO.H connect their shared types, state, and declarations. The Source code page maps files to routines without requiring every detail here.

Building the 16-bit module

The 16-bit build requires Borland C++ 4.52, its MAKE utility, Turbo Link 7.00, and the MajorBBS/Worldgroup development files and build utilities. The project's makefile expects the normal BBS directory layout: C sources and MPOGEMP.MAK in \WGSERV\SRC, MSG files in \WGSERV, and the host's libraries and scripts in their usual locations. The supplied paths also refer to Borland and Phar Lap support files under \BC45 and \RUN286. Set up the BBS development environment so MAKE, bcc, tlink, and the BBS tools are available, and MBBS points to the BBS directory. The author runs this DOS toolchain under DOSEMU2 on Linux.

Run the build from the BBS's SRC directory, not from a detached source checkout. The MKU.BAT helper in the BBS's SRC directory is a convenience wrapper containing make -f%1, so these commands are equivalent:

C:\>CD \WGSERV\SRC
C:\WGSERV\SRC>MKU MPOGEMP.MAK

The direct invocation is MAKE -fMPOGEMP.MAK. MKU.BAT does not set up the toolchain or change directories; the BBS build environment must already be configured.

The standard MPOGEMP.MAK compiles the C files into \WGSERV\PHOBJ. Its ctdll and ltdll scripts use bcc and tlink; MPOGEMP.LNK supplies the object and library list that produces \WGSERV\MPOGEMP.DLL. The build includes GEDROIDS.C and does not link GEARENA.C. It does not define GE_ARENA, so #ifndef GE_ARENA paths in shared files provide the persistent-game behavior.

The makefile also invokes wgsmsx for the MPOGEMSG.MSG, MPOGEHLP.MSG, and MPOGESHP.MSG sources and their generated headers. Main messages and options, help, and ship classes are separate resources. GEMAIN.H selects the matching headers and compiled message files; changing an identifier, format argument, or class-table shape requires compatible resources and code, not just a replacement text file. See Configuring Galactic Empire and Ship class configuration.

ge-next purposefully retains all ifdefs necessary to compile on MajorBBS 5.x, so while it should compile in that environment, it has not been tested.

Building ge-arena

From the same configured \WGSERV\SRC directory, run MKU MPOGA.MAK (or MAKE -fMPOGA.MAK) instead. MPOGA.MAK builds the shared files with -DGE_ARENA into \WGSERV\GAOBJ, adds GEARENA.C, and links \WGSERV\MPOGA.DLL. It does not link GEDROIDS.C. The build generates headers from MPOGAMSG.MSG, MPOGAHLP.MSG, and MPOGASHP.MSG; use the corresponding arena message resources with the DLL. Keeping the two object directories separate prevents the wrong compile-time variant of a shared file from being linked. See ge-arena development for the code and resource differences.

Building for MajorBBS V10

The 32-bit tree uses a Visual Studio mpogemp.vcxproj project instead of the 16-bit make/link pair. It compiles the corresponding shared C files, includes GEDROIDS.C, excludes GEARENA.C, and links against the MajorBBS V10 SDK libraries and module definition. This project also leaves GE_ARENA undefined. The V10 host uses different entry-point conventions, type widths, packing, and Btrieve record sizes, so this port is not simply the 16-bit build with a wider compiler. Architecture-specific code should preserve the same visible rules; Integer and storage assumptions and Data structures document the important boundaries.

Module identity and persistent records

The standard module identifies itself to MajorBBS separately from classic GE and ge-arena. In the shared GEMAIN.C and GEMAIN.H, the non-arena build selects the mpoge module block, MPOGEMP.MDF, MPOGEMSG.MCV, the MPOGE data prefix, and the standard roster and menu files. That separation lets the games coexist without sharing live records or message IDs. The 16-bit and 32-bit ge-next packages also use different record layouts and clean-template conventions; do not treat their databases as drop-in substitutes.

Unlike ge-arena, standard ge-next retains long-lived user, ship, planet/sector, and mail databases. MPOGETEA.DAT stores teams as a fixed-width text file rather than a Btrieve database. Ships, colonies, user preferences, cash, and scores survive sessions; planet production and other scheduled work advance this saved game over time. A module reload or new build therefore has to respect existing record sizes, keys, and migrations. Database files covers the operational file set, while Data structures explains its layout.

Shared code and arena boundaries

The same 16-bit ge-next source tree can produce ge-arena by defining GE_ARENA and using the arena build target. Shared code is retained for movement, scanning, damage, ordnance, and other mechanics; conditional sections select where lifecycles, commands, databases, NPCs, or planets truly differ. The arena-only GEARENA.C is not present in an ordinary ge-next binary. This arrangement allows a common bug fix to benefit both games without copying whole routines, but a shared edit still needs a review of its effects in both builds. See ge-arena development for that build's resources and hooks.

Engineering and verification

Inherited defects are checked against classic source and, when relevant, against observable classic behavior before being changed. Corrections should be separated from deliberate balance or feature changes and recorded in the Classic bug database or ge-next release history as appropriate. The original causes matter: a port that only hides a symptom may retain the broken record mutation or event ordering.

The legacy host is single-threaded and uses globals as shared workspace; maintaining it does not require threading or a wholesale rewrite of that state. Particular care is needed around MajorBBS callbacks, message-buffer ownership, delayed projectiles, Btrieve operations, cleanup, and record limits. The 16-bit edition is tested with MajorBBS and MBBSEmu; the 32-bit edition targets MajorBBS V10. A change to shared behavior should be checked in both architectures and in ge-arena where the code is also compiled. See MajorBBS integration, Game timing, and Porting Galactic Empire for the wider host contract.