A fresh step forward P2 - The Engine

This is part 2 of A fresh step forward - Proposal for future development and collaboration.


Note, this includes short, medium, and long term goals. It is what I think the engine should look like EventuallyTM.

Core engine - amethyst

When a person starts using Amethyst, they will import amethyst and set a limited number of feature flags. After that, they should be able to create a basic 2D or 3D game with relative ease. Anything that isn’t necessary to achieve that should be excluded, including networking.

What I think we can limit to for bare essentials:

  • ECS
  • Renderer
    • Distinct 2D and 3D APIs, with feature flags
      • The APIs should be compatible. 2D APIs should be usable to write to a canvas manipulated in 3D space.
    • Move away from Rendy
      • Long term goal. The surface API is more critical, and the move away from Rendy after the aforementioned APIs are in place should cause little to no breaks
  • Input
    • Keyboard and mouse events
    • Feature flag for controller support

More notes

While handy, things like Stages should not have first-class support. They are easy enough to include if we keep the entry APIs simple enough. When I dived back into consuming Amethyst recently, I was overwhelmed with the “helpful” things I needed to sort through to know what I needed. Our whole Application design will need to go.

Extensions - amethyst_ext

The idea is that this should be a bundle around “high demand” utilities, but avoiding specialized needs. Not networking, because people may want TCP, UDP, Laminar, QUIC, or who knows what. Not ateliar_assets, because it’s too big to wrap.

It should include amethyst_locale, some things from amethyst_utils, amethyst_core, and old amethyst, such as the Stages API or a background Task executor.


We should review crates for deprecation. One I’m looking at is amethyst_config. It’s not only very easy to do by hand, it’s restricted to the RON format.

Please share any and all thoughts. I didn’t include all of my thinking for many of the points, so please ask me to elaborate on anything.


I would suggest sketching out a roadmap that goes out to at least the end of the year. The core thing we lack (and have always lacked) is a coherent plan to get from A to B to C.

Here is a page from Game Engine Architecture that lays out most of the components of a game engine. It might be worthwhile to go over it and see what we have, what we are missing, and use that to start figuring out what we even need.

@erlend_sh and @mralve and @CleanCut should weigh in on this too.




:face_with_raised_eyebrow: On the face of it this sounds like another huge transition (nooooo!), but I have no context. Can someone give me the TL;DR version of what’s so architecturally wrong with Rendy that we can’t just fix it? Or even better, link me to some other place where this has already been explained so I can read up on it. At least this is listed as a “long term goal”.

:100: This has been my experience every time.

I wish I were experienced enough with the code to have an opinion here. Whenever I see “throw it out and rewrite it”, warning bells go off in my head. Many developers will happily rewrite ad infinitum and never actually ship anything (me included). Not saying a rewrite here isn’t necessary (or even whether it’s a lot of effort), but I think we should have a high bar for rewrites.

It isn’t clear to me if you are saying we should have some sort of extension or plugin system, or if you’re advocating a specific single “extensions” feature that bundles up everything we want to offer, or something else. Could you clarify?

:100: Always a fan of revisiting old code and cleaning it out if it makes sense.

:100: Yes! Yes!

Hehe, I have the book right here. Page 33. :open_book:

I’m too tired to go any further tonight. I’ll rejoin this discussion again when I can. Thanks for being awesome, everyone. :heart:


Oh, and you are on-form tonight, @khionu – that gif made me actually laugh out loud. :laughing:


Re Rendy, the short of it is that it’s too much, even for itself. There’s some that you can read back on in #rendering on Discord, including what was last said by Viral himself. Rendy is an incredible project, but it has a couple critical faults, the one I would primarily use as evidence for a need to switch away is the difficulty to pick it up. It will hinder contributions as well as users who need more than what we provide, nevermind attempts to fix it. Additionally, it has gone into maintenance-only mode.

