A tilemap that could store values would prove to be a perfect 2D matrix simile, with as many columns and rows as needed.
This can be useful to give attributes to tiles as varied as the type of a tile, its economical worthiness, if it's occupied or damaged, etc.
Unfortunately the 'Tile' is an object of type Tile, it's not a mere Game Object, and it's not visible in the hierarchy as far as I know which means it cannot be called and can't be isolated to harbor a FSM that would contain variables.
Cells are the placeholders on the grid where tiles fit. The tilemap is divided and scaled at specific values. It's possible to get some basic data for cells but it's just stuff that Unity provides like position, size, etc.
Rules for tiles would have been interesting if it were possible to expand this utility beyond what it does, which is telling how tiles behave next to other tiles. Rules are useful during the filling process of a tilemap, the level design so to speak, but it is certainly not meant to be used at runtime.
The Arraymaker extension doesn't allow users to create an infinite amount of columns because the type of variables are logically only capable of holding a limited amount of slots. For the example, the largest type of variable, the quaternion, allows us to store four values in a row. We would need a special var type, a special row in fact, where there can be as many values to be stored in.
Since it's not available and would probably ruin the UI anyway, it's out of the picture.
We are left with Scriptable Objects as the only available solution it seems, but unfortunately that falls beyond the scope of Playmaker. See video
here.
But there may be another solution:
TArray - Ultimate Serializable Array [C# / Unity] (this is installed under Packages, not Assets).
The user can then make this array stack over the tilemap so the cells in that array will correspond to occupied cells, therefore tiles, in the tilemap.
Each cell in the TArray can contain only one value in its most basic use but it's not a problem because it can store GameObjects.
Which means that for each type of tile in your game, especially those with different values from others, you can create a list of GameObjects acting like a database.
Create for example a TArray parent, have the TArray script on it and shove as children all different types of tiles you will have under the form of GameObjects. You can store prefabs that way. Each GameObject can have a FSM that stores data.
Then, when the game picks a given cell, checks if it has a tile, then it can look into the array at the corresponding coordinates for column and row, pick the GameObject and extract its values.
For this however you would need actions that can work with this extension so it can parse the TArray. Like get and set value at {x;y}, at the very least.
It's also annoying to have to populate the TArray manually.
You would need to run some kind of script that can populate the TArray automatically by parsing every single tile of the tilemap successively, row by row. For each tile, it would check its type (usually its name) and then fetch the correspond GameObject and store it as a GameObject value at the corresponding coordinates, so that say tilemap{32;6} finds a tile "wet dirt", then picks the GameObject WetDirt and stores it at TArray{32;6} coordinates.
The WetDirt GameObject would contain a bunch of values like speed, slipperiness, humidity, cover...
The issue with this extension is that it's not optimized for the Inspector's UI but doesn't use its own either. Too many columns or rows will bring Unity to a crawl.
