Vehicles Tutorial

(Redirected from Vehicles)
Jump to: navigation, search

He advanced.png


Before working through this tutorial, you should be familiar with:


In this tutorial you will:

So, what is a vehicle?

HeroEngine is agnostic to the behavioral characteristics of the "character" a player controls. That means the player can control a female elf, bear, car, plane, train, dragon, spaceship or a piece of paper and it does not matter to the engine. What does matter, is that a controller exists that understands the environment and can make the appropriate decisions to trigger the desired "character" animation based on the player's control input. HeroEngine comes with a character controller designed to be exhibit the common behavioral characteristics of a Massively Multiplayer Online Roleplaying Game, behaving much in the manner you would expect of the character controller in World of Warcraft and other similar games.

Implementing vehicles ultimately is simply the creation of new character controllers that have the behavioral characteristics desired.

The addition of additional types of character controllers (i.e. vehicle vs standard MMO biped controller) should be a deliberate decision based on analysis of the costs and benefits. If the primary benefit is it would be "cool", you may wish to reconsider as this is a classic way for a product to die of feature creep. The use of Vehicles in a game design should provide a sufficiently compelling game-play experience to make the time and effort invested worthwhile.

What problems does this tutorial address?

What problems does this tutorial not address?

Design Considerations

Why Have Vehicles?

Vehicles can provide a different twist to what otherwise is fairly standard game-play elements. In some games, vehicles provide alternate modes of play for the user to explore providing new strengths and weaknesses. Some games replace the traditional biped character with an alternative that is appropriate to the game environment. For example, spaces games often abstract the idea of character out leaving the player controlling/advancing their ship without trying to showing the crew.

Some questions for designers:

It is important to make sure that vehicles have a defined purpose in the game design with corresponding effort invested in their development or they will almost certainly feel gimmicky or second class.

Characters and Vehicles, the Best of Both Worlds!

Well, if vehicles provide alternate modes of play and interesting twists to game mechanics then why not have vehicles AND characters? That way we have the best of both worlds right?

In general the answer is no, making the game-play experience compelling for two or more different modes (e.g. characters and the cars they drive) is like making two or more games simultaneously.

Space games are somewhat infamous for failing here, all the interesting stuff occurred while you were out on a mission and then when you returned to your "base" there was paperwork and lectures waiting for you. The effort that went into creating the interior environments, character interactions, and so on was in many ways wasted because its only purpose is to read the story to you and allow bookkeeping tasks. That is not to say that it is not possible to have bimodal (or more) designs that are fun in all modes...but it takes time and effort.

Consider whether or not it is really important to a game design to initially release with multiple modes, or whether additional modes might be added on later. Star Wars Galaxies is an example of a game that released with one mode (controlling a biped character) and later adding another mode in an expansion (spaceships)

Tools vs "Characters"

In the game design, consider whether vehicles are tools to be used and discarded or "characters" the player advances whether through "leveling" or purchasing improvements. In games like Halo, vehicles are tools to be used (or not) that are discarded when "killed" or the game-play forces the player to transition modes. Other games make the vehicle a centerpiece of game-play allowing the player to customize/advance them in a variety of ways (faster, turns more quickly, different weapons, customized paint schemes, etc).


HeroEngine's character system is capable of allowing customization for vehicle "characters" using the Dynamic Character Parts System just like biped characters. Allowing the use of Dynamic Texture Banks, Rules based substitutions/selective display, and swappable character parts. Since there are trade-offs to using these features, you should decide how big a part customization plays in the game design and how many options should be available to players.

Customization of "character" vehicles (as opposed to tools above) introduces variety and uniqueness, which in turn can help maintain player retention. On the other hand, care should be taken to watch the scope of utilizing these features as it can explode the art budget and increase the install/download sizes significantly.

Architectural Considerations

Inverse Kinematics

Inverse Kinematics (IK) is a process that determines all of the parameters required to adjust the joints of an animation RIG to achieve a desired position. For example, adjusting the mechanics of a car so that the wheels all touch the ground on uneven terrain. Massively Multiplayer games generally do not use IK because it is relatively expensive in terms of CPU utilization, even those games that do you use it tend to restrict it to a small number of actors.

HeroEngine, like most engines developed for Massively Multiple Online Games, does not support IK.

Scale and Distance are Relative

A common mistake when implementing space games is forgetting that scale and distance are all relative. The player has no ability to discern that the "massive" space station is forty kilometers or four meters long. The reason this is important is that game engines generally restrict models to sizes of less than 65k polys and desired graphics performance and minimum specs generally dictate less than that. Consequently, common techniques such as scaling models down and slowing camera speeds are used to provide the illusion of distance and scale.

