How do I check to see for a specific tile type and add data to tiles?

Hey,

So I have this tilemap where I create manually in the editor (not generated at runtime).

What I want is something similar to what is in the game Neo Scavenger, I can click on "Scavenge" and get loot/information based on the tile type. Expanding on that, it is like if you're on a forest tile you get bushes and ropes. If you're in a mountainous area, you get rocks and maybe some iron.

Now how do I add data to each tile (i.e. each tile knows what kind of text to display and what kind of loot to provide?) and how do I check which tile is which when the player clicks on "Scavenge" on it?

One way I thought about this was storing data in a JSON/XML/CSV file. But that basically makes the whole create the map in editor moot and I have to generate it at runtime and I don't want that.

Since I use Unity mainly, the equivalent to this in Unity is to create a data object (doesn't live in the level) and put all the data a tile type needs in it. Then each tile (also a data object) is then given an attribute of type "tile data" and then linking both. Does Construct 2 have something like this? Any ideas how I can do this?

If the map isn't huge like thousands and thousands of tiles, I would go with sprites, and store the data in their instance variables instead of a tilemap.

You get relative xy's as well as other benefits of frames, collision poly's etc.

If the map isn't huge like thousands and thousands of tiles, I would go with sprites, and store the data in their instance variables instead of a tilemap.

You get relative xy's as well as other benefits of frames, collision poly's etc.

I wondered about that, but I was worried about performance. Do you know what is the upper bounds of something like that rouhgly? Like for example would a map of about 6K tiles be OK? Would that be too much?

The upper limits for modern computers for objects in a layout is anywhere between 5000 to 10000 depending on hardware with limited to moderate movement.

Less, and a wider range for mobile of course.

There are a few optimizations like Render Cells, and mixed objects(part tilemap, part sprites, part tiled background ect.)

The upper limits for modern computers for objects in a layout is anywhere between 5000 to 10000 depending on hardware with limited to moderate movement.

Less, and a wider range for mobile of course.

There are a few optimizations like Render Cells, and mixed objects(part tilemap, part sprites, part tiled background ect.)

I have just run a test and I was able to put 10K objects (not in the same screen of course) and it worked just fine (web). Mobile isn't a very big concern right now. But if worse comes to worst, I can always separate those into like 4 levels or something.

I didn't know about Render Cells. Just read about them, super useful. Thank you very much.

I would suggest making a simple level editor. Just a separate capx where you can click on a tile to change its type and enter specific info about this tile into a few text boxes. Save this info in an array, and then export Array.AsJSON and Tilemap.TilesJSON.

I thought of this at one point but then felt the hassle is going to defeat the purpose of making this prototype/demo in Construct 2 (quick easy, couple of days work). Unless level editors in Construct 2 are a quick 1-2 hours thing.

Another option is similar to newt's suggestion - put sprites on your tilemap, but you probably don't need to cover the entire map, only the tiles which have any valuable resources. And this sprite may be a single invisible square.

Thanks for the suggestion between yours and Newt's I think I'll choose this actually. Have a layer with a Tilemap and then another layer on top of it some squares that On Click or something do some stuff.

If I want to change the tilemap's tile, I can just simply do that still (since it is a tilemap and don't have to detect what object I am on) using the tilemap.At or I can be lazy and spawn a sprite right on top of that part of the tilemap to render on top as if it replaced it :D

Thank you both very much!