ECS Designs and The Vision of Amethyst

(Zicklag) #1

Continuing the discussion from Archetypal vs Grouped ECS Architectures, my take:

Amethyst’s current direction has been to move from Specs to Legion for the ECS. I believe reasonable evidence was provided to show that a move from Specs to Legion would be a benefit to the project. The reason being not most powerfully because of its performance but due to its flexibility compared to Specs ( a reference ).

The discussion thus far in the post “Archetypal vs Grouped ECS Architectures, my take” has been about the ECS models specifically and the way that they work and perform. We need to figure out practically, though, how this discussion is going to apply to Amethyst.

As far as I’ve seen, Amethyst’s decision making model is somewhat free-form. We discuss and work on stuff when we can, and the direction tends to go a certain way based on the general consensus of those involved and those willing to put in the work to go in a certain direction.

Anyway, what I’m wanting to distill here, is what we need to do to make further discussion on the ECS productive to the Amethyst project and community.

If there was a decision to be made, is it really “do we use Shipyard or Legion for Amethyst?”, or is this just a philosophical discussion about ECS design? If it is just philosophical, then that’s fine and there is nothing that needs to be done about it, but there is an extent to which the ECS that we build on now will be the foundation on which we build everything later and that makes this unfortunately difficult topic an unfortunately import one.

That said, does anybody have any thoughts for what this means for Amethyst? @kabergstrom @azriel91 @erlend_sh @jaynus @fletcher @distransient ( sorry for the pings, I don’t know who’s best to involve in this ).

From what I’ve gathered from the discussion, it seems like Legion will likely provide decent performance for the general case . While a different model ECS could provide more performance tailoring for the more experience developer . All engine designs have to make trade-offs and I think that this is the design decision that we have to make for Amethyst: easier general case performance without requiring user customization or more tuneable performance that requires more experience.

Obviously that simplifies the difference between the two models drastically, but that is my best attempt at the practical, direction-affecting difference between them for the Amethyst project.

This brings up an even more general and more important aspect of Amethyst that I’ve wanted to discuss: what is the vision of Amethyst? This question of the vision of a project is maybe the single most important question of any project. The vision is the overarching goal of the project that every other endeavor and interaction that it participates in should reflect.

The Why are you here? topic offers some interesting and valuable insight. What you will notice is that everybody is here for different reasons . Amethyst is an intriguing community. Like I mentioned earlier, decision making here seems to be somewhat free-form. That isn’t at all bad. This community has organically grown from people who share interests around gaming and Rust and it is a cool thing to be a part of. The way that we move forward is driven by the combined efforts and visions of the contributors.

Still, I think that it is important to truly define what the goal and driving motivation for the Amethyst project is. We need to know what we are working for. When decisions come up we can then bounce the decision off of our vision and work to determine what is going to best accomplish our goal for Amethyst.

For example, ( taking from the Why are you here? ):

  • @erlend_sh ( link ) is working on Amethyst because he wants to bring certain kinds of games such as procedural, simulation, and eSports to the community. Amethyst is a tool to help him do that. He doesn’t specifically want to beat Unity, Godot, etc.
  • @azriel91 ( link ) is here because Amethyst is providing tools for Rust game development and because he can’t afford to write everything Amethyst has already written.
  • @kabergstrom ( link ) is here to help create an Open Source alternative to commercial or in-house game engines and to help increase the amount of sharing that happens in Commercial game development.

We all have things we want to accomplish with Amethyst, but there are going to be times where we have to make directional decisions that will effect the future of Amethyst and we have to have something to base those decisions off of.

To illustrate, if @erlend_sh wants to make games that are, in general, simpler and not as performance dependent as a commercial “Star Wars® Battlefront II®” game or something like that, he might prefer that we use an ECS that is easier for beginners more than an ECS that is more performant. On the other hand, @kabergstrom who wants to make an engine suitable for mid-to-large commercial games might prefer an ECS that is more performant over one that is easier. What we have to distill is what Amethyst as an organization wants. This is something that we will have to decide upon as a community.

At this point I would like to get thoughts on that. Do you think that we need a defined vision, and, if so, what do you think it should be?

My vision for a game engine comes from the Arsenal project vision and my use of Amethyst is mostly a way to help make Arsenal a reality. I want to make a game engine that is approachable to anybody, but that is suitable for a game of any size or complexity. That said, to a certain extent I’m not super tied to Amethyst. If it had a different goal that didn’t facilitate Arsenal, then I would be fine building on something else, not that I don’t like this project or enjoy being in this community! :slight_smile:

Step 2: After the Vision Comes Leadership :busts_in_silhouette:
Why are you here? (Personal stories of arrival)
(Zicklag) #2

Hey y’all, I really got no response on this one didn’t I? :wink:

Anyway, @OvermindDL1 also interested in the Amethyst vision and I’m considering making this public. The Why are you here? topic is an internals only post so I wanted to double check with @erlend_sh, @azriel91, and @kabergstrom before I published this as it includes summaries of what you guys put in there.

If you would rather that didn’t go public, I can just create a new post with those parts generalized.

(Erlend Sogge Heggen) #3

That’s fine. I agree it’s important to have a wider discussion about this, so I’ve gone ahead and moved this topic into public view now.

1 Like
(Zicklag) #4

Awesome, thanks! :slight_smile:

(Nathan) #5

Yes! This is a vitally-important discussion.

My Vision for Amethyst:

Provide an amazing experience for indie game devs through reliability & follow-through for the carefully-selected set of well-supported core features.

If I were after the largest number of fanciest features, I’d be using UE4 right now. But they are focused on producing cutting-edge, buggy features rather than addressing their buggy core experience. Though they don’t state it, the de-facto attitude I observed from Epic throughout my experience grappling with their bugs was “We provide you tons of new features every quarter – you provide the team of C++ experts to fix the features you want to use.”

I want an engine that follows through on its promises, which means we need a culture of building up volunteers to maintain what we have. If we create a feature, we need to follow up with finding folks willing to maintain the feature long-term. The reality is that creating features and maintaining features are usually not mindsets shared by the same people. That’s normal, and something that should be addressed. There are people who just like to keep things working (I’m one of them). I want to know if Amethyst supports Platform X, Y, and Z, that I can rely on that and not get “we’re too busy focusing on adding feature A for major corporation B, so go deal with broken platform support yourself”–as if every indie dev were an expert in how to make things work on every platform.

If Amethyst provides something, then it should follow through with it. That means keeping documentation up-to-date. Finishing and delivering features. Not leaving things half-done. I’m thinking of UE4’s 2D support as an anti-example. Years ago they announce “now we support 2D, we made a bunch of new tools!” and then abandoned them and never actually made it a good experience.

If we were to agree with this vision (or something very similar) for the project, then the next step I would love to see is defining what core features we are working to support now, what features we are not working on, and a set of criteria for judging when/how we can add new core features while holding close to the vision. (You can’t just add features willy-nilly if you can’t keep your commitments to the core).

(Nathan) #6

Perhaps another way to phrase it:

A stable platform for Indie Devs to build on.

1 Like
(Zicklag) #7

I like that. Additionally I think that is important to decide what we want to target making Amethyst suitable for. That is going to effect things like what engine design decisions we make such as which ECS.

So according to your vision one of the pillars of the vision is stability, but what do we want stable? An engine to make 2D games? An engine to make AAA 3D games? That goes along with “defining what core features we are working to support now” but it also goes along with finding out what we want to work towards into the future, because that future target will inevitably effect our decisions now. Even if we only commit to stabilizing certain things now, we do need to know what we are going to want to stabilize later.

(Nathan) #8

An engine to make 2D games would be my preference at first, with 3D support planned later.

I’d love for us to focus on the core fundamentals of a workflow to ship 2D games. Amethyst is not much use if you can’t ship something folks can download and run without any knowledge of Rust.

