How gunnyii/basegunnyii works
1. What this repo is
- This is a multi-project .NET game platform for the “GunnyII” base, not a single app.
- The architecture is split into shared libraries, long-running servers, web request endpoints, and front-end ASP.NET pages/Flash assets.
2. Core shared foundation
- Game.Base, Game.Logic, SqlDataProvider, and Bussiness are the main reusable layers.
- Game.Base provides server/runtime infrastructure such as packet parsing, command dispatch, events, config loading, queues, and script management.
- Game.Logic contains the core game rules: physics, maps, objects, skills/spells, AI, missions, PvE/PvP logic, and effect processing.
- SqlDataProvider is the typed data/model layer for database entities like players, items, quests, consortia, maps, logs, and rates.
- Bussiness wraps higher-level domain operations and service references used by the web and server tiers.
3. Main server runtime: Game.Server
- This is the central gameplay server and the largest runtime boundary.
- It handles scene gameplay, room management, inventory, chat, quests, marriage, hot spring rooms, login integration, battle integration, and packet dispatch.
- The packet layer is very explicit: there are many Packets/Client/*Handler.cs classes and Packets/Server/* abstractions, showing a message-driven architecture.
- It also contains multiple gameplay domains that can be diagrammed as submodules: Rooms, SceneGames, SceneMarryRooms, HotSpringRooms, Battle, Managers, Quests, and Statics.
4. Battle-specific runtime: Fighting.Server
- This is a dedicated combat server for match/battle execution.
- It has its own room manager, game manager, guild integration, server client, and battle/game objects.
- The presence of Games, Rooms, Servers, and ProxyPlayer indicates it can host or proxy combat sessions independently from the main game server.
- Conceptually, Game.Server coordinates player/world state, while Fighting.Server runs the fight instance itself.
5. Center/coordination runtime: Center.Server
- Center.Server appears to be the central coordination and registry service.
- It has server/client management, login management, consortium management, static configuration, logging, and a WCF-style service boundary (Services/ICenterService.cs, CenterService.cs).
- This is likely used to publish server info, manage cross-server metadata, and support login/server selection flows.
6. Request/API tier: Tank.Request and Road.Request
- These projects are ASP.NET request gateways made up of many .ashx handlers and some .aspx pages.
- They expose account/login, server list, item lists, quest data, mail, consortia, ranking, rewards, and payment-related endpoints.
- Tank.Request is the larger production-facing endpoint layer for game services; Road.Request looks like a related/older or alternate request surface with similar responsibilities.
- These layers are the main bridge between browser/client-facing flows and the backend servers/database.
7. Client-facing web UI / launchers
- Tank.Flash is the main web front-end and launcher surface, containing Flash-era pages, loading screens, login entry points, scripts, and image assets.
- RenRenAssistant and Tank.Assistant are auxiliary ASP.NET apps for login transfer or platform integration.
- These are presentation and entry layers; they do not hold the core game rules.
8. Service hosts / background processes
- Game.Service, Fighting.Service, and Center.Service are service-hosting projects used to run or manage the server processes.
- They include console/service start actions, install/uninstall routines, and in some cases Lua or config assets.
- This suggests the servers can be launched as Windows services or console processes depending on deployment.
9. Gameplay domain boundaries inside the servers
- The repo cleanly separates major gameplay concerns:
- scene/world play: SceneGames, Games, MapMgr, WorldMgr
- room/session flow: Rooms, ProxyRoom, RoomMgr
- combat and physics: Phy, Battle, TankGameLogicProcessor
- social systems: consortia/guild, marriage, IM/chat, hot spring
- economy/inventory: items, shops, auctions, strengthen/fusion/refinery, drops
- progression: quests, achievements, levels, daily awards, active events
- That structure matters for architecture diagrams because each area can be shown as a separate bounded subsystem feeding the same player state and database.
10. Content, AI, and script layer
- GameServerScript and parts of Game.Logic contain game-specific AI/missions/NPC logic.
- There are many script classes for maps, NPCs, missions, and difficulty variants, plus Lua support in Game.Logic/LuaMgr.cs and Game.Service/ai.
- This is effectively the content scripting layer over the engine, distinct from the server transport and persistence layers.
11. Data and persistence path
- Persistent data originates in SqlDataProvider entity types and is used by Bussiness, server managers, and request handlers.
- RoadDatabase contains LINQ/DB helper infrastructure and the DBML/DataSet artifacts that back the persistence model.
- Many request endpoints and server managers appear to read/write player, item, quest, log, and configuration data through this shared data layer.
- From a diagram perspective, the database sits behind the request layer and the game servers, with SqlDataProvider as the common contract.
12. External service dependencies
- There are WCF service references to CenterService and WebLogin, showing that parts of the system depend on centralized login and center coordination services.
- This is a distributed system, not a monolith: login, server selection, and center metadata are shared across multiple processes.
- Logging is also a visible cross-cutting concern via log4net config files and per-server log configurations.
13. Tools, tests, and maintenance
- Game.Config, Game.Tools, and RoadTest are supporting utilities for configuration, admin tooling, and validation.
- Game.Test and RoadTest contain unit/multi-thread tests for marshalling, DB access, crypto, XML, and buffering.
- These projects help validate infrastructure pieces rather than game-play features.
14. How to diagram the data flow
- A useful architecture diagram would show:
- browser/Flash client and admin tools on the left
- ASP.NET request gateways in front of them
- shared business/data layers in the middle
- Game.Server, Fighting.Server, and Center.Server as the main runtime services
- the database and shared WCF login/center services on the right/back end
- The key runtime flow is: client request or socket message -> packet/handler dispatch -> domain manager/business logic -> shared data provider/database and/or inter-server service -> response back through the same boundary.
Main entry points: Game.Server Game Server · Bussiness Bussiness · Tank.Request Tank Request · Center.Server Center Server
Components 21
Client / UI
Browser, Flash-era launcher, and auxiliary login-assistant front ends.
- Tank Flash · Flash-era web front end, loading flow, and game entry surface.
Tank.Flash - Tank Assistant · Auxiliary ASP.NET login-transfer and platform integration app.
Tank.Assistant - RenRen Assistant · Auxiliary ASP.NET app for transfer/login/payment integration.
RenRenAssistant
Request Gateways
ASP.NET handlers and pages that expose account, server, inventory, quest, and payment flows.
- Tank Request · Main request surface with handlers for login, server list, items, quests, mail, consortia, ranking, and payments.
Tank.Request - Road Request · Alternate/older request surface with similar data-loading and account flows.
Road.Request
Shared Foundation
Reusable business, logic, and data-model layers consumed by servers and request projects.
- Game Base · Core server infrastructure for packet parsing, command dispatch, config, events, queues, and scripts.
Game.Base - Game Logic · Core gameplay rules: physics, maps, objects, spells, AI, missions, PvE/PvP, and effects.
Game.Logic - Bussiness · Higher-level domain operations and service wrappers used by web and server tiers.
Bussiness - SqlDataProvider · Typed database entities and shared persistence contract for players, items, quests, logs, and rates.
SqlDataProvider - Game Scripts · GameServerScript content layer for AI, missions, NPC behavior, and scenario-specific logic.
GameServerScript
Server Runtimes
Long-running gameplay, combat, and coordination processes.
- Center Server · Central registry/login coordination service with server management, config, and WCF boundary.
Center.Server - Game Server · Main gameplay runtime for scene play, rooms, inventory, chat, quests, social systems, and packet dispatch.
Game.Server - Fighting Server · Dedicated combat server for battle sessions, room management, proxies, and fight execution.
Fighting.Server
Backend Services
Persistence, center/login coordination, and supporting hosts.
- RoadDatabase · LINQ, DBML, and database helper infrastructure supporting the shared persistence model.
RoadDatabase - Game Service · Windows service / console host for Game.Server deployment and lifecycle control.
Game.Service - Fighting Service · Windows service / console host for Fighting.Server deployment and lifecycle control.
Fighting.Service - Center Service · Windows service / console host for the center coordination process.
Center.Service - Game Config · Configuration utility for managing server and game settings.
Game.Config - Game Tools · Admin and maintenance client tooling for operational tasks.
Game.Tools - Game Test · Infrastructure and data-access tests for marshaling, crypto, XML, buffering, and DB access.
Game.Test - Road Test · Database and service tests for the Road stack.
RoadTest
Connections 28
- Tank Flash → Tank Request: HTTP · Browser/launcher flows call request endpoints for login, loading, and game metadata.
- Tank Assistant → Tank Request: HTTP · Auxiliary app uses the request tier for login transfer and integration flows.
- RenRen Assistant → Tank Request: HTTP · Platform integration app routes through the request tier.
- Tank Request → Bussiness: domain ops · Handlers delegate account, item, quest, consortia, and payment operations to business services.
- Road Request → Bussiness: domain ops · Alternate request surface also uses the shared business layer.
- Tank Request → SqlDataProvider: models · Request handlers read and write shared entity models.
- Road Request → RoadDatabase: db access · Road request endpoints lean on database helper infrastructure.
- Bussiness → SqlDataProvider: entities · Business services operate on shared persistence entities.
- Bussiness → RoadDatabase: persistence · Higher-level services use database helpers and generated mappings.
- Game Server → Game Base: infra · Gameplay runtime builds on shared server infrastructure and packet/command machinery.
- Game Server → Game Logic: rules · Scene, room, inventory, and quest code execute against the shared game engine.
- Game Server → Bussiness: services · Server-side gameplay operations call into shared domain services when needed.
- Game Server → SqlDataProvider: state · Player, item, quest, social, and log state persists through shared data models.
- Game Server → Center Server: coordination · Gameplay server depends on center services for login and cross-server metadata.
- Game Server → Fighting Server: battle link · Main server connects to dedicated combat sessions and proxies fights to the combat runtime.
- Fighting Server → Game Logic: combat rules · Combat server reuses shared game physics, spells, and battle logic.
- Fighting Server → Game Base: infra · Combat runtime uses the same packet and command foundation.
- Center Server → SqlDataProvider: config/state · Center service manages shared server, login, and consortium metadata.
- Center Server → Bussiness: registry ops · Center coordination uses business/domain wrappers for management tasks.
- Game Service → Game Server: host · Service host starts and manages the main gameplay process.
- Fighting Service → Fighting Server: host · Service host starts and manages the combat process.
- Center Service → Center Server: host · Service host starts and manages the center process.
- Game Scripts → Game Logic: content · Scenario AI, missions, and NPC scripts extend the shared game logic.
- Game Scripts → Game Server: content · Server gameplay processors consume scripted content and AI definitions.
- Game Config → Game Base: config · Configuration tool targets shared runtime settings and XML config infrastructure.
- Game Tools → Game Server: admin · Operational tooling interacts with the main runtime for administration.
- Game Test → Game Base: validation · Tests cover shared infrastructure pieces such as marshalling and buffering.
- Road Test → RoadDatabase: validation · Road tests exercise database and service integration.