Alternative to Rule Tiles?

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 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:

Code (csharp):

1. // Very, very simplified version of how the built-in RuleTiles and RuleOverrideTiles work:
2. class RuleTile : TileBase {
3.     List<TilingRule> tilingRules;
4. }
5.  
6. class TilingRule {
7.     List<int> neighbors; // rules
8.     List<Sprite> sprites; // sprites
9. }
10.  
11. class RuleOverrideTile {
12.     RuleTile ruleTile;
13.     Dictionary<Sprite, Sprite> replacements;
14. }
15.    
16. // Very, very simplified version of how our replacement works:
17. class RuleSet {
18.     List<Rule> rules;
19. }
20.  
21. Rule {
22.     List<int> neighbors; // rules
23.     List<int> spriteIDs;
24. }
25.  
26. class RuleTile : TileBase {
27.     RuleSet ruleSet;
28.     Dictionary<int, Sprite> spriteForID;
29. }

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.

 

Yes. This was the main goal of our setup. There was some reasons why we wanted to do this:
- It's much easier to understand when painting the world. No matter which tileset the level designers are painting with (caves, houses, ruins, whatever), the same rules apply.
- If we find a bug in the rules we have made, we can fix it once instead of having to apply the same fix to all tilesets.
- Once the system was in place, new tilesets just required artwork, and a single button in a custom editor window. Nobody had to sit down and drag-and-drop things.

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!

 

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.

 

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? : /



https://ldtk.io/