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.)
 - https://heaps.io/
 - https://www.openfl.org/
 - https://haxe.org/use-cases/games/
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 examples of Haxe-Electron apps include the Ogmo level editor and the CastleDB editor.
Writing in Haxe brings nice syntax, and some flexibility regarding target language/platform, and possible UI frameworks.
- ArmoryPaint and most Haxe games don't rely on Electron for UI.
- HaxeUI provide a nice list of components, rendered as composite or native on various backends (html5, wxWidgets, experimental pdcurse..^^)
- MVCoconut 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.
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.
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
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.
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.
The Haxe website has links to some other popular frameworks like OpenFL and HaxeFlixel: https://haxe.org/use-cases/games/
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 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!
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 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.
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
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.
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?
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'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.
For examples, see https://haxeflixel.com/documentation/loading-the-tilemap/ .
(English is not his first language)
> HTML5: LDtk is built around modern web standards.
Why its size is so huge? Is it Electron-based?
Size of Tiled 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?
caring about program size to this degree is just so comically misplaced lol
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.
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.
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.