How should GDevelop handle entities in Tilemap data from LDtk and Tiled

[Silver-Streak]

Bringing over the conversation from #2434

From @blurymind 's original question: #2434 (comment)

One idea I had for getting ldtk/tiled entities into gdevelop is to create some sort of an event sheet action which basically gets an entity you specify and assigns all of its variables to a gdevelop object which you specify.
That way you can automatically transfer variables of an entity in ldtk to those of an object inside gdevelop.

@4ian @Bouh @Silver-Streak @deepnight what do you think of that approach? I am just trying to figure out a way we can get entity data into gdevelop quickly, but allow for flexibility of that entity to be edited in gdevelop. It needs some sort of pairing mechanism to link ldtk entities to gdevelop objects and allow those objects to be edited in gdevelop's ide

In any case dealing with entities with variables from tiled and ldtk needs its own pr/issue and could be tricky to get right imo.

The big question and conversation:

How should we handle entity data in GDevelop?

[Silver-Streak]

For anyone wanting to chime in and aren't familiar with LDtk Entities: https://ldtk.io/docs/general/editor-components/entities/

Entities are generic data that can be placed in your levels, such as the Player start position or Items to pick up.

An Entity can be displayed in various ways (a rectangle, a circle, a tile etc.) and have its own constraints.
For example, you could limit the amount of PlayerStart entity to 1. Adding more will simply move the existing PlayerStart.

Entities can be either a single point, or an entire array of data.

Entities are SUPER useful for numerous things in game design. One common one I've thought about is the Point (array) entity. If we can utilize this in GDevelop, we can build an enemy patrol path in the Tilemap (which stores x/y points), and use that data in events for movement.
Assuming this gets tracked as another layer in the tilemap, you could show that layer to also see what path the object would travel.

Here is an example with two different point arrays that could easily be used for enemy patrol paths:

(I will mention that a slightly different beast is the Enum type (enumerator). These are MUCH more complex and can lead to different things. My understanding is they will eventually be how LDtk handles collision structures.)

[Silver-Streak]

I think the closest thing that Tiled has to entities are Objects? Looking at @blurymind to clarify if they know more.

For more info on Tiled Objects, refer to here:
https://doc.mapeditor.org/en/stable/manual/layers/

Types shared between LDtk entities and Tiled Objects:

• Rectangle shapes
• Ellipses shapes
• Point (single)
• Point (array/path), called Polyline
• Tile (In LDtk, this is any Entity where you select a tile as the visible representation)
• Text

[Silver-Streak]

My general suggestion is to pull the entity data in as an object variable on the tilemap. That way we can use existing expressions/actions/etc to utilize that data in game logic as needed.

From my original post here: #2434 (comment)

What if the entity data was imported as object variables (probably some kind of structure or array) of the tilemap object as part of using the LDTK map?

Like, turning this from the output JSON into an array or structure variable on the tilemap object itself?

(probably without the need for the grid/pivot/etc, but the Name (identifier), UID (assuming we're not actively displaying the entities layer in some way, this would be important to know entity "order"), type (array), then a "Values" subarray which includes {Point, cx 10, cy 24}, {Point, cx14, cy21}, etc)

In theory this would allow all of the entity data to be visible in the Editor (by looking at the Tilemap's object variables), the user could use existing events and expressions to pull those variables for other needs, and you wouldn't have to worry about object creation?

[blurymind]

So for this task ideally we want the same api to handle tiled and ldtk entities identically.

There are a number of things you need to take into consideration:

• Gdevelop itself does not have the ability to write to tiled/ldtk files. So if you edit your entities in gdevelop and save - the edits will not get stored in the original data. All gdevelop can do is read from that data, it cant change it. We really want to keep that data in one place and not end up having to keep it in sync in two places.
• When you edit entities in ldtk/tiled, their data is in the tilemap. How do we materialize it in the gdevelop IDE without running into problems with them not working as expected. Natively gdevelop's c++ engine doesnt know about these tilemap data structures or entities. It has its own IDE with different rules and data structures.

If you look of usages of tiled and ldtk with other game engines - all the behaviour of what entities do is declared in the game engine. They are just there as placeholders of data to create objects that the game engine understands - this happens when you run the game - it doesnt happen when you edit them in the game engine's ide. You either use tiled/ldtk to edit entities data or you use the game engine ide to do it - you dont use both and try to keep their data in sync. If we try to create data mirroring the one from tilded/ldtk inside gdevelop I think we will end up with potentially harder to maintain code with many corner case bugs to whack.

My idea for handling this goes like so:
We add a commands/expressions/conditions to the event sheet that reads from the entities data and lets you create gdevelop objects from it. Doing this in the event sheet and it happening on runtime will let us do what other engines do - keep it simple and yet flexible. You declare all the behaviour in Gdevelop, you keep all the entity data editing in ldtk/tiled. We dont try to add any specifics about how that entity data is interpret - we allow the game developer to do that themselves with the event sheet.

Entities can be rendered in Gdevelop's IDE, you just cant move them in it or change their properties.If you want to do that - you use ldtk/tiled.

Gdevelop has events for creating objects already, they can greatly compliment these entities. As part of such a task of course a good example project will demonstrate how to use entities data to create a game from it

[Bouh]

Would entities also be of interest to be added to GDevelop?
Because if so, let's create the same type of entities in GDevelop, then interface them with those in LDtk.
And in the engine some expression and actions & conditions are added to get the entity data.

This way it's not just related to LDtk, but in GDevelop, that will be also usefull to make spawners, path node and others.. ,even an entity with a collider because actually people use a sprite for make a NPC moveing from left to right and vise versa, an entity is better than a sprite in this case.

I think that entities are very useful in both LDtk and GDevelop.

[Silver-Streak]

I think Bouh's idea is an interesting one.

Am I understanding the idea correctly: There is some kind of Entity object that can be used (e.g. "This is an object that isn't visually rendered during runtime, but can contain have variables/logic/be impacted by events") and a bunch get automatically created when an LDTK/Tiled map is imported?

Is this something that would be created in the editor (slightly different than the runtime idea of Blurymind) Or am I misunderstanding?

[Bouh]

Am I understanding the idea correctly: There is some kind of Entity object that can be used (e.g. "This is an object that isn't visually rendered during runtime, but can contain have variables/logic/be impacted by events") and a bunch get automatically created when an LDTK/Tiled map is imported?

That's the idea I had in mind 👍

Is this something that would be created in the editor (slightly different than the runtime idea of Blurymind)

We add a commands/expressions/conditions to the event sheet that reads from the entities data and lets you create gdevelop objects from it. Doing this in the event sheet and it happening on runtime will let us do what other engines do

Sort of yes. Entities could be a new type in object list (visible in IDE only, not in preview, but useable in runtime for get data), The user choose Entity object, select the type, enum (structure variable?), point, etc… and configure the next inputs inherited from the chosen type.
All entities from LDtk have to be in read only in GDevelop scene editor, I agree with that.
The others entities (not from LDtk) are free to be edited and moved, they are not linked to a file from another program.

Reminder: We should think IDE first and event sheet after in general in my opinion. Let's not fall into the trap of doing everything by events, both are complementary, IDE is much easier to use for people, event sheet is so powerful. Of course, it is necessary to be able to get the data from the entities 😁

[blurymind]

Yes I agree it might be better informed after we have ldtk itself bundled with gdevelop. I was thinking of having the renderer display entities in gdevelops ide, but not in the runtime, unless you have created an object out of them via the event sheet. One other idea I had was to have gdevelop create objects based on the data that is set in ldtk. For example if you set a gdType field in ldtk to sprite on an entity, gdevelop can interpret that as an instruction to create an object of it in the runtime. In that regard gdevelop can have some sort of a schema you would use in ldtk to instruct it what to create.

…

On Sat, 24 Jul 2021, 19:46 Aurélien Vivet, ***@***.***> wrote: Am I understanding the idea correctly: There is some kind of Entity object that can be used (e.g. "This is an object that isn't visually rendered during runtime, but can contain have variables/logic/be impacted by events") and a bunch get automatically created when an LDTK/Tiled map is imported? That's the idea I had in mind 👍 Is this something that would be created in the editor (slightly different than the runtime idea of Blurymind) We add a commands/expressions/conditions to the event sheet that reads from the entities data and lets you create gdevelop objects from it. Doing this in the event sheet and it happening on runtime will let us do what other engines do Sort of yes. Entities could be a new type in object list, The user choose *Entity object*, select the type, enum (structure variable?), point, etc… and configure the next inputs inherited from the chosen type. All entities from LDtk have to be in read only in GDevelop scene editor, I agree with that. The others entities (not from LDtk) are free to be edited and moved, they are not linked to a file from another program. Reminder: We should think IDE first and event sheet after in general in my opinion. Let's not fall into the trap of doing everything by events, both are complementary, IDE is much easier to use for people, event sheet is so powerful. Of course, it is necessary to be able to get the data from the entities 😁 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2836 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRRWVNNLGL66WP6PNRP6OTTZMDBBANCNFSM5A4LGCWQ> .

[Silver-Streak]

Correct me if I'm wrong, what I'm seeing above between sounds like the order of operations would be (as far as implementing/suggested idea):

1. Rendering Tiled/LDTK Entities in the IDE Visually and data-accessible (read-only, allows the user to use it for game logic as needed, or copy the data if needed to other objects as needed via events, etc)
2. Adding an Entity object type that could be used just like LDtk entities. Displayed in IDE, can have logic applied, but is not rendered in game (very likely the next best method to do Hitbox objects/collision objects/etc, no more "Hide at beginning of scene events")
3. Adding logic that would allow for object creation on runtime based off tags/flags/metadata added to the LDtk/Tiled objects. (Or a toggle via events that lets you create objects from the map file, similar to how external layouts work)

If the above is correct, with the eventual goal of getting LDtk integrated as the native map editor, would there be an option around loading an LDtk map creates the entity object types mentioned in #2 above, but modifying them also modifies the LDtk file? Or would this not really be needed since we can modify the entities in the integrated LDtk tab at that point?

[blurymind]

Actually rendering them in the ide is easy. Making them editable in gdevelops ide imo is a waste of time, especially because you would have ldtk bundled anyways.

The data being usable really is up to how we expose it and to what. Exposing it to the event sheet will make it usable imo. In my head adding a new object to interface with them is kind of like adding a middleman to deal with when implementing game logic. The middle man is not doing anything useful for us other than making the task more complicated.

Once you have easy access to them, you can make some logic in a few lines that iterates through all entities on the start of the game, based on their values makes instances of objects which you have already made in gdevelop.

You have made your objects already in gdevelop, the entities are there just to spawn them with some properties

[Silver-Streak]

Actually rendering them in the ide is easy. Making them editable in gdevelops ide imo is a waste of time, especially because you would have ldtk bundled anyways.

Yeah, if the discussion is more "How do we deal with Entities after LDtk is integrated as an editor", then it really does become moot on "editing" them in the main scene editor, so long as they're rendered in the scene editor. At that point LDtk is part of the IDE already, so no need to replicate the work to have them editable in both places, the user can just go to the LDtk tab to edit their positioning/add stuff to them.

Surfacing the data to be available for events is the larger thing, I think?

(That said, I still think having entities as an object type would be valuable, as bouh mentioned, but that doesn't need to be linked with integrating LDtk, at least not at first, anyway)

Edit: Changed "Wouldn't be value" to "would be valuable." Gdevelop having the concept of entities as an object can have a lot of uses.