Part of the Android multiplayer epic: #14
Goal
Investigate reviving real internet matchmaking (browsable lobbies, not a manually-shared virtual LAN) by pointing the existing GameSpy client at a community server replacement — i.e. the GeneralsOnline project. This is the most ambitious option and is explicitly research/spike first, because of the determinism wall.
Why this is even plausible
The upstream project deliberately preserved the GameSpy client to keep this door open:
docs/WORKDIR/archive/reports/SESSION_31_STATUS.md:17 → "GeneralsOnlineDevelopmentTeam maintains opensource GameSpy server — compatibility is MANDATORY for future integration."docs/WORKDIR/archive/sessions/SESSION23_HANDOFF.md:144 → "Preserve infrastructure for potential community servers."
The client half is intact and shipping: the GameSpy matchmaking/chat/peer stack (Core/GameEngine/Source/GameNetwork/GameSpy/ — Chat.cpp, PeerDefs.cpp, GSConfig.cpp, LadderDefs.cpp, StagingRoomGameInfo.cpp, Thread/; plus GeneralsMD/.../GameNetwork/GameSpy*), and libgamespy.so is built and bundled.
The original problem
GameSpy's master servers were shut down industry-wide in mid-2014. Retail Generals online has been dead ever since for everyone; community projects (GeneralsOnline / C&C:Online-style) stand up protocol-compatible replacement servers.
Two integration routes
Route A — redirect endpoints (lean). The retail client resolves master-server hostnames (*.gamespy.com: peerchat, gpcm, master/serverlist). If GeneralsOnline speaks the retail protocol, "integration" = overriding those endpoints (via GSConfig/PeerDefs server-address config or a DNS/hosts redirect) so the client connects to the community server. This is the route the "compatibility is MANDATORY" note anticipates. Needs: find where the endpoints are defined, confirm GeneralsOnline accepts the vanilla protocol, expose the override.
Route B — adopt GeneralsOnline's own client (heavy). The references/generals-online-client submodule points at GeneralsOnlineDevelopmentTeam/GameClient — their modified Windows client with custom netcode / anti-cheat / matchmaking. It is referenced, not integrated (submodule not even initialized). Merging it is a large Windows-targeted fork-merge and is not realistic for Android. Documented here only so the option is on record.
The blockers (in priority order)
- Determinism (fatal for cross-platform). GeneralsOnline lobbies are populated by Windows players. Even a flawless lobby connection ends in a desync the moment the match starts, because Android's arm64/bionic sim won't be bit-identical to x86/Windows (see the determinism sub-issue). So realistically this only yields Android-vs-Android matches hosted through the community server — at which point LAN-over-VPN already gives you that with far less work.
- Untested socket/thread stack on Android. The GameSpy peerchat threads, blocking DNS, and any
WSA*/Win32 socket idioms have never run on bionic.
- Protocol/version compatibility. Whether GeneralsOnline accepts an unmodified retail-ZH client at all, or mandates their client/patch level.
- ToS / keys / anti-cheat. Community servers may gate on client identity or ban unofficial clients.
Investigation / acceptance criteria (spike)
Recommendation
Do not start here. Treat as a research spike gated behind the LAN + determinism sub-issues. The determinism wall means the reachable outcome (Android-vs-Android) is identical to LAN-over-VPN, which is a fraction of the effort and has no server dependency. Only invest if browsable internet matchmaking (vs a shared virtual LAN) is an explicit product goal.
Goal
Investigate reviving real internet matchmaking (browsable lobbies, not a manually-shared virtual LAN) by pointing the existing GameSpy client at a community server replacement — i.e. the GeneralsOnline project. This is the most ambitious option and is explicitly research/spike first, because of the determinism wall.
Why this is even plausible
The upstream project deliberately preserved the GameSpy client to keep this door open:
docs/WORKDIR/archive/reports/SESSION_31_STATUS.md:17→ "GeneralsOnlineDevelopmentTeam maintains opensource GameSpy server — compatibility is MANDATORY for future integration."docs/WORKDIR/archive/sessions/SESSION23_HANDOFF.md:144→ "Preserve infrastructure for potential community servers."The client half is intact and shipping: the GameSpy matchmaking/chat/peer stack (
Core/GameEngine/Source/GameNetwork/GameSpy/—Chat.cpp,PeerDefs.cpp,GSConfig.cpp,LadderDefs.cpp,StagingRoomGameInfo.cpp,Thread/; plusGeneralsMD/.../GameNetwork/GameSpy*), andlibgamespy.sois built and bundled.The original problem
GameSpy's master servers were shut down industry-wide in mid-2014. Retail Generals online has been dead ever since for everyone; community projects (GeneralsOnline / C&C:Online-style) stand up protocol-compatible replacement servers.
Two integration routes
Route A — redirect endpoints (lean). The retail client resolves master-server hostnames (
*.gamespy.com: peerchat, gpcm, master/serverlist). If GeneralsOnline speaks the retail protocol, "integration" = overriding those endpoints (viaGSConfig/PeerDefsserver-address config or a DNS/hosts redirect) so the client connects to the community server. This is the route the "compatibility is MANDATORY" note anticipates. Needs: find where the endpoints are defined, confirm GeneralsOnline accepts the vanilla protocol, expose the override.Route B — adopt GeneralsOnline's own client (heavy). The
references/generals-online-clientsubmodule points atGeneralsOnlineDevelopmentTeam/GameClient— their modified Windows client with custom netcode / anti-cheat / matchmaking. It is referenced, not integrated (submodule not even initialized). Merging it is a large Windows-targeted fork-merge and is not realistic for Android. Documented here only so the option is on record.The blockers (in priority order)
WSA*/Win32 socket idioms have never run on bionic.Investigation / acceptance criteria (spike)
GSConfig,PeerDefs, any*.gamespy.comstring) and whether they're overridable without recompiling.Recommendation
Do not start here. Treat as a research spike gated behind the LAN + determinism sub-issues. The determinism wall means the reachable outcome (Android-vs-Android) is identical to LAN-over-VPN, which is a fraction of the effort and has no server dependency. Only invest if browsable internet matchmaking (vs a shared virtual LAN) is an explicit product goal.