Alternative Renderer Ideas and Options

[3mic4nia]

Description

GDevelop 5 Can export his projects to HTML5, but I think this is not enough,
it could be great to generate Haxe code from the project files, in this way, GDevelop games can be easily compiled natively to desktop, mobile, web, and even consoles with the maximum of performances.

[4ian]

It's an interesting idea, though this also means several rewrite of the game engine/renderers/extensions. But Haxe is definitely very interesting and I keep a look at it. Some extensions could be written in Haxe as a proof of concept.

[blurymind]

Haxe has this https://github.com/pixijs/pixi-haxe Can also compile to js. Will it really compile to native target if it still uses pixi

…

On Thu, 27 Aug 2020, 00:06 Florian Rival, ***@***.***> wrote: It's an interesting idea, though this also means several rewrite of the game engine/renderers/extensions. But Haxe is definitely very interesting and I keep a look at it. Some extensions could be written in Haxe as a proof of concept. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1944 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRRWVICDM7TXTT46QMJL6LSCWIQDANCNFSM4QLSTXKQ> .

[Silver-Streak]

Yeah, I wonder if Pixi-Haxe would allow for most of the existing stuff to stay functional, but potentially add on an alternative renderer and event type (Haxe event similar to JS event).

[Wend1go]

There is also the Kha framework which is used by the Armory Engine and also based on Haxe.

[blurymind]

Its interesting, but a huge task. What will it give us apart of native compile. Also when we say native, how involved will it be to set by our non programmer user base? Remember we still have cocos and that is a bit involved to set up locally and doesn't support gdevelops all features

…

On Thu, 27 Aug 2020, 06:35 Wend1go, ***@***.***> wrote: There is also the Kha framework <https://github.com/Kode/Kha> which is used by the Armory Engine and also based on Haxe. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1944 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRRWVM553P2SA3XVGYSNOTSCXWB7ANCNFSM4QLSTXKQ> .

[3mic4nia]

Hello everyone, I'll try to make a simple Haxe exporter for proof-of-concept, it could be useful to look at the GDevelop JavaScript exporter. Can someone show me where is it in the source code?

[arthuro555]

Conveniently, 4ian wrote a blog post about it a few hours ago: https://forum.gdevelop-app.com/t/code-generation-process/27155/2?u=arthuro555

Personally I think a haxe platform is a bad idea as it means:

1. Trashing all our current extensions away as afaik haxe compiles to other platforms but not from other platforms to haxe, only export to a language and use pre existing code (pixi-haxe only supports export to JavaScript) So we would have to forbid export to another platform than Js which would kinda beat the purpose
2. It's a lot of work to support multiple platforms
3. Haxe may not be much more Faster? I read that it's slow as it outputs readable instead of optimized code.

If we were to make such a big platform change/addition I would suggest either rewriting GDCpp to use SDL2, as it would port pretty well to pretty much any platform (SDL being an industry standard) and be way faster, or write a new platform in rust, which allows for better speeds and less bugs thanks to its approach for memory management.

[arthuro555]

I would like to redirect this discussion to a question I have asked a few times but I think the answer of is still vague:

1. Are there any plans to add any other platforms in the near or distant future?
2. If yes, what languages/libraries could be considered and why?

[Silver-Streak]

I agree with Arthuro.

If we can get an understanding of what interest there is in other renderers/exporters, I'm happy to start doing some digging for options that match the desired languages/etc.

[4ian]

1. Near future: not immediately no. This deduplicates the effort and I think there is still much optimisation to do in the current engine to reach its full potential.
2. Anything that is battle tested, bullet proof, support for large number of platforms and as much as possible allow to keep a single codebase. Examples: Haxe, but also things like C++ or Rust compiled to WebAssembly (for the web) or natively (for other platforms). Bonus point for runtimes that would support JS, as otherwise this means churning out a fair number of extensions and that might not be viable.

[Silver-Streak]

@4ian some digging has been completed. 😄

This is a HUGE post, which I apologize for.

Super high level, my favorites:

Haxe: Kha
C++/C: Raylib
JS: Phaser
Rust: Bevy

More info:

If looking at Haxe: I am personally a fan Kha first from a functionality standpoint (Performance + Export targets), HaxeFlixel second (severely battle tested, very large community, but 2D only focus and has some stigma stemming from having a very ancient flash lineage). The other "Big name" I saw a lot was Heaps.io, but people are generally down on that engine from a functionality/stability standpoint, apparently.

If looking at C/C++: I am a huge fan of Raylib. It's C99/C and not C++, but is extremely modular, extremely well regarded, and extremely functional. Other options are Cocos Creator (C++ engine only, as the JS engine does not allow it to be used for other engines) and Defold (great engine, license has no concerns with modifications to/reuse of the engine, but not truly open source.)

If looking at Javascript: There are no options for JS that export natively without Electron. That said, I am pretty fond of what I read for Phaser. Phaser reworked their renderer a year or two ago and basically are completely separated from PixiJS now, but similar concepts. The biggest differentiator is that it has pretty much every function you could want natively with no need for plugins/addons. Phaser was generally recommended slightly higher than PixiJS, so there's not a lot of other options I could find for 2D. 3D is another story but I didn't dig deeper.

If looking at Rust:
Rust engines are really early. There's no perfect options. There really seems like only 1 option that is in any usable state, and that is Bevy. Bevy seemed super appealing but even they warn it is early. Another one is Amethyst but that is _even earlier_.

Much more details:

• Haxe:

  • KHA:
    • Pros:
      • Explicitly designed as a framework to be used as part of engines, which makes it seem like a great fit. Has apparently even been used on top of Unity and Unreal by some devs.
      • Numerous engines have been built entirely with Kha, so it's use in this space is pretty well tested
      • Has functionality for Direct3D and openGL
      • Export targets for consoles directly, even has export targets for RaspberryPis.
      • Benchmarks of its rendering capabilities (bunnymark) showed massive​ performance deltas compared to others. (130k bunnymark before dropping below 60 fps vs ~40-50k for PixiJS, 65k for Love2D)
      • Main developer (RobDangeorus) is very active and responsive in numerous dev communities/message boards even outside of Kha's github.
      • No breaking changes in over 3 years.
      • Decent number of games on web/mobile, both commercial and open source.
    • Cons:
      • Engine documentation is available, but some info is sparse. Because of this I can't confirm all object types are supported, even though they seem​ to (I can find examples for all of them, but not necessarily documentation)
      • Requires multiple pieces for export, Kha (main framework), Kore (exporter logic/additional functionality), Krafix (HLSL/GLSL)
      • Not able to find any games listing using Kha that have large retail releases, but this may also be because they're made with other engines that use Kha as their backend.
  • HaxeFlixel:
    • Pros:
      • Pretty battle tested, two big games I know of recently released on numerous platforms (Friday Night Funkin', Defender's Quest: Valley of the Forgotton)
      • Support for all of the existing object types(Sprite, tiled sprite, 9-patch, video, tilemap, text, bitmap text, physics, etc)
      • Builds for native targets using SDL2 rather than Electron, so likely better performance.
      • Builds for HTML5 directly
      • Fantastic shader support
      • Very active community/tons of documentation around the backend
    • Cons:
      • Similar sound issues to what GD5 has right now (need to ensure to cache sounds beforehand)
      • No 3D shaders/3D render path options at all (if GD5 ever wants to expand that way)
      • Is based off ActionScript methods/mentality, not really a huge con, but can have a stigma to some people.

• C/C++:

  • Raylib:
    • Pros:
      • One of the most modular engines out there.
      • Bindings dozens of languages (https://github.com/raysan5/raylib/blob/master/BINDINGS.md)
      • Supports all object types we currently have.
      • Pretty advanced text rendering and on-the-fly bitmap font generation as needed.
      • HTML5 and native exports for numerous platforms.
      • Great support for 2D and 3D, including pretty varied shader support.
      • No external Dependencies
    • Cons:
      • While the engine supports tons of bindings, the engine itself is C (C99), not C++. This could be a showstopper depending on the devteam's feelings.
      • While I don't understand this, some folks have been vocal about the "no external dependencies" bit for RayLib as a negative thing, but I can't find any reasoning.
  • Cocos Creator Native Engine. (The engine, not the editor)
    • Pros:
      • This seems to be the Cocos Team's "evergreen" platform. Actively developed by them on a regular basis, and seems to have pulled in all of their old Cocos2D-x functionality.
      • Very​ well regarded by the reviewers I can find. Commonly referred to has having exceptional performance and functionality.
      • Pretty easily extendable with a decent number of addons already out there.
    • Cons:
      • Cocos team already has their own editor on top of it. This had lead to some licensing oddities that makes it hard to decipher if we can even make GDevelop on top of it. From asking around, the C++ engines is​ MIT licensed, but the editor and JS engines are not, so it wouldn't be usable for web export without emscripten.
      • As with Cocos2D-JS, no way to know if they'll ever just randomly drop it.
  • Defold
    • Pros:
      • Very battle tested. Originally an engine developed by the game publisher/developer King (Candy Crush), used for aby their games, but also a few dozen commercial mobile and desktop games that I've heard of.
      • Extremely actively maintained.
      • True native OS and web exports
      • Very large amount of community made extensions, with everything from Haxe language support for game logic, to Steamworks, to extra cameras.
      • Supports all object types and then some.
      • From benchmarks I can find, great desktop/mobile performance and pretty good HTML5 performance
      • Supports Nitendo Switch export targets in addition to Windows/Mac/Linux/Android/iOS/HTML5
      • Compiles/builds internally as part of the engine.
    • Cons:
      • Source available and very open licensed, not fully open sourced. Per the license page, making edits/changes/redistributing/etc the engine code is fine so long as you don't commercialize and sell it. More details here: https://defold.com/license/
      • Is not really designed as a framework (although has all of the needed/expected/etc APIs for it, which should make it work fine.
      • Native logic language is Lua (or Haxe with an extension). Not a huge deal since folks shouldn't be using code for their game logic anyway.

• Javascript/TypeScript:

  • Phaser
    • Pros:
      • Uses many similar concepts as PixiJS (and in fact used to utilize PixiJS until they branched a a while back)
      • Numerous functional items out of the box (sprite sheets, texture packing, tweens, animation timelines, etc)
      • Phaser 3 introduced multiple physics engines, including some fluid dynamics support.
      • Numerous input types by default, including a input manager for remapping controls
      • Has a canvas/game screen size scaling manager fully implemented, from what research I can find has some of the best 2D scaling logic in the Javascript framework/engine field.
    • Cons:
      • Base engine is not as lightweight as Pixi, roughly double the footprint without code (~6mb ram for Pixi, 11.5 mb for phaser). However actual asset handling appears to be better on the phaser end, so the delta dramatically changes for larger games.
      • Still electron for native builds.

• Rust:

  • Bevy: https://bevyengine.org/
    • Pros:
      • Numerous tilemap plugins (both LDtk, tiled, and others)
      • Steamworks support
      • Numerous physics engines supported, with the main one (Rapier) maintained by the actual physics engine team.
      • Simple GUI object support (egui integration)
      • Network support
    • Cons:
      • While numerous places feel this engine is exceptional/highly recommended, it is also still early. They even warn as such on their page.
      • May need one of the plugin based renderers rather than the default, as the default is apparently more hybrid focused with some missing basics for 2D. (There are numerous plugins that handle this, but still a con that it's not out of the box)
      • ECS focused. Unclear if this is a huge deal for GDevelop or not. Also unclear if this is a positive or negative, since I know feelings in the dev world on ECS are mixed.

[arthuro555]

🤔 You seem to have mistaken rust and ruby.

I couldn't help but notice you have talked almost only about other game engines. While those are great to ensure having a lot of features, they are also often heavier and might implement some features in a non gdevelop backwards compatible way so we might not be able to use them (the features) anyways. I'd therefore look more into renderers libraries as well.

I would also like to say that I don't want to touch anything cocos, whatever they build they seem to destroy with fire after a few years and I tried to learn it to work on the cocos renderers but the English documentation was IMO extremely bad and incomplete. I can see how it is performant, used by many people and all but to me the unsafety that they might throw away everything at any minute to remake a new cocos and the unusability due to a lack of quality documentation are dealbreakers.

Another option would be to look into NodeJS bindings for native engines. Since the rendering code would be natively run we should be able to achieve higher speeds, and since we would not use Chromium we would gain lower file sizes. Since it would still run on JavaScript, it should be mostly compatible with GDJS and it's extensions. An example native renderer would be the Raylib bindings for node.

[Silver-Streak]

🤔 You seem to have mistaken rust and ruby.

Oh Jeez, you're correct! 😭
These recommendations are Rust, but I wrote Ruby. Correcting now.

I couldn't help but notice you have talked almost only about other game engines.

Just to clarify, I tried to find a decent mix of both frameworks and more feature-filled engine style options, based off prior conversations with 4ian about potential options.

I would also like to say that I don't want to touch anything cocos,

Yeah, I definitely agree on this one, exactly for the same reason you list. I listed it because it showed up numerous times in recommendations while I was digging into stuff.

Another option would be to look into NodeJS bindings for native engines. Since the rendering code would be natively run we should be able to achieve higher speeds, and since we would not use Chromium we would gain lower file sizes. Since it would still run on JavaScript, it should be mostly compatible with GDJS and it's extensions. An example native renderer would be the Raylib bindings for node.

Raylib greatly intrigues me, just as much as the Haxe options. I think Haxe may draw in more contributors right now as it's pretty popular in the dev world, but I think either of the Haxe options, or the method you mention with Raylib, could be amazing.

[blurymind]

What about godot :) its probably the best open source engine atm and even has a web editor now

…

On Sat, 14 Aug 2021, 08:38 Silver-Streak, ***@***.***> wrote: 🤔 You seem to have mistaken rust and ruby. Oh Jeez, you're correct! 😭 These recommendations *are* Rust, but I wrote Ruby. Correcting now. I couldn't help but notice you have talked almost only about other game engines. Just to clarify, I tried to find a decent mix of both frameworks and more feature-filled engine style options, based off prior conversations with 4ian about potential options. I would also like to say that I don't want to touch anything cocos, Yeah, I definitely agree on this one, exactly for the same reason you list. I listed it because it showed up *numerous* times in recommendations while I was digging into stuff. Another option would be to look into NodeJS bindings for native engines. Since the rendering code would be natively run we should be able to achieve higher speeds, and since we would not use Chromium we would gain lower file sizes. Since it would still run on JavaScript, it should be mostly compatible with GDJS and it's extensions. An example native renderer would be the Raylib bindings for node. Raylib *greatly* intrigues me, just as much as the Haxe options. I think Haxe may draw in more contributors right now as it's pretty popular in the dev world, but I think either of the Haxe options, or the method you mention with Raylib, could be amazing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2347 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRRWVJGVH74AE2EKEVTV63T4YMQZANCNFSM5CB4V7NQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[Silver-Streak]

What about godot

I had thought about Godot, but quite honestly.. the project maintainers/contributors POV have kind of killed my interest in the engine pretty hard.

I've seen numerous people in their Github discussions want to talk around enhancing (or really, fixing) their visual scripting system, only to be shot down due to the devs viewpoint that there's nothing to enhance. If I remember correctly, some folks' PRs to enhance visual scripting's ease of use got rejected even after completion because it was counter to the dev's vision for it (which is still unclear, but basically seemed to boil down as they viewed it as a tool for programmers to use for themselves, not for non-coders/artists/etc)

I've even seen your suggestions around user experience enhancements get ignored, @blurymind 😆

All of the above in mind took it out of my research really quickly. I still think the engine is a great piece of software and could one day be the true alternative to Unity some folks are looking for (once they make 3D realistically viable), just not necessarily a fit for this.

(Also its general performance for both native and web was pretty poor compared to all of the other options above, at least from the benchmarks I could find. Still good performance, to be clear, just worst than the rest above when averaged.)

I'm not a decider in this at all, though, so I just wanted to provide context to your question.

Edit: To be clear, if you feel there is a good path to utilize Godot that doesn't require an entire fork to be made that is shunned/ignored by the maintainers, I definitely think it could be viable! I just feel like the way the maintainers react to other engines when they get good press/backing/grants/etc on social media and elsewhere make me exceedingly concerned they'd not be pleased with GDevelop using their code as a framework.

[blurymind]

There are other game engines made with godot fork that use visual programming doing really well. Rpg in a box for example https://www.rpginabox.com/#:~:text=RPG%20in%20a%20Box%20lets,together%20%22in%20a%20box%22 . Godot core devs are not very good at ux, but when the community is loud enough about an issue, they start letting the changes happen. They don't understand the value of an event sheet approach for sure, but that doesn't mean someone else won't take their excellent mit licensed engine and build an event sheet ontop of it. Its a matter of time imo

…

On Sat, 14 Aug 2021, 09:14 Silver-Streak, ***@***.***> wrote: What about godot I had thought about Godot, but quite honestly.. the project maintainers/contributors POV have kind of killed my interest in the engine pretty hard. I've seen numerous people in their Github discussions want to talk around enhancing (or really, fixing) their visual scripting system, only to be shot down due to the devs viewpoint that there's nothing to enhance. If I remember correctly, some folks' PRs to enhance visual scripting's ease of use got rejected even after completion because it was counter to the dev's vision for it (which is still unclear, but basically seemed to boil down as they viewed it as a tool for programmers to use for themselves, not for non-coders/artists/etc) I've even seen your suggestions around user experience enhancements get ignored, @blurymind <https://github.com/blurymind> 😆 All of the above in mind took it out of my research really quickly. I still think the engine is a great piece of software and could one day be the true alternative to Unity some folks are looking for (once they make 3D realistically viable), just not necessarily a fit for this. (Also its general performance for both native and web was pretty poor compared to all of the other options above, at least from the benchmarks I could find. Still *good* performance, to be clear, just worst than the rest above when averaged.) I'm not a decider in this at all, though, so I just wanted to provide context to your question. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2347 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRRWVLVYPBBEZF5LG52Y23T4YQUXANCNFSM5CB4V7NQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[Silver-Streak]

Godot core devs are not very good at ux, but when the community is loud enough about an issue, they start letting the changes happen.

Makes sense to me!

I really do like the Godot engine, and with your added context, I think it just comes down to what makes the most sense from a GDevelop perspective.

If Haxe becomes preferred as the alternate, I think the two above are both great options.

If C++ becomes preferred, I think the devs can/should eliminate Cocos and Defold right out of the gate due to licensing/longevity concerns, and then it becomes Framework vs Engine. Raylib's framework nature could be a boon, and it may be the most performant option out of all of the ones I look at. Godot has a lot of great functionality, especially with making builds easier.

(JS seems to really just be Phaser or Pixi until you get into 3D, and Rust only seems to have very early projects)

[Silver-Streak]

Just to add some updates to this discussion, focused on the above engines I posted about:

• Raylib: Released 4.0 at the end of 2021 - https://github.com/raysan5/raylib/releases/tag/4.0.0
  • Big features:
    • Control of the game loop. Likely good for making GDevelop behave the same if moved over.
    • Primary openGL renderer decoupled into its own library, making it easier for updates/fixes to be non-breaking
    • Improved text rendering, including rotation
    • Rework of it's immediate-mode GUI library to be faster and more flexible
• Bevy: Released 0.7 mid April 2022 - https://bevyengine.org/news/bevy-0-7/
  • Big Features:
    • Render to texture support
    • Texture compression support
    • More structured entity support
    • Better audio support and controls
• Phaser: 3.60 beta (supposedly) nearing Release candidate - https://github.com/photonstorm/phaser/releases
  • Big Features:
    • Compressed texture support
    • Update/overhaul of physics engine with ~40% performance improvement
    • Numerous Tileset enhancements and new features

All of these have a lot more features than the list above, these were just the big ones they listed and/or caught my eye.