This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
gamedev:deigde:editors:gamedefinition [2020/04/01 10:42] – [Object Classes] dragonlord | gamedev:deigde:editors:gamedefinition [2024/03/14 16:32] (current) – dragonlord | ||
---|---|---|---|
Line 8: | Line 8: | ||
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. | 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. | ||
- | {{ : | + | <WRAP group> |
+ | <WRAP column> | ||
+ | {{: | ||
+ | </ | ||
+ | </ | ||
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 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. | ||
Line 42: | Line 46: | ||
The IGDE supports automatic scanning for suitable content in the game directory. Resources like **Skin** resources can be automatically scanned and added not requiring them to be defined manually. The IGDE also supports **XML Element Classes** (*.deeclass). Found element classes are converted to //Object classes// while loading the game project. You only need to define the object classes your XML element classes are using. The rest is done by the IGDE. | The IGDE supports automatic scanning for suitable content in the game directory. Resources like **Skin** resources can be automatically scanned and added not requiring them to be defined manually. The IGDE also supports **XML Element Classes** (*.deeclass). Found element classes are converted to //Object classes// while loading the game project. You only need to define the object classes your XML element classes are using. The rest is done by the IGDE. | ||
</ | </ | ||
+ | <WRAP clear/> | ||
+ | |||
+ | ====== Categories ====== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | Use < | ||
+ | |||
+ | 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. | ||
+ | |||
+ | <WRAP center round tip 60%> | ||
+ | Auto categorizing is a very helpful for working with XML Element Classes. If your *.deeclass files are organized in directories reflecting their type then you can create categories matching these types and assign them the matching path pattern. When your artists then create new *.deeclass files they will automatically show up in the right category. | ||
+ | </ | ||
+ | |||
+ | The **Assigned Elements** list is a read-only list showing all resources with the category set of the selected category. | ||
<WRAP clear/> | <WRAP clear/> | ||
Line 73: | Line 100: | ||
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 // | 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 // | ||
+ | |||
+ | 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 // | ||
+ | <WRAP clear/> | ||
+ | |||
+ | ====== Sub Objects ====== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | 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 < | ||
+ | |||
+ | 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// | ||
+ | ^ Type ^ DragonScript Class ^ Drag[en]gine Class ^ | ||
+ | | Billboard | ||
+ | | Camera | ||
+ | | Component | ||
+ | | Environment Map Probe | # | ||
+ | | Light | # | ||
+ | | Navigation Space | # | ||
+ | | Navigation Blocker | ||
+ | | Particle Emitter | ||
+ | | Force Field | # | ||
+ | | Speaker | ||
+ | |||
+ | 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. | ||
+ | |||
<WRAP clear/> | <WRAP clear/> | ||