Fundamentals to Focus On

  1. Stable developer experience for Amethyst itself and inviting new contributors (the nicer life is for us, the nicer we can make it for others) – work on improving our own team communication (like this discussion!), better and faster CI (working on it!), faster compilation, finding ways to express design and decisions in a way that others can consume, agreeing on a good way to make fast decisions that balance considering all the input with moving forward without delay. Eventually I’d like to have a CI/CD pipeline that supports auto-deploying a new, installable binary version of Amethyst with every merged pull request.
  2. Stable 2D “features” - tons of ways to play with sprites and shapes and some primitive collision detection, moving towards physics support later on.
  3. Stable ability to package your project into some sort of installer/archive for easy consumption (I’m assuming that means Mac/Linux/Windows now-ish, and WASM soon-ish, with the rest of the platforms coming in the future) – start with instructions, move on to command-line tools, then cross-compiling/publishing, moving towards push-button publishing for all platforms from any supported dev platform.
  4. Stable Editor – to make life easier for folks using Amethyst. My guess is we’ll need to ditch the editor and start over 3 times before we discover the Best Way™ to make an editor, so stick to basics. This should focus on minimum viable things like loading and arranging assets and saving them back to something useful by the engine. It should not try to be the one-stop-shop for creating an Amethyst project, yet.
  5. Fun With Amethyst! - I’d like to have more fun with the game engine! How about hack days, game jams, demo competitions, etc.? Anything to get us and our community out and using Amethyst together in some way. I’d personally be interested in participating in a game jam held after the legion-integration release. :smile: Honestly, I look forward to a day when I occasionally tinker with Amethyst’s internals to help keep them working, but mostly I build things with Amethyst.

Things I don’t think we should focus on:

  • Scripting - Until we’ve got a decently-mature engine to hook into, this seems unnecessary and unhelpful to me (plus I’d rather we went straight to visual scripting–if I’m going to write code, I’d like to write it in Rust). Having said that, I do still believe some research here to pick a scripting language and how we would integrate it into the engine would help us avoid making design decisions that would make scripting harder in the future. In other words, I see this as a great candidate for a long-term, background, experimental feature, but not a focus of the project right now.

  • 3D Anything - I’m willing to give 3D up for a year (or two) if it means we can have less to focus on to get into a good spot with the overall engine experience using 2D. Once you get into 3D, there seems to be no end of work required to really get it how you want. Importing all the asset types from every external tool in the world, models, materials, skinning, rigging, inverse kinematics, animation, physics, lighting, AI, navigation meshes, terrain, and on and on and on. I’d much rather be able to ship a simple 2D arcade game to a bunch of platforms and soon than be able to compete head-on with UE4, maybe, sorta, in 20 years.

I’m curious to hear other folks’ thoughts of even better approaches!

(Zicklag) #9

That’s the kind of explanation I’m looking for! :+1: :smiley:

Now the question is, who else supports this vision for Amethyst? We’ve probably got a lot of people interested in Amethyst and all for different reasons. What are other’s visions for Amethyst? What percentage of the user/developer-base would be happy to get behind this particular vision for Amethyst? How do we go about solidifying that metric and making a decision, i.e. polls, RFC’s, discussion, etc.?

For my personal projects I’ve decided that I want to start gathering together my own engine that isn’t based on Amethyst and I don’t have any specific plans to use Amethyst directly, so I don’t really care what place in the spectrum that Amethyst wants to sit. I’ll leave it up to the larger community and developers on where they want it.

1 Like
(Azriel Hoh) #10

Heya, sorry I hadn’t replied when you first posted (slipped my mind, and then never re-emerged).

I would focus on user experience (and our users are developers), so very much in support of @CleanCut’s post. It’s difficult to achieve something conceptually simple using Amethyst as the following is lacking:

  • high level abstractions (shapes, collision)
  • good error messages (either crashes with no error message, or does not crash with no error message).
  • documentation (limitations of assets, writing a UI, …)

Amethyst has had too many “sideways” movements (nalgebra, renderer, transform, wasm, legion) and not enough commitment for a long period in a single direction – evident on the number of giant refactorings in my game. I’ve stuck with the wasm branch though – it gives me GL as a backend, so CI can run with a software renderer to test the actual game headlessly. Kazan (vulkan software renderer) seems to have stopped development due to Covid.

My full time indie-game hourglass ran out (and am back to work); and have half a day each week to spend on the game / open source projects, so though I would prefer more focus on usability, my reduced presence means my voice carries less weighting.


Is there a mid or long term vision of being able to hire full/part time developers to work on the project? Or contract work on specific features?
It is mentioned on the donate page on the website, but don’t know if anything concrete have been discussed or considered.
I can see amethyst currently gets 525$ from monthly donors on the opencollective, and don’t know how much on donorbox besides my own 20$