Additionally, floating point resolution is an issue when dealing with significant distances. Imagine a space game representing a volume of millions of light-years of space, a planet much less a spaceship is so tiny in comparison that issues of floating point resolution come into play. For that matter, simply representing the volume of space encompassing our solar system is problematic as floating point errors creep into animation and other systems as they move a significant distance from the origin. HeroEngine's areas all have their own frame of reference, but that can not help you if your area is representing seven billion kilometers (the solar system) or worse the universe.

Also, representing massive distances (while accurate) tends to result in boring game-play. Most space games (like science fiction books) introduce faster-than-light travel within solar systems and near-instantaneous travel through "warp gates", black holes, etc to eliminate the dull and tedious portions of space travel.

Ultimately, the only thing that matters is that the player experiences the appropriate feeling of scale/distance.


Massively Multiplayer Online Games typically perform collision tests between a controlled "character" and the environment, but generally not between the characters of two different players. There are a number of reasons for this ranging from game-play (not allowing one player to block access through a doorway, etc) to performance where collision tests and physics simulation queries are among the more expensive operations. The default character controller performs two different types of collision tests one to get the ground beneath it (and its normal) and another continuous swept collision test to determine whether or not animated driven motion has resulted in a valid place for the character to be placed (and/or make adjustments as necessary).

// Performs a swept collision test from specified start position to end position
external function SweepCollideCharacterPhysX(char as NodeRef of Class HBNode, start_position as Vector3, end_position as Vector3, volume_width_in_units as Float, volume_height_in_units as Float, max_step_height_in_units as Float, max_walkable_slope_degrees as Float, test_using_capsule as Boolean, enable_debug as Boolean, final_position references Vector3, collision_occurred_during_sweep references Boolean, collide_normal references Vector3, standing_possible_at_final_position references Boolean, stand_normal_at_final_position references Vector3) as Boolean  
external function RaycastPhysX(v1 as Vector3, v2 as Vector3, intercept references Vector3, normal references Vector3, walkable references Boolean) as Boolean  
external function RaycastPhysXNode(v1 as Vector3, v2 as Vector3, intercept references Vector3, normal references Vector3, node references NodeRef) as Boolean
external function GetGrounding(paramPos as Vector3,checkAbove as Float,walkSlope as Float,groundY references Float) as Boolean

The character controller for vehicles might require additional collision sensors (ray-casts or swept volumes) keeping in mind the cpu cost to only perform the checks when necessary.

For example, consider a space game where there are relatively few objects in extremely large amounts of open space. This would be a situation where no collision tests should be performed at all until something is sufficiently close that it might matter, which could be done by providing spaceships with an collision proximity awareness range (in Spatial Awareness). When the ship is notified of the presence of objects within its awareness it could start to perform the additional collision tests.

Game-play vs Simulation

There is often a difference between fun game-play and realistic simulation, make sure you know which one is appropriate (or where the balance between them lies) for the game design. There was a attack helicopter game a while back that achieved a very realistic simulation, but was sufficiently difficult to play that it was sometimes hard to say it was fun. Understanding the target market and play testing are the keys to creating the right controller for the game.

Models vs Characters

There are several potential choices available:

Choosing the appropriate model/character type generally boils down to the features required for vehicles in the game design. For example, the need for sophisticated animation of a skeleton dictates the need to utilize animated characters.

Static vs Animated Models

For some types of vehicles (spaceships in particular), there may be no need at all for animations allowing all movement to be controlled by the controller directly. Static models have significant advantages in performance over animated characters (and a lessor one over animated models), but lack (obviously) the ability to play an animation. An animated model is capable of playing only a single animation (stop/start/pause), but that might be sufficient for some types of vehicles in certain game designs.

Additionally, static and animated models do not utilize the Dynamic Character Parts System and thus lack the customization features it supports.

Utilizing Static or Animated Models for the player's "character" requires additional script effort as it diverges from some of the default mechanics that expect the existence of a _CharacterAppearance node which is used to generate the client-side visualization.

Animated Characters

Animated characters allow for much more complicated animations to be achieved, supporting blending and channels of animations with sophisticated scripted control over the sequences played. Animated characters are much more resource intensive than static or animated models.

Static vs Dynamic Characters

Related to the Static vs Animated Models discussion, there are performance advantages to utilizing static characters over dynamic characters though static characters lack the customization options found in the Dynamic Character System.


