I switched to Godot purely because of Godot’s friendly auto-tile system. It’s quick and simple to set up compared to the rule tiles in Unity. However, I ran into some other limitations that have made me reconsider using Unity, but the rule tiles drive me crazy and are very time-consuming to set up.
Does anyone know if there are any rule tile alternatives or really good auto-tile packages?
(rather avoid writing my own auto-tile system if possible)
Hi @Zenov ! I’d love to hear more details about the end result you were trying to achieve with auto-tiling in Godot and Rule Tile in Unity. At which point did you run into something that slowed you down or blocked you? What made auto-tiling friendly? Finally, which limitations in Godot made you reconsider Unity? It’s especially useful if we can get the nitty-gritty so that we have a clear understanding of your intended workflow. Also, images would be super-useful too! Thank you! 
Hi Rustum,
I’m working on a top-down tile-based RPG. With Godot, I can quickly paint the bitmask onto the tiles instead of having to click on each tile multiple times like the rule tiles.
Also, the tiles are laid out nicely as a sprite sheet instead of a long messy list. The rule tiles are just tedious in comparison.
It’s also a lot easier to make mistakes with the rule tiles and there is a “select” label that covers up part of the tiles so I can’t see one corner.
It literally takes me only a few minutes in Godot compared to the hour it takes to set up with Unity. Swapping out tilesets is also a breeze. It’s just an easier-to-use workflow overall.
What brought me back to Unity was the AI navigation and pixel-perfect rendering. Godot 4 may solve these issues, but I don’t want to wait a year for a stable release.
If it’s useful to you @rustum , we use RuleTiles extensively in our current production (10 person ish team, 3 year production), and we found the way you edit them so inadequate that we wrote a complete UI replacement.
Our rule tiles almost 500 different sprites, many with unique rules, some with shared rules. There’s also a few variants of each rule tile (one for sloped tilesets, one for blocky).
Understanding and having an overview of the rules would have been impossible if it was just a long list of rules as in the built-in RuleTile UI. We tried to do that with much simpler rulesets than we have now, and our brains broke. Making the rule override tiles was the most tedious exercise in drag-and-dropping I have been through in my life. That could be solved by automation, but the core UI issue couldn’t.
The core insight that made things a million times better was to make a UI where you see the whole texture you’re turning into a rule tile, instead of just a list of sprites. We click a sprite in that texture to select it, and then get a UI for what rule that sprite should have.
This is the inverse of the built-in workflow, as we select sprites and assign rules instead of selecting rules and assigning sprites:
This required us to implement a restrictions that might not be desirable for everyone: each rule tile has a single texture. No having a rule tile spread over several textures. The artists did this on their own anyway, so it wasn’t really a problem for us, but maybe if you’re putting these together from stuff off the asset store it might be a problem?
Anyway, this was a huge win as we were able to understand our rules in the context of the image, and we ended up with a really good workflow for designing the rules.
We also set up the whole way of sharing rules completely differently, as we found RuleOverrideTiles very cumbersome and essentially something that came out a poor initial design. We have instead split the set of rules and the set of sprites into two different types, so the rules can be reused. Here’s a simplified code overview:
// Very, very simplified version of how the built-in RuleTiles and RuleOverrideTiles work:
class RuleTile : TileBase {
List<TilingRule> tilingRules;
}
class TilingRule {
List<int> neighbors; // rules
List<Sprite> sprites; // sprites
}
class RuleOverrideTile {
RuleTile ruleTile;
Dictionary<Sprite, Sprite> replacements;
}
// Very, very simplified version of how our replacement works:
class RuleSet {
List<Rule> rules;
}
Rule {
List<int> neighbors; // rules
List<int> spriteIDs;
}
class RuleTile : TileBase {
RuleSet ruleSet;
Dictionary<int, Sprite> spriteForID;
}
This makes it very, very easy to create several rule tiles that have the same rules, but different textures. The ID is simply generated from the x/y position of the sprite in the texture, and then we’re off to the races. We have a button that the artist can press to set the correct settings on the texture, create a new RuleTile, and assign the RuleSet and spriteForID dictionary.
There’s also a slight memory win. In the built-in case, you always need the sprites for the original RuleTile loaded in order for the RuleOverrideTile to be able to resolve it’s rules. Since we’re sharing the rule asset instead of overriding sprites, we don’t need that at all.
@Zenov & @Baste : Thank you for the insights into your processes! I especially appreciate the additional detail on how the current setup is challenging for your goals. We will consider these points when we plan for future improvements. Thanks again!
Thank you @Zenov and @Baste ! I agree with Rus. These are all great feedback, super useful! The screenshots help so much too.
I have some super basic follow-up questions:
I find the approach of decoupling the set of rules and the set of Sprites really interesting as this allows the rules (and I’m assuming the rule tiles variants as well) to be reusable on any sets of Sprites. Is that correct?
Q: Did you guys have any use cases where a set of Sprites require more than 1 set of rules?
I also like the approach of editing rule tiles in the context of the entire texture and the inverse workflow where you select a Sprite to edit/assign the rules.
Q: Could you also help me understand a bit more on what you mean by “No having a rule tile spread over several textures.”? And how did you guys/the artists overcome this restriction?
Thank you!
Yes. This was the main goal of our setup. There was some reasons why we wanted to do this:
No. We support different kinds of rules (in theory, we haven’t tested it), but we never got around to needing any more than the initial ruleset once we introduced sloped variants.
Note that we ended up using Tilemaps less than we had anticipated. I’d say our level geometry is split something like 60% SpriteShape, 30% Tilemap, and 10% just SpriteRenderers. If we had been making a more blocky game (Ie. if we were remaking Teslagrad, or something akin to Celeste instead of making our current game), it might be that we’d want different kinds of rules.
Simply that all the sprites that a rule tile reference originate in the same texture. For normal rule tiles, you could have a bunch of different textures provide sprites for the same rule tile. You could for example have all the left walls in one texture, all the right walls in a different texture, and so on, and combine the sprites from those textures into a wall rule tile.
We instead have to have a single texture that has all the sprites that goes into a RuleTile. But, hey, that’s what our artists were doing anyway (in order to be able to apply Photoshop filters to all the tiles), so it’s not a problem for us. I mentioned this as it might be a problem for other teams - especially teams that were sourcing their sprites from the asset store or somewhere else online, and wanted to mix-and-match the stuff they have bought/downloaded. In those cases having to combine them by hand into a big texture would be annoying.
Since we have to see the entire texture when we’re editing the rule tile, we don’t support that at all in our UI. The backend supports (it’s just a list of sprites), but our UI don’t. I suppose it would be possible to make a UI that supports multiple textures with different sizes, but we didn’t!
Thank you so much @Baste , these are really great points! Thank you for helping me to understand all the advantages and reasoning to these approaches. These are super! I’ve feedbacked this to the team and also noted them down in our ProductBoard so that we can take all of these into consideration as we continue to improve the system.
Yeah so true. This approach sounds scalable to N number of textures too with the necessary UI support.
It’s also interesting how you mentioned the art ratio too. Just out of curiosity:
Q: How do you guys decide when to use SpriteShapes or Tilemaps? Do you guys ever blend any SpriteShapes with Tilemaps together to generate more texture permutations/variations or to save texture costs? Or does your team use them separately for different parts of the Scene?
It’s nothing complex - we use Tilemaps if it’s appropriate to have blocky geometry (90 or 45 degree angles), and SpriteShapes when it’s appropriate to have slopes. So generally Tilemaps goes in man-made structures like houses and whatnot, and SpriteShapes goes in hills and caves and whatever.
There’s also practical things - like if we have a decent grass SpriteShape, but not any grass Tilemaps, and we need some flat ground, we’ll just use a flat SpriteShape rather than making a new Tilemap.
So far, none of our choices about using Tilemaps or Spriteshapes has been based on texture costs. We’re not targeting mobile, so we have a lot more flexibility there than a lot of your customers 
Having them join is generally hard, so wherever there’s a transition we generally just let the SpriteShape go on top and cover up the edge.
Very cool! Yeah, these are very reasonable and practical decisions. Exactly like you said, SpriteShapes are better suited for more organic and malleable terrains.
Right! This definitely gives a lot more artistic freedom.
Very true on this point too. Thanks for all the super helpful details!
I just wanted to chime-in and say I’m encouraged to see the Unity Product Designers being receptive to alternatives to the current RuleTile system. I’m coming from Godot where making the equivalent to RuleTiles (Terrains) is SO quick and easy (even better in Godot 4 with also being able to paint collision masks, pathfinding masks, custom data, etc. onto individual tiles), It’s actually demoralizing to have to slog through the current RuleTile creation process.
LDTk is great example of good rule tile editor too,
just paint your tiles into that template, and its done.
(and then can of course edit advanced settings and those neighour tiles in advanced settings)
would be nice to have something similar in unity… so save time from having to make custom rule tile editor? : /
