Network Optimization

From HEWIKI
Jump to: navigation, search

Specifically addressing Network utilization, HeroEngine has sophisticated Bandwidth Management, Data Replication (bit efficient) and High-speed Awareness Systems designed to support the demands of Massive Multiplayer Games.

http://hewiki.heroengine.com/wiki/Replication

http://hewiki.heroengine.com/wiki/Spatial_awareness

However, HeroEngine does not negate the need for your designers and programmers to:

   * design the game world that supports massive populations
   * design game play that supports massive populations
   * provide sufficient content for massive populations
   * utilize the engine's features
   * architect systems that are asynchronous, parrallelizable, perform caching, lazy evaluation, etc as appropriate (designers think of area server instance as geometry with npcs, shops, quests, etc.  As programmers we know an area server instance is a unit of simulation and we have control over spinning up additional processes called areas each of which can be used to run any code we need http://hewiki.heroengine.com/wiki/System_areas.)
   * write good code


No engine, no programming language, no technology can make a bad N^2 algorithm anything other than a bad N^2 algorithm.


We are often asked, "Can HeroEngine support X players..."

This is, however, the wrong question as it tries to simplify an extremely complicated topic to a yes or no answer rendering the answer effectively meaningless. The answer is Yes, absolutely HeroEngine can handle X players for any value of X (please see the previous sentence).

A production HeroEngine Cluster is typically composed of a database server capable of handling many worlds (often referred to as "shards" or "servers" by players), with a supporting cast of 1...N physical machines called "world" servers (in a server group) upon which the "world" processes (such as area server instances) are run on. Because HeroEngine is a process oriented architecture, expanding cluster compute capacity is simply adding another physical server into the server group and processes (such as area server instances) will start spinning up on the new machine.

Ok...process oriented and an area server instance is a process. What if we ask how many players can be serviced by an area server instance? Maybe that will give us an answer we can use...

Unfortunately, this again is not the right question because there are too many variables that are entirely under your team's control.

For example, I personally have run 5000 AI controlled characters in an area server instance. Great! That means we can have 5000 players in an area server instance easy right?

Maybe...

It is all a matter game design, architecture and coding.

The number of players a game can support in a "shard" is more often a question of where is the proper balance point for a world to feel populated (i.e. massive) but not over populated such that there is insufficient content for the players (competition for resources such as "spawns") or systems (e.g. auctions) are no longer sufficiently responsive.

My example of running thousands of AI controlled characters was based on the following choices for the test, modifying any of them has the potential to modify the number by orders of magnitude in either direction.

   * dedicated commodity server hardware ~3 years old (as opposed to a development cluster in HeroCloud where your worlds run in a shared virtualized environment).  Technically, this test only utilized a single core since it was performed in a single process.
   * characters were placed in packets of 100 with sufficent separation that each character would only receive awareness events for up to 99 others entering/leaving awareness
   * ai behavior was simple wandering using pathfinding
   * I write really good code


If we alter the parameters to place 5000 players within awareness range of each other, ignoring the fact the client will not be able to render 5000 typical animated MMO characters simultaneously, the overhead from awareness events would have reduced the processing that could be spent for on other things. Depending on the choices I made when defining the DOM's replication parameters, I might pump out more data in movement messages than can be pushed through the a physical server's network interface(s) because of everyone being aware of everyone (remember the N^2 algorithm discussion from earlier?).

Well...gee after all of that can we get a number?

HeroEngine is designed for Massive Multiplayer games, easily accommodating thousands, tens of thousands or hundreds of thousands of players in a cluster (dependent upon the type of game, the skill of the team, and resource budgets allocated per player).

An individual area server instance (i.e. process) can be expected to handle hundreds or thousands of players depending on the what resource demands are per character for the typical activities performed there. For example, a "housing" area server instance (http://hewiki.heroengine.com/wiki/Player_Housing_Tutorial) where players generally sit around doing little to nothing and generally are not aware of each other could reasonably be expected to handle thousands or even tens of thousands of players. A battle ground area instance where PvP combat events run might only handle a few hundred (though here probably the issue will be more of a client one depending on the topology represented and number of characters a given client simultaneously observes).

So its quite reasonable that the answer varies where some area instances of your game might handle hundreds of players while others might handle thousands. Of course, if you have a game where each player controls 1000 AI characters the area server instance might only handle 10s of players.

The real question is, based on my game's budgeting of resources (How much is on average required per player? CPU, RAM, Database I/O, Persisted Data Size, etc), how many physical servers are required to service X players?

The good news is...in HeroCloud we handle the servers leaving you to concentrate on making a game, which is after all what you probably wanted to do anyway.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox