$12256 / $11500
There are a lot of tilesets and images with individual frames of animation on this site, but every programmer who wants to use them needs to recreate the information which specifies which tiles can be adjacent to which other tiles (and in which direction), the x, y, width, and height of where a tile is in the larger image, or which frames of animation can follow other frames.
It would be great if there was a standard plain text file format for specifying all that information, and a spot in each oga entry where either the original artist or other users could upload it- what does anyone else think?
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
This is a good idea i'm surprised no one has suggested it before. I think making a standard is a good start.
Actually, we sorta brought it up when we uploaded the Abuse graphics.
I think it would be great if someone thought up a good format. My preference would be something that is extendable with arbitrary attributes and is easy to parse. JSON is (relatively) human-readable and many languages can read it into easily-manipulated objects and write it back, and it is freeform enough to allow you to add attributes as needed.
Anyone up for designing this?
I'd vote for JSON, too (+human readable, +wide support, +convertable to XML, ...).
Let's start finding attributes for image (sprites/tiles) objects:
Image:
Using standard tags would make tilesets interoperable but they could be translated somehow, too. An Image id can be replaced by adding a unique tag to the tag list. east/west/north/south may change when using, say hex tiles: north, northwest, west, southwest, southeast, east, northeast.
For animation I would assume individual animation objects which reuse images.
Animation:
To animations attributes may be added for side effects (display text, invoke function, start sound) which may be game specific. Frames may be objects again containing the metadata for a frame (static offset and hotbox of the Image could be overridden).
Frame:
Of course not all attributes are always required but specifying more increases reusability.
[Edited 2011 01 04: added Image.file, Image.scissorbox,described 2d box]
[Edited 2011 01 11: left, right, etc tags renamed to west, east, etc]
Moved this to the Feedback forum.
I would take a look at what the editor Tiled expects, and use that.
As far I have just seen Tiled only expects a tileset image and information about individual tile-locations on that image. I've added that to the proposal above: You may now name a file for the Image and set a scissorbox to select a tile. Several Images may name the same tileset-imagefile.
And as far I have seen Tiled allows yourself to set any user provided properties - the proposal allows that, too. And on automatic conversion the attributes would become user provided properties to Tiled. For other editors: Load in any language and spill out xml or whatever. Or map 1:1 to xml and use xslt to convert to any other format. But yes it is wise to provide an initial converter to the Tiled format so that the standard format can be useful right away.
[BTW we may say that JSON and XML both conform to the standard and are just dual representations of the same thing - the later beeing the 'compiled' format and JSON the 'source' format for artists and human interchange on OGA]
IMHO it is better to make a superset with more metadata than just what one program expects. In this case binarymillenium specifically needs more metadata to connect tiles and ceninan pointed out the use of metadata for animations. And there is always the option to convert formats - except when data is missing.
I feel like I was having a discussion with some other folks at one point and discovered that there's already a standard metadata format for art. If this format already has the fields we're talking about (or can be extended to contain them), then it might be best to look into it. I just need to remember who it was that was talking about it. :)
Just found this meta-data-related info: http://www.frogatto.com/?p=290#more-290
It is about Frogatto's way to use multi-tile-patterns (MTP) - ie. building a larger tile out out of smaller 'tilelets' (with random variation). Noteable is that images may be doubled/replaced by others (with random chance).
On the one hand, this would probably be very convenient for projects. On the other hand, it seems like it would add a fair amount of logistical work for the artist beyond the standard formatting, which is something of a pain--just doing simply image masks is a pain and adds a fair amount of time onto a piece.
Yes, adding semantic information is a daunting task - I tried to test-write metadata for my street-tileset and just like http://www.frogatto.com/?p=290#more-290 suggests: It is an data explosion even for small tilesets - getting worse the larger the set gets. That's why we need standards and tools.
We aren't talking about artists on OGA writing metadata for submissions by default. Maybe Feedback is the wrong place - could be under "Programming - Procedural Content Generation".
Nobody forces an artist to do write down metadata (at least not my intention...yet ;) - it can be retrofitted by caring developers or using simple tools. BUT to create metadata a developer may need the original artist's help. Because the artist knows his tileset better (metadata == canned knowledge). Speaking for myself: Sometimes I can't discern head and tail on a complex tileset. Which ones are supposed to be adjacent? Which one is in which layer? Which one is an alternative to which other? How do I build walls and corners? ...
But I don't want to talk about yes or no, I'd like to talk about where to go. It's actually quite curious to think about it that there is no adopted standard for anything like this after so many years of tile-graphics. I'm sure it was done several times in proprietary game-map-editors and even open projects but general purpose open map-editors and formats are still where they where decades (+flashy gui) ago. Just think about what we got format-wise: tga, jpeg, gif, png,..., mp3, ogg, ..., avi, divx,..., obj, VRML, X3D, ..., XML, HTML, RSS, OWL ..., and not a single standard format for Map-editing and tiles? Don't even mention metadata. Search the internet and you will find this very forum page. Maybe now - that tile graphics are mature and with a need and the means for collaboration - it's the right time.
Assuming there would be a standard metaformat then mapeditors like Tiled could support creating portable metadata through clicking here and there to link tiles and assign tags. And then a mapeditor may suggest you which tile to place where and speed up mapediting in a smart way. Or it may autoplace some patches. And one task at hand is automatic/procedural map generation which relies on metadata either hardcoded-throw-away (nay) or metafile-based (yay). And finally new game projects may rely on standards and standard libraries to ease efforts.
This is a huge effort but to those interested: Start it by collecting data and building a hub right here!
[\political campaign]
Tiles metadata would be very usefull for procedural random map generation too.
Tiles should have a code ABCD corresponding to the 4 parts of the tile :
AB
CD
A, B, C or D would take their values in [0:number of layers -1] and there would have (number of layers)^4 (power 4), different tiles possibles. Generation algorithm / suggesting algorithms for tile selection would then use these data for their algorithms. You could even have some themes with this.
Q: Creating metadata for tilesets to automate mapping is a daunting task, what could be done to make it easier?
When you (you reading this) got a map and a tileset then the map already contains a lot of metadata waiting to be extracted.
Q: How?
A map-editor like Tiled could promt you for tile-tags (ie. unique tile name and other describing tags) then it may extract metadata from an example map:
Which tags or combination of tags where used on which layer?
Which neighbouring tags does a tagged tile have to the east, west, north, south?
Which neighbours on the layer above and below the tile?
This may be aggregated to add additional metadata to single tiles - which then again can be used to autocreate maps or assist in editing. Just like learning from examples.
wow, while this certainly sounds like a great idea, from an artists perspective I find it massively daunting. I make textures and models, sometimes I turn them into tilesets, but if I had to learn a whole new metadata language to do so, I'd be much less likely to make any at all. If this gets implemented, it better be easy for artists to understand and implemet, the idea of tagging in tiled seems good, but it still seems like a waste of my time, what would you prefer me to spend my tile on, applying massive metadata tags to existing art, or creating new art? One sounds fun, the other, not so much.
It seems to me, as it so often does when working with FOSS games, that there needs to be a whole bunch of volunteers, who don't have artistic or programming skills but still want to help make games, that can be given these inbetweeny tasks. I really think a central job board type site, that lets programmers, artists and volunteers get together would be a major boon to the FOSS community.
As a sidenote and disclaimer because this topic should be in the Procedural-Content-Generation-Forum: We aren't talking about mandatory OGA-submission standards for tilesets - but maybe what may become an OGA-standard for metadata - we want to get more out of available data for PCG, rapid game development, or even gamemakers and as a sideproduct mapediting-ease. Where the last two probably are the killer-apps for metadata to reach critical mass. Come tools, come standards.
@p0ss: I understand your arguments and will take them into consideration - that's why I talked about automatic metadata generation given a map and a tileset. But whoever it does: It can't be too much to expect them to give a tile at least a name (ie. an individual unique tag) and *maybe* even some more tags to describe it (*). It would be best if this could be done in a mapeditor, where and when the map using these tiles is created. The actual writing of a metafile could then be automatic. But of course somebody else could do these "inbetweeny tasks", it would be just one step in the pipeline.
(*) just something like "mygrass0, grass, summer, dry", or "mygrass1, grass, summer, wet" will do - other fields of the proposal above could be generated automaticaly from the fact that these two tiles are (or aren't) neighbours on a given map. It could even be reasoned (automatically) that a wet-tagged grass-tile is never placed beside a dry-tagged grass-tile. It may even be a better idea to have neighbourship probability instead of binary yes/no. But these are technical considerations.