// the find
cherry-game/cherry
🍒 Cherry — Go game server framework powered by Actor Model. Serial goroutine per actor, NATS/etcd discovery, pluggable connectors (TCP/WS/HTTP), protobuf & object-pooled messaging, time wheel, snowflake. Born for MMO/SLG/RPG, scales to millions.
Cherry is a Go game server framework built on the Actor Model, targeting MMO/SLG/RPG workloads. Each actor runs in its own goroutine with a serial mailbox, NATS handles cross-node RPC, and etcd or NATS handle service discovery. It is spiritually a Go successor to NetEase's pomelo and Topfreegames' pitaya.
Three separate actor queues (local client requests, remote RPC, system events) enforce clean message routing without shared state — the right design for a game server where a single actor owns a player or room. Object-pooled messages with reference counting are a practical win; GC pauses kill game servers and this addresses it directly. The layered time wheel is a proper implementation, not a naive ticker — essential when you have thousands of concurrent cooldowns and spawn timers. Pomelo protocol compatibility is worth real money: you inherit a decade of Unity, Cocos, and mobile client SDKs without writing your own.
The primary README and most documentation are in Chinese, and the English README is thinner — international teams will hit a wall quickly when the docs run out. The etcd discovery backend and several production-critical components (DB write queue, Lua scripting, rate limiting) live in a separate repository and some are listed as 'pending release', so the framework is not self-contained for production. The mapstructure library is vendored as a full source copy inside extend/, meaning you absorb its bugs and miss upstream fixes silently. The examples live in a third repository, which makes the getting-started path fragmented — you are chasing across three repos before you have a running server.