-
-
Notifications
You must be signed in to change notification settings - Fork 746
RFC: Extensions system "Shards" #34
Comments
Any suggestions on missed tasks or redundant tasks are hihgly welcomed! That's an extremely early draft of something Amethyst will be built on, so we need to come to conclussions and discover missing parts. |
@White-Oak Looks pretty good so far. There are a few points that I'm not quite clear on:
|
|
|
2,3. Hm. I had in mind that shards would not be designed to be fullfully interchangeable. I mean if I don't want to use Amethyst's ECS I can either use some other little bit different ECS as a replacement shard or I could just use some other completely different system and it would be my responsibility to glue it with renderer etc. |
As being disscussed in Gitter we are still not sure on whether shards should be added via Points about the latter form:
|
As I see it, our ECS should be a separate and independent crate so that it could be used with other projects and game engines, and our Amethyst should depend on it. However, I don't see it as an optional dependency (same as renderer, audio, etc), because all except the most basic games are going to use entities, audio and graphics (but probably not AI). In the end, a game engine's purpose is to provide game developer with the most essential APIs for games, which include graphics and logic/ECS. Because of this, I don't fully understand the necessity for shards. If there are going to be other shards which will be truly optional, please, give an example. But for now, I'm against that idea, as it introduces additional complexity both for game ("why do I need to explicitly add all these basic subsystems which needed for every game anyway?") and engine ("can't I assume that ECS library is already included?") developers. |
All in all, after a discussion in Gitter, I came to a thought, that maybe none of this is needed. ECS, Graphics, Audio are all must-have for every video game, so why bother with 'shards'. It sounds cool, it looks cool, but for the simplicity sake and as common sense tells, it's better just to have monolithic game engine. It will ease interdependencies and all. |
I don't understand what kind of engine you have in mind. Do you want to create a monolithic game engine such as Unity or UnrealEngine ? My vision about this project wasn't a monolithic game engine.
and the developer had to choose some shards: all shards can be configurable in
and they can contains traditional crate feature but also component, system and entities.
in this vision amethyst would only be
|
I would think of it the same way, the 'Engine' should be an ECS/Event or similar driven engine with others 'Shards' that add components and systems, whether Scenegraph (octree systems, portal systems, etc... and related components), OGL/Vulkan/DX Rendering systems (or none for, say, a headless server, heck someone could make a Console rendering system that dumps information to the console or over SSH or so). Just simple addable parts to let people add and use only what they need. |
@thiolliere I believe you are mistaking decomposability for monolithic design. Personally, I believe that I do not believe that something as complex as an ECS, which is essentially a game-making approach, can be hot-plugged without becoming a tangled mess of dependencies, e.g. Piston. However, I agree with you on all other points. The engine would contain very basic resource management, configuration loading ( |
We're pretty unlikely to implement this at this point. No one is motivated to do so and we have cargo features and modularization if anyone really needs to do something like this. So I'm closing this. |
Each Amethyst game project can contain several 'shards', which are essentialy Amethyst fucnctionality packages with code and/or resources.
Examples of such shards can be:
Shards can be connected together in the core
amethyst_engine
crate to have additional functionality such asFollowing tasks are considered completed when discussed and implemented. If the team comes to a conclussion on a task, it is marked in a certain way:
Part 1: Features
Technically, adding shards to projects will be done through 'features' -
conditional compilation supported by Rust and Cargo. Thus, adding, for example 'ecs' shard will result in adding 'ecs' feature to Cargo.toml of a project. Feature
ecs
will enable ecs crate inamethyst_engine
.Some features, as mentioned above, can be glued together in
amethyst_engine
crate using combinned features (i.e.cfg(all(ecs, renderer))
).Some shards may not be included in base
amethyst_engine
crate and CLI will need to inject an additional dependency, when ading such a shard.Proposed:
Alternatives:
There may be inconsistence between shard name and its crate name. As well, some shards may not be included in the base crate, so an additonal dependency needs to be injected. A list of such mapping ('exotic_shard' -> 'exotic') and a list of necessary dependencies needs to exist.
tools
crateUser-specific shards. Users may share their own shards for a specific purpose. How to handle them?These are called third-party libraries or extensions and are not shards.Part 2: Shards' resources
Each shard may bring its own resources, and/or configuration files, and/or modify existing. I have no idea of this part. It should be thouroughfully discussed and, maybe, even separated to its own RFC.
The text was updated successfully, but these errors were encountered: