ECS Designs and The Vision of Amethyst

(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.

5 Likes
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.

:100:

: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:

5 Likes
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
#16

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.

4 Likes
(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.

4 Likes
(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.

5 Likes
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.

4 Likes
(Zicklag) #21

A little bit tangential to the topic, but actually I do pick an engine based on the merits of ECS. At this point if I can at all help it I wouldn’t write a game without one, but that’s just me. :slight_smile:

5 Likes
(Nathan) #22

@zicklag You make a good point, my friend, but remember that you and I and everyone here at this stage are, quite frankly, innovators who are creating the new thing, so we are a different group. :laughing: The next group of folks we need to attract are early adopters, and they may make choices different than we do (and the later groups definitely will).

1 Like
(Lochlan) #23

Couple thoughts from someone relatively detached from the project:

  • 2D is a good focus but dropping 3D development entirely doesn’t seem like the best move. There’s a million ways to make a 2D game and some of the most interesting “2D” games end up being 3D (just my opinion) — think Limbo or Fez. With that said, as long as 3D remains possible, I can continue to invest in Amethyst.
  • There are strong alternatives to the 2D story right now (ggez), Amethyst is the only serious 3D engine for Rust at the moment.
  • Is an editor a good focus project at this stage of development? If I was going for ease of use there’s virtually no reason why I wouldn’t pick Unity over Amethyst. I’m using Rust for its performance and lowerLevel features so I can have deeper control. An editor doesn’t help my achieve those goals. Faster iteration would be cool though, I think some sort of hot reloading capability would be much more valuable than an editor at this stage.
  • I don’t think being a 3D engine means you have to support every format under the sun. Best thing to do is just make sure it’s possible to develop the integrations separately: Three.JS is a great example of this.
4 Likes
(Khionu Sybiern) #24

I fully agree. We’re already at the point of supporting 3D, it would only be a regression for us.

The editor, for a number of reasons, is being developed behind a curtain. It will be as OSS as the rest of the engine after the MVP is reached.

(Zicklag) #25

I think the fact that the editor is being kept as a separate behind-the-scenes effort while not drawing a lot of investment from the general community is a fine situation right now.

Also, from a different perspective, I’m not sure what else @mralve works on, but being that the editor is close to the heart of @mralve and that is what he is motivated to work on, I think it makes sense that he can contribute to and design that. I can’t speak for him, but otherwise he might no be contributing at all? In situations where a contributor wants to champion a certain feature, as long as it isn’t detracting or hurting other efforts, it isn’t a detriment in any way.

(Khionu Sybiern) #26

The editor is a massive undertaking. That said, he is working on freshening up our branding as well, and is also thinking forward for scripting support.

1 Like
(Alve Larsson) #27

Yeah we have a private Editor repo I and @fletcher is working on, this repo will go public when we hit MVP status and it’s going to serve as our official editor.

1 Like
(Nathan) #28

This is the strongest reason I’ve seen for why to choose some end-to-end 3D functionality as the next main focus after legion. It needs to be mapped to a specific closed set of 3D functionality for it to be actionable. I would be willing to support this direction if someone could map it out in a reasonable amount of detail.

3 Likes
(Khionu Sybiern) #29

:wink: Did you hear? I’m making a roadmap

4 Likes
(Nathan) #30

Woohoo! :heart:

2 Likes
#31

I would suggest plugging up some holes we have in FOSS 3D engines: we have a few that are mature, but most of them can be considered “legacy” in 2020s. Perhaps such a list is a good start but not comprehensive:

  • Modern graphics API (which Amethyst is already using)
  • PBR shading, with or without fancier things (shadows, GI probes, volumetrics, etc). Note that it’s those fancier things that we lack in FOSS 3D engines
  • Environment texture/material/shaders
  • Easy way to use Custom or Compute shaders (which is absurdly hard in Amethyst right now)
  • GPU/CPU Particles
  • Pipeline to import and use 3D modles, skeleton and animation. gltf 2.0 is probably the best format for this.
  • Collision detection, continuous or not
  • Some support of physics, or API to implement one’s own physics engine
  • UI overlay
  • Custom render target and viewports
  • Compositing

More inspiration can be found by looking at documentation of more mature engines, say Godot.
The features I list above are what I consider essential for a modern 3D engine.

(Khionu Sybiern) #32

All great things, but a roadmap for our next year will likely have no more than half of that, likely a significant bit less. We have technical debt to wade through, and we don’t have anyone paid full-time.

2 Likes