Tile Map Accelerator - High Performance Shader Based Tile Map Renderer

After working on the compression algorithm for a bit longer I've managed to further reduce the file sizes by allowing any tile type to be run length compressed rather than just compressing the transparent space. The 50MB isometric map file shown in my previous post is now down to 31MB. A regular single layered square tile map of size 2048x2048 takes a little under 2MB.

​

Right now the implementation goes through the map data array and turns any sequence of a same tile type into a single line containing the type, a separator character and the run length of this sequence. This is your average run length encoding compression algorithm but it works quite nicely on tile maps. While I'm sure I could probably further reduce the size by using a look up table of type patterns in a way similar to LZW compression, I doubt the amount of compression gained would warrant the effort.

For those wondering what the file format looks like, here is a screenshot of the top part of the bigmap_compressed file. Starting with some info about map size, the "7x2" style lines are run length encoded tile types ( left side of the x is the tile type, right side is the run length ) and finally the lines containing single numbers are regular tile types.

​

 

While for the last month I have mostly been working on my dungeon generator asset, I have been able to add a few more isometric sprites to the "V2" style demo scene. One of these new sprites is a seamless forest object that has an Isometric Height value of 1 to mask the tree line when other forest tiles are added right next to it, which creates seamless looking forests that I think look pretty neat!

​

Adding these new sprites / objects allowed me to stumble on a small yet annoying bug with the tile splitting GUI which apparently throws an error when cancelling the saving process. This is nothing major or asset breaking but it will be fixed for next version

 

Here are a bunch of screenshots showing off some basic tile type transitions using a system very similar to the regular square "AutoTiles" to achieve some nice cliffs instead of a hard grass to water tile transition. The cliffs are only drawn "towards" the game camera in order to simulate the fake 3D effect, which really makes the various land masses pop out and appear higher than the water.

​

Because I was quickly testing to make sure the coordinate system was working as intended with neighbor gathering I'm still missing some transition tiles that will be added later, most importantly the various "combined" tiles ( say a cliff to the isometric north and to the south simultaneously on a single tile; essentially a river ).

Still I have uploaded the new V2 style Isometric Demo to Itch and, since isometric takes more memory and has to use a reduced map size for WebGL to work, a Win64 build which features a map twice as large as the web demo.

 

It's just a demo so barely worth mentioning, but in Firefox (Linux) I get the error RangeError: bad Memory initial size.

On Chrome, also the demo, I'm seeing some odd behavior:


Either way, this is so bloody awesome. Keep it up! I for one am very interested to see more AutoTile improvements.

 

