LEd: Open-Source 2D Level Editor(deepnight.net)
deepnight.net
LEd: Open-Source 2D Level Editor
https://deepnight.net/tools/led-2d-level-editor/
60 comments
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 :)
Oh uhh, hello there. You make really, really cool stuff.
That makes complete sense though, feels like you have to be told about it (or go on a Wikipedia programming-language crawl) to know it exists.
Thanks for the response, and keep being awesome =D
That makes complete sense though, feels like you have to be told about it (or go on a Wikipedia programming-language crawl) to know it exists.
Thanks for the response, and keep being awesome =D
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.
- 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)
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)
Wow, that is beautiful. The aesthetics remind me so closely of the original SNES Tales of Phantasia (absolutely stunning art, to this day) but with a warmer/lighter feel, like Chrono Trigger/Harvest Moon.
https://images.148apps.com/2014/1/37154/219974/img-0815-600x...
Thanks for sharing this. Out of curiosity, where does the art/assets for this come from?
https://images.148apps.com/2014/1/37154/219974/img-0815-600x...
Thanks for sharing this. Out of curiosity, where does the art/assets for this come from?
Thanks! :)
The art assets are all free for commercial use. See my credits for all references: https://rpgplayground.com/credits/
The art assets are all free for commercial use. See my credits for all references: https://rpgplayground.com/credits/
This is a really cool tool, but all the example images are using Rpg Maker assets, which is a bit of a turn off to a lot of folks I'm sure. Do you plan on building your own asset set? Kind of like the official RTP packages?
One of the reasons I could bootstrap this project was because there are so many freely available graphics out there. Although I put a lot of effort into making sure not to use anything from RTP.
Unfortunately this has the drawback of being a "rpg maker" clone. Getting traction on Twitter is therefore really hard.
When I ever do custom assets, they will be 3D.
Or give users to use custom graphics and share/sell them.
Unfortunately this has the drawback of being a "rpg maker" clone. Getting traction on Twitter is therefore really hard.
When I ever do custom assets, they will be 3D.
Or give users to use custom graphics and share/sell them.
Very cool. I'm building a similar thing for platformers (not in Haxe though) https://jump.club
> 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!
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!
Whaaat?! The man is not joking apparently:
https://www.reddit.com/r/haxe/comments/dwpvm7/pok%C3%A9mon_s...
This feels a bit like "Game studios HATE him! This ONE secret they don't want you to know, will make you 10x Game Dev!"
Crazy, and neat.
https://www.reddit.com/r/haxe/comments/dwpvm7/pok%C3%A9mon_s...
This feels a bit like "Game studios HATE him! This ONE secret they don't want you to know, will make you 10x Game Dev!"
Crazy, and neat.
Around the transition to Xbox One and PlayStation 4, I know Haxe was considered an option for ActionScript/Scaleform codebases in certain AAA studios.
The OP meant something more along the lines of "failed to be as popular as Unity/Unreal/Godot?" not "failed to find some users"
> 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.
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.
Flixel still exists as Phaser
For those who aren’t aware, this is deepnight, author known not only for Dead Cells but also for winning or placing high in many, many ludum dare contests over the years. His stature definitely lends a lot of credence to this project.
> LEd is based on my personal experience creating Dead Cells and making game jams.
Cool, they made Dead Cells which gives this instant cred as opposed to yet another gamedev tool from someone who never managed to ship a game because they decided to just make gamedev tools.
Cool, they made Dead Cells which gives this instant cred as opposed to yet another gamedev tool from someone who never managed to ship a game because they decided to just make gamedev tools.
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.
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.
I agree: sometimes, making tools during a game dev process gives you a LOT of insight on what is going wrong in a project. Happened many many times to me :)
Building tools is an integral part of building games.
You can sometimes use generic tools but it is often preferable to have a custom level editor, even better when it runs directly inside the game.
You can sometimes use generic tools but it is often preferable to have a custom level editor, even better when it runs directly inside the game.
I think we get stuck building tools as a form of procrastination because gamedev is so hard and open ended. If you find yourself building tools instead of getting on with what you set out to do, you’ll probably come up with justification like your comment, but scrutiny will reveal it’s just procrastination.
The trick is to avoid trying to "future-proof" your tools.
You have to treat them as quite disposable, not polished gems.
Add features as you need them and build components that you can salvage for your next tool.
Add features as you need them and build components that you can salvage for your next tool.
Maybe jig would be a better description. They are more focused on the workpiece and the outcome, a part may have multiple steps that it undergoes and a jig assists in its production.
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...
If you have some free time, you may want to give it a try, it is really good :)
Deserves a controller if you have one.
The space of [A-Z]Ed names for editors is pretty crowded. LEd is also an old but good LaTeX editor for Windows[0].
[0] https://en.wikipedia.org/wiki/LEd
[0] https://en.wikipedia.org/wiki/LEd
Is there a way to see tile id from inside the editor? When I pull the JSON into my game I get a bunch of "tileId" objects, but there's not an easy way for me to see what tile "45" is without manually counting into my tileset.
I was hoping I could just click a tile and it would display the tileId somewhere...
I was hoping I could just click a tile and it would display the tileId somewhere...
> 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?
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?
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.
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.
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.
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.
Doesn't seem like it would be too hard. I bet I could convert LEd json to Tiled json in a python script + an afternoon if I wanted.
> 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!
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!
An alternative to Tiled, oh thank the maker.
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.
Yea, it organically grew in features over time and just never had the opportunity to rethink the fundamentals of how it worked.
Do they generate js/web app from Haxe and run it inside the bundled Electron? Why?
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)
If people complain about the binary size and/or memory usage, one tip would be to see if it'll run with either NW.js or Tauri, should be close to a drop-in replacement.
Tauri is even smaller than NW.js (I think ~600kb hello-world binary size) but uses Rust in it's toolchain way under the hood to build, so take that as either a positive or a negative.
https://github.com/tauri-apps/tauri
NW.js is essentially lighter-weight Electron.
https://github.com/nwjs/nw.js
Would be neat if it was a straighforward implementation and produced tiny self-containing cross-platform binaries.
Disclaimer: I also have no idea how gamedev works though, so this might not be applicable
Tauri is even smaller than NW.js (I think ~600kb hello-world binary size) but uses Rust in it's toolchain way under the hood to build, so take that as either a positive or a negative.
https://github.com/tauri-apps/tauri
NW.js is essentially lighter-weight Electron.
https://github.com/nwjs/nw.js
Would be neat if it was a straighforward implementation and produced tiny self-containing cross-platform binaries.
Disclaimer: I also have no idea how gamedev works though, so this might not be applicable
Actually, the app was both NwJs AND Electron based, but at some point, but I dropped NwJs support to clean up the code and only kept Electron.
But all Electron related calls are easy to locate and you could use compiler conditions (just like I did before) to use something else (ie. to open a system dialog or display a page template).
But all Electron related calls are easy to locate and you could use compiler conditions (just like I did before) to use something else (ie. to open a system dialog or display a page template).
If it is easy (at least that's the premise of Haxe), would be great if you generate a different target as well - for those end users who despise Electron.
Generating the core logic for different target is one thing but the UI code if it is written for specific target is a different thing. Haxe has many game libraries that would allow doing that with little or no changes, but in this case LEd is using direct html generation for UI. Making such porting more difficult.
This is cool. Curious to see how auto tiling works but I really like the simple parameter editing for entities.
I have a level editor I rolled after frustration with tiled and end up using for all of my projects. Every time it’s not quite right and I discover some basic bugs. Feels like I spend more time fixing bugs than making levels.
I have a level editor I rolled after frustration with tiled and end up using for all of my projects. Every time it’s not quite right and I discover some basic bugs. Feels like I spend more time fixing bugs than making levels.
Take a look at the json files, you'll quickly understand how the auto tiling rules are configured.
I love the effect on undo/redo. So many times in all kinds of editors do I cycle through undo/redo in a game of spot the difference just to find where did I made a change. Now I'm off to see how to implement this in my code editor.
Makes me wanna develop a game today.
I played so many of this guy's games. They were my childhood.
Can you make an official Unity plugin.
This looks interesting, but I'm too lazy to venture beyond Unity in my game Dev journey
This looks interesting, but I'm too lazy to venture beyond Unity in my game Dev journey
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.
The beauty of this is that it is completely engine agnostic.
Shouldn't be too hard when I think about it , if I write my own unity integration I'll open source it .
This looks awesome. Wondering if anyone has any suggestions for a similar tool but for isometric sprites?
There's Tiled, but it's not as advanced as LEd seems at
first glance.
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
1 - https://github.com/victorqribeiro/tileEditor
2 - https://github.com/victorqribeiro/isocity
This is really nice. Especially the automatic rules are lovely.
I had seen this before -- it's really cool! I never dug enough into the site to realize the creator was also on Dead Cells.
The most interesting part to me, is the use of Haxe (in Dead Cells!).
Haxe is to code what Esperanto was meant to be for spoken language.
> "Haxe can build cross-platform applications targeting JavaScript, C++, C#, Java, JVM, Python, Lua, PHP, Flash, and allows access to each platform's native capabilities. Haxe has its own VMs (HashLink and NekoVM) but can also run in interpreted mode."
Syntactically, there's "nothing new to see here" -- it may as well be Not-Quite-Typescript (with some other goodies; Pattern-Matching, GADT's, compile-time behavior, etc).
But it never "took off". Yet here I learn that very impressive software/stunning games have been written in it, by incredibly knowledgeable folks.
What happened with Haxe, where did it fail? I've never tried it myself, but I have a passion for pixelated 2D/isometric games and the tutorials on the authors' site are very sound, so I might give it a shot.