The game is only one part of the product.
Undead Forever is a portrait social zombie RPG: missions, player rivalry, clans, mutations, and long-term progression. It is available on both the App Store and Google Play. Its implementation spans C++ game code, platform-specific interfaces, online services, and the release tools around them.
The useful engineering question is where each responsibility belongs. A mobile interface needs to feel comfortable on its platform. Account progress needs to survive a closed app. A store purchase needs a verified, repeatable outcome even when a device retries a request.
Share the rules. Respect the platform.
The project uses C++23 for shared game systems and core tests. Platform integrations remain explicit: the iOS app includes Objective-C++ and Apple frameworks, while Android combines its Java application layer with native code. Sharing the foundation does not remove the work of building, testing, and supporting both interfaces.
That separation helps keep a platform feature from becoming a different set of game rules. It also means that a successful desktop or core test is only one checkpoint. Touch input, lifecycle behavior, permissions, and store integrations still need their own verification.
Let the service own lasting progress.
Online progression belongs to the server. The game’s service validates supported account and purchase flows, applies changes, and persists the resulting state. The clients present the experience and send requests; reconnecting should return the player to the same account and progress.
Purchase handling is a useful example. A successful payment callback is not a reason to award the same purchase twice. The implementation has separate platform verification paths and transaction records so a retry can be recognized rather than becoming a second grant.
Two release pipelines are still two release pipelines.
For iOS, the release path produces an Xcode archive and an App Store Connect upload. Android uses Gradle to build its release package or app bundle and checks that release-signing configuration is present. The store packages are different outputs with their own requirements.
A build passing, a store accepting an upload, and the game behaving correctly on a phone answer different questions. Keeping those checkpoints separate makes a release easier to assess and a regression easier to locate.
The supporting work is part of shipping.
A player also needs a clear download page, understandable guides, account help, and product policies. Those are part of Bezhig’s product surface alongside the game and its services.
FateMMO takes the next step with a custom engine, editor, content pipeline, and a larger multiplayer world. The public engine repository is available for a closer look at that technology. Undead Forever’s game and service implementation remain separate from the public engine.
Interested in the engineering behind the work? Contact Caleb or follow future engineering stories.