The first error is related to WebGL using too much memory ( I don't know if you can change this somewhere in browser settings ) since I needed to allocate a full 2GB to WebGL for this style of map, but the screenshot is weird, seems similar to the issue you were having earlier. I'm kinda suspecting a weird texture compression scheme is taking place on your GPU which messes up the tile map data. But it's insanely hard to tell without having it happen on my side, even my underpowered laptop seems to work fine.

What are the specs of the device you're using to test this, and do you have any other available computers to test it on? If you can tell me which GPU you are using and on which OS I may be able to do some research to see if there are ways around this glitch. The fact that you are running linux may have something to do with it as well.

 

Yesterday after doing some research on potential ways to optimize the edit baking process on large maps I found something rather game changing for the asset. Apparently, Unity offers a function called Graphics.CopyTexture which allows for GPU sided transfer of pixels between two textures.

This in turn allows me to drastically optimize the amount of data that has to be transferred between the CPU and GPU to bake edits, even many edits simultaneously, especially if those edits are contained within a same "chunk" of the full tile map. In earlier testing I found that tile maps (textures) of size 128x128 could be sent to the GPU with minimal framerate drop. A texture of this size, called the Edit Buffer, is loaded with the current tile map data as well as the edit made by the user. This small buffer texture is sent to the GPU, which is much faster than sending the entire tile map, and a Texture to Texture copy is performed to apply the changes contained within the buffer to the full tile map, again with minimal framerate drop.

While this may not be as fast as I think we could get with a Unity provided function that allows changing literally one pixel on a GPU stored texture, or as other way more complex solutions involving C++ native plugins, this new edit baking technique far exceeded my expectations, even without having played around with the buffer texture's size. For "city builder" type games that usually involve very close proximity map edits it would likely be faster with a smaller buffer size, while games that involve large edits would suffer from the smaller buffer.

Below is a video demonstration of this new feature. The edits being made to the map in this video are all real time edits made to the texture storing tile map data. There are no sprite / game object based tiles being applied, which you can see after I minimize the game viewport. In the first part of the video I rotate the cursor around while selecting tiles to give an idea of how much FPS drops just by having CPU based actions as simple as moving the cursor icon to the selected tile. I do it again a bit later in the video while baking edits to show how the FPS still remains well above 500 even while baking edits that are contained within multiple chunks.

​

One final thing relating to the last point I touched on, when multiple chunks are being edited the current process is to simply queue them and bake them one by one. This process, which slows the game for longer when done in a single Update loop iteration, could be smoothed out even further by adding a delay in between each edit buffer baking.

 

After fixing an annoying bug with isometric objects refusing to behaving properly when added as edits I managed to create a simple GUI for the demo scene to select tile types, including tall objects, and apply them to the tile map as edits! While it appear that WebGL sadly does not support the Graphics.Copy feature as of yet, you can check it out in action by downloading the new Windows 64 demo scene or by watching the video below!

​

 

Sorry for the delay in getting back to you.

I noticed that the same memory issues occurred on Firefox WebGL so I changed to chrome, and noticed the same graphical issues in the screenshot above. So I downloaded the windows build and oddly enough, I had the same result.

I'm using Windows 10.
Processor Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz, 2494 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM) 24.0 GB
NVIDIA GeForce GTX 980M

Hopefully that helps.

 

I managed to temporarily get my hands on a laptop with a GTX 970M and it appear to do the same thing. I can't really do any debugging on my side on that laptop since it's not mine but it allowed me to get a better look at the weirdness going on. Here are a few things I've noticed.

Apparently the texture can only be edited in three vertical regions of increasing size.

​

Some pixel data appears to be "stuck" in a wrong state from the very start and cannot be edited. Here I tried to edit the transparent part of the map and a bugged checker pattern is clearly visible.

​

​

At a glance this really doesn't give me any clear indication of what might be happening beyond the fact that tile map data is being wrongly read by the GPU. Perhaps the GPU isn't liking the non square texture and ends up cloning data into and rendering tiles that actually are not actually there, but the bounds of the map seem to be correct.

This is something I didn't have time to check on that laptop and I know it's going to sound cliché but are the drivers up to date? Perhaps this is caused by unity expecting a newer version of the graphics API. I doubt this is it but it can't hurt to check.

In any case, I'm going to be looking into this for a bit and report back when I find out more.

 

Alright so I found what causes the issue but I still have absolutely no clue why it does it on Nvidia GPUs and not AMD. I had a bit more time with the GTX 970M to try a few things and turns out the fact that the tile map data texture is of size 4100x8192 causes an issue with the sampling. Weirdly enough most documentation I find on the topic says that modern GPUs should handle this stuff just fine, which I expected after having no issues on my main computer.

Fow now I can only implement a sort of compatibility mode which will force the true tile map size to use power of two values. The only drawback is that it makes it so the converted coordinate range is of 2046x2048 instead of 2048x2048. I'd really like to find out why this is happening and if there are ways to get NPOT texture sampling working as expected on nvidia so I started a thread on the shader subforum. Hopefully someone with more in depth shader programming knowledge can shed some light on this weirdness.

You check to make sure that it also fixes the issue on your side using this nvidia compatibility build.

 

Well ain't that some rubbish. Looks like your compatibility fix solved it on Windows. If you have the chance to put together a WebGL build for compatibility mode, I can check it on linux.

I suppose this is why they tell us to keep our textures in power of two.

