That's basically correct, although there is also a cross platform runtime called Hashlink but is unsupported by Kha.

https://hashlink.haxe.org/

Have you seen Kha by any chance? It has similar goals. I find it quite awesome, but it won't gain mass adoption for a bunch of reasons. https://github.com/Kode/Kha

Someone built an immediate mode renderer on top https://github.com/armory3d/zui, which is utilised by ArmorPaint https://armorpaint.org. I also use Zui for my own bespoke 2D game engine.

I find this tech and tooling really quite amazing (just look at how little source code Zui has) given just how small the ecosystem around it is. I think Kha really illustrates what can be achievable if the lower levels have robust but simple APIs, just exposing the bare minimum as a standard for others to build upon. It really suggest taking a look at the graphics2 (2d canvas like) api.

For the kind of project I work on (mostly 2d games), I think it would really awesome if your framework also supported low level audio, and a variety of inputs such as keyboard, mice, and gamepads. If it also had decent text rendering support it would basically be my dream library/framework.

Currently it is the low level, cross platform layer that is the most complex and the biggest hurdle towards making a game engine viable. If it wasn't so insanely complex, and the technical barrier towards making your own engine is reduced, the tired cliche of "don't build an engine" wouldn't hold as much weight, and it opens the doors to building a bespoke, fit for purpose engine for every game you create. Don't underestimate what an individual or small teams can produce if they are operating on a solid platform that facilitates a rich ecosystem of tools.

I use a very obscure library called Kha[3] and it has by far and away the best performance for 2d rendering that I have encountered. It is amazing what you can do with just a very basic immediate mode ui library called Zui[4]. I think it is shitty advice to say that you are either building an engine or game. This advice would be applicable if you are building a general purpose game engine, not the highly specific and bespoke engine used for you own game. Your game and your engine are basically the same thing and you take many shortcuts, make many compromises, and build out a rough and minimalistic "editor" used just by your small teams (or yourself) to get the job done.

[1] https://maddymakesgames.com/articles/celeste_and_towerfall_p... [2] https://ldtk.io/ [3] https://github.com/Kode/Kha [4] https://github.com/armory3d/zui

Comments URL: https://news.ycombinator.com/item?id=36220687

Points: 2

# Comments: 0

I reckon taking something like Godot's vector draw tools, and combining that with a Flash timeline/library, with a Javascript runtime, and you would win over all those animators that keep saying "why can't they just re-make Flash".

I'm surprised no one has had a good crack at re-creating the core functionality of Flash circa 2004, based on web tech, or something like Kha[1]. I've thought many times about starting such a project. I think the biggest challenges are developing a solid vector rendering runtime alongside the vector drawing tools, but just about everything else that ex-Flashers want can be reduced down to some pretty simple functionality. You could even forego all the cruft of the display list, the event model, etc, and just go with a simpler immediate mode renderer and I think you'd still be retaining those core components that made Flash special.

There are so many use cases (eLearning experience, Digital Signage, Touch Screen Kiosks) that Unity isn't particularly suitable for, and for which HTML/Javascript is just clunky, that such a tool could far better accomodate.

1. https://github.com/Kode/Kha.

I had an OP-1 for a number of years but I could never progress beyond 2-4 bar loops. When I bought my Deluge I made a full track in my first two hours with it, and I was pretty proud of it. I own a number of groove boxes now, but have only ever managed to completed tracks on my Deluge.

For my last project I went with CSS in JS. It has some shortcomings and I don't think it would work very well if I use a lot of components from NPM, but it was really nice at encapsulating the component to a single file.

I don't think either approach is more or less proper. Inline styles had obvious large shortcomings in 2010, but not so much in the current context of front-end development.