It would be much easier to achieve a stable base and consistant progress if the project had people who could dedicate a certain amount of time each week to coordinating and contributing.
Thinking of something like how Godot runs.

1 Like

I mostly agree with what everyone said and would like to emphasise the usability point, which caused me a lot of friction while developing my game.

The amethyst examples look really nice, but unfortunatelly it seems that everything was desgined around them and not the other way around. Talking about hiding everything in prefab ron files and hardcoded rendering pipelines.

I believe that amethyst should firstly have a strong base with reusability and wouldn’t force you into specific game genres. There are tons of “easy” game engines that push for features, have fancy editors, but all the games that you can make are just variations on the examples, because they have zero customizability. So I don’t think that amethyst should be “easy” considering that rust itself is not trivial to learn. Instead amethyst should focus on usability (not to be confused with easy for beginners) by building a strong base to become a robust game engine in rust.

Again, you can find many engines that allow you to easily create games through editors, but what would amethyst offer over them? Just the rust language? Rust would fall behind in terms of features compared to other easier languages. But when it comes to high performance memory-safe engines, there are none. And performance is one of the main selling points of rust language.

By this I don’t mean that we should focus on 3D features, I mean that we should have a good base so that if someone decides to implement them they could actually do it and wouldn’t be blocked by previous design decisions.

(Erlend Sogge Heggen) #13

I’m in full agreement with your entire post. My version of a vision statement would just add a bit more specificity:

An engine to make 2D games using an ECS.

ECS design is absolutely integral to Amethyst. Instead of making it optional the way ggez or bracket-lib does, we go all-in on the ECS paradigm, baking it into our core. Any 2D game made in Rust that’s using specs Legion ought to have very few reasons not to use Amethyst.

Making an ECS game is already a harder-than-average way to make a game. It should only be done because a game’s design necessitates taking this path, i.e. because it’s expected to reach a certain level of complexity that will benefit from an ECS further down the line. Amethyst won’t be the easy way to make a game, but it can make an inevitably complex game easier to make.

Have you decided that you need an ECS (Legion) for your game? Then there’s a 99% chance you’ll also want to use Amethyst, because its entire purpose is to have already figured out for you how everything else you need for your game architecture fits in with the ECS paradim.

As such, we should also be more honest about what Amethyst is not for, i.e. the simpler types of games that you’d have a much nicer time making in ggez.

:100: Also in strong agreement here. I wrote this a year and a half ago:

I never pushed this stance very hard because up until recently most of the active contributors to Amethyst were scratching their personal 3D itch. Nowadays it seems like this path won’t be facing nearly as much pushback, so I would be more than happy to go all-in on 2D. Those wanting to make advances in 3D should look at projects like Harmony (also Legion-based), rg3d and renderer_prototype.

A more fitting example game
(Nathan) #14

The answer to the second question is clearly yes, as it has already been done with Mozilla’s WASM grant. I haven’t seen anything about an overall vision or disposition towards full/part-time work. My limited understanding of the current financial situation is that the bulk of current donations go straight to infrastructure costs.

I have a dream of running my own Indie Game team (speaking for myself specifically, not for Amethyst) whose products are based on Amethyst. In that scenario, my team would directly contribute to Amethyst on an ongoing basis. That doesn’t mean much until it becomes a reality, but I would guess many others have similar plans and are just waiting for us to reach a level of usability where they can ship with us. In my particular case, I’d love to leverage my existing tiny company’s relationships’ with console manufacturers into providing paid commercial support for platforms where support can’t legally be open-sourced. That’s a long road that begins with being able to ship things.

:heart: :100: I completely agree, and I think when we communicate this to the public we should phrase this in terms of the benefit it provides (something like “good game architecture by default that won’t get in your way as your game grows” but better worded) to be more understandable to the aspiring game developer. I discovered the concept of an ECS long after I had already been unknowingly using it in “larger” game engines, and I had no idea the ECS was a big part of why my attempts using the large game engines worked so much better than my raw prototypes using media frameworks that spiraled into spaghetti code.

