User defined structs

[nyalloc]

Summary

LDtk could add support for a user-defined "struct" field type - a group of related fields with a unique type name. The workflow would be similar to LDtk's user-defined "enum" support.

Justification

Editing fields can become labourious as a project increases in scope. Currently LDtk has no way to group related fields together or to share field definitions across related entity types.

Entities could use struct fields to group together related fields under a unique type name. This would be a quality of life improvement in several ways:

• Entities with similar properties could move their fields into a struct. If that struct changes in the future, the changes will automatically propogate to every entity type that uses it. This is a better workflow than having to update every entity definition individually.

• Create arrays of groups of data. LDtk 1.1.3 has no way to group related data together into an array, besides creating multiple array fields and relating the values by index, which is much less comfortable from a user perspective.

Example

Suppose you are working on a top-down RPG - not an unusual use case for an editor like LDtk. These games require a lot of data - character stats, inventories, gameplay stats, item stats. The designer would need a way to quickly author a lot of this data, and would need a good workflow to iterate on this data quickly. This would be challenging in LDtk 1.1.3.

Adding support for user-defined "Struct" field types could help remedy this. This feature would fit in with LDtk's existing features well. The user could create a Struct similarly to how they can create a user-defined Enum:

Editing a Struct would be very similar to editing the fields of an entity.

You want to add enemeis to your RPG, so you create two entity types, "Guard", and "Boss". Both needed their Stats to be defined. Instead of having each entity redefine these fields, you would simply add a "BaseStats" field to each.

Then, in the Entity editor, the struct would present itself as a collapasable region of fields.

Potential Issues

Getting the editor right for a field that is an "array of structs" could be tricky. I think this would be a very powerful feature - especially for games that need to place data-rich entities around the level, but care would need to be given so that this is easily digestable.

Developers may want entity types to be able to override the default values of their struct fields, rather than relying on the defaults set by that struct's definition. This would be powerful from an editing standpoint, but it could complicate the entity editor.

To simplify the implementation / UI, it might make sense to prevent the user from adding struct fields to another struct.

[deepnight]

Thanks for sharing this! I like this approach as it fits really well the current LDtk paradygms, and solves lots of "large projects" related issues. I'll look into that as soon as possible :)

[JustusPan]

It sounds like the "custom class" feature in Tiled. When object(Entity) has been assigned to a class type, it will own the properties(field) which are defined in the class definition. FYI https://doc.mapeditor.org/en/stable/manual/custom-properties/#custom-classes

[deepnight]

It sounds like the "custom class" feature in Tiled. When object(Entity) has been assigned to a class type, it will own the properties(field) which are defined in the class definition. FYI https://doc.mapeditor.org/en/stable/manual/custom-properties/#custom-classes

Thanks for this article!

I think @nyalloc approach is more versatile. You could, say, define a "Creature stats" type which contains core creature info (HP, inventory, move speed etc.), then also add a more specific type like "AI settings" with enemy AI related fields. An enemy would have both these types, which are more like collections of sub fields.