You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a simple proposal to ease the whole tileset creation system. I don't know if it's the best idea but I think it might be worth some eyes.
I was thinking about ways to create a tileset importer when I thought, why can't we just create a new resource.
So tilesets are just a Resource Type and that we use in the TileMap node. But can't we create a new Tileset Resource in which we can just give it the spritesheet and ask it to generate the tiles for use and then we can edit them. Add collision and stuff.
And with the improvements to the inspector that have been done it will be quite a reasonable way to create tileset.
Here's some examples,
I created this script to generate tileset using the API already in place, but I would love to see a more integrated and advanced version, where we can open the tiles in a separate editor window, add collision shape and occluder with relative ease.
And more features like that. That can make the whole process easier while still maintaining backwards compatibility too, or atleast we can create a new resource type while still allowing the older resource to be usable.
And I don't think it will be so hard to do. Although I have yet to see the tileset's C++ code, for myself.
The text was updated successfully, but these errors were encountered:
The ability to generate and edit tilesets is rather painful. What follows may be a little ranty.
With generation, the biggest issue is that while you can create tileset resources themselves, you can't actually create tiles within those tilesets. Editing parameters is tedious, and using a scene to generate or modify tiles feels like a clumsy hack at best, yet it's currently the only option outside of a text editor or third party programs (by which I mean the Tiled editor, maybe, if it's compatible). The editor for autotiles isn't too bad, but defining the shapes as polygons is A) Tedious and B) Can't possibly be optimal from a performance standpoint.
Even using tilesets is a bit of a nightmare. When inspecting the tiles at my disposal, I want the representation to be a compact grid. The only time names are relevant is if I've got an absolutely massive list and I'm trying to search by name, and if that's the case, I definitely don't want a sparse grid with text labels under every tile. Further more, if I feel the need to reorder tiles, I should be able to do so painlessly.
Autotiles are a step in the right direction, but using them is a painful, mainly because I can't lock existing tiles. I think this might be one of the things that's getting improved on 3.1?
Tiles and tilemaps are the lifeblood of a lot of 2D games. But they need a lot of love. I'd probably dig through Godot's source myself if I didn't think it'd be easier to just construct a specialized program for the sole purpose of creating and editing them.
@vpellen I think that auto-tiles might be the step in the right way but they are far below the standard for anything that is required in a proper game engine.
I did like a more simpler and more easier and friendlier way of design for it.
I have a simple proposal to ease the whole tileset creation system. I don't know if it's the best idea but I think it might be worth some eyes.
I was thinking about ways to create a tileset importer when I thought, why can't we just create a new resource.
So tilesets are just a Resource Type and that we use in the TileMap node. But can't we create a new Tileset Resource in which we can just give it the spritesheet and ask it to generate the tiles for use and then we can edit them. Add collision and stuff.
And with the improvements to the inspector that have been done it will be quite a reasonable way to create tileset.
Here's some examples,
I created this script to generate tileset using the API already in place, but I would love to see a more integrated and advanced version, where we can open the tiles in a separate editor window, add collision shape and occluder with relative ease.
And more features like that. That can make the whole process easier while still maintaining backwards compatibility too, or atleast we can create a new resource type while still allowing the older resource to be usable.
And I don't think it will be so hard to do. Although I have yet to see the tileset's C++ code, for myself.
The text was updated successfully, but these errors were encountered: