Tile_config is "legacy"?

Game Talk The Toolbox
1

Hi!

I’m making a tileset. In Cataclysm-DDA/TILESET.md at f17115a89ed8b08f7f13bed0a4d6fa5d09e446a7 · CleverRaven/Cataclysm-DDA · GitHub “tile_config” is under “Legacy tilesets” and it says:

“Prior to October 2019, when compose.py was made, sprite indices in tile_config.json had to be calculated by hand.”

All of the tilesets that came with the game use tile_config. Are they using the “legacy” method? Writing a tile_config file is a time-consuming task. I don’t want to start doing it if in a month or a year I’ll have to switch to the new method. What is the new method? If it was explained in TILESET.md I didn’t understand it. I’m not a programmer. I learned to use tile_config by looking at the other tilesets. Is there an example of a tileset made using the new method?

Thank you!

2

The new method is we run a script that make tile_config automatically without having to do it manually.

Here the github where the tileset included with the game are made CDDA-Tilesets/gfx at master · I-am-Erk/CDDA-Tilesets · GitHub you can see how stuff are organised in the gfx folder. To make a tileset you need to irganise your spirte in a similar manner and run the compose.py script that will make the tilesheets and the tile_config.json automatically from your individual sprites

3

Thank you for clarifying!

So every sprite needs its own png and json files? How do people work with hundreds of sprites all in different files? :thinking:

4

The json files are not always necessary, if you name the png file of the sprite with the id of the stuff it represents that’s enough for the script to work.

5

How do artists work with hundreds of sprite files? What if you want to change the color of wood and 500 sprites have wood in them? Surely no one would open, edit and save a file 500 times just to do this.

6

You can edit tilesheet itself and then use the decompose.py script to turn it back into individual sprites. There is also another script to associate a smaller subset of sprites into a sheet but I forgot its name.
But so far that problem did not really come up. It would be pretty weird to suddenly need to edit 500 sprites at once

7

The example I gave isn’t weird at all. Changing the shade of a material like wood or concrete across all sprites is totally within the realm of what an artist might want to do. Does the new method not provide a convenient way to do this?

8

If you have a compositing tileset, you just change all the sprites and rerun compose.py. If you don’t have a compositing tileset, you run decompose.py on your tileset to produce a compositing tileset and then refer to the previous sentence.

If you’re asking “how do I know which of my 10,000 sprites have wood in them so I know which ones to change” then you’re asking a question beyond the scope of tile_config.json and the associated tools. Tileset authors are assumed to know what style of sprites they want for the various game entities. Currently, we don’t provide many tools to give artists more information, though admittedly I think this is the first time it came up.

9

Thank you for helping out! I’m asking:

  1. How do other artists work with 10,000 sprite files?
  2. How is it better than working with one or several tilesheets?
10

because instead of manually making the tilesheet bigger and keeping track of where each sprite is in the sheet to write manually in tile_config, you just make your sprite, name it, drop it n the folder and you’re done.

11

As soon as you write something with additional tiles, like:

        {
          "id": "t_splitrail_fence_season_summer",
          "multitile": true,
          "fg": 1272,
          "bg": 1713,
          "additional_tiles": [
            { "id": "center", "bg": 1713, "fg": 1257 },
            { "id": "corner", "bg": 1713, "fg": [ 1259, 1261, 1260, 1258 ] },
            { "id": "t_connection", "bg": 1713, "fg": [ 1269, 1271, 1270, 1268 ] },
            { "id": "edge", "bg": 1713, "fg": [ 1263, 1262 ] },
            { "id": "end_piece", "bg": 1713, "fg": [ 1265, 1267, 1266, 1264 ] },
            { "bg": 1713, "id": "unconnected", "fg": [ 1272, 1272 ] }
          ]
        },

you’re going to find yourself asking whether you continually want to count sprite offsets and get stuff wrong, or replace those numbers with sprite names and let compose.py figure out the sprite offsets. And even if you decide you want to count sprite offsets yourself, what are you going to do when something gets obsoleted and you no longer need its sprite or when you decide to add a variant sprite for a monster or piece of terrain? How much time do you want to spend recounting your sprite offsets?

I’m not a sprite artist; my contribution to this part of the project was writing [de]compose.py[1] and some clean-up of the spreadsheet that the Ultica team uses to track their progress on completing sprites. I don’t know how artists work with 10,000 sprite files other than to say it seems to be easier than working with 4-17 individual sprite sheets like Chesth0le or SomeDeadGuy used to be doing.

[1] Didn’t say I wrote them well, but int_ua seems to have them well in hand now.

12

Thanks again!

I still need to understand how others work with individual sprite files. With my current knowledge and tools it would still be easier to use sprite sheets – even with the inconvenience of keeping track of the sprites and writing tile_config manually. I assume others are using a tool or workflow that I’m not aware of. Any idea how I could reach an artist or two to ask them?

13

There’s a semi-active discussion of spriting and tilesets on the Discord CDDA development server, and there should be a link to it around here somewhere.

14

Thanks! I’ll try that.