[SOLVED] TileMap and TileMapMask - Improvement that can benefit everyone

[willianholtz]

I had a conversation with silver-Streak on Discord about possible ideas about “TileMapMask” and “TileMap” simultaneously.

We currently know that the version of “TileMapMask” is in EXPERIMENTAL state, and as we have seen, it works very well.

But how does it currently work?

1 – When creating a collision in Tiled, we are forced to put in the CLASS parameter the name of the collision that will be created in Gdevelop. This CLASS can have any name at first, however, this name used in Tiled must be placed in the “TileMapMask” by Gdevelop.

2 – So if we have more than one type of collision, we must create more than one “TileMapMask” for each one, which happens with JumpThru, Ladder and Platform.

3 – Now, if you create a game with several rooms, or even huge rooms, with several objects in the scene, it becomes kind of frustrating. See the example of my game if I were to use the “TileMapMask”:

What would happen if I had all 3 Behaviors in every room? Unfortunately, I would at some point get lost in the placement of some collisions, what if I had placed the collisions above objects? If I were to move an object I would be forced to delete the collision masks or move them to the side. Not to mention that I would have to create 36 more “TileMapMask” which would not be pleasant.

The idea behind it all!!
When we create a collision in gdevelop through the “TileMapMask” what happens in practice, it is almost the same thing as creating a normal object and placing it as a platform (jumpThru or Ladder), as we did before version 139 (138?).

So what FACT changes in this type of collision, is that gdevelop recognizes and “draws” according to the collision shape that was placed in Tiled.

But in that case, how do I believe it should work? Well, my opinion is to do the same rule that the user “Pandako” did with the extension “TileMapCollision”, but in an automated way and following the rules of D8H. What makes the version of “Pandako” have a bad side, is that if our “TileMap” has several layers with collisions, the original version of the extension does not do that, because it only works with 1 layer per “TileMap”, but in this case I adapted it myself and it worked perfectly.

Contrary to what D8H did, it does not use CLASS but the name of the created collisions. However, adapting to the ways the two developers did with collisions would make everything easier to work with and much more robust.

As:
• Use the “drawing” version that the D8H made, as well as the automatic creation of collisions
• Use the creation of objects that Pandako did through TileMap, but without the need to create them manually
• The “TileMapMask” could be a BEHAVIOR instead of being objects, and with that link to the “TileMap” only
• In Tiled, when putting a name on the collision we want, it would be interesting to follow the rule of gdevelop itself, how to use only: Platform, Ladder and JumpThru instead of the user writing any name that comes to mind, this would be easier at the time of programming inside gdevelop, because the user would be forced to put the correct name that must be read by gdevelop.

I understand that it can be a bit of work, and sometimes not so much, because both solutions are there, just both developers talk and reach a consensus to improve collisions even more.

[davy]

Why do you split the tile map?

[willianholtz]

In this case, the Tilemaps are divided by the fact that they use the room-based metroidvania-style camera.

[davy]

Wouldn’t it be easier to only use one tile map and an object to set the room bounds?

[Silver-Streak]

Just as a heads up, even ignoring the collision ask you’d probably be much better off using an actual separate “camera room” indicator object, and having a large tilemap for the zone instead of splitting each room into a tilemap.

Specifically for situations where you want to control the camera in a special room (such as a boss room) where you then expand the camera room to be larger after a cutscene.

[willianholtz]

I’m partly right about rooms and maps.

But purpose of the post is not my game, but to improve a function in the GD, regardless of how the user uses the “TileMap”.

The idea is to combine the useful with the pleasant!

[davy]

If you base your reflection on a use case that is not representative of how tile maps are used, we can’t reach any conclusion.
Please update your message with an other example, so we understand better what you mean.

[willianholtz]

Okay, let’s make my thinking clearer.

1. We have a TileMap that communicates with Tiled, right?
2. And a TileMapMask that also communicates with Tiled.

Why not combine the two?

With the combination of the two, the only thing we would have to do is, when creating a type of collision in Tiled, the name of the Class of this collision would be the same existing in Gdevelop, that is:

• Platform
• ladder
• JumpThru

Recognition of collisions would be done only by TileMap, we would not need TileMapMask.

You’ve already done the hard part that was to transform the collisions created in Tiled to Gdevelop. However, the way you did it, was pretty much doing what we were already doing, which was manual collisions. Don’t get me wrong, I’m not saying it’s a bad thing or it was a bad thought, far from it (really sorry if I sounded arrogant in the message above).

So the way it should work would be something like this:

