Home

A simple start.

Introduction

Racer is starting to become a more generic game engine rather than a pure racing game. A component & entity system is being built in which allows for the creation of more flexible game rules and objects.

Terminology

First we need to define a couple of terms relating the Racer's game engine side:

• Game - a collection of archetypes and scripts for a specific game.
• Component - a piece of data, specific for a certain part of behavior/functionality. Think of a 'mesh' component for example, which holds a 3D model.
  Racer v0.9.0RC8 extends components to be used at any abstraction level. For example, a simple mesh component just contains a 3D model. Making a grouping of components to create a mesh that for example moves around is also a component (but this time a group component). As an example, consider a movingball component, which contains a ball mesh component, a script component to move it around, and an audio component to make sound when it hits something. The movingball itself is also a component, but at one higher abstraction level.
  You can continue this abstraction; add a bunch of movingballs (instances) and you get another component. You can work with component at varying levels of abstraction therefore.
• Entity - a group of one or more components. Together they form an entity in the world. Although you can use the term loosely, example entities could be cars, boats, a box, but also more abstract things which talk to the external world (external to Racer, that is; like a network packet receiver).
• Onyx - Racer's scripting language that looks much like C++ and is used to create logic. The future may also see support for Lua (which is more mature).

Obsolete terms (since Racer v0.9.0RC8):

• Behavior - logic (code in Onyx) that acts on one or components. For example, given a physics and a mesh component, a typical behavior would be to pass the physics position/orientation on to the mesh location before rendering a frame.
• Archetype - a template entity, used in quickly building useful entities in your track. A Racer 'track' can be seen as a 'level', which contains a number of entities (NPC or not).

More abbreviations you'll come acrsoss:

• EID - entity ID. These are just numbers to reference a particle entity. These numbers are normally unique and the same across all computers running the game.
• AID - archetype ID. A number for an archetype. Has become obsolete; archetypes are just components now.

Workflow

Roughly, a game is created using the following procedure:

• Create a game directory (i.e. c:/sims/racer/games/mygame)
• Create archetypes for the game (templates for useful entities that define component mixes). These go into games/mygame/archetypes/*. The archetypes are really groups of archetypes; one archetype directory can contain multiple archetypes, although they are normally quite related (for example similar game objects that do mostly the same thing). In an archetype (group) directory, place a definition.ini file which indicates the archetypes, defined mostly as regular entities.
• Register the archetypes for use in the game by defining them in games/<name>/game.ini under archetypes.archetype<n>, with <n> starting at 0 (i.e. archetypes.archetype0=balls means load games/<name>/archetype/balls/definition.ini and create archetypes for all those in definition.ini.
• In a track, in world.ini, create entities, possible relating to the archetypes defined globally for the game. It is also possible to create entities directly in world.ini, so to create custom entities specific to the track.
• In racer.ini, set game.initial to your game directory (i.e. mygame).

RPC - remote procedure calls

These calls are used to communicate events that don't happen often, such as the spawning of a player or NPC (non-player-character) object. For more information on RPC's, read this article.

Callbacks

Onyx scripts can contain functions, which are called when certain events happen. This allows the scripts to act upon events that happen in the game. Read more about callbacks here.

Subsystems

The game engine consists of C++ code (high-performance) and custom Onyx scripts that you can write yourself. Some built-in subsystems are exposed to Onyx, to be of assistance to the Onyx side of things.

Existing subsystems are:

• Base engine - a collection of functions that are useful to communicate with the basics of the game engine. Not really a functional group, more of a mix of useful calls.
• Entities - functions to work with the entities in the world.
• System setting/getting - the System is a unified tree of parameters and signals that point directly to values inside the engine. These can be used to get a close look at what's happening inside the engine. Onyx has hooks into the game engine to work with the system.
• Timelines - tracks contain a number of timelines, which are used to indicate a route through the scenery. These lines can be used with the timeline manager to detect entities crossing these timelines.
• Physics- rigid body functions that can be used with PhysicsComponent-type components. These interact directly with the physics engine inside the game engine.

Debugging

Debugging scripts is an important part of the development of a game. This article explains debugging with the game engine and Onyx in more detail.

Components (also called resources / assets in other game engines)

The game engine uses a more globally defined components database, stored in the components/ directory. This is currently a deep directory full of objects; the future will see a method to compress these into packages, to improve loading times and coherence.
These types of components exist:

• Fonts - postfix .font.
• Meshes - 3D models
• ...

File structure

This article describes the files used in the game engine. This can be useful to understand what goes on under the hood.

(last updated July 3, 2014 )