Rad fix! I'm looking forward to a package update, as I think this might be how to fix the issues I was having a month or two ago!

Mad props!

 

Yeah this is all quite weird, still I'm glad to hear this fixed it for you on Windows! I'm going to be throwing together a fixed WebGL build when I find the time, as for the next asset update it should be ready to send in for validation within the next two weeks!

 

The weird Nvidia issue has been reported to unity with a bug reproduction project that causes the error using minimal code, not sure when we'll hear back from them on this regard let alone if a bug fix is to be expected any time soon for this but since the workaround is simple and does the job I'm likely not going to be waiting for this to release next version.

 

I've also updated the webgl isometric demo on itch to use the nvidia compatibility mode, while the browser memory usage limitation still stands it should now work on nvidia gpus!

 

The next update has just been sent for validation and should hopefully release some time next week! By the way I still haven't heard anything back from the issue report I sent about the Nvidia related bug, hopefully they actually received it and will eventually get around to checking my report.

 

Great news, version 1.3 of the asset has released last night!

 

I have just received an update on the NVidia bug from Unity. Apparently the error is entirely due to NVidia drivers and not caused by something Unity is doing, which means I'll have to contact NVidia about this in hopes of a potential better workaround allowing NPOT texture values or perhaps even get them to fix their drivers.

​

In any case I'm glad to finally get an answer on this confirming that this is in fact not caused by me doing something wrong, although a real permanent fix might still be a few weeks away.

​

 

While I have not been posting on the forum recently I've been quite busy adding to the asset, most importantly I've been working on a simple game built with the asset which helps me find features that might be missing in order to allow someone to build their own game without issues. While doing this a few extra helper functions have been added but so far the process has been very smooth which tells me there isn't much of anything important or major missing.

Right now the game is just a simple city builder loop involving placing various sized city tiles in order to generate money which is then spent on other thing such as wind farms and reactors to generate power. Balance isn't exactly my strong suite when it comes to game development so the main gameplay loop is basically over within 5-10 minutes, however I have been mainly focused on adding to the core mechanics so I'll get to tweak this at a later date.

​

One of the features added around this game was the idea of taking game object entities like units, planes, tanks, anything game object based that a regular RTS would allow players to move around the map and giving them some degree of interaction with the shader based tile map. Say for instance you want to add an airbase tile type and have the plane units appear to come out from underneath a drawn hangar. Since the rendering is all done on a single quad / layer we cannot rely on Z layering to put the plane "behind" the hangar sprite. Personally I was trying to hide a missile inside of a silo that can be opened then launched and have it so the missile looks like it actually comes out from the silo.

The solution to this problem is a combined use of the function that allows a tile map position to be converted into unity world space position and sprite masks. Essentially my process went like this : in an image editor I open the original missile silo sprite and use a new layer to start outlining the area I want to hide things behind. I then drew downwards in order to make an area to hide the missile object behind. Since this new texture to use as a mask is not based around a single game world tile it won't just "snap" into place with other tiles. To work around this, in Unity I parent the sprite mask to an empty game object and start the game. I then built a missile silo in the game, hit pause and moved the created sprite mask parent object to the position of the selector, which directly uses the result of map tile to world position function which essentially returns the center position of a tile. From there the sprite mask is moved and scaled in order to fit on top of the silo sprite at the same position it was when I drew it in my image editor.

​

This, in short, gives me a game object to instantiate that can be easily placed at a tile center point and correctly mask the missile object behind or "inside" the silo as it will be launched. The effect is quite neat, as simple as it is, and really gives the illusion that the silo object is actually a hole. Perhaps some slight transparent shadow effect could be applied near the rim in order to enhance the look but even without that I think it looks pretty good.

​

While I plan to eventually release this small game on its own, it will also be included with the next version of the asset as a sample project / reference / example on how to build a game using the shader and it's various utility scripts

 

Well... I gotta say that looks damned awesome! Looking forward to trying out the changes!

 

While working to implement an explosion feature that edits a large area of tiles I discovered and fixed a bug with the isometric tile map edit baking system. This bug made it so that part of the edits were getting lost before being sent to the GPU. This apparently only happens in cases where multiple chunks were sent at once and when "tall" isometric object sprites are being added which caused the chunks to reload tile map data multiple times. Now that this has been fixed, here's a warhead that carpets an area with trees when it goes off :

​

 

Added some more features to the game built around the asset, mostly some visuals that show explosions and some clouds to show wind directions. As far as the asset itself is concerned for the next version I will be implementing Edit Buffers to the square tile maps in order to optimize the edit baking process. I'm still trying to look for ways to get this feature working in WebGL, hopefully a newer version of the API might come sooner or later and allow for GPU sided texture copy on this platform.

 

Here is another feature I've been wanting to add to the asset for a while : Modding support! Right now it supports basic sprite mods replacing the original tiles with ones loaded at runtime from disk, but it would be pretty straightforward to extend this in order to allow for script mods and other custom mod files to be loaded.

​

 

I took some more time out of this wonderful quarantine break and decided to release the RTS game demo in it's current state for Windows 64 bit. You can check it out here.

This release contains the newly added modding support and should allow you to replace any tile sprite with folder loaded mod tiles. Guidelines for making modded sprites are the same as those for making sprites in the Editor, except that the name of a mod file will be interpreted directly as the tile type it replaces in the tileset array sent to the shader. Mods can be loaded at runtime and multiple times, however the original sprites do not come back if you remove the modded sprite it was replaced with from the folder.

 

Here are two new videos showing off some of the latest additions to the RTS tech demo! I've been working on this stuff on and off this last month, adding quite a few features to both the demo and the core asset itself. In the second video I show off the most recent feature I've added, a simple "animation" of some city tiles that causes the light pattern on buildings to change randomly. You can see it more easily if you focus on a certain populated area for a bit. This gives quite a bit of life to the world, as does the air traffic between built airports.

​

Some of the added features not shown in the video include a simple AI that builds a city then starts launching nukes at other players, various UI improvements and a "sector" game mechanic where 3x3 areas containing specific structures deliver resource generation bonuses / handicaps.

​

 

I love the new features. I’m eager to give them a go!!

 

While playing around with the tech demo to test a few things I noticed a rarely occurring bug in the isometric edit baking system causing some positions on the tile map to fail to refresh the correct neighboring edit chunks, which causes edited "Tall" sprite to not be properly rendered until another edit queues the chunk containing the top part of the sprite for baking. This has been fixed for the next update however if anyone runs into this issue ( which may be hard to spot given it only happens at the intersection of edit baking chunks ) just let me know and I will show you the edits needed to fix the issue right away.

As far as a release date for the next version of the asset is concerned I sadly cannot give an ETA more precise than some time next month. I've been neglecting the release of update for my dungeon generator asset for a while so I may focus on this other asset for the rest of the month or at least until I get the latest round of updates sent out for validation.

 

Here is another feature I've added to the RTS tech demo, some modular road sprites using a system similar to auto tiles in order to automatically pick the correct road piece!

 

While working on an improved AI for the tech demo which also acts as a way to stress test the asset in game conditions where the entire map is occupied by edited tiles I identified a memory leak caused by the edit baking system. While I previously thought the RAM usage was rising normally when manually placing tiles, adding a bunch of AI players and letting them run wild made me realize it was eating up way more memory than expected. A quick look at the Unity memory profiler revealed a ton of small Texture2D objects that did not get garbage collected. After some googling I found out that apparently creating a Texture2D as a local field in script creates a new "Asset" that doesn't get the same GC treatment other variables do in such a context. The solution is thus to simply call the Destroy function on this texture variable at the end of the edit baking process.

Even if this may be a bit more on the technical side for most users, it's worth to note this behavior of the engine if you intend on perhaps creating your own custom edit baking system, optimized for your own use scenario in case it would need it.