1 - Create collisions in Tiled, with the names obligatorily those of gdevelop (Platform, Ladder or JumpThru)

2 - Only in Tilemap, we set which collisions we want to create.

Well, I believe that from the images I was very specific about the treatment of TileMap and TileMapMask. I hope you understand.

And please don’t take offense if any word sounds offensive (google translator sometimes doesn’t correctly convey what I actually write)

[davy]

On which objects would the 3 platform behaviors be attached?

[willianholtz]

When you created the TileMapMask, how did you create the objects if there weren’t any? It follows the same idea, but in this case, it would create virtual objects. Each with specific behaviors.

[davy]

I don’t understand. What do you mean by virtual objects?

Also, what if the user is doing a top-down game and wants to know when the player is on grass, sand or water to apply a different effect?

[willianholtz]

@davy

Also, what if the user is doing a top-down game and wants to know when the player is on grass, sand or water to apply a different effect?

Virtual object is practically creating the collisions referring to Gdevelop in cache (or memory).
In practice it would be an OOP.

In the case of sand, flowers and other objects, this would be customized by the user.
The real thing is that everything can be done through this field, both the collisions themselves and passable and impassable objects.

You can create an “edit” field on the TileMap object, and work with array

Explanation: When selecting one or all of the checkboxes, collisions marked by the user are generated.

Therefore, the user may want to check the “Platform” box and also write “Platform” in the edit field. In this case, either you compare the array names made in the edit field and ignore the checkbox, or leave the checkbox inactive if the user wants to use the edit field.

[davy]

In top-down view, in addition to the grass, sand and water walking effect, users want want to handle wall collisions.

What would the events be?

[willianholtz]

you don’t have to do it exactly as I left it in the image, I just made an example. You can deal with this through a ComboBox, the same used in Behaviors, making the user select what type of collision will be created

Something like:

With this selection, you can separate the types of collisions for different games.

[davy]

What I mean is that objects have a collision masks that is used by conditions like “Collision” and “Point is inside object”, actions like “Separate object” or behaviors like “Platform” and “Obstacle for pathfinding”.

Attaching 3 Platform behaviors on the same object won’t work.
What do you suggest?

[willianholtz]

My idea would be like this:

In Tile there are two types of Classes (not counting custom classes):

Tile Class

Object Class

We know, for example that to make a collision of the “Platform” type, we need to select between three types, which are:

• Platform
• JumpThru
• Ladder

However top-down does not deal with this type of collision, but, as you said, the “Separate object” and “Obstacle for pathfinding”.

We would have to make the two types of classes work together, how? So:

In the tile class, it receives the behavior that the user wants to use:

• TopDown
• Platform

In the object name, which type do you want to use:

Platform:

• Platform
• JumpThru
• ladder

TopDown:

• Collision

For the platform, there’s not much to be done. But in TopDown, internally you would put the correct behavior for this type of collision;

For pathfindin you can use the object’s class and set it as:

And then internally you define the type of class (or subclass in this case) used for that specific object!

Making Tiled’s class and name scripts standard for gdevelop makes it easier to work with, and for you internally.

[davy]

The tile map collision map object already use the Tiled class. I don’t understand your point.

What I was asking is:
How do you expect events and behaviors to work if there is only one object?

[willianholtz]

The collision mask you created is also just one object, this object goes above another one. The difference is that the “TileMapMask” object needs the user to put a behavior related to what they need.

What I propose, is to use both classes of Tiles to define the behavior using without the need to create a “TileMapMask”. The recognition of the entire collision process would be done by the “Tilemap Object” itself

[davy]

Sorry, I still have no clue what you mean.

[willianholtz]

I’ll make my last post to try to describe how I think it should be:

1 - First we select which type of collision we will have in our Tilemap

2 - Depending on the Type we selected, some options would be presented below

Platform

TopDown

That would be the first part.

Now for everything to work according to gdevelop, we must follow some rules:

Tiled: Follow the creation rules, so gdevelop understands what each collision object is

1 - Class Name = Platform ( This appear how options on gdevelop - First image)
2 - Class and name of objects
2.1 - Platform (Type: can be Jumpthru or Ladder too)
2.2 - Pathfinding (Behavior is activate or not)

The same things with TopDown:

1 - Class Name = TopDown ( This appear how options on gdevelop - First image)
2 - Class and name of objects
2.1 - Collision (Set: Move away from)
2.2 - Pathfinding (Behavior is activate or not)

That way you work with classes and subclasses, with class being Number 1 and subclasses number 2, referring to the image.