Re another huge transition, not if we create the 2D and 3D APIs on top of it, first, then swap Rendy out from underneath. Even if the glue between the APIs is poor in performance, getting the API in front and getting that relatively stabilized will mitigate much of the pains involved in transitioning.

I agree. I could have phrased this more delicately. The gist of Application is that it’s an opinionated and over engineered piece of glue that doesn’t actually bind together much. It’s a rather thick abstraction on top of the modularity that I want to avoid in the new amethyst crate. In an ideal implementation, I’d want to keep the new amethyst simple enough where glue doesn’t feel necessary.

Where I started with the idea of amethyst_ext was to bundle all the small and less opinionated modules in Amethyst. amethyst_locale, amethyst_config, the Stages from current amethyst, possibly the Editor integration(s), etc. Baggage that people would only not want to import if they were trying to trim down, essentially. A crate full of utility, nothing as elaborate as a plugin system, that should be kept out of scope as the scripting engine.


This may be a premature discussion and it would need a new topic, but WGPU could be a great option for the renderer in the future. I think it would open up access to the renderer to new contributors much easier as you can write 100% safe Rust.

Also, I think it is going to have massive community backing in the future ( who can take care of all the unsafe Rust ), likely becoming the de-facto Rust graphics backend IMO. It actually borrowed some parts of Rendy, and it is build on GFX as well, so we keep the cross platform abstraction. And Mozilla is going to be using it in Firefox, so that kind of guarantees a certain amount of backing for it, assuming they stick with it.

I think it’s a good fit from a maintenance perspective.


:+1: So it would be like, “here’s a set of extra stuff that some people will need, but that aren’t necessary to make a game”.


s/some people/most people/, but yes. One could debate that controller support could go there, but I’d default to leaving it in amethyst unless there were statistical data to support otherwise.

To be blunt, it is premature. My roadmap won’t include removing Rendy for 2020, possibly several months into 2021. My #1 priority in this roadmap is to have the changes be iterative, allow us to do releases while the work is on-going.


I think WGPU is a really nice candidate for rendy replacement. It shouldn’t be too hard to replace either, the API is pretty similar IMO. We would have a graphics backend that is already supported by a huge developer team and organisations, so no need to invest our developer time, which is what rendy lacks.

Another thing that really scares off contributors (and regular game developers) is unnecessarily complicated engine code, which usually is a result of patching bad architecture/design. Like the mentioned Application, it has 3 (!) generics and a lifetime, while its functions have an additional 2-3 generics. One of the reasons for this is StateEvent, which attempts to bundle all possible event types (window, input, ui) so that the state wouldn’t have to register ReaderId for EventChannels. Not only this infects Application with generics, but there is also a procedural macro which slows compilation time and obfuscates code, and also makes amethyst_ui a required dependency. All of this was added just to save a few lines of code in the state. Why not go the other route and make ReaderId registration automatic or simplified?

I got a bit carried away by this example, but I think it proves my point that engine’s code is made really complex for new contributors to understand just due to bad design choices and extreme focus of reducing boilerplate. I can add example folder prefabs to this also. All the examples were so slimmed down to prefabs that it has no learning value. People keep asking the same questions “how to create a mesh”, because there are no real examples.

I agree with @khionu that you should be able to use just the bare minimum (ecs, rendering, input) without compiling everything else. Currently all amethyst_x crates are so coupled that it’s even impossible to exclude crates that are under feature flags.


Right now, it’s my primary candidate, and I’m doing some experiments with it and Legion. That said, I’d like to emphasize that moving off of Rendy is definitely a long term goal. The 2D and 3D APIs need to be created first, to make the transition to whichever engine relatively smooth. Moving off of Rendy is easily 9+ months down the road, potentially longer. I apologize for laying this so thickly, but I don’t want anyone to be under any misconceptions.

After the Legion port, we’re done with drastic, blocking changes. It’s not an option anymore, it’s how we landed with Rendy to begin with. Everything in my proposal can be attained without ripping off proverbial band-aids.


No need to apologize for being clear. Repetition is a fundamental component of clear communication.