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.
@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. 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).
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.
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.
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.
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.
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.
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.
Did you hear? I’m making a roadmap
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
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.
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.
I agree that those are essential features for a competitive, modern 3D engine that is complete. I think all of those things are worth working towards, but I agree with @khionu that we can’t hit the majority of those in the next year.
Until then we’ll be building up the core essentials necessary to make anything and make sure that it actually works. Once you have a foundation that works, then you can start layering on extra features and make sure each of those work without killing yourself by having to keep the thing from falling apart at the seams.
I can understand that. Now, many of the things above can actually be delegated to the user of the engine. This should strip down the list significantly:
- Modern graphics API
- PBR materials with support of custom GLSL shader and rendering/compute pipeline (allowing the user to code up more complex things like shadows, probes, particles, hair, grass, etc)
- Lights and environment object that can load custom shaders (delegating implementation to user). Optionally provide at least cubemap or rectangle HDRI maps
- API for 3D models, skeleton, and animation imported from gltf 2.0.
- Render targets (with this, the user can composite with custom shaders + pipelines, and implement UI)
With these, the engine would provide features that are absolutely essential or common (such as PBR materials).While other features from the original list are also important, the user can at least code them without significantly modifying the engine itself.Just think how hard it is to write a shader in Amethyst right now.
I do think armature and animation are essential, because these are truly difficult for the user to implement.I can spend hours debugging a custom shader, but I would go nuts if the model is twitching in a sanity-draining way because I have to code armature animation myself.