Ghostees: Server Technology

The server technology is interesting. Our background is primarily in high performance serverdevelopment. We wanted a design that could scale to support a very large number of players. Who doesn’t? Server-side tasks are logically divided into services and architected so that they can run and live independently on remote hardware. This way we can distribute the load based on capacities any particular service can handle.

Servers are auto discoverable and communicate with each other efficiently over UDP. This is a huge benefit. As servers come on and offline, we don’t need to do any reconfiguring of dependent servers. They are designed to locate the appropriate service by dropping a service discovery packet on the network. All servers that provide that service respond with server information and current server load. This way the seeking server can choose among servers with more available capacity.

Servers are auto discoverable and communicate with each other efficiently over UDP

For instance we have a combat service. All it does is create and maintain a combat encounter for a set of entities (players and NPCs). A Ghosteesplayer initiating combat will cause the player’s gateway server to request a combat encounter instance on an available combat server. Other players and NPCs can join a combat encounter even if they are not on the same gateway.

A gateway is the server a player’s browser communicates directly with. It takes care of the core RTMP / AMFstuff that Flash communicates with natively. It is also responsible for persisting player information to the database and also for facilitating access to the other servers in the system. It does not do chat, movement, routing or even quests or NPC AI. Those are all different services potentially running elsewhere.

A zone server is responsible for simply tracking the entrance/exit and movement of entities. When an entity enters a zone (player or NPC), the zone broadcasts to all connected gateways that they need to subscribe to this new entity. It also sends messages back to the connecting player information about the zone, such as graphic asset information, music, collision layers and other existing entities.

To a zone server, an NPC looks just like any other player.

On each simulation step the zone server updates the positions of entities it knows about. When a player or NPC requests a route to a new destination, the zone server facilitates the route calculation, obstacle avoidance and potential zone transfers. Once the route is calculated it is sent to the requesting entity. This overrides any predicted route done by the client.  It’s pretty cool actually!

NPC AI runs on their own gateway server. To a zone server, an NPC looks just like any other player. NPCs can be scripted to request routes and respond to player interactions among other things just like a player.

I think your getting the idea by now. We’re really enjoying working with this design. It’s quite flexible and powerful.

• Bookmark on Delicious
• Digg this post
• Recommend on Facebook
• share via Reddit
• Share with Stumblers
• Tweet about it
• Subscribe to the comments on this post

Tags: flash, Ghostees, Ghostees server technology, MMORPG, server