Now that this problem has been dealt with, here are a few videos showing off this latest progress! First, here is a close up of the AI growth algorithm in action. The AI will add buildings in a particular region until a certain amount of buildings have been added, at which point it will use the cheap road tiles to reach a new region. It's still quite naive but it works quite nicely compared to the previous iteration. One of the behaviors not really shown in this video is the way the AI will build "Airport" tiles on different islands to keep growing their base when the current landmass is full.

​

Since all the optimization I talked about had to do with the AI in a large scale context, here is a timelapse showing the entire map being taken over by a couple of AI players. Even while every AI is constantly making edits ( at a rate much faster than human players ever could ) the FPS remained well above the 120 FPS range. Rendering performance remains untouched and delivers 1000+ FPS when no edits are being performed even if the map has been extensively edited like in the below timelapse.

Note that you might want to watch this one in fullscreen to be able to see more easily the landmass turning into cities from this far away.

​

As I expected I overshot the release ETA I gave last month for next version so I'm gonna stop giving those when I'm not sure on how much time next version is going to take. Whenever I'll be sure a new version is about to release I'll be back to share the news!

 

Hello simply.

wonderful work, I have seen your progress and I was delighted, I was looking for a way to optimize tiles for large worlds, and I found your project, I must say that it looks promising, I hope you can continue adding improvements. Meanwhile I decided to buy the asset, and adapt it to my project.

Keep going, I look forward to seeing your progress.

regards.

 

Here are a bunch of screenshots showing off some new grass to grass cliffs. The map generation algorithm uses the same noise value used to generate landmasses to create 8 distinct height levels. The RTS tech demo AI still works and correctly avoids those cliffs as the tile types making up cliffs are not considered "Buildable". It really adds some depth to the maps compared to the previously completely flat terrain. First screenshot shows the old terrain for comparison.

​

 

Another thing added to the asset, this time it's a core feature of the isometric tile map generator that's been improved. As the size of a tile map increases, the amount of time it takes to generate it becomes so long it almost looks like the game is stuck. To many users this may very well result in them forcefully closing the process after assuming it froze.

To this end, I've added an asynchronous version of the (isometric) map generation algorithm. Essentially, the algorithm will simply return after a set amount of tiles generated and resume at the same position on the next iteration of the whole game loop. This means UI processes like a loading bar and a percentage text can be updated and show that the game is not frozen. It also gives users back the use UI controls like buttons since the click callbacks are being processed like normal.

The amount of tiles generated on each "pass" of the map generation algorithm can be set in the Editor using these controls. You can also see the new height level control relating to the feature I showed in the previous post.

​

By increasing the amount of Async Steps per pass you will achieve lower loading times but less in menu FPS while the map generation process is going on. With the current value of 50000 the game can generate a 1024x1024 classic isometric map in about 30 seconds and gives around 30 FPS in menu. That is very acceptable to me considering I have yet to fully optimize the overall generation process which currently happens in 3 distinct phases that could be instead executed in a nearly simultaneous manner, drastically reducing the amount of iterations needed to generate isometric maps.

 

Hi @r3eckon - As far as I know, async doesnt work on WebGL; is that still the case? Have you implemented fallback support?

 

I'm interested in this asset, but does it work with animated tiles as well? I have a tileset (not big, a 1024x1024 texture with 16x16 pixel tiles). Then for example 3 different tiles in the tileset is the animation of a tree. Would it be still fast, if I update e.g. 10% of the tilemap each frame to render the different tree animations? Of course, for far zoomed out views, I guess I don't have to animate it, the user wouldn't see any difference anyway for a big tilemap.

 

It should work on all platforms as it's technically not true C# jargon async which means it does not rely on threading to accomplish. The idea is to cause the main thread to return even during a long process that has not yet finished. I'm merely keeping track of the tile map generation process to resume it after the UI has been updated to show the amount of tiles generated on the previous iteration and update a loading bar.

