Editor properties for custom tile

[GLeBaTi]

Hi. Can i add properties in editor to my tile?
I was create tile class like this tutorial: Unity - Manual: Create a scriptable tile with a provided example

public class RoadTile : Tile {
public float SpeedRatio = 1; // ← i want change this value from editor to each tile
…
}

[Lo-renzo]

Try inheriting from TileBase. “Tile” might be using a custom Inspector, suppressing the normal inspector showing the float. You could also make your own custom Inspector if you want something fancy.

[GLeBaTi]

@Lo-renzo

Try inheriting from TileBase. “Tile” might be using a custom Inspector, suppressing the normal inspector showing the float. You could also make your own custom Inspector if you want something fancy.

It shown if i select tile in “project” window. But this is not shown if i click on tile in “Scene” window.

[GLeBaTi]

[Lo-renzo]

Where you have your wood, each wood references the same Tile. There reason why the GridSelection tool doesn’t give you its properties like that is that would imply that you can edit per-tile properties, which you cannot. All wood have the same Speed. In other words, when looking at a particular position, if there’s a wood there, you can’t adjust the speed for that position, only across all places where there’s wood by changing the asset (in project window). So, GridSelection only tells you what Tile asset is at a particular spot. You can then adjust that asset’s properties from the Inspector for the asset.

[GLeBaTi]

@Lo-renzo

Where you have your wood, each wood references the same Tile. There reason why the GridSelection tool doesn’t give you its properties like that is that would imply that you can edit per-tile properties, which you cannot. All wood have the same Speed. In other words, when looking at a particular position, if there’s a wood there, you can’t adjust the speed for that position, only across all places where there’s wood by changing the asset (in project window). So, GridSelection only tells you what Tile asset is at a particular spot. You can then adjust that asset’s properties from the Inspector for the asset.

Thanks for reply! This is helpful

[bluny00]

I will slightly divert this thread. I hope that is okay.

@Lo-renzo

Where you have your wood, each wood references the same Tile. There reason why the GridSelection tool doesn’t give you its properties like that is that would imply that you can edit per-tile properties, which you cannot. All wood have the same Speed. In other words, when looking at a particular position, if there’s a wood there, you can’t adjust the speed for that position, only across all places where there’s wood by changing the asset (in project window). So, GridSelection only tells you what Tile asset is at a particular spot. You can then adjust that asset’s properties from the Inspector for the asset.

So this part in the example:

    private bool HasRoadTile(ITilemap tilemap, Vector3Int position)
    {
        return tilemap.GetTile(position) == this;
    }

works because of the same reason?
When I was looking into the example I thought this isn’t right, that it would only be true when the instance of the RoadTile is at that specific position, and that the correct version for the function would be something like this:

    private bool HasRoadTile(ITilemap tilemap, Vector3Int position)
    {
        return tilemap.GetTile<RoadTile>(position) != null;
    }

But it would be also surprising if such a mistake went unnoticed in the documentation for more than two years, so I started to look into the forum.

But it feels like now I get it, there is only one RoadTile instance which can be present in multiple cells in the Scene, that is why it works with the “== this”. Is this correct?
Is there a case where there would be multiple RoadTile instances in the same Scene?

[Lo-renzo]

@bluny00

But it feels like now I get it, there is only one RoadTile instance which can be present in multiple cells in the Scene, that is why it works with the “== this”. Is this correct?

That is correct. “== this” is doing reference comparison. Keep in mind, you could create multiple tile assets of the same road tile script. Then the “==this” is checking whether this instance (i.e. this asset) is the same as that instance at the particular cell.

@bluny00

Is there a case where there would be multiple RoadTile instances in the same Scene?

Yes, create a RoadTile asset. Then copy and paste it in the Project. Then paint both to the same tilemap. Now you have multiple on the same tilemap.

[Aridez_1]

And in the case that I want an editable property on a per-tile basis how should we go about it? For example, I might set up a tile that can be burned, then once burnt I want to be able to set and check a boolean “isBurnt” and potentially do other actions (such as changing its sprite or burning neighbor tiles among others)

[Lo-renzo]

@Aridez_1

And in the case that I want an editable property on a per-tile basis how should we go about it?

Three strategies:

@""

1. For any cell that needs data, use game objects. This gives you the full suite of per-cell properties and flexibility of attaching MonoBehaviours as needed. TileData has a slot for a gameobject so this is the most built-in option. This option may be more appropriate for games with pre-defined levels because you can control placing gameobjects so their number is reasonable. For a more dynamic game, unless you’re careful about what cells have g.o.s then it could become a problem if maps are large.

2. Keep an independent data store. Parallel to your tilemap, keep a collection (array for staticly-sized maps, dictionary for dynamic) where you can look up per-cell gameplay data. Given a particular cell, this allows you to retrieve either the tile information (from tilemap) or the gameplay information (from parallel collection).

@""

3. Store the data in your own Tile subclass, and then Instance your Tiles at creation. Author your level using these subclassed tiles (such as DestructableTile), and then at level load time, iterate the Tilemap and lift each Tile out, then use Instantiate() it to make a fresh copy of it and put it back into the Tilemap. It will appear to be the same as before, but now each one is its own copy (of the original disk asset), but now it can have a different level of damage than any other tile.

When you want to do load / save files in the future, this also provides a handy central place where you can grab all the Tile objects and get their pickaxe damage and store it to a saved game, as well as restore it on load.

[Aridez_1]

@Lo-renzo

Three strategies:

The problem with #1 would be that the power of using the Tile Palette would be lost, which would be a shame since it speeds up the creation of the maps a ton. For #2 I’ve seen that Unity offers the GridInformation script, even though it is not supported anymore, but with that solution then we lose the power of using the inspector to quickly edit each tile settings.

I think it is a lose-lose situation with each solution without a way around

[Lo-renzo]

With #1, it’s possible to attach a prefab to a tile. There’s even a Prefab Brush in the Tilemap Extras package:
https://docs.unity3d.com/Packages/com.unity.2d.tilemap.extras@1.5/manual/PrefabBrush.html

With #2, the overall strategy is to keep a strict separation between the Visual Layer and the Gameplay Layer. The tilemap becomes a visual representation of gameplay data rather than being associated with any tiles themselves. This is more suitable for certain types of games (simulations) than others (pre-designed levels).

With any solution, you may find you need to build an in-game or editor tool to print information. The GridInformation is never going to be able to print everything you may need, especially if you want lots of custom data. The #1 solution with Prefab/GameObjects can still make use of the Inspector. There’s also this free asset which I haven’t used but aims to solve this problem.