> Universal and agnostic: compatible with all languages (not only Haxe) and game frameworks in the world
Does anybody who is experienced with game dev understand how exactly this is true? There must be a lot of engineering work between parsing the JSON and having a playable level in ones engine, no?
The output file is pure JSON, and I tried to make it legible and easy to parse for quick use cases. So it should be quite simple for any game dev out there with basic parser knowledge to make its own importer. But at some point, I plan to try to have a proper "official" importers for major engines, to make devs life even easier.
Curious to hear if you think there'd be value in a lossy conversion to Tiled XML/JSON as well. It might help with adoption if developers can take advantage of existing loaders, even if it's not perfect.
That said, I don't know what the amount of work would be, especially if the two formats make different decisions on how to do things.
I build Planimeter’s Grid Engine, and we use Tiled for our primary implementation, which also has a terrific generic map abstraction that aligns well to multiple types of level design and game engine architecture.
While there is a bit of work one has to do, there isn’t as much as you’d think. If one has enough engine level code implemented already, multiple map formats are feasible.
> There must be a lot of engineering work between parsing the JSON and having a playable level in ones engine
Yes (btw., if this wall of text already seems iffy, there's a convenient TL;DR at the bottom end), making a level playable involves many things which such an editor doesn't even touch. The game logic updating game states, enemy AI, pathfinding, physics, rendering, audio …
Whereas this “just” puts tiles into grid cells in layers. But: There's a UI that lets you quickly pick the type of tile you want to place next. And it doesn't have to be one particular sprite; it could be a collection of variations from which each grid cell receives one at random. And then you can undo that last one you accidentally misplaced. Then you can select a region, move it a few clicks over, copy and paste, etc. You have a UI for adding meta-data — e.g. ‘this region is tagged to trigger cut-scene #3 when entered’ — actually implementing that functionality in your engine is still up to you.
So how is this universal, agnostic, compatible? Good question. Now, disclaimer: I haven't actually looked at LEd yet beyond quickly skimming the above-linked site; I'm just a little familiar with relevant concepts from having come across similar tools (e.g. mapeditor.org, mentioned in andrewmcwatters's sibling comment). Check out the animation at the top of the linked page — note that when the user changes a particular tile or region of tiles, there are additional tiles adjacent to the edited region also changing. This sort of convenience saves a lot of time when editing levels, and with the right set of tools, you can get this almost for free.
Here's how: There are certain quasi-standard ways of laying out related tiles within a tile sheet (i.e. an image file / texture atlas with an implicit regular grid of rectangular cells) where you know that if you hand a graphics artist a template and they fill everything in with their pixels, every combination, transition, edge- and corner-case will have been handled. For example, if the tile at (3, 3) is land (some_enum.0) and the tile at (4, 3) is water (some_enum.7), you want a land graphic with a coast on its right edge and, to the right of that, a water animation with waves on its left side. As the tile sheet layout is well defined, so is the algorithm for translating that situation into the concrete offsets into the tile sheet where the respective tile graphics will be found. Someone might still have to implement that algorithm, but in an Open Source scenario, this only has to be done once for a given engine or graphics tool, instead of starting from scratch for every single game project.
As I was in a bit of a hurry and the above attempt at an explanation turned out quite vague and potentially confusing, I meant to offer a quite fun way of accessing much better illustrations of the concept: Look into the new-ish technique of wave function collapse! For a quick intro to the basics, see [0] or [1]. Alas, the particular implementation that very clearly shows how this is related to mapping the types of adjacent tiles to coordinates in a tile sheet stubbornly refused to show up even after a quarter hour of furiously searching the web and my bookmarks. Add ‘game‘ and/or ‘tiled‘ to that search term and you'll get a bonanza of interesting thesis papers and talks by pro game devs. I hope that skimming the abstracts for some top search results will get the point across.
Quick bonus tangent: Perusing Sebastien Benard's 2019 GDC talk on Dead Cells[2] is an absolute must. Unfortunately it's completely unrelated to the above-mentioned topics, even though Dead Cells does make an appearance in some of the relevant literature; but if you're at all interested in game design, it's way too good to not mention.
Summary: Implementing the enzymes that let your engine digest the output of your JSON parser will be a non-zilch amount of effort, but it's much less work than inventing a level editor from scratch. Or, paraphrasing poet/philosopher Fatboy Slim's sampling of some ancient IBM commercial[3]: “People[4] should think; machines can do the work.”
𝗘𝗱𝗶𝘁: In case you hadn't decided already: I'm a complete idiot. Hours before I even showed up here, bdickason† already mentioned[5] the relevant term of art: auto-tiling. Go look that up.
Does anybody who is experienced with game dev understand how exactly this is true? There must be a lot of engineering work between parsing the JSON and having a playable level in ones engine, no?