Introduction

The purpose of this article is to familiarise yourself with the core aspects of the TGB Platformer Starterkit. The basic interaction with core systems will be explained here in brief, while more detail about specific elements can be found in the script comments of the individual script files. After reading this article, you should have a good understanding of the main concepts of the kit.

Actors and Platforms

In platform games, the user controls a player character that moves around in and interacts with the world and its inhabitants. In the starter kit a character is called an "Actor". In this kit, actors are a shell which does not do anything unless they are told to using a "Controller". There are two types of controllers provided in this kit, a Player Controller and an AI Controller. Player controllers are used by actors which the user has the ability to move and AI controllers are used by the computer to control (more detail will be explained in the next section).

Any actor, whether it is user controlled or controlled by the computer, interacts with surfaces called "Platforms". Platforms act as the ground or walls which help the user move throughout the world. There are two types of platforms, Solid and One-Way. Solid platforms prevent the actor from moving when a collision is detected, whereas one-way platforms only allow the actor to collide with them under certain conditions.

This kit uses the TGB 1.5 system of behaviors to specify what type of object a scene object is. Adding an "ActorBehavior" to an object turns it into an actor and similarly a "PlatformBehavior" turns the object into a platform.

The "PlatformBehavior" acts as a parent behavior for more advanced types of platforms that actors may encounter. Two additional types of platforms are included with this kit, "FallingPlatformBehavior" and "TrampolineBehavior". The basic platform behavior acts as a container for advanced platform functionality, like the two provided with the kit. The platform behavior notifies any attached platform types that an actor has landed or left the platform.

Controllers

As mentioned above, controllers must be added to actor objects which are used to give "life" to the possessed object. Without a controller, the actor does not know what to do. It will still be able to interact with the world and receive damaged, however, it cannot move!

It is important to separate the brain from the body. If the controller was built into the actor then it would be difficult to program different types of AI, not to mention the need to create a new type of actor for a user controlled character. It also allows you to relinquish control of a player controller to the computer when necessary, for example: in a cutscene. As a general rule, whenever possible, simplify!

Actor Animation and Sound

The actor's animation manager used in the starter kit is perhaps the most complex of the core systems used. It is based around a finite state machine (FSM) which handles transitions between predefined states used to animate the actor.

There are 15 animation states used in the kit, and more can be added easily.

    1.  Idle
    2.  Run
    3.  RunJump
    4.  RunFall
    5.  Slide
    6.  Jump
    7.  Fall
    8.  ClimbIdle
    9.  ClimbUp
    10. ClimbDown
    11. ClimbJump
    12. Action
    13. Damage
    14. Spawn
    15. Die

The animation manager was designed to make implementing animation and sound for your actors as simple as possible, provided you are consistent when naming your datablocks. For each of the above states, an animation can be specified by you, or you can let the kit attempt to find the most appropriate. The animation manager uses the following naming convention:

    <Actor Type><State Name><"Animation" / "Sound">

The "Actor Type" should be different for each of your actor types. The "State Name" is from the list of the 15 states above and the "Animation" or "Sound" suffixes depend on what type of datablock it is (animation, or sound).

The FSM also handles animation transitions between states and uses the following naming convention:

    <Actor Type><State Name From><"_to_"><State Name  To><"Animation">

Note: Transitional animations cannot loop, they must play only once.

Animations and sounds are initiated when the FSM called a new state. If an animation or sound is looped, it will cease playing once the FSM changes to a new state. The animation manager also supports "step sounds", where you can specify which frame(s) of an animation a sound is played on.

Despite the manager favouring the use of this convention, you are able to specify animations for each state manually. However, transitioning between animation states is not possible unless you use the "Actor Type" and "Animation" suffixes.

It is difficult to explain the above, so an example is provided: This kit has two actors, a dragon and a drill. If I were to create the animations for the dragon actor, then I would use "Dragon" as my Actor Type. The animation datablock for the "idle" state would be called:

    "DragonIdleAnimation"