Yes the asset works with animations, see the first post in this thread and check out the animated webgl demo on itch.io. The animations work over the entire map and essentially create a whole map quad for each frame of your animations which are then turned on and off to create the animation loop. If your longest animation is say 10 frames long, there will be 10 unique tile map rendering quads with slightly different sprites. As the animations rely on shared tile map data, the only data that has to be different for each "frame" quad is the tileset. One of the downsides is that you do not have fine control over framerate. The whole map has to have animations running at the same framerate or whole number fractions of that speed. like 1/2, 1/3 etc. This is why I would probably not use this for complex animations and my example build is just using a 3 frame loop, but the advantage is that this animation runs over the whole map at all times.

If you need more complex animations running at different speeds when close to the tile map but still want to benefit from the rendering performance of the shader when zoomed out you could also sort of blend both by using small chunked native tile maps when close.

Also for rarely occurring animations like the animated building windows I posted about a few weeks ago, directly editing the tile map with a new tile works just fine for me and still keeps the performance well above what I need. But this is only for a randomly occurring animation, editing only a few tiles at most every 2 seconds or so.

 

Thanks, I bought your asset, trying it now. I just noticed some warnings. They are not critical, except maybe if someone wants to use TMPoint in a hashmap, but might be still a good idea to fix them.

 

Yeah I've gotten around to fix most of those in the latest version, at least the warnings relating to overloaded operators since I used a Dictionary to keep track of built structures in the game tech demo I'm currently working on. A few other errors are fixed in this version but I'm still not sure when I'll release it. If you encounter some bugs check the previous forum posts to see if I've fixed it for next version, if not just let me know about it so I can look into fixing it. Next version will bring a ton of new example and utility scripts built around the game tech demo as well as the bug fixes that were found while trying to use the asset to make a small RTS game.

Since the asset is still very much in early development if you eventually feel like my utility code isn't solid enough for your own purposes, keep in mind that the core shader of the asset can be used with minimal programming. All the shader cares about to render your tile map is receiving a Texture2DArray containing your sprites and a Texture2D representing your tile map data. While the isometric shader is a bit more complex to manage, square tile maps are very straightforward so don't be afraid to go off on your own if you feel you need to.

 

Its absolutely not a big deal, but could we at some point fix the demos to support both input formats?

Code (CSharp):

1. InvalidOperationException: You are trying to read Input using the UnityEngine.Input class, but you have switched active Input handling to Input System package in Player Settings.

 

Is this related to the new input system I believe I've heard about? It's admittedly been a while since I've updated my Unity Editor so I'll have to look into this. Thanks for bringing it up!

 

Alright so I think I found what must be done to fix the issue however since I'm still unsure when I'll release an update the main idea seems to be to migrate the calls to the old input system over to those listed on this page : https://docs.unity3d.com/Packages/com.unity.inputsystem@0.9/manual/Migration.html

So if this problem is too annoying you can refer to the page I linked and replace calls to the old input system in the scripts you're using. I've been staying on older versions for my projects because Unity has been removing (and changing) perfectly good features and I find that quite frustrating. Recently made a new project on 2019.3 and was shocked to find the resolution selection screen removed with no way to turn it back on.

 

Finally got something new to show! During the month of July I worked on revamping the multiplayer code I wrote for Procedural Dungeon Toolkit and rebuilt it into a more modular and self contained asset. I recently decided that this code was now stable and easy to work with enough that I would start using it to implement multiplayer with the shader game tech demo. So far I've gotten some basic lobby features working allowing players to connect to a hosted server, but the part that's most relevant to this asset is the Networked Tile Map Edit feature.

​

While this is mostly going to be a tailor made implementation specific to the game I'm building, the core systems responsible for sending tile map edits over the network and recreating edits upon receiving network data is going to be a part of the next update I release for the asset most likely in the form of a multiplayer demo scene. I know I've previously talked about releasing the tech demo as part of next update, however I most likely will delay adding it to the asset until the game has been released so I may release the next update without the tech demo part. I'm still very much undecided about when I'll be doing that so I may very well change my mind again before then.

