I’ve also been adding Facebook integration.  So far the integration solutions for Unity3D that I’ve found so far have had huge security holes so I’ve had to come up with something myself. Not to say it doesn’t have holes either but at least I tried to keep people from hacking the app

What I’ve done is use the .NET Facebook API. I validate the Facebook user and look up their details in SimpleDB and put it all together in a class.  I serialize the class, RSA encrypt the bits salt and sign the data.  I send this as a cookie that gets picked up in the Facebook page and forwarded to Unity3D through JavaScript.

Unity3D takes this blob of data when establishing communication with the UDP server.  The server can then validate the signature, decrypt the data and viola.

The server culls down how many entities the game client will see so not to overload it. On the server I have masks that are used to categorize and prioritize what needs to be seen on any client. Click the video to head on over to youtube.com and watch it in HD.

As of this writing, I’ve had the server up to 400 concurrent connections @ 50% cpu but in the next build I think I can double that performance. There are many optimizations I know I can do at this point. Load has a lot to do with the number of entities that can see each other at any one time which corresponds to the number of messages I need to generate.

The chart below is with 95 connected entities that can all literally see each other.

As it is in that video, every entity can see every other entity within a vision radius. To achieve the 400 connections, I reduced the vision radius of NPCs and left the larger radius for actual players. This is where the masking comes in. NPCs don’t really care about a lot of entities. They may not care about any entities of their same race for instance. They may only care about players or perhaps even entities of a race they are at war with. The mask is simply a set of flags that determine who they care about seeing. Combine this with an appropriate vision radius. For instance, NPC’s don’t have to see as far as players. They only need to see as far as their maximum aggro radius. On the other hand, players need to see further so that characters don’t magically warp in.

World design also plays a part in controlling this. If you can see a great distance in front of you at any one time, you could potentially see a lot of entities. Have a look carefully at the design of Orgimmar or Iron Forge in World of Warcraft. Also think about how dungeon instances are designed. These areas are designed either to manage a high density of players or to keep game latency down to a minimum by carefully managing your visual distance. This will keep both the client and server snappy.

If you have other ideas for managing this, I’d love to hear them. Please post a comment!

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.

Hiya, cats and kittens! I am the writer and class designer for Ghostees!, our upcoming MMORPG, and I just wanted to start out saying hello and that I hope you will enjoy Ghostees. We’re very excited to bring you this new game, and our developers are hard at work to bring you the very best gaming experience possible.

Today we are going to cover some of the background lore of the game, covering the Otherwhere and its connection to the human realm.

Otherwhere

The Otherwhere is a world that coexists with the normal human world, intersecting it at certain places and times but otherwise only perceivable through its influence. In the Otherwhere the dreams, fantasies, and beliefs of the human world are given form and life. As to whether they are given their existence from our dreams, or our dreams are caused by their existence…no one knows.

The Seasonal Realms

For some unknown reason, the cycle of existence of the human world and the Otherwhere are linked. Our seasons are linked to specific regions in the Otherwhere, and as our world goes through its changes the Otherwhere comes into and out of alignment with us. The alignments are closest at certain times, and these times have been traditionally called “holidays” by the humans barely aware of their origins. In the modern era we have forgotten their meaning, but the Seasonal Realms of the Otherwhere are still there, affecting us.

The Aisling

The Aisling, or “Dreams”, are the natives of the Otherwhere. They each express a theme or archetype called an Essence that defines the way they look, the personalities they have, and their abilities.

Essences

These are the living manifestations of our fascinations and stereotypes that have arisen over the course of human existence. We birth them from our minds, and they change as we change, but it is not a one-way street. Our worlds are interwoven, and if their nature changes, so too do our dreams, hopes, and fears. As they live or die, succeed or fail, so too does that realm of our imaginations.

The Autumn Realm

In the 21st Century world, human understanding of the Otherwhere and its seasonal influence has faded, only to be replaced by more “rational” explanations for the holidays. Where once the night of October 31 was a festival that acknowledge the power of death and the coming winter, it came to be a night of monsters, ghouls, pranks, and ghosts. The Autumn Realm followed suit and came to manifest as Halloween, with Aisling as old as dreaming itself remade as vampires, mummies, and witches.

Next Time:

Next time I will give you a sneak peak into the realm-spanning war between the Technocrat’s Great Plan and Grim Jack’s misfit crew of monsters, the Terata. Stay tuned!