Is Unity Tilesets Good?

This 2 weeks of development time on this game can be summarized as

WALLS

But before I write about that, I want to write what I’ve learned through the last fortnight.

Things I’ve learned through the last Fortnite™

I’ve watched a lot of Nick Chapsas videos about C# and .NET. I consider myself as pretty comfortable with the language. But, I still have a lot to learn, obviously. I’ve only been into programming for about 15 years after all! I have learned about many optimization features and what I’ve been doing wrong about lists and enumerables and such. Not just from Nick though. I’ve watched other youtubers as well. Here’s a quick list of what I’ve learned throughout:

• So much.

Okay here’s a longer list of what I’ve learned:

• Smart enums with methods.
• in keyword makes ref’s immutable.
• Lowering C# (IL) to predict performance. (Great video)
• Dictionary improvements.
• Spans.
• Tuple returns.
• C# can have “unsafe” code which is just C code.
• is null checking.
• Parallel tasks.
• Deconstructors. (NTBCW Disposables)
• Unity has a struct called Bounds (how have I never heard of this?)

About walls again…

How hard could it be to put some walls around our procedural map? It’s not. Probably. I wasn’t able to make a simple rule set that drew the correct wall I wanted, though. So I thought, maybe we should switch to tile sets? Our game consisted of individual tile objects to make a map. Since each tile holds some logic in it, I never thought we should use tilesets since they lack the ability to do logic. Maybe we can sync tiles with objects in the background? Or maybe we could… argh- so many options, game development is hard.

Option 1 - Individual tiles with sprite logic

This was my original idea. Just do a wall drawing logic and instantiate wall tiles around our map. They won’t be walkable or interactable, but at least they are shown and they look really good. Here’s the problem though: Rulesets are hard to implement in the right way. I don’t even know if there’s any “right” way. You could go and check every single tile one by one and maybe write a logic around them, but it’ll be all hard-coded and impossible to change later. What if we want to implement a wall that is interactable? Like, lighting a torch. This made me want to try other ways, but I’ll still talk about what I’ve tried, just in case any of you who read this blog, don’t do the same mistakes I did.

Bunch of if statements

This sucks, don’t even try this at home. Basically I was lazy and switch statement is basically a bunch of if statements for IL. I’ve written a bunch of ifs for walls after getting all of the wall positions, then draw them accordingly. This didn’t work since edge cases are a problem and it’s literal hell to code any extensions (therefore breaks the open-closed principle).

Binary flag checks

This was promising. I basically made a binary logic flag system for checking where the wall is touching. If it matches a case, then it does whatever I ask it to do. It was good at first, but then I realized how I also needed OPTIONAL cases and order of the checks mattered so it was too hard to check left and right walls. I might return to this later.

Looks hella cool though

Just change wall sprites to no-corners

No. I want this design and I’m not admitting defeat yet.

Option 2 - Tiles with GameObjects

Advanced tiles can hold GameObjects. It looks like a good idea at first, but problem arises when we want to separate walls from floors. Floors would be generated and be walkable while walls could just draw themselves around floor tiles to look cool. But, Unity does not have a way to “stack” rule tiles. They don’t work with each other. Adam C Younis has a great video talking about some of his cases of default Unity tileset problems and his first case explains the problems with slope rules. He found no workarounds during the development so he switched to a third party tool for making maps. I also have read about a workaround of basically implementing a rule tile based child object that overrides the checking method to enable other tiles. So in the end, we didn't implement this idea.

Option 3 - Synced tiles

This idea comes from my original tile system. I’ve had tiles saved in a dictionary of Vector2s and Tiles. Whenever I needed a tile, I just needed to write Vector2(1,1) and dictionary gave the corresponding tile back to me if it existed. I could also do quick searches with Linq (dictionary and linq idea from Tarodev, check him out he’s great!). I could’ve just made a tileset drawn on the map and sync their position with my own tiles. This could work, but this generates a different problem. Code getting more complicated.
Basically whenever I need to swap the sprite or draw a tile, I also need to change the tileset. I’ve had checkered pattern on the tiles by changing the sprite alpha and now it cannot be done since drawing is not handled by my own game object. So I decided against this option either.

Conclusion

Unity’s tileset system is very limited. It is quite powerful especially with the composite collider and such, but very limited. If you need to make your own levels, go for it. It’s simple enough to build your own levels effortlessly but complicated enough to do cool things. But when you want to do more, you need to go your own ways to, by Adam’s words, “Work Against Unity”.
For now, I think I’m going to revert back and stick to my own game object logic and stay away from Unity’s tileset system. Our game does not need a collider on tiles and I do not need an optimized tile system.