Tutorials/04Entities

From NeoAxis Engine Wiki

Enabling level design

Introduction

When talking about game development, you will find that commonly there are three separated roles you will need to cover in your development team. These roles are:

designers: They are responsible of defining the game in terms of look, feel and gameplay. This oftenlly divides into two steps: creating the design document (a huge document that describe how the whole game should be) and then, create the game levels to match the desired gameplay.
programmers: They are responsable of the code behind the game, they have to implement the mechanics required to achieve the goals defined by the designers. Also, as a programmer you will have to provide the designers with appropiate tools for level design.
artists: They are the ones that create the graphic assets required for the game, such as 3d model, textures, GUI, etc.

If your development team is huge, you will have several programmers, several artist, and probably a few designers. If your team is small, probably there will be people acting both as programmer, artist or designer. Even in some cases, a single "crazy" guy will do all the job.

In any case, you will need to understand that these different task belong to separate roles. Specially, when doing your programming stuff, you will have to keep designers in mind (even if you are the designer too). A good programmer will do his best to provide the designers with the objects they need to achieve the goals of each level, in terms of gameplay and playing experience.

NeoAxis provides a cool and powerfull mechanism that allow programmers to create objects that can be placed and configured by game designers. In this tutorial we are discusing how you should expose configurable properties on your game objects, and how to put them to use on Resource and Map editors.

Preparing for this tutorial

To follow this tutorial, you will need to download this file File:Tutorial04.zip.

The zip includes 3 new materials. Once you've got the zip file, you need to extract the folder "Materials" to the Data directory of the NeoAxis SDK, which depending on you local configuration, will be something like:

C:\Program Files\NeoAxis Engine Non-Commercial SDK 0.XX\Game\Bin\Data

As there is already two folders there with the same names, your OS or Zip utility program will may ask you if you want to proceed with the copy or extraction.

Once you are done, open Resource editor and check that you can preview the three new materials you have installed, go to Data\Materials\BreakOut and locate the new materials called bluebrick.material, redbrick.material and yellowbrick.material.

Design requirements for a BreakOut game

A good BreakOut game must provide lots of levels. Each of these levels must consists of bricks placed using different patterns in each levels. Also, several types of bricks are required to give the game more variety. To bricks will differ merelly on how many hits will they resist before getting destroyed. Also, to make more fun, some bricks will drop a power-up item when destroyed.

As a rule, there will be only three types of brick, the ones that resists one impact, the ones that resists two impacts, and the hardest ones that will take up to three hits. Each type will allways appear on a level with the same color, so the player will easilly identify the color with the resitence of the brick.

The color or resistence of the brick won't have nothing to do with the power-ups, instead they will be assigned by the level designer in the most convenient places. This way, most times the power-ups will take the player by surprise, but experienced players will try to remember the bricks that drop and those that don't.

Creating the brick object

We will be showing how the programmers can expose parametric functionallity using the Entity system of NeoAxis. These will enable game designers to expand the possibilities and combinations possible during gameplay, using NeoAxis editors, with no additional code.

We are creating an object called BOBrick that will represent an object of our game that can be destroyed with a certain amount of hits.

Locate the BreakOut folder of the GameEntities project. And create a new code file called BOBrick.cs inside.

Copy and paste the following code:

using System;
using System.Collections.Generic;
using System.Text;
using System.ComponentModel;

namespace GameEntities.BreakOut
{

    class BOBrickType : UnitType
    {
        [FieldSerialize]
        private int hitResistence;

        [Description("Hits the brick will ressits")]
        [DefaultValue(1)]
        public int HitResistence
        {
            get { return hitResistence; }
            set { hitResistence = value; }
        }
    }

    class BOBrick : Unit
    {
        BOBrickType _type = null; public new BOBrickType Type { get { return _type; } }
    }

}

In the above code, we are creating both the entity class BOBrick and its archetype class BOBrickType. The archetype mechanism of NeoAxis enable the game designers to determine how many variations of bricks will be available in the game.

