In MMOs instancing generally refers to the practice of running multiple copies of a "area" in the game world, to which a subset of players are connected for their play experience. As players move around in the world, they may be given the option to go to Instance 1 of the Capitol City vs Instance 2 of the Capitol City or they may be shuttled off into a private instance for their group to complete a mission/quest. City of Heroes uses this style of instancing. Many other MMOs use instanced dungeons to support "raids" of large groups of players in an "epic" environment.
There are a number of reasons that instancing is common in MMOs:
- Distribute the population into managable subpopulations
- Distribute the processing load
- Rendering considerations relating to the number of characters
- Provide content protected from outside interferance
The development environment of HeroEngine is a highly instanced environment, where many instances of a specification of a physical location (its geometry and assets) runs each in its own thread. The specification of a physical location in the game world is called an "Area" and the instantiation of that specification is call an "Area Instance". Even when using HeroEngine in a "seamless" world mode, behind the scenes the engine is using numerous area instances each in charge of manageable chunk of the physical location.
One of the greatest challenges of instancing in HeroEngine is that any given Area Instance knows little to nothing about another Area Instance even if they share the same specification. Each instance maintains its own view of its specification and the objects loaded into its local GOM, changes in one play instance are not propagated nor are they persisted (the exception being to "root" nodes like the account/character which handle their own persistance). Communication between Area Instances is asynchronous.
HeroScript is uniquely empowered as a scripting language to take advantage of the instanced nature of the environment to spin up Area Instances to provide chunks of processing.
- This is a loaded word, it means too many things to be generally useful in discussion. Server may mean a "world", an Area Instance, a physical machine and so on. This is a good word to just avoid to prevent confusion.
- In the typical player parlance, this is a "Server". The login proceedure probably will allow them to choose a "world" in which they may create a new character or play an existing character on that world. Each world is represented by a special areainstance (areaid 0 areainstancenumber 0) that is always running and is commonly called the world. The world is the ONLY location that knows some important data with certainty, such as where all characters are and what areainstances are running.
- An area is the collection of data and processing, it may or may not represent a physical location (assets that result in geometry rendering on the client). Every Area is assigned a unique id, and may be considered a specification from which 0...N Area Instances may be spun up.
- Area Instance
- Area instances are instantiated versions of an area. The have both an Area ID and an Area Instance Number by which they are identified. Only the EDIT instance of an area saves changes, the edit instance is Area Instance 0 for any given Area ID. Every Area Instance runs on its own process (thread) and may or may not be running on the same physical machine as any other instance of that Area. Within a given Area, Area Instance Numbers are unique. Area Instance Numbers MAY also be used in another Area's Area Instances but generally are unique. (i.e. Area 444 Area Instance Number 12 is the only instance 12 of area 444, there could be an Area Instance Number 12 of area 555)
- Lack of temporal concurrence (i.e. absence of synchronism).
Asynchronous programming typically splits an operation into two parts; the first accepts a request(with parameters) starting an the asynchronous operation, the second supplies the results when the operation is completed. The first part, in addition to handling the start of the asynchronous operation, may optionally provide an object that will ultimately receive the results.
In HeroScript, results generated by interfacing with the asynchronous C++ function calls are generally returned to a script specified as a part of the input. For HeroScript Required Systems results may be returned directly to a script, the requesting object, or a proxy object that knows how to handle the results depending on the implementation.
|Each Area Instance is running its own HeroMachine, each machine is limited to knowing the data loaded in the local GOM for the Area Instance.|
The HeroMachine (virtual machine in charge of running HeroScript) processes HeroScript synchronously where one instruction must complete its operation before the next one may be started. The synchronous nature of the average HSL script simplifies the learning processes allowing relatively unsophositicated programmers to work comfortably in the environment.
However, as soon as a script requires information unknown to the local GOM a developer is introduced into the basics of asynchronous programming by virtue needing to utilize messaging between Area Instances to request information known to a different local GOM. The Inter-Process Communication mechanisms most commonly used are Remote Call and Replication.
See also: Inter-Process Communication
Some operations from HeroScript are inherantly asynchronous; disk I/O, intra-instance messaging, and server-client messaging. Other HSL systems may build in their own asynchronous mechanism to split up the processing of a large task across a period of time or multiple area instances.
Inherantly Asynchronous Operations
- Messaging (Remote Call)
- Loading Nodes from the Database (Arbitrary Root Nodes)
- Disk I/O from HeroScript
- Login Process