The game definition editor allows to edit game definition files (*.degd). These are used for development and stores information about object classes and certain resources like skin resources or sky resources. For each game project a game definition file is created and stored in the project directory.

This editor is usually used to edit the game definition of the current project (Game-Definition → Open Project menu entry) but can be also used to edit any game definition file. This works since in contrary to other editors this editor is allowed to edit files outside the game virtual file system. By default the project game definition is not loaded to reduce loading times.

This editor is mostly important to mappers, hence users of the World Editor. Here you can add object classes and other important resources.

Since game definition files are decoupled from game logic they can be distributed to developers and modders to work with the game in the realm of modding or addon content creation. Using the game definition file they can properly use game objects without needing the game development content just the game content they already own.

The editor window composes of the preview area and the properties panel on the left side.

The preview window shows the currently selected object class. See 3D-View Navigation for how to navigate the view.

Defines general properties of the game definition.

The Base Path points to the directory where the game content is located in. For the current project game definition this is automatically set. For game definitions of installed games this contains the path to the installed game data.

The VFS Path indicates under which directory the game content is shown in the game virtual file system.

The World Properties list contains all properties the mapper can use for World files (*.deworld). These apply to the entire game world and work like object class properties.

The Decal Properties list contains all properties the mapper can use for Decal resources. These apply to decals the mapper adds to the game world not decals defined by object classes. The decal properties work like object class properties.

The Auto Find Path panels allow to define virtual file system path scanned by the IGDE to find suitable content while loading a game project. The content is only virtually added to the game definition to work with.

The object classes and other resources added to the game definition are organized in a category tree. It is possible to not assign resources to a category. In this case browsers show them in the Uncategorized category.

Resources are assigned to categories using a Category Path String. The category path string is similar to Unix file path. For example a child category “World” inside a root category “Hello” would use the category path string “Hello/World”.

Use MOUSE_RIGHT context menu to add and remove categories.

The Hidden parameters hides the category from Browsers. Elements inside hidden categories can be still used unless they are hidden themselves.

The Auto Categorize parameter defines a list of path patterns used by the Auto-Find Feature. Resources added dynamically to the game definition by scanning auto-find directories are matches against the auto-categorize path patterns of all categories. The resources is then assigned to the first matching category. If no category matches the behavior depends on the resource type:

• Resources like skins or skies are assigned to no category being shown up uncategorized.
• XML Element Classes are assigned to the category of their Parent Class if found. If not found no category is assigned and they show up as uncategorized.

The Assigned Elements list is a read-only list showing all resources with the category set of the selected category.

An object class represents a game entity type but in an abstract way. The implementation details are fully hidden using this approach. The object class is typically a script class of some kind but can be anything as defined by the coder.

The mapper defines how the object class is represented in the world editor. This can be either using a 3D model or billboards for example. This representation is not required to be fully accurate to the in-game representation. For some object classes it is better to have an abstract representation (like billboards for lights or triggers) while in other situations it is important to get as close as possible to the in-game representation.

The Object Class panel contains general parameters of the object class like name or description shown to the mapper.

The Scale Mode indicates how the mapper can scale the object. Fixed prevents the object from being scaled. Uniform forces scaling to be uniform across all axes. Free allows to freely scale the object in all directions.

The Def Inherit Prop Pref defines the default property prefix to use for inheriting if the user adds this object class as inherit.

The Ghost parameter defines if the object is considered a ghost during editing. Ghost objects are ignored during certain interactions like dropping objects to the ground. This is typically used for triggers, lights and other objects which the mapper does not want to get in the way of editing.

The Can Instantiate parameter defines if the object class is shown in Browsers. Disable this for helper object classes used only to provide content for inheriting but otherwise not existing in the game. This prevents the mapper from adding them to the game world.

The Properties panel contains object class properties the mapper can use when adding objects to the game world. Properties are a list of unique named keys storing a string value. This design choice completely decouples game logic from editing allowing coders to focus designing their script classes to best suite the game needs not needing to deal with editing compatibility all the time. For the mapper it allows to focus on what is important for him to work efficient not having to worry about his setup having negative influence on the game afterwards.

The Property Values panel allows to set default values for inherited properties. For regular properties the default value can be defined in the properties panel above. Using property values is typically required for game object classes changing base class properties upon constructing. Using Set from Sub Objects from the context menu you can let the editor scan sub objects for linked properties having different values than the object classes inherited from declares as default value. This usually provides a good starting ground.

The Texture Properties panel define properties the mapper can assign to individual textures. They work similar to object class properties.

The Inherits panel allows to include the content of other object classes with optional property prefixes. This feature allows to model typical coding scenarios like Subclassing or Composing. For subclassing the property prefix is typically empty while for composing it is usually unique. The property prefix is applied to all inherited properties and helps to avoid name clashes. Object classes can be inherited from multiple times using different property prefixes. Inherits can be used also by the mapper as a tool to add features to object classes useful for editing not necessarily having an in-game counterpart.

The Hide Tags panel allows to define a set of tags the mapper can use to dynamically hide object classes. A typical example is the Editing tag which allows to quickly hide all objects like lights or triggers to better evaluate the content.

The Partial Hide Tags panel defines another set of tags the mapper can use to partially hide object classes. Partially hidden objects stay visible if the tag is used but certain Sub Objects of them are hidden. This is for example used with light objects which has a Light sub object and a Billboard sub object used to show the light source. When partially hidden the billboard sub object should be hidden but not he light sub object. Using Partial Hide Tags this can be done. To hide everything (including the light sub object) use Hide Tags instead.

Sub Objects have to be added to object classes to make them visible. Without any visible element object classes are shown using a missing object box. Various sub objects can be added using the MOUSE_RIGHT context menu. Here Component sub object is described as an example. The other sub object types work similar.

The parameters in the Object Class Component (sub object type specific) mostly mirror the important parameter values of the respective game engine resource. Most parameters are path of resources to use or values. See the documentation of your Script Module of choice or the Engine API Documentation for details. This list is a little help for you:

The Snap Point type is different. This type is only for IGDE use by the mapper and has no game engine counter part. As the name suggests snap points define spots on the object class other object classes can snap to. If objects have no snap points their origin is used for snapping. If objects have snap points all of them can snap to each other. Furthermore snap points can be Aligned or not. Aligned snap points snap position and orientation while not aligned snap points only snap position.

The Properties sub panel links the content of sub object parameters to properties defined in the parent object class. This allows the editors to update sub object parameters if the mapper changes object properties. Use here the name of the property as defined in the object class. The IGDE takes care of applying Inherit Property Prefixes for you.