In this example case, bricks will differ from one to another in how many impatcs they will ressists before getting broken and dissapear. To enable designers configure the number of desired impacts, we place a property called HitResistance inside the archetype:

        [FieldSerialize]
        private int hitResistence;

        [Description("Hits the brick will ressits")]
        [DefaultValue(1)]
        public int HitResistence
        {
            get { return hitResistence; }
            set { hitResistence = value; }
        }

NeoAxis uses Reflection to automatically save and load the properties defined inside the archetypes. For this mechanism to work you have to tag the variables you want to be saved and loaded with the [FieldSerialize] attibute:

        [FieldSerialize]
        private int hitResistence;

The HitResistance public property will be automatically accesible inside the Resource Editor, you don't need to, but is recomended to place a [Description("...")] atributte next to public properties, for a description to be shown on the properties tab on the Resource Editor. And using a [DefaultValue(...)] will be usefull to set the default value this property will have when the a new resource of this type is created:

        [Description("Hits the brick will ressits")]
        [DefaultValue(1)]
        public int HitResistence
        {
            get { return hitResistence; }
            set { hitResistence = value; }
        }

The rest, is the definition of the entity class, just like we have done in the previous tutorials:

    class BOBrick : Unit
    {
        BOBrickType _type = null; public new BOBrickType Type { get { return _type; } }
    }

Three different types of bricks

Now compile your code and if everything went ok, just open Resource Editor.

Locate the Data\Types\BreakOut folder where we placed the Type Resourced created in previous tutorials. Create a new resource Type, by right clicking on the BreakOut folder in the tree and selecting New Resource.

The new resource dialog will appear, choose Entity Type:

Now click Next, twice, and the New Entity Type Wizard dialog will open. Type BOBrick_Blue as the name for the new resource being created, and choose the class BOBrick in the dropdown menu:

The BOBrick_Blue entity is now created and appears now on the resource tree on the left. We have now to attach a propper model to this entity. First, step into Entity Editing mode, by double clicking BOBrick_Blue on the tree:

Locate the AttachedObjects property on the tab on the right, and click the utility button for the collection editor dialog to appear. Use the Add button to add a Mesh object, you'll dialog will look something like this:

Now configure the added Mesh to point to our brick.mesh 3d model (provided in the first tutorial). To do so, locate the MeshName property and click the utility button to pop up the model browser dialog:

Now comes the trickiest part. We are replacing the material that's referenced inside the 3D model (the one the artist applied before exporting the model) with a colored material named bluebrick.material (provided with this tutorial). Locate the property ForceMaterial and click the utility button. This time the resource browser will pop up with the available materials. Browse to the BreakOut folder, where the provided materials reside, and choose bluebrick.material.

Now, click Ok twice and the resource editor will show how our first type of brick looks like. It must be displying a blue-textured block like in the following picture:

Before the first type of brick can be considered ready to rumble, we need to configure one more property that is very relevant in our gameplay. We want the blue bricks to be the weakest ones, so configure it's HitResistence property to 1.

We are done now with the blue brick. Click any other entity in the resource tree on the left to abandon the edit mode and then click save to store your changes.

The first type of brick is ready, we must now create the other two left. The process is the same, the only thing that will differ are the material used for each type, and the associated HitResistance. For instance, let's create a BOBrick_Red and apply it the redbrick.material and a HitResistance of 2. And finally a BOBrick_Yellow type, with the yellowbrick.material applied, and a harder HitResistance of 3.

You have two choices now, repeat the whole process described above for these two new types (lame, not recommended!) or use Copy the existing type and Paste it, the Rename and Editing his properties (much more cooler this way, don't you think?).

Once you are done, you gotta have three new types called BOBrick_Blue, BOBrick_Red and BOBrick_Yellow configured to have different materials and different hit resistances:

Search

Toolbox