Template7

From GameStudio Wiki

This document gives an overview of the 3DGameStudio/Lite-C: Template7 system. For more detailed information on using Template7, goto t7_Doc, and/or download the T7 Tutorial from the download page.

Goals

“Create a 30-minute (or 30-second) experience. A new user should have their game up and running without having to read a manual.”

• Allow rapid project development.
• Entire games can be created with no coding or scripting.
• Users can modify game elements using only GUI tools.
• Advanced users can extend/modify the template7 system using lite-c.
• The template7 system can be added to existing lite-c projects.
• More advanced users can extend t7DLL and/or write their own editing tools.

Concepts

Template7 extends the core A7 engine to make it a Data-Driven system based around Game Entities (GEs) and Components (CMPs).

Game Entities (GE)

Game Entities are entities (models, sprites, WMBs) that are controlled (in part or in whole) by t7.

GEs can be created automatically from data, made by other GE, or by calling “entity_add(..)” with the entity as an argument.

In addition to managing the entity, GEs can have zero or more Components attached to them.

Components (CMPs)

Components are self-contained logic units that add features to GEs.

For example, the “PhysBiped” CMP makes the GE move like a biped. The “Animate” CMP animates the GE depending on its state.

Use

GEs can be created several ways. The traditional way of adding and editing entities using WED works the same as Template6:

1. Create a level and add Template7 project using Project Manager.
2. Add a entity in WED and attach one of the available t7 behaviors using the Property dialog.
3. Edit behavior using the Behavior dialog.
   

The key difference is that the t7 lite-c actions contain logic and the data used to create the GE is stored in a separate data file.

For example, the t7biped_player action looks like this:

/// action: t7biped_player
/// title: Player (biped)
/// desc: Simple biped player behavior
/// Should one be one per level.
/// behavior: biped_player
action biped_player()
{
    wait(1);// allow the entity to load
    if(!entity_add(my))// add as GE 
        return;

    camera_set_target_ent(my);// make this the target of the camera system

    // additional game logic can follow...
}

The “behavior” tag in the header points to the data structure containing the CMPs and editable fields:

	<Behavior name="biped_player" class="bipedEntity" group="Player">
		<Doc>Player controlled avatar.</Doc>
		<Component name="health">
			<Edit name="health" value="100" /> <!-- start with 100 health -->
		</Component>
		<Component name="control">
			<Edit name="type" value="joypad" />
		</Component>
		<Component name="physBiped">
			<Edit name="xForce" value="8" />
			<Edit name="yForce" value="5" />
			<Edit name="aForce" value="5" />
			<Edit name="jumpHeight" value="30" />
		</Component>
		....

The separate data structure is easier to maintain, allows for easy editing, and allows reuse.

When the user edits the entity using the Behavior dialog, those edits are stored in another data structure:

		<Entity name="test_mdl" behavior="biped_player">
			<Component name="health">
				<Edit name="health" value="75" />
			</Component>
		</Entity>

The name is the link.name of the entity and only the values which the user changes will be stored. This saves space and frees us from the built in limits of WED.

When an entity is loaded in the game, its action will call entity_add(my) which will create a GE and look up the data structure for the entity. The data is used to load CMPs and starting values into the GE.

The GE will be updated once a frame until it is removed.

Controlling GE

Entities attached to GEs can still be used like normal entities (although some things, like directly moving or removing an entity isn't recommended). Plus they can be controlled by sending it messages (edits and actions).

For example, the following is a simple moving biped:

/// action: t7_biped_dumb
/// title: Dumb AI (biped)
/// desc: Example of a dumb AI biped.
/// behavior: biped_baseAI
action t7_biped_dumb()
{
	wait(1);		// allow the entity to load
	entity_add(my);	// add as GE 

	while(my)
	{
		entity_edit_vec(my,t7EntityEdit_setForce,0.5,0,0);	// move forward half speed
		entity_edit_vec(my,t7EntityEdit_setAForce,0.25,0,0);// in a circle
		wait(1);
	}
}

In this example, entity_edit_vec() sets the linear and angular forces of the GE. These forces are used by CMPs in the GE that move and animate the entity.