LDtk: A modern and open-source 2D level editor(deepnight.itch.io)
deepnight.itch.io
LDtk: A modern and open-source 2D level editor
https://deepnight.itch.io/ldtk
55 comments
Been also working on a 2D game engine and editor. Still a few features missing but getting there! http://github.com/ensisoft/gamestudio
Hi this is really cool! Looks like you roll your own UI system? That's impressive~~
Yes I wanted something that is simple and integrates perfectly with my graphics stack and editor. Styling is completely separate from the logical UI functionality.
With this and tiled - I really don't understand how you hook them into your game without a bunch of code managing the boundary between level editor and real code.
I think you just load the generated file into the game. One part I don't know is how to handle entities. Each game has its own entites and maybe even completely different treatment (architecture) of entites. I'm not sure how flexible they are.
I'm building a simple 2d RPG that is a Ultima spin off and a map editor. In my game I could put different components into entities (not ecs but more oldschooled way) and call each component's update(). Since I'm building my own editor, it's a lot easy to integrate all those into it. For example I could even have a dedicated entity tab that designers can enter some values. I wonder how tiled treat this kind of questions. I browsed through the manual and didn't see anything related so I think it's a pure map editor.
I'm building a simple 2d RPG that is a Ultima spin off and a map editor. In my game I could put different components into entities (not ecs but more oldschooled way) and call each component's update(). Since I'm building my own editor, it's a lot easy to integrate all those into it. For example I could even have a dedicated entity tab that designers can enter some values. I wonder how tiled treat this kind of questions. I browsed through the manual and didn't see anything related so I think it's a pure map editor.
Many Haxe game engines do indeed provide a shim layer which converts things like objects, pathing, behaviours, and triggers from the level engine's output into game logic.
For examples, see https://haxeflixel.com/documentation/loading-the-tilemap/ .
For examples, see https://haxeflixel.com/documentation/loading-the-tilemap/ .
The level editor exports a file. You need to write code that parses that level file into a format your game can use.
Another similar tool: https://rxi.itch.io/tilekit
My friend has been working on an open source game engine/editor for some years now, inspired at first by the platformer fangame SMBX.
(English is not his first language)
https://github.com/WohlSoft/Moondust-Project
(English is not his first language)
https://github.com/WohlSoft/Moondust-Project
This is absolutely fantastic work.
I’ve been tinkering with Unity’s hex grid trying to automate some top down level building under this alternate grid system. It has some interesting challenges surrounding height/cliffs and water. Quite a useful tool here, even in a traditional square grid space.
I’ve been tinkering with Unity’s hex grid trying to automate some top down level building under this alternate grid system. It has some interesting challenges surrounding height/cliffs and water. Quite a useful tool here, even in a traditional square grid space.
Thanks, this looks really cool. I wonder what kind of algorithm and tilesets are needed to achieve what we see in the first two animated gifs on right side.
The second gif seems to be sort of 2D LOD -- once the designer zooms out a different layer is shown instead of the tiles. I think this can be achieved by preparing one set of tileset for detail editing and one for zoomed out views and switch between them.
However I'm not sure how to do things in the first gif. Looks like you have to prepare a few different (but visually close) tiles for one "group" (say grass/dirt/sky/etc.) and when the designer drag the mouse the editor randomly chooses one tile from each group. Still I think it's a lot more complicated than I thought.
I think "Tiled" does a lot of those cool things too, just wondering where we can find tutorials on those algorithms (I don't even know their names)
The second gif seems to be sort of 2D LOD -- once the designer zooms out a different layer is shown instead of the tiles. I think this can be achieved by preparing one set of tileset for detail editing and one for zoomed out views and switch between them.
However I'm not sure how to do things in the first gif. Looks like you have to prepare a few different (but visually close) tiles for one "group" (say grass/dirt/sky/etc.) and when the designer drag the mouse the editor randomly chooses one tile from each group. Still I think it's a lot more complicated than I thought.
I think "Tiled" does a lot of those cool things too, just wondering where we can find tutorials on those algorithms (I don't even know their names)
> However I'm not sure how to do things in the first gif. Looks like you have to prepare a few different (but visually close) tiles for one "group" (say grass/dirt/sky/etc.) and when the designer drag the mouse the editor randomly chooses one tile from each group. Still I think it's a lot more complicated than I thought.
The algorithm is called Wang Tiles. I think you identify a set of tiles which have edges compatible with each other by coloring them. Every time you place a tile, it will pick a random tile that meets all edge constraints.
https://en.wikipedia.org/wiki/Wang_tile
The algorithm is called Wang Tiles. I think you identify a set of tiles which have edges compatible with each other by coloring them. Every time you place a tile, it will pick a random tile that meets all edge constraints.
https://en.wikipedia.org/wiki/Wang_tile
Thanks! Am checking it out, sounds cool~~
From the "lead dev and game designer on Dead Cells"! I started off watching the GIFs for LDtk, ended up playing this https://deepnight.itch.io/petit-tracteur-bleu!
EDIT: finished the tractor game, now onto https://deepnight.itch.io/fort-loop which I think uses some early version of the level designer called LEd? There's a tabletop rpg map editor too https://deepnight.itch.io/tabletop-rpg-map-editor
EDIT: finished the tractor game, now onto https://deepnight.itch.io/fort-loop which I think uses some early version of the level designer called LEd? There's a tabletop rpg map editor too https://deepnight.itch.io/tabletop-rpg-map-editor
Thanks for posting these. I saw it was the guy from Dead Cells, but didn't think to look through his other projects. The tractor game is polished enough that I would have kept playing if there were more than one level. The RPG Map Editor reminds me of an ancient project where I was trying to draw and export Dragon Warrior style tile maps in javascript, but about a million times better.
Between this and 0x72: https://0x72.itch.io/ there's really enough nice looking assets and tools to get something nice looking off the ground.
Between this and 0x72: https://0x72.itch.io/ there's really enough nice looking assets and tools to get something nice looking off the ground.
Thanks for mentioning.
LDtk is just amazing! One of those "why didn't someone made that before?" (maybe I'm missing something? it on some level resembles puzzlescript.net) Genius, relatively simple to implement and extremely useful. Easily can save you hundreds hours of work for even in a small project.
Sébastien deserves all the praise - LDtk is not only a great idea, but also super-polished and open-source. What not to love?
LDtk is just amazing! One of those "why didn't someone made that before?" (maybe I'm missing something? it on some level resembles puzzlescript.net) Genius, relatively simple to implement and extremely useful. Easily can save you hundreds hours of work for even in a small project.
Sébastien deserves all the praise - LDtk is not only a great idea, but also super-polished and open-source. What not to love?
Oh cool! Love your artwork. I came across it near the end days of Kongregate when there were a lot of clever little platformers getting posted by different users that had some suspiciously similar art. I particularly like your micrometroidvania kit:
https://0x72.itch.io/2bitmicrometroidvaniatileset
> Linux Ubuntu (experimental) 76 MB
> HTML5: LDtk is built around modern web standards.
Why its size is so huge? Is it Electron-based?
Size of Tiled[0] app binaries for each of MacOS/Win/Linux platform is 3 time smaller than LDtk's binaries.
What is "modern" in differnce between LDtk and Tiled?
[0] https://github.com/mapeditor/tiled/releases
> HTML5: LDtk is built around modern web standards.
Why its size is so huge? Is it Electron-based?
Size of Tiled[0] app binaries for each of MacOS/Win/Linux platform is 3 time smaller than LDtk's binaries.
What is "modern" in differnce between LDtk and Tiled?
[0] https://github.com/mapeditor/tiled/releases
Why does it matter? At all? Is anyone really pushed for 76MB?
Not to mention game development asset creation is inherently a disk intensive task. You're going to have lots of huge images, 3D files, sounds, etc. in lossless high quality formats (even for simple 2D games). 76 megabytes is tiny compared to the rest of the stuff you're dealing with.
Because Tiled is a very mature 2D tilemap editor with quite a few features, so if a new product comes on the market that is three times bigger then an obvious question is "what does this have to offer that the older, smaller program doesn't?"
Having used both Tiled and LDtk, the latter is far more fun to use. Tiled is bogged down by legacy compatibility quirks that will never be fixed.
uh we aren't so pressed for size that a larger program has to also have more functionality
caring about program size to this degree is just so comically misplaced lol
caring about program size to this degree is just so comically misplaced lol
Many find software bloat objectionable, if not disappointing.
bloated disk space usage can be an indicator of bloated cpu and memory requirements.
This is absolutely not true. You might be able to make the argument that if a dev was careless with disk space they may also be careless with performance, but there are plenty of applications that are large and performant (see: any AAA video game, Linux, web browsers).
> AAA video game
The overwhelming majority of the size there is art assets, not actual code. Also, reducing the size of those art assets can actually improve performance by the simple virtue of not hitting the memory wall all the time, so I'm not really convinced here.
> Linux
A monolithic kernel supporting every piece of hardware under the sun from the last three decades is not really a valid point of comparison.
> Web browsers
Same story: the requirements of a 2D level editor are nowhere near the vastness and complexity of everything that web browsers have to support.
The overwhelming majority of the size there is art assets, not actual code. Also, reducing the size of those art assets can actually improve performance by the simple virtue of not hitting the memory wall all the time, so I'm not really convinced here.
> Linux
A monolithic kernel supporting every piece of hardware under the sun from the last three decades is not really a valid point of comparison.
> Web browsers
Same story: the requirements of a 2D level editor are nowhere near the vastness and complexity of everything that web browsers have to support.
since when?
one bug reason binaries get large is due to optimizations such as inlining and code gen/specialization of generics..there are so many examples where runtime performance is gained in exchange for larger binary size.
one bug reason binaries get large is due to optimizations such as inlining and code gen/specialization of generics..there are so many examples where runtime performance is gained in exchange for larger binary size.
Regarding Tiled, I think it is probably the de facto editor for 2D game level editing. I'm trying to look into the first release and learn from the source code, as I'm also using C++ and QT.
windows release contains both 32 and 64bit versions, it's indeed a waste to ship both in a single file..
Oh hey it's deepnight - I remember your awesome Ludum Dare games. Thank you for sharing this tool with the gamedev community!
I want to talk about Haxe. Haxe is a small niche language. But I almost fell out of my chair when I saw the showcase of games written with Haxe. Quality indie games I have played myself, like Dead Cells, and this level editor is another very polished example. Even things like Pokemon Sword and Shield. What's going on here? I need to learn me some Haxe.
Are all of these using Kha - so called "SDL but super-charged"? Or are there even more great graphics libraries for Haxe?
(Also, I found LDtk on a four month old HN post less than three hours ago, and now it's front page. I'm not the one who submitted it. My connection to the hive mind must be a good one.)
Are all of these using Kha - so called "SDL but super-charged"? Or are there even more great graphics libraries for Haxe?
(Also, I found LDtk on a four month old HN post less than three hours ago, and now it's front page. I'm not the one who submitted it. My connection to the hive mind must be a good one.)
As far as I can remember, Dead Cells specifically was made using Heaps[1], which the creator of Haxe himself made. Paper's Please uses OpenFL[2] instead. I'd say the Language has quite a few good libraries and frameworks to work with. The Haxe site itself lists a few others too [3] at the very bottom of the page. My advice would be to look at some sample code or documentation and see which one strikes you as either the most interesting or the most practical.
[1] - https://heaps.io/ [2] - https://www.openfl.org/ [3] - https://haxe.org/use-cases/games/
[1] - https://heaps.io/ [2] - https://www.openfl.org/ [3] - https://haxe.org/use-cases/games/
There aren’t many games using Kha, but I am using it for my game and think it’s absolutely awesome! I used to use the Flash display list, OpenFl, Heaps, but since learning React I have a developed a complete distain for the Object Oriented approaches for game development. Like the HTML canvas api, Kha allows me to build my own state structure, and then the visuals are just a functional expression of that structure. Combining this approach with Haxe’s extremely powerful Enum and pattern matching capabilities has been such an eye opening experience, and make it difficult for me to go back to just about any other language. Haxe is just so clean and well designed.
Haxe is one of the very few languages in which a perfect cross-platform widget toolkit could be made. A toolkit that would produce platform-native binaries (no pesky FFI like JNI) using platform specific libraries: targeting Java (maybe even JVM?) for Android, targeting C# for Windows/the-current-Windows-toolkit, targeting Hashlink for Gnome/Gtk, targeting C++ for KDE/Qt, targeting C++ with Objective-C++ for MacOS/Cocoa and iOS/Cocoa Touch. Probably even a web target is viable.
Other language, that it is possible to do with is Scheme, but it is quite a different beast all together.
That's my little dream. I intend to do gobject-introspection bindings one day for it as my first step.
Other language, that it is possible to do with is Scheme, but it is quite a different beast all together.
That's my little dream. I intend to do gobject-introspection bindings one day for it as my first step.
The funny thing about a lot of these cross platform Haxe GUI applications is that they are actually made with Electron.
I guess using Haxe means that you could also share libraries with your “real” game code that likely compiles to C++, which could be a big benefit. I just thought it was funny that LDtk could be written in JavaScript and be just as cross-platform as it is.
Other examples of Haxe-Electron apps include the Ogmo level editor and the CastleDB editor.
I guess using Haxe means that you could also share libraries with your “real” game code that likely compiles to C++, which could be a big benefit. I just thought it was funny that LDtk could be written in JavaScript and be just as cross-platform as it is.
Other examples of Haxe-Electron apps include the Ogmo level editor and the CastleDB editor.
Indeed, Electron is very useful for any compile-to-js language, and benefit from js popularity, toolkits and frameworks for rich UI.
Writing in Haxe brings nice syntax, and some flexibility regarding target language/platform, and possible UI frameworks.
- ArmoryPaint[1] and most Haxe games don't rely on Electron for UI.
- HaxeUI[2] provide a nice list of components, rendered as composite or native on various backends[3] (html5, wxWidgets, experimental pdcurse..^^)
- MVCoconut[4] also allow to bind to various front-ends : Dom, React, React-native
There is always a degree of lock-in depending on the path you choose, but having a cross platform base for logic and glue is a nice feature.
[1] https://armorpaint.org/
[2] http://www.haxeui.org/
[3] https://github.com/haxeui/haxeui-core#backends
[4] https://github.com/MVCoconut/
Writing in Haxe brings nice syntax, and some flexibility regarding target language/platform, and possible UI frameworks.
- ArmoryPaint[1] and most Haxe games don't rely on Electron for UI.
- HaxeUI[2] provide a nice list of components, rendered as composite or native on various backends[3] (html5, wxWidgets, experimental pdcurse..^^)
- MVCoconut[4] also allow to bind to various front-ends : Dom, React, React-native
There is always a degree of lock-in depending on the path you choose, but having a cross platform base for logic and glue is a nice feature.
[1] https://armorpaint.org/
[2] http://www.haxeui.org/
[3] https://github.com/haxeui/haxeui-core#backends
[4] https://github.com/MVCoconut/
I agree. Such a project exists [0] but will need more work, and workforce is quite limited.
[0]: http://www.haxeui.org/
[0]: http://www.haxeui.org/
Haxe is a great piece of technology on its own, and I am often working in it as a default, but I always caution potential users that it is more like a building block than a comprehensive package: if you want to do complex cross-platform things using Haxe, you will still want an full-time engineering team working with you to build out the full solution, since you will probably need to leverage the strengths and tooling of the target environments too. Haxe tries hard to get out of the way and give you the access you need, but builds and debugging always introduce challenges that depend on platform-specific behaviors. The quality of the results is more suggestive of the quality of the average Haxe user than the language itself doing anything magic(though it is a very sensible design).
That said, you can make some great things just sticking within the available frameworks. OpenFL is good, as is Kha. HaxeUI is definitely worth checking out(it can use multiple backends). For editing tools there's still going to be a bias towards working with Electron because of the combined set of I/O features.
That said, you can make some great things just sticking within the available frameworks. OpenFL is good, as is Kha. HaxeUI is definitely worth checking out(it can use multiple backends). For editing tools there's still going to be a bias towards working with Electron because of the combined set of I/O features.
From my limited experience, Haxe seems like a really neat language but good grief the documentation and learning resources are awful. It’s possible that I was going about it wrong, but there was very little by way of “here’s where everything is and how you’re supposed to do things” resources. I feel if that issue was better handled the language would see much more use than it currently does.
Do you have concrete examples of things that are missing? We are aware that documentation is generally lacking, but it's not easy to see exactly how/where from inside. Would gladly contribute on such a list.
Sure!
My thoughts, taking a quick second look at the Haxe website:
* The core docs are split across three different sites: https://haxe.org/documentation/introduction, https://haxe.org/manual/introduction.html and https://api.haxe.org/. To a new user this is extremely confusing.
* Let's say I go with the first of those. I go through the pages, which contain lots of useful information, but it doesn't actually tell me how to do what I want - which is presumably "make a game" given how Haxe is marketed. As a new user, I'd like to know how to use your library to make a game - say, pong or tic-tac-toe. If graphics/input/whatever isn't part of the standard library that's fine, but then your intro should tell me that and give me some suggestions where I can find those libraries and how to install them. Compare to the nodejs.dev or reactjs into tutorials, which immediately show you how to do the thing that many/most people will want to do (make a server, or make a dynamically-updating frontend respectively)
* On that note, your package manager is VERY hidden! It's just labeled as "haxelib" (very non-descriptive) at the bottom of the "Learn Haxe" menu.
* The other thing that the docs aren't really telling me is "what's the typical way to combine these ingredients"? How do people typically work with haxe.Resource-s, macros, MainLoops, etc? What are the common patterns?
* Many of Haxe Standard Library docs pages are minimally populated. For example, MainLoop sounds important, but the docs tell me almost nothing. https://api.haxe.org/haxe/MainLoop.html
My thoughts, taking a quick second look at the Haxe website:
* The core docs are split across three different sites: https://haxe.org/documentation/introduction, https://haxe.org/manual/introduction.html and https://api.haxe.org/. To a new user this is extremely confusing.
* Let's say I go with the first of those. I go through the pages, which contain lots of useful information, but it doesn't actually tell me how to do what I want - which is presumably "make a game" given how Haxe is marketed. As a new user, I'd like to know how to use your library to make a game - say, pong or tic-tac-toe. If graphics/input/whatever isn't part of the standard library that's fine, but then your intro should tell me that and give me some suggestions where I can find those libraries and how to install them. Compare to the nodejs.dev or reactjs into tutorials, which immediately show you how to do the thing that many/most people will want to do (make a server, or make a dynamically-updating frontend respectively)
* On that note, your package manager is VERY hidden! It's just labeled as "haxelib" (very non-descriptive) at the bottom of the "Learn Haxe" menu.
* The other thing that the docs aren't really telling me is "what's the typical way to combine these ingredients"? How do people typically work with haxe.Resource-s, macros, MainLoops, etc? What are the common patterns?
* Many of Haxe Standard Library docs pages are minimally populated. For example, MainLoop sounds important, but the docs tell me almost nothing. https://api.haxe.org/haxe/MainLoop.html
I completely agree with this. I went through the process of learning/attempting to learn haxe earlier in the year. (I was on a nostalgia 'I want to build flash games again' journey)
There is lots of information. But not a lot of direction. I thought about writing some stuff on 'here is how to get started building a game'. But I started running out of steam when I hit some bugs with heaps and the newest version of haxe.
There is lots of information. But not a lot of direction. I thought about writing some stuff on 'here is how to get started building a game'. But I started running out of steam when I hit some bugs with heaps and the newest version of haxe.
Thanks :)
For the first point, yeah I agree, though I would still keep standard API documentation separated. And it gets "worse" when you add the 4th site: https://code.haxe.org which helps with 4th point (partly?).
Tricky thing with guides like "how to make a game" is that it's not a haxe-specific thing; it's a haxe framework specific thing which they handle on their own: https://haxeflixel.com/documentation/, https://heaps.io/documentation/home.html, https://github.com/Kode/Kha/wiki (is there a better link for kha?), etc. There are links in https://haxe.org/use-cases/games/ but discoverability could likely be much better and include a generic "how to make a game" start point which points to either framework depending on your needs (2D/3D, mobile/desktop/console/web, etc.).
Indeed Haxelib isn't visible :x Now that you mention it, we had a few haxe newcomers that didn't know about it. We need to do something about that (even if it might get a replacement in the near-ish future https://github.com/HaxeFoundation/haxe/issues/9135)
Good point about std lib docs too! Some, maybe including MainLoop, are harder for community to document but we should ask help from core compiler devs.
For the first point, yeah I agree, though I would still keep standard API documentation separated. And it gets "worse" when you add the 4th site: https://code.haxe.org which helps with 4th point (partly?).
Tricky thing with guides like "how to make a game" is that it's not a haxe-specific thing; it's a haxe framework specific thing which they handle on their own: https://haxeflixel.com/documentation/, https://heaps.io/documentation/home.html, https://github.com/Kode/Kha/wiki (is there a better link for kha?), etc. There are links in https://haxe.org/use-cases/games/ but discoverability could likely be much better and include a generic "how to make a game" start point which points to either framework depending on your needs (2D/3D, mobile/desktop/console/web, etc.).
Indeed Haxelib isn't visible :x Now that you mention it, we had a few haxe newcomers that didn't know about it. We need to do something about that (even if it might get a replacement in the near-ish future https://github.com/HaxeFoundation/haxe/issues/9135)
Good point about std lib docs too! Some, maybe including MainLoop, are harder for community to document but we should ask help from core compiler devs.
Haxe is hard to document because its scope is large: "accommodate everything all these other languages do". So there isn't a one way of documenting it that will accommodate all users and workflows. It would help if you outlined what you need.
[deleted]
Dead Cells and a number of other high-quality commercial games are using Heaps: https://heaps.io/
The Haxe website has links to some other popular frameworks like OpenFL and HaxeFlixel: https://haxe.org/use-cases/games/
The Haxe website has links to some other popular frameworks like OpenFL and HaxeFlixel: https://haxe.org/use-cases/games/
Thanks for bringing heaps and the others to my attention.
I look at this list and suddenly 4 of the top 10 game engines I'd consider for a personal project are from the Haxe ecosystem.
I look at this list and suddenly 4 of the top 10 game engines I'd consider for a personal project are from the Haxe ecosystem.
Haxe is awesome! I'm using that and Kha for my https://rpgplayground.com
I think most games use Heaps, which is also written by the Haxe developer.
Some other libraries such as OpenFL were ported from ActionScript to Haxe. (Basically Haxe took in a lot of Flash refugees :)).
Definitely recommended technologies!
I think most games use Heaps, which is also written by the Haxe developer.
Some other libraries such as OpenFL were ported from ActionScript to Haxe. (Basically Haxe took in a lot of Flash refugees :)).
Definitely recommended technologies!
rpgplayground is pretty cool.