Adding or inheriting new types to the editor

From Frozenbyte Wiki
Revision as of 10:10, 15 June 2018 by AnteroFB (talk | contribs) (Created page with "Different versions of the editor are tied to different games and thus have different types and assets or resources. Creating one new type might lead to creating tens of other...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Different versions of the editor are tied to different games and thus have different types and assets or resources. Creating one new type might lead to creating tens of other types that the original one is dependent on.

Short explanation of types and inheritance

Types

In order to understand a bit better the task and point of inheriting new types, something should be said of the types themselves.

Essentially, everything that can be seen in the Type tree is a type in and on itself. All the components, all the entities, all the fonts and all the GUI-widgets are types. By editing a property of a type in the Type tree, the modified properties are applied to all the copies or instances of that type. As an example, if one changes the property DiffuseColor of RockCollisionHelperModelComponent from COL(0.5,0.5,0.5) (grey) to COL(1,0,0) (red), all the entities that use this component have their DiffuseColor set to red by default. In contrast, if the property DiffuseColor in the RockCollisionHelperModelComponent of one instance in the scene is changed, the effects are applied only to that specific instance.

Thus, types in the Type tree are the originals, and all the instances in the scene are copies of these. Modifying the original changes the copies, but modifying the copies only affect themselves.

Inheritance

It's not always entirely clear whether a new type should be inherited or if the possible parent type should just be modified in the scene every time it's used. A good rule of thumb is to be the right kind of lazy: the more one has to fiddle with the properties of just one instance, the more error prone and time consuming it will be to do the same to multiple other instances of the same type. This doesn't mean creating multiple types of one collision helper which are just different sizes, but instead creating multiple types of collision helpers for cases that area clearly different from one another (e.g. RockCollisionHelper, MetalCollisionHelper, WoodCollisionHelper) and would need extensive alterations in their properties. An especially clear situation where the laziness rule should be used is the adding of new components: if new components are needed for the entity, most probably it should be a new type of it's own.

Another thing that should be kept in mind when inheriting new types is the choice of the parent type. If the new and the old type share an is-a relationship, the new type should be inherited from the furthest descendant of this old type, with which it still shares the is-a relationship. As an example, RockCollisionHelper should be inherited from CollisionHelper, because it clearly is a CollisionHelper. In contrast, DynamicRockCollisionHelper shouldn't be inherited from CollisionHelper, because although it too clearly is a CollisionHelper, it's also clearly a RockCollisionHelper, which is a further descendant of CollisionHelper.

Two example inheritance hierarchies

Incorrect inheritance hierarchy

  • object
    • Helper
      • CollisionHelper
        • RockCollisionHelper
          • MetalCollisionHelper
        • DynamicRockCollisionHelper

The first example breaks both of the rules for deciding a parent of the new inherited type. First of all, MetalCollisionHelper is descended from RockCollisionHelper even though MetalCollisionHelper is not a RockCollisionHelper. Secondly, DynamicRockCollisionHelper is a RockCollisionHelper and should be descended from it, rather than from CollisionHelper.

Correct inheritance hierarchy

  • object
    • Helper
      • CollisionHelper
        • RockCollisionHelper
          • DynamicRockCollisionHelper
          • CuttableRockCollisionHelper
        • MetalCollisionHelper
          • DynamicMetalCollisionHelper

In this example the Dynamic and Cuttable objects are descended from the correct types and is-a relationship isn't broken with incorrect inheritance.


Inheriting MetalCollisionHelper from CollisionHelper

MetalCollisionHelper in Trine 3 editor
Inherit new type
Inherit new type 2
Inherit new type 3

The components we need for the MetalCollisionHelper are:

  • MetalCollisionHelperModelComponent
  • MetalCollisionHelperBoxPhysicsComponent, which needs a
    • CollisionHelperBoxPhysicsComponentBoxPhysicsCollisionComponent and
    • MetalPhysicsMaterial
  • TransformComponent

If your editor already has a CollisionHelper, our job is relatively easy. What we need to do is to inherit the MetalCollisionHelper from the CollisionHelper and inherit the needed components and change some of their properties. Inheriting can be done by right clicking on the type we want to inherit and then choosing "Inherit new type". This opens a window, where we can choose the name of the new type (MetalCollisionHelper) and the components we want to inherit. If we don't check the boxes of the components, the new "main type" we created uses the components of the type we inherited from. If we do check the boxes, the component types themselves are inherited to new component types that are used for this "main type" specifically. In this case, we want to inherit new component types as well, so let's check the boxes.

Pressing "OK" for the first time fills the "New type script file". You can modify the path if needed but in general you should just use the default given path.

Pressing "OK" the second time either closes the window if we didn't decide to inherit the component types, or opens the same window again if we did decide to inherit them. In this case the latter is true, and the procedure is exactly same as before, except we're not going to inherit the CollisionHelperBoxPhysicsComponentBoxPhysicsCollisionComponent type as a new type (not checking the box in the "Inherit new type" window).


If everything went correctly, we should now have a MetalCollisionHelper beneath the CollisionHelper in our Type tree. It also has it's own component types, namely MetalCollisionHelperModelComponent and MetalCollisionHelperBoxPhysicsComponent, which we decided to inherit when we inherited the entity type from CollisionHelper.

Saving the types

After we are satisfied with out new types, we should remember to save them. File -> Save Types