Allow multiple versions of the same tile? ($30 on Bountysource)

[sparr]

While implementing #11823 it occurred to me that it would be nice to have multiple versions of the same tile. Walls with graffiti, lopsided trees, etc.

Simply replacing each sprite number with an array of sprite numbers to be chosen between is a simple idea, but perhaps too simple. Some alternatives should be more common than others. Maybe we could just hard code a probability curve? first sprite 80%, second sprite 16%, etc.

Also, keeping the view consistent would be important. I'm thinking the random selection could be based on the global X/Y/Z coordinates of the tile. Are there any non-cryptographic hashes that are fast enough to put inside the tile drawing loop that would produce results that don't appear patterned to a human if they just lay down a solid block of those tiles?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Chezzo]

I would love this! I was going to use the multi tile end piece for graffiti on walls cause it mixes them in pretty randomly. Your way is better! And works for everything, not just walls.

[sparr]

@Chezzo if we went with a static % for each provided tile, what would make sense to you?

50%, 25%, 13%, 7%, 4% ... ?

66%, 22%, 8%, 3%, 1% ... ?

90%, 9%, 0.9%, 0.09% ... ?

[kevingranade]

Why not per-tile weights?

[sparr]

Per tile weights is the most flexible, but also makes the JSON structure significantly more complex.

[sparr]

It was suggested in another discussion that the weights simply be 1/N, and if the tileset designer wants to make one sprite more common they can just list it multiple times:

[1000, 1000, 1000, 1000, 1000, 1000, 1000, 1001, 1001, 1002]

70% 1000, 20% 1001, 10% 1002

(this came up when discussing adding this sort of functionality to the mapgen json)

[Chezzo]

While the above is more versatile, if we are worried about readabilty, we could have two or three booleans, equal, uncommon and rare.

[sparr]

Where would the booleans live in the data structure?

Here's what it might look like with weights for three different foregrounds, each with four individually rotated sprites:

'fg': [
    {'weight':90,'sprite':[1000,1001,1002,1003]},
    {'weight': 9,'sprite':[1004,1005,1006,1007]},
    {'weight': 1,'sprite':[1008,1009,1010,1011]}
],
'bg': [2000,2001,2002,2003]

[iguanaman]

Would it be possible to update the title with the bounty tag and amount? Currently @ $30

https://www.bountysource.com/issues/10279028-allow-multiple-versions-of-the-same-tile

[sparr]

I can't change the label, but I changed the title.

I'd like to reach a consensus on the approach to probabilities before someone implements this, though.

So far the simplest option that has come up that still allows all of the flexibility is to just allow the list to have repeated entries and pick from all entries with equal probability.

My favorite is the one where we make fg and/or bg into a list of objects with weight and sprite keys. This is the most extensible in the future, such as if we want to add conditions to certain sprites.

[iguanaman]

The best solution I've seen so far is the example you posted last. With the weight and sprite as one object inside an array.