NettyGameServer is a Java, GPL-3.0 licensed distributed mobile-game server built on Netty 4.X that gives backend teams TCP, UDP, HTTP and WebSocket entry points, protobuf-based protocol handling and sharded, Redis-cached MySQL persistence in one starting point.

What it is

NettyGameServer is an open-source, distributed server framework for mobile games, written in Java and built on Netty 4.X. It lives in the Java server ecosystem alongside MyBatis 3, MySQL and Redis, and it ships network entry points for TCP, UDP, HTTP and WebSocket, using a custom protobuf protocol stack for communication and supporting RPC remote invocation between services. Around that core the project bundles a set of companion components: a Netty proxy mode for gateway forwarding, the master-spring-boot branch for Spring Boot deployments, and a separate Cocos Creator client example project for connecting an actual game client. Companion repositories cover the data-dictionary generator, the sharded game database, a game thread pool, a scheduling executor and Redis-based game transactions.

The problem it solves is integration labour. A studio building a mobile game backend normally writes its own socket server, its own protocol framing, its own data-dictionary classes and its own persistence and cache-synchronisation layer before it can ship a single feature. NettyGameServer supplies those layers as one codebase: MyBatis 3 storage with database and table sharding, asynchronous MySQL writes that synchronously refresh the Redis cache, and an ExcelToCode pipeline that generates Java classes and JSON data dictionaries from Excel so that DictService reads the JSON directly and the data-dictionary portion of the code shrinks accordingly.

Key capabilities

• Multi-protocol ingress through Netty 4.X: TCP, UDP, HTTP and WebSocket links for different client types.
• A custom protobuf protocol stack for network communication, with RPC remote invocation for service-to-service calls.
• MyBatis 3-backed persistence with database and table sharding for game data.
• Asynchronous MySQL storage, where a database save also synchronously updates the Redis cache.
• Netty proxy mode providing gateway proxy forwarding for distributed deployments.
• ExcelToCode: generates Java classes and JSON data dictionaries from Excel, which DictService reads directly.
• game-executor: an in-game asynchronous event global service with event sharding and balanced asynchronous event execution.
• The master-spring-boot branch, which supports running the server under Spring Boot.

Who uses it and how

• Java backend teams building a distributed mobile-game server that needs a gateway proxy tier in front of game logic processes.
• Projects whose designers maintain game data in Excel and want a build step that emits Java classes plus a JSON data dictionary instead of hand-maintained constants.
• Studios serving several client shapes at once, for example a Cocos Creator client connecting over the network while HTTP endpoints serve other needs.
• Games with heavy write traffic that rely on sharded MySQL tables with Redis kept in step, or that need asynchronous database writes off the request path.
• Teams already standardised on Spring Boot, who can take the master-spring-boot branch rather than the default layout.

Getting started

The README documents the project through its GitHub Wiki rather than a published package or container image, so the practical route is to clone the repository and build it from source, choosing the master-spring-boot branch if Spring Boot is wanted. A companion Cocos Creator client example project is linked for wiring up a working client connection.

How it compares

No commercial product list is given in the facts, and the README names companion open-source projects rather than competing servers: ExcelToCode, GameShardingDb, GameThreadPool, game-executor, GameCodeGenerate and redis-game-transaction. NettyGameServer sits as the integration hub those components plug into, with no directly comparable alternative named here, so it stands alone in this registry.

When to use it — and when not to

A self-hoster must run and operate the Java and Netty processes along with the surrounding state: MySQL with sharding across database and table partitions, plus Redis for the cache that database writes refresh. Teams that want a hosted or managed backend, or that cannot accept GPL-3.0 obligations on derivative distribution, should look elsewhere, and the README itself is sparse enough that the Wiki is the real source of operational detail rather than the repository front page.