If I wanted the dragon to make a sound when it was in the idle state, I would also create a sound datablock called:

    "DragonIdleSound"

If the dragon was previously running and was now idle, the transition animation would be named:

    "DragonRun_to_IdleAnimation"

Object Types

Rather than having collision groups being linked with numbers, the kit implements a hierarchical labelling system. Basically, objects can be set to a particular type, defining the way other objects interact with it. It is used throughout the kit and is an easy way of dealing with conditional collisions. The hierarchy comes into the equation when we want to deal with different types of objects, which may be related in some way. Here is an example:

    ObjectMethod::addObjectType("Fruit  Apple");
    ObjectMethod::addObjectType("Fruit  Orange");

Both Apples and Oranges are Fruit. If an object is set to collide with Apples, it will collide with objects set to either Fruit or Apple, and will ignore Oranges. Similarly, if an object is set to collide with Oranges with will collide with Fruit or Oranges, and ignore Apples. However, if an object is set to collide with Fruit, it will collide with Apples and Oranges.

This system was designed to reduce the number of potential collisions the engine may process, which in turn reduces system usage and allows for more triggers and objects to be placed in a scene. It also allows you to group objects by name rather than by number, which can be quite confusing when you have a large group of object types.

Pick-up Items

This kit provides the framework for pickup interaction between pick up objects and actors and also has a basic inventory system enabled. Collectable items are static/animated sprites that when added to the scene has a trigger placed on top of them. The conditional collision system implemented in the kit prevents enemy actors from picking up objects for players.
Collectable objects can either be added straight into your game, or you can use spawn points to add them. More about spawn points will be discussed bellow.

Spawn Points

Spawn Points, spawn, things. They will generate the target object either in intervals or when the previously spawned object has been removed from the scene. Minimum and maximum distances are defined so that objects aren't spawned when the camera is too close or too far away (saves on resources).

If an actor is created through a spawn point, its direction will be initially set to the direction of the camera and it will attempt to play its spawn animation sequence. This is done so that enemies will always at least try to head in your direction initially, before being clobbered over the head ;)

Any object that has been spawned can be automatically despawned. Spawned objects will be despawned when the camera is 1.5 times the maximum spawn distance from the spawn point, provided that both object and spawn point are in the same direction from the camera.

If you want to force a spawn point to generate an object regardless of the number of objects spawned, or the spawn interval, you can just use the script:

    %spawnPointBehaviorRef.spawnTarget(true);

Spawn Points also interact with checkpoints, recording the number of objects spawned when a checkpoint is saved, and reverting to that number when a checkpoint is loaded.

Checkpoint System

A checkpoint is a collectable item that records the respawn point of an actor. It also uses these two global functions to save and load the scene's state at the time of collection:

    saveCheckPoint();
    loadCheckPoint();

When a checkpoint is saved it will find all of the spawn point objects in the scene and record the number of units that spawn point has generated. Saving also records the items in each of the actor's inventories.

When a checkpoint is loaded, it will revert all of the spawn points to the saved quantity and despawn any currently spawned objects. Loading also restores an actor's inventory, ensuring that no newly collected objects are still in there and that old objects are restored.

The save and load functions can be called at any time, as they are global functions, but are only called in the kit when a checkpoint egg is collected or when the player dies (respectively). These functions will not save and restore miscellaneous items in the scene that are not generated using spawn points. This allows you to create easter eggs, or one use only objects in your game.

Conclusion

I hope that you now have a firm grasp on the contents of this kit and are now ready to either start creating a demo level, or a full blown game. I wish you the very best of luck and sincerely hope that this kit will help you in your endeavours. If you have any questions, feel free to post them on the forum or on the wiki.

I would also like to give a huge shout-out to the GG team, in particular Derek Bronson and Thomas Buscaglia. Without their assistance I would not have been able to bring this project to life.

Phillip O'Shea
(Lead Designer)