Described below are rough descriptions of some basic systems and architectures to express different vehicle types, they concentrate on the use of Characters as its probably most designs will choose to take advantage of more complicated animations supported by characters and (optionally) the customization features of the Dynamic Character Parts System.

Character Controller Replacement

Other than planning, the initial step held in common in creating vehicles is the creation of one or more character controller replacements. The character controller is HSL based and is used to translate gross navigational decisions (move forward) into the appropriate settings to cause a character to move forward whether through animation or translation by HeroScript. HeroEngine's character controller is called the Advanced Customizable Character Controller (ACCC).

The basic requirements are the creation of a new controller class and modification of the $ACCC system node to instantiate the alternate controller when appropriate.

What major components are involved in alternate character controllers?

The existing default character controller provides a class (HeroEngine_ACCController) and script (HeroEngine_ACCControllerClassMethods) that serve as an example of a typical MMO biped character controller. However, it is improbable the implementation and its DOM definitions will be directly applicable due to the difference in types of information and behavior between bipeds and vehicles.

Dynamic Character - Car

This section will provide an general overview of implementation of a car as a dynamic character for some kind of racing game.


We need to start by first getting a rough idea of what functionality we need:

Car Performance Characteristics

Our hypothetical racing game will support differentiation between different cars performance characteristics in additional to the visual differences. Additionally, the player may be able to improve those through the purchase of more advanced "parts" and tuning services. All of this means we need a way to define the parameters for our cars as well as their the art. We will leverage the Spec System for our data store, allowing for the easy creation of new car specifications and modification of existing ones.

While detailing the implementation of a Spec System is beyond the scope of this documentation, lets rough out some of the details:

The specification for a car needs data such as:

carManufacturer - The name of the company that produced the car
carModel - The model of the car
carYear - The year the car was produced
carModelDescription - Description of the car model for presentation to the player in UIs
carSpecification - The character specification tells the engine where in the repository it will find the various art files it needs animations, models, textures, etc. (see also: Add Creature to Engine)
baseAcceleration - The base acceleration of this model of car
maxAcceleration - The maximum acceleration allowed for this model of car. Parts and engine tuning modifications can not exceed this value
baseDeceleration - The base deceleration for this model of car
maxDeceleration - The maximum deceleration allowed for this model of car. Modification from Parts can not increase this value above the maximum
baseTurnRadiusDegrees - The base turning radius in degrees
maxTurnRateDegrees - The maximum allowed turning radius in degrees for this model of car. Increases from Parts can not increase this value above this maximum

The "character" for a car is the object that represents the current statistics for the character and would have such data as:


Which would contain the modified values for a specific player's customized car taking into account "engine tuning" and better "parts" bought.


There are three major areas to cover:

The major animations for our car are related to the wheels rotating and turning. For the rotation of the wheels we will use two animations (low speed vs maximum speed) combined in a Speed Blend allowing the controller to provide input into the blend amount.

To turn the wheels we have a couple options; creating animation channels (track masks) to play the turn animations on top of the rotation of the wheels, or we can utilize Rotate Bone sequence ability to manipulate the bones to turn the wheels.

The animation agent is more complicated as it needs to agree with the character controller on the inputs it allows and their valid values for those inputs. However, we do not need to know everything up front as we can expand the agent over time. There are some obvious inputs however that we can start with:

// Animation Agent Scripts input declaration section
  BaseState = Idle, Turning, Moving
  MoveDirection = None, Forward, Backward
  TurnDirection = None, Right, Left

Visual Customization

The dynamic character parts system requires we identify the "slots" (Dynamic Character Primer) in which parts may be placed. Additionally, we have the option to describe texture layers to change out the textures for the parts. For the purposes of our example we create the following divisions and slots:

When exposing the slots to players in a UI, it is common to restrict the allowed modifications and linking others together (for example you may choose to not allow the user to specify different types of wheels for each wheel). Additionally, there might be some modifications that are available only if the player purchases them through micro-transactions or in-game currencies.

Character Controller

The character controller is one of the larger parts of this process, and needs to implement the behaviors (in a data-driven fashion to account for our engine tuning and parts enhancements to performance) we want for our car.

Character controllers generally handle these types of behaviors:

translation of behavior commands into gross navigational decisions
pre-animation processing
evaluation/adjust gross navigational decisions
transformation of gross navigational decisions into inputs applied to the animation agent
post-animation processing
adjusting position based on
collision, gravity, impulses, grounding
adjusting rotation based on
turn rate

See Also

Personal tools