I'm gonna go on a slight tangent, about the Haxe language.
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.
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 :)
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)
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.
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.
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.
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.
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 :)
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.
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.
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...
> 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.
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.
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).
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 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.
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.