Area architecture

From HEWIKI
Revision as of 14:25, 20 June 2011 by HE-NICK (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

This page covers information about how area geography works in a conceptual manner. To get hands-on in creating an area, see Building Areas Tutorial, and for more technical information about how Area Server processes work, see Area Server.

Areas as Non-Linear Space

Currently, HeroEngine uses a concept of geography representation known as Non-Linear Space. Essentially, the world is subdivided into geographic chunks of arbitrary size. The non-linear part comes from the idea that the physical placement relationship between any two areas is also arbitrary.

For example, in this illustration we have four areas. Each is arbitrary in size, and all are independent of each other:

AreasAsNonLinearSpace.jpg

Connecting Areas

Areas are linked together to create the illusion of a physically contiguous space. This is done by creating junctions at key points in the terrain to link them together. Here, they are represented by circles:

AreasLinkedToCreateIllusionOfContiguousSpace.jpg

Notice that the main connections between areas 1 and 2 and 1 and 3, where they meet at the border, represent a typical physical connectivity (neighboring areas). However you can also see that areas can be connected in more unusual ways:

The connection marked A, represents a non-linear connection which doesn't map into the physical world as we know it. One could think of it as a teleportation, although it doesn't necessarily require a teleportation effect. Notice that Area 4 doesn't map into the physical contiguous space as laid out by areas 2 and 3, yet can easily be connected as indicated by C and B anyway.

Arbitrary Geographic Space

The benefits of this free-form connectivity is that you can treat space as an arbitrary continuum. So large spaces can exist inside of small spaces, spaces can wrap back around on themselves, and so forth. In many cases this can be used to create convincing illusions of tremendous space without having to create all that space. For example, typically the insides of buildings have to be created extra-large to account for the "over the shoulder camera" and other factors. But this causes the outsides of buildings to have to be unusually large as well. But with non-linear space you can separate out these concepts of space... making the outside normal size and the inside larger. This can be used to have large dungeons underneath modest sized keeps, that then provide an underground travel to other parts of the continent even though the distance traveled doesn't map 1-to-1 with the surface (aka, a short-cut). Essentially, this gives your designers the freedom to do things that make sense for game-play purposes even if they don't map entirely to the real-world physical expectations.


Space Right-Sizing

Another critical benefit of non-linear space is that you can utilize it's arbitrary nature to freely modify your world topology after you release the game. This is a key benefit over the rigidly defined contiguous map model. The primary use of this is to dynamically adjust your world to the unexpected usage patterns of your players. For example, consider this situation:

AreaSpaceRightSizingOriginal.jpg

Here we have four areas connected in a fairly conventional relationship (neighboring areas). Now, let's presume that for some reason (due to unexpected player usage patterns), there needed to be an whole new section of terrain between areas 2 and 4. With our non-linear space paradigm you can simply "slide" area 4 over and insert the extra needed territory like this:

AreaSpaceRightSizingAdjusted.jpg


The insertion of Area 5 was easily accomplished by adjusting the splitting the linkage between 2 and 4. Note that all existing players will still login to where they were located before the insertion (be int area 2 or 4). In other words, the land would not suddenly "shift" under them in anyway. But when they travel back towards the other area, there will suddenly be this new space between. Also notice that the connectivity between Area 3 and 4 did not have to be modified because of this new space. Again, this was possible because of the non-linear space paradigm of HeroEngine.

Area Instancing

Of particular value is the fact that any Area can be instanced in any way that is desireable. For Areas that make up the "common" space, it is probably suitable to have one instance of each area. But you can also, at any point, make a decision that an Area will become Instanced. This is useful for both Instanced missions/quests, but also for common areas where you need to adjust to unexpected overpopulation situations.

For example, in this scenerio, Area 2 was an unexpected hub of activity. So the decision was made (even after release) that it should be instanced with players divided between the available instances in a CoH style:

AreaArchitectureInstancing.jpg


You have complete control over how instancing takes place, how it is presented to the user, the heuristic used to divy up players and spin up new instances (users can choose themselves too). That is all under HeroScript control.


Instanced Areas for Missions The other major use of Area Instancing, of course, is Instanced Quests and Missions. Because instancing of areas is a natural characteristic of HeroEngine, it is easy to spin up Instanced dungeons or other scenarios. This let's you easily create defined starting conditions, easily segregate players during these adventures and so forth.

Perhaps more importantly, other features of HeroEngine support the concept of Instanced Missions/Quests at a deep level. For example, a mission usually has a lot of game-play states: Which doors were unlocked, what chests were looted, what bosses defeated, etc. This information can be expressed using HeroEngine's Area State system. But what happens if a party of adventurers logs off before completing a mission? What do you do on their return? With HeroEngine you can serialize the Area States and store them with the character who owns the mission (for example). Then when the player returns and reinitiates the mission, the Area States can be restored to the state they were saved at! This makes sense, of course, only in an Instanced Area because that represents a private version of the mission.

Reference Frame Solution

Another important benefit of the Non-Linear Space approach is that it solves the numerical precision issues related to floating point values over large ranges. In a continuous space environment, as characters move farther and farther from the origin of (0,0,0) floating point values lost their precision. If this is taken too far, eventually very undesirable visual artifacts will result in character and object motion and animation (jittering unhappiness!).

The solution for this is to keep your physical world size limited (which many MMOs do because of this) or utilize complex reference-frame shifting schemes. But in HeroEngine, each Area is it's own reference frame with it's own origin. So building your world out to arbitrarily large sizes is not a problem.


Contiguous Space

In a design that desires a contiguous topology to the world surface, HeroEngine's Non-Linear Space paradigm may seem a poor fit. But, in reality, you can achieve most anything you want with this approach by simply being clever in your world building. Here is how you'd do this:

Currently, the limitations are that no more than two Areas are loaded into the client any given time. As you approach the connection between two areas, the other area is loaded asynchronously in preparation of the crossing. Only one area is every actually "active" on the client, and the player is only actually located in one area at any given moment. The illusion of a contiguous space occurs because both areas share a common bit of geometry which represents the link between the two areas.

The geometry can be virtually anything, like a building or a mountain pass, or windy city street. The limitation is that it has a shape that creates a space in them middle where you cannot see directly out to either side. When the player gets into this spot, they are transfered to the other area. Because the geometry is the same in each area, the switch is invisible to the player!

Here is an example of just such a transition piece for a medieval city environment:

AreaArchitectureTransitionPiece.jpg

Here it is from the top view:


AreaArchitectureTransitionPieceTopView.jpg

And from the player's point of view:


AreaArchitectureTransitionPiecePlayerView.jpg

The transition space is easily disguised by your artists through clever use of geometry. Here an massive wall separates two areas with a gatehouse serving as the transition piece:

AreaArchitectureTransitionPieceGate.jpg

In Hero's Journey we use caves, passes, fallen giant hollow trees, city streets, dungeons and other means of create a lot of variety in these transition pieces. Players are never aware of them directly.

Multiple Junctions Between Areas

There can be as many junctions between the same two areas as you like. But each has to conform to the above requirements. The point, of course, is that along any given border between two areas you can have many ways to "get across", not just one.


Flying Across the Terrain

Naturally if you would like to have flying mounts, or something of this nature, the junction requirement can be a tad restrictive. Where as with land-based travel it is easy to block movement with walls, buildings, mountains and such, a flying creature can just bypass all of that. So the question is, how could you handle this in HeroEngine:

One way is to have flying having altitude limitations. Therefore you can create large mountain ranges that block travel (and sight-lines) between areas. Then create mount pass (or gaping caves, or other interesting means) to serve as junctions between areas. This is the most straight-forward approach. It works especially well if flight is not free-form (in other words, it is on a rail). If it is free-form, it will still work but you have to be more careful with your level design.

Depending on the limitations you are willing to accept, you can do this sort of game play today.


See Also



Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox