LEd: Open-Source 2D Level Editor

My 2 cents on this one :) The Haxe core team is made of great coders, but not so great marketing guys. On day one, a proper game engine with decent documentation should have been a thing, but yet, as of today, it's quite rough to get into Haxe. I've tried to do my share by posting some tutorials, guides & open source projects (like LEd or GameBase), but it's a long road :)

A few notable game projects that use Haxe --

- Spellbreak: https://playspellbreak.com/en

- Dicey Dungeons: https://store.steampowered.com/app/861540/Dicey_Dungeons/#ap...

- Northgard: https://store.steampowered.com/app/466560/Northgard/

- Papers Please: https://papersplea.se/

- Brawlhalla: https://www.brawlhalla.com/ (for the console ports)

It never quite took off and exploded on a Unity/Unreal scale, but it's a solid sleeper hit in a bunch of places you don't expect, and steadily growing. It's in a much more mature place then when I started using it years ago.

Why would you think it failed? I'm a heavy Haxe user myself since I'm developing https://rpgplayground.com in it.

Since the years I see more and more people using Haxe, including recently Pokemon Sword and Shield (for scripting) and Spellbreak (on top of Unreal Engine)

> What happened with Haxe, where did it fail?

Who says it failed? Haxe is alive and well, even if it isn't a mainstream programming language. Even the latest Pokemon game used Haxe!

> What happened with Haxe, where did it fail?

As I remember Haxe started as an alternative to ActionScript (language used by the Flash player) when Adobe refused to do anything about it's platform's coming demise around 2010, it's main feature was that you could compile it to ActionScript and JS.

I think it failed to become big because it was not backed by a tech giant - they developed their own language which they could fully control (MS - C#, Google - Dart,..) Also the small team behind it did not have the resources to make great tooling for it, thus Unity took over Flash in the small/medium game segment.

Damn I love haxe, I wonder how many ex Actionscripters are out there? Haxe, Flixel and Haxeflixel (thanks Adam Atomic) had a big influence on me as a young Dev. Even in the massively scaling SaaS work I do now I'm always inspired by 2d blitting stuff and what I learned about frame economising. Lovely.

This is true, in a narrow sense.

Countless times though, talented people need stimulation to finish something. Tools provide that. Indie games take years to make too, many of the best ones 4-7 years, entering "early access" as essentially finished products.

Authoring tools give someone with a diverse set of skills time and space to figure out something, usually in the context of originality. It is also a rehearsal for the successful game that may very well be done in a fury in six months at the end of seven years.

Just realized I have Dead Cells in my Steam library. Paid for it and didn't even try it out. I buy way too many games...

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.

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.

[0] https://robertheaton.com/2018/12/17/wavefunction-collapse-al... [1] https://gridbugs.org/wave-function-collapse/ [2] https://youtu.be/OfSpBoA6TWw [3] https://youtu.be/_IZw2CoYztk [4] game/level designers [5] https://news.ycombinator.com/item?id=24599602 † Yeah, I know. But this contribution is genuinely very relevant and helpful. Credit where credit is due!

Another alternative (but not free) option is https://rxi.itch.io/tilekit

I like Tiled but dang it has some quirky behaviors that can't be fixed for backwards compatibility reasons.

Yes, the code base is Haxe and it "transpiles" to JS + node + electron. The idea is I'm more comfortable with Haxe but I really wanted to have a ~somewhat~ future-proof technology for the app (ie. JS/HTML5/CSS)

Take a look at the json files, you'll quickly understand how the auto tiling rules are configured.

You don't need a Unity plugin. Just use LEd, export to JSON, and have a unity script read in the level as JSON and populate the scene.

The beauty of this is that it is completely engine agnostic.

I'm have plans to add isometric tiles to my tileEditor[1]. But if you want to see how it's done you can take a look at isoCity source code[2]

1 - https://github.com/victorqribeiro/tileEditor

2 - https://github.com/victorqribeiro/isocity

There's Tiled, but it's not as advanced as LEd seems at first glance.

Thanks <3