Some more specifics about the networked edits implementation : each edit made to the tile map uses 6 bytes of data to be reflected. With a typical sized send buffer over TCP sockets this allows up more than enough edits to be sent in a single go. Much like the edits sent to the GPU are "queued" before all being baked at once if multiple edits are made simultaneously, it's better to wait before sending edits over the network rather than sending every edit as a single packet in order to avoid the extra overhead.

 

This is looking great, keep it up!

 

@r3eckon Is there an instruction manual of some kind to go along with these tools?

 

Yes the asset comes with a readme that details how to make use of the included scripts and GUI utilities like the tile splitter and autotile generator. I had plans to write up a more detailed and polished usage manual but as I've been quite busy with life outside of asset development these past few months I have not found the time to do it. The readme is however very dense in information and I believe I've touched up on most of the main use cases.

Of course you can always send me emails if you have questions that are not answered in the readme and I'll be happy to help. I always end up adding those unanswered question.

To give a bit of a general update to everyone on what I've been up to, the next version is still in the works. As the process of building a game around the asset progresses I have been added a couple new features to the core asset, more recently in the form of various reset / cleanup methods that correctly prepare everything for a new tile map, which I needed in order to make it possible to start a new game without stopping the game process. The Isometric Interaction Manager and Tile Map Manager classes now contain those new methods. The latest build of the game tech demo also contains game saving and loading, which makes use of the existing tile map save file feature.

Still no ETA possible on next version sadly, as I've mentioned I'm quite busy with projects that have to take priority, however I'm still able to slowly but surely be adding to the asset / tech demo whenever possible.

 

Thanks to a user reminding me that the readme doc does not touch up on "from scratch" setup, which is something I have been meaning to do for a while now, I took some time to quickly throw together a beginner friendly video guide on how to start from empty scene and set up the asset for basic single layer square tile map rendering. The video goes from empty scene to working tile map within 5 minutes and goes over a tiny bit of customization at the end by showing how map generator modules can be easily swapped. Anything more in depth about particular components of the asset should will be answered by the readme.

 

hello guys, i can't use it yet, if i write code with its tilemap, can it return the collider tag?

 

I'm not sure I understand. The asset does not rely on native tilemaps. It does not create game objects for each tiles so there can't be special tile type tags with colliders. Unlike game object based tiles of unity tilemaps, the whole map is rendered on a single quad game object. Colliders are dynamic / pooled around the player as needed. They are aware of which tile type they are on in order to be shaped differently or act as triggers instead of physical colliders based on tile type. The dynamic collider behaviors are specified in the TileType.cs class.

 

oh I mean can i detect collisions with tiles by script with this tilemap?

 

Yes, there are script functions that you can use to check which X,Y point on the tile map any world position is located inside of. This is not "collision" detection but since the system can be used to know if a certain point is inside of a tile or not, you can easily use it for collision detection. This is what my dynamic physical collider system uses. The collision part is entirely handled by Unity, I simply built a system to add the correct colliders around the player as they move around the tile map at the right position, as well as the code needed to translate back and forth between tile map X,Y position and world X,Y positions in your scene.

Basically, the collider pooling system will use the position of the "Player" object in your scene and calculate which tile this point is in. Then, the neighboring tiles will be checked for needed physical colliders based on their types ( water tile shave square colliders while trees have round colliders, signs have "trigger" colliders that write random messages to debug ) and the pooling system spawns the necessary colliders. So if the player object is found to be on a grass tile that is next to a bunch of tree tiles, a round collider specific to the "Tree" tile type will be spawned on the tile. In the TileType.cs class you can specify a delegate method to use when the player collides with the spawned collider, this is what signs use to call Debug.Log function. In a real game this could instead call the function that opens a drawn image of a sign on screen with the message written on it.

This spawning position can be found using the reverse function which gives a world position of the center point of any tile. In the game I am working on I use this feature not for colliders but to spawn game objects in the game world that still appear to be attached to the tile map.

 

oh wow, thank you so much bro, i will try buy it :3 because now i don't have enough money

 

No worries, if you have other questions to make sure the asset is suited to your needs just let me know, you can also email me to reach me more quickly since I don't always check the forum every day.