:100: I propose that after legion and wasm are merged we do no more stop-the-world-while-we-transition changes. That is to say, we 1) default to avoiding any unnecessary large transitions at all in favor of making what we’ve got work. And just as importantly, 2) when we decide to do a large transition anyway, we do it as a public but not widely-publicized experiment in parallel to the mainline development until it is fully baked. Then we ask the community for extended feedback on the experiment. And then either we abandon it or we schedule a future date for merging it and then announce the transition, so that the transition has certainty and a fully supported upgrade path on the day that we start announcing we’re going to make the change. This has the additional benefit of making it okay to fail at a big transition without adversely affecting the main project and the community. We need to be able to try crazy things and see how they actually turn out without messing up everyone’s ongoing plans. This has the drawback of requiring more effort overall, but I think we’re more willing to put in that effort as a community when we don’t have to fear causing any harm due to slowness or failure to ship.

:cry: I see both of these statements as symptoms of where we’re at today: a not-very-usable engine with lots of potential. Don’t get me wrong, I’m not disparaging what we have or the effort that has been put in to get here! We don’t yet provide a usable end-to-end experience for building any particular thing, and I want to get there soon. This reinforces my desire to sacrifice fancy features and theoretical awesomeness in favor of focusing on getting a very small set of features out there to support a really usable workflow. Having the potential to be great gets folks interested, delivering on the potential keeps folks involved.


:heart: I was hesitant to suggest focusing on 2D due to how cool 3D is, but I’m quite happy with the amount of support folks have shown for the idea so far in this thread. :smile:

Legion Transform Design Discussion
(Zicklag) #15

Just to be clear, a recent direction change with Arsenal means that we probably won’t be using Amethyst for it ( see a the blog post for more info ). This was partially due to the vague vision of Amethyst which we are thankfully fleshing out here, but it is also because we have a very specific vision for Arsenal and we want to build it piece-by-piece to suit our vision which has different requirements than this newly emerging vision for Amethyst.

For example, Arsenal needs scripting as a first priority, while that is not a first priority for Amethyst. This divergence is fine, and I agree with everybody that Amethyst should start to focus on a smaller target goal so that we can finally get something stable and user-friendly.

What I love about Amethyst as a community is that they are contributing not just to Amethyst, but to Rust gamedev as a whole, and that benefits all Rust game engines.

I am very happy to see this discussion making some progress and I think that this will be invaluable to the future of Amethyst! :tada:

1 Like

I wrote in more detail my thoughts here: 2020 Project Direction - The summary of which could be, “Amethyst needs to have more focus.”

Lots of the above big-picture ideas (targeting indies, focusing on 2D) sound great. (On a technical level I would be careful about going to far with “2D-only.” For example I’d keep the transforms capable of expressing 3D.)

Approaching it from a “vertical slice” perspective could drive focus be very motivating. Maybe it would be worth coming up with a short list of what should be included in it.

(Khionu Sybiern) #17

I’ve been a bit out of the loop, adjusting to work and all, so I’m only getting around to responding to this now, my apologies.

First off, 2D as a priority doesn’t make sense to me. The requirements of a high-level 2D API differ strongly from a 3D API, but both can be backed by the same rendering engine. I’m all for us creating a stronger 2D API, but not at a higher priority than 3D. It is more than possible to support both.

I don’t like the idea of marketing ourselves in such a manner. While it’s definitely something that sets us apart, talking like this leads to thoughts like “if I don’t need an ECS, I shouldn’t use Amethyst”. I don’t think we should be leading people to those assumptions. ECS has many advantages, and as the most prolific game engine in Rust right now, we shouldn’t let the downsides of ECS play a role in our identity as a project.

What I would say we are, what I think we should be, is a community that aims to reduce the pains of being an OSS game developer, primarily through our namesake engine.

While that doesn’t substantially add or reduce from what could be said to be our vision up to this point, I think it’s the most we can say without limiting our potential. What Amethyst needs is more than a vision; it needs structure.

(Alve Larsson) #18

I strongly agree with Khionu, Amethyst should not be a 2D only engine.
Most of the heavy lifting will come from the editor during creation, and we are working on it with 3D and 2D in mind.

" An engine to make 2D games using an ECS "
it would become kinda pointless tbh, not all 2D games need ECS and there already is a massive amount of 2D only engines.

if you go the 2D only route then I will probably move away from Amethyst entirely.

1 Like
(Nathan) #19

I think there are three levels of things we need to agree on as the Amethyst Developers*:

  1. “Why” - what is our shared motivation that never changes.
  2. “How” - the general strategy we use to get there.
  3. “What” - the specific thing we are going to ship next.

*How do we refer to ourselves, to those of us working on Amethyst? Most of us are not part of the non-profit Amethyst Foundation via employment or legal association, so I hesitate to use that as the name of the group. Amethyst Developers? Amethystians?

1. Why

Another name for this is “the vision” or “the dream” or “the big audacious goal”. This is WE believe and are always reaching for. It is specific enough that we can use it to judge whether something

That’s getting close! We need a “why” that resonates with the group. What about this?

We make open source tools to bring game development dreams to life.

The why we agree on should constantly guide our internal decisions, our marketing, and affect everything we do. It’s worth spending some time and getting it right. It is not branding. It is not a slogan. It is not something that gets changed with our moods. It is about who we are and why we are doing this. It will be evident in everything that we do and it will be a constant attractive force to those who it resonates with, both internal developers and “user” developers.

Can you ever be finished making all the open source tools necessary to bring all game development dreams to life? Hopefully not. It is best for the “Why” to be open-ended. A never-ending journey.

2. How

This is how we’re going to accomplish some of our why. Something we’ll put a lot of energy into over a long time. I think we’ve got this one nailed down for the next several years: we’re making a game engine called Amethyst. You may have heard of it:

In the long term, we may change or add additional hows in ways that fits with our why. This is a relatively rare, though.

Side note: I think our ECS is just a sidenote of our How. An important sidenote, to be sure, but I don’t think it’s worth obsessing over. I don’t think game developers choose an engine based on the technical merits of a single subsystem, no matter how impressive or fundamental it is to our architecture. Our “Data-driven game engine…” tag line hints at the ECS and more, which is fantastic. I would like to better define what exactly “data-driven” means to us in some other thread some other time. ECS? Hot-loading? Prefab? Lots of configs? External files?

3. What

Getting people to agree on what to focus on next is important. It enables making rapid progress in a specific direction. At the moment, I think the group of people actively working on Amethyst is small enough to be considered a single group, so we just need a single what. (If we had multiple teams, we’d need a bigger what for the organization and a smaller what for each team).

Right now, “switch to Legion” is our de-facto what. I’d like to be intentional about picking the next what before we get there.

“2D features first” is an attempt at proposing a next what. I anticipate that any 2D features we provide would be implemented in the context of a 3D engine. It is most definitely not a suggestion for making Amethyst a 2D only engine. My proposal is not the only option. We could do something else! I don’t have any better ideas at the moment. Perhaps some of you do?

Most of our daily life revolves around the what. Having an inspiring why and a great how makes it easier to pick a what to work on that feels satisfying and fulfilling.

A fresh step forward - Proposal for future development and collaboration
(Khionu Sybiern) #20
  1. Your Why and How can be combined. In fact, legally, we have them combined as our Mission Statement. We can adjust our Mission Statement to align with what is discussed here, but given the legal obligation to adhere to a mission statement as a non-profit, I think it best we think in terms of a mission statement.

  2. I don’t think our “next” is as important as much as “what are we working towards”. That’s really the kicker in what led us to this point. There was a vision of how Amethyst should be as a product, but as that vision was approached, there was burn out in tandem with some design mistakes.

Amethyst as an engine is a product, and we can’t make a product without having a combination of an “end” goal as well as an iterative plan to get there.

Our current position is one with many potential directions, and many ways to get to each. The community doesn’t resemble what it was when most of the engine was designed as we know it. We need to reassess our product goals, first, then decide our immediate next steps.

Something else to consider, our community can be considered a product, in the sense that it’s something we want to grow in relation to our primary product. Our community supports our engine, and keeping the community healthy promotes contributor retention and on-boarding.

With the abstract out of the way, I have a proposal for concretes to match. I’ll be making another thread for discussing the pros/cons of the ideas presented, of how much is used.