projectshome.genengine.networking

Network Layout

• Dedicated Server & Client System
• Each client is only aware of the server
• The Server is aware of all clients
• A client sends a message to the server. Depending on what that data is the server may either:
  • Process the data and broadcast it to multiple clients
  • Process the data and send it to 1 or more clients i.e. a smaller subset of the above
  • Process the data and send verification to the client that it has been processed i.e. ack 
  • In reality the first two are going to be the same thing as we hope to enable broadcasting to limited groups of users. User A on the farthest left edge of the world doesnt need to know that User B on the opposite side of the world moved left.

Programmatic Structure

• There is a single Networking dll class that does all the lowest level data sending and receiving. It is oblivous to the actual data beyond knowing it is a byte array.
• Theres a single abstract class called NetworkDataHandler that handles the data that is passed to and from the Networking dll.
• The client and the server both have their own network data handler classes that implement the above Networking version. The reason for this is due to the server will need to handle the data differently than the client i.e. the client sends data solely to the server but the server sends data to oodles of clients.
• Actual game world interacting with the network involves calling functions on the relevant network data handler i.e. ClientNetworkDataHandler.Instance.sendMoveCommand(this.id, this.x, this.y); would send the players current position to the server.

To Do

• Re-implement sending binary data
• Start adding more data types that can be passed and finish implementing the ones that already exist.
• Implement sending to groups instead of every client. That will allow us to do things like say “broadcast this message to all clients within x radius of my current position” instead of how it is now which is “broadcast this message to all clients connected to the server”.

Idea Chalkboard

There are two different approaches that have stood out immediately when it comes to linking the world avatars together.

1. Use a dedicated server which multiple clients interact with
   • Can control all the world data in one location
   • Can provide better security in an MMOG in that no client will (or is supposed to) have access to the world data including other players beyond what you let them know
   • Needs hefty servers if you expect alot of players
   • Works well with UDP as you can broadcast data to all the players or specific groups of them
   • Entropia Universe uses a dedicated server
   • Theres nothing stopping you distributing the dedicated server so anyone can host
2. Have one client act as a host AND a client and one or more players can connect to them
   1. Means you dont have to run your own server i.e. as the developer / game company
   2. Your world data is actually on someone elses machine, in fact its on everyone who runs the games machine
   3. Dawn of war is like this. You use gamespy to actually meet other players but the game itself is hosted on one of their machines i.e. not a dedicated server.

As you can see; they all have their advantages and disadvantages. I'm kind of tinkering with a third idea I had. In the long run, with this project, we would want to have a dedicated server that we run in a single location. All players would connect to this server. It could be multiple servers. They stream down the world data using various methods when they connect and as they are playing. My idea is to use a shared network, similar to EMule. We give people the option to host the server on their machine. In return they get something in-game similar to a wage. The flow would go something like this:

• We have a central server located here
• we have 100 happy campers willing to host the sub servers all over the globe
• when a player connects they first come to our central server
• The central server checks its internal list of sub server hosts and send the player the 1..n closest to their vicinity in the real world
• Each player can stream the world data from multiple sub server hosts which hopefully will give them a decent speed regardless of where they are. Obviously this depends on how many people play and where they are :¬)
• Each sub server connects to the central one periodically and gets the latest state of the world

In this setup the central server is still the only one that is capable of generating the world data and maintaining its state. the sub servers that our 100 happy campers host merely hold the latest binary data in case the world has been deformed somehow as well as the latest states of things like clouds, water etc.

Each player would connect to all the sub servers when they join the game so that if one of the servers goes down then they wont see a substantial delay as they authorise with the next server.

Collision detection and other basic functionality is handled on each client.

Enviromental control and NPO control resides on the server.

If we wanted a plane to fly around in a circle continuously we would send that to the client in one go as a single command i.e. «create a plane at x/y and make it spin round and round». The client gets that when they get the rest of the world data. From then on the client deals with rendering the planes animation. We can always send another command later on to say “make the plane land”.

Entropia seems to let the client control movement and collision detection. You can see this because you can still slide into buildings. I dont know if you can literally slide into a building, I tend to jump at a wall for a while. Eventually you pop through and are inside the building. This is neat but it can be a pain to get out. The only other way out is to teleport/wormhole to another location. If you log off and back on again without escaping the building then you'll appear inside it again. Even if their server only did bounds checking when the player first connects/disconnects you would appear outside the building when you reconnect later on.

One of the main disadvantages of letting the client handle collision detection like this is that someone can hack the client and give themself “Ghost Mode”. If they could fly through walls, well even just fly then it can give them an advantage over other players. The other players wont be doing the same kind of checks on all the other avatars as they'll solely be dealing with their own checks. This means they will see the other player flying and moving through walls. I mean obviously if they gave themselves ghost mode then they could just make themselves invisible.

Both of those two things might or might not give them advantages over other players. Taking entropia again (i need to play more mmorpgs!) the ability to walk through walls would let you enter peoples private estates. you can buy apartments and houses and lock them from other avatars so their private. just because they can ghost into that persons bedroom doesnt mean they can pick up that persons belongings. Whenever that type of event happens its down to the server to verify who can and cant pick/drop things in a location. that means the only thing they can really do is check things out like the wall paper or what chair they have :¬)

So in that situation its fine to let people ghost. Take another game that is more strategic, i havent player any so i'll just outline the type o game i mean. Its an mmorpg, their are two vast armies forming behind a hill. army A is on the left and army B is on the right. neither side can see what the other is preparing due to heavy cover. now throw in someone who has applied a ghost hack to the client. they can easily walk through the enemy encampment (their invisible as well) and then report back. bummer!