View source for Ge-next development

{{DISPLAYTITLE: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.

<code>GEMAIN.C</code> owns the module's host entry points, menus, startup, recurring work, and database lifecycle. <code>GECMDS.C</code> handles game commands; <code>GEFUNCS.C</code> contains much of the ship and combat machinery; <code>GECYBS.C</code> and <code>GEDROIDS.C</code> handle automated ships; <code>GEPLANET.C</code> handles planetary records and updates; <code>GELIB.C</code> supplies geometry and utilities. ge-next also has <code>GESCAN.C</code> for scans and reports, which was not a separate file in classic GE. <code>GEMAIN.H</code>, <code>GEGLOBAL.H</code>, and <code>GEPROTO.H</code> 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 <code>MPOGEMP.MAK</code> in <code>\WGSERV\SRC</code>, MSG files in <code>\WGSERV</code>, and the host's libraries and scripts in their usual locations. The supplied paths also refer to Borland and Phar Lap support files under <code>\BC45</code> and <code>\RUN286</code>. Set up the BBS development environment so <code>MAKE</code>, <code>bcc</code>, <code>tlink</code>, and the BBS tools are available, and <code>MBBS</code> points to the BBS directory. The author runs this DOS toolchain under DOSEMU2 on Linux.

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

<syntaxhighlight lang="text">
C:\>CD \WGSERV\SRC
C:\WGSERV\SRC>MKU MPOGEMP.MAK
</syntaxhighlight>

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

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

The makefile also invokes <code>wgsmsx</code> for the <code>MPOGEMSG.MSG</code>, <code>MPOGEHLP.MSG</code>, and <code>MPOGESHP.MSG</code> sources and their generated headers. Main messages and options, help, and ship classes are separate resources. <code>GEMAIN.H</code> 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 <code>ifdef</code>s 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 <code>\WGSERV\SRC</code> directory, run <code>MKU MPOGA.MAK</code> (or <code>MAKE -fMPOGA.MAK</code>) instead. <code>MPOGA.MAK</code> builds the shared files with <code>-DGE_ARENA</code> into <code>\WGSERV\GAOBJ</code>, adds <code>GEARENA.C</code>, and links <code>\WGSERV\MPOGA.DLL</code>. It does not link <code>GEDROIDS.C</code>. The build generates headers from <code>MPOGAMSG.MSG</code>, <code>MPOGAHLP.MSG</code>, and <code>MPOGASHP.MSG</code>; 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 <code>mpogemp.vcxproj</code> project instead of the 16-bit make/link pair. It compiles the corresponding shared C files, includes <code>GEDROIDS.C</code>, excludes <code>GEARENA.C</code>, and links against [https://github.com/TheMajorBBS/MBBS-v10-module-SDK the MajorBBS V10 SDK libraries] and module definition. This project also leaves <code>GE_ARENA</code> 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 <code>GEMAIN.C</code> and <code>GEMAIN.H</code>, the non-arena build selects the <code>mpoge</code> module block, <code>MPOGEMP.MDF</code>, <code>MPOGEMSG.MCV</code>, the <code>MPOGE</code> 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. <code>MPOGETEA.DAT</code> 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 <code>GE_ARENA</code> 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 <code>GEARENA.C</code> 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.

== See also ==
* [[Source code]] and [[Data structures]]
* [[Configuring Galactic Empire]] and [[Database files]]
* [[ge-arena development]]
* [https://github.com/manicpop/ge-next 16-bit source and releases]
* [https://github.com/manicpop/ge-next32 MajorBBS V10 port]

{{GE navigation}}
[[Category:ge-next]]
[[Category:Development]]