Comments (12)
@bytebuddha @Julianobsg Welcome to the project! We appreciate the feedback. If you guys need any help feel free to join us on gitter.
@ebkalderon I think we should keep it as the nested structure because of the ability to easily compile the project. Maybe we can create a WIKI page to describe the structure of the project. I think adding a ton of folders to the root of the project just makes it harder to understand whats going on.
from amethyst.
I recently moved one of my personal projects to a monorepo layout and I like it a lot. Not a fan of splitting into separate projects since coordinating changes between projects becomes increasingly painful. Unreal Engine is a single repo for example.
from amethyst.
Having modules and crates mixed in src
is pretty confusing for me.
When #152 is merged, amethyst_renderer is going to be the only "feature" that is implemented as seperate crate (at that moment).
I would encourage for a flat hierarchy that would currently look like
* amethyst/
* examples/
* src/
* Cargo.toml
* amethyst_renderer/
* examples/
* src/
* Cargo.toml
For new features that are integrated, it should be individually determined if it makes sense to mantain these as seperate crates.
This could be, for example, if the crate would be useful outside of the amethyst project.
(Therefore seperate crates may avoid dependency of the main amethyst
crate.)
from amethyst.
Hey, First let me say nice project!
I'm currently using amethyst to build a Pokemon clone as a learning project. If i may offer my two cents, i would like to see it organized this way. I've had some issues when trying to use each crate separately (I quite trying and just use the main crate now). I cant remember the exact error's i was receiving but next time i come across one i could post an issue.
PS. Amethyst has some of the nicest looking code I've seen. It's been easy for me as a newbie to dig though and understand exactly what is happening under the hood, and i very much appreciate that!
from amethyst.
Hi, new to this project and rust.
I'm using some rust projects to learn the language and yours got my attention, not sure if my opinion can be useful for you, but I would like to suggest you, to split the code in separated project, as the code base and contributors grow, splitting projects helps out.
from amethyst.
While we are talking about this, I've been thinking that maybe making each portion of the engine to be separate crates instead of modules might not be the best idea. You can see the problems it causes with amethyst_context
only being able to get other crates through importing it by its Cargo.toml
:
[dependencies.amethyst_renderer]
path = "../renderer/"
version = "0.3.0"
Which means that any bit of modularity it might have is diminished (since it now depends on getting another crate locally). The only current benefit I see of splitting into separate crates is shorter compile times (which will eventually be swapped when incremental compilation comes along).
from amethyst.
I am working on my own game engine with similar design. I switched to multiple crates from modules. Compile time was much faster. It made it inconvenient to change dependencies such as gfx versions. It was also more hierarchical and less interconnected so it was easier to switch out parts of the engine.
from amethyst.
I personally would prefer a flat hierarchy as it's easier to distinguish the different components or layers of the engine. The top-level README could contain a quick overview, which directory contains the actual engine/entrypoint.
from amethyst.
Crate dependencies are not obvious if there is no hierarchy.
I'm not sure the current set up is too obvious with the dependencies (since some crates may depend on other sub-crates). So I think moving them to the top-level might make it easier to read anyways.
A simple
cargo build
at the top level is enough to build the whole thing.
Wouldn't it be easy to do this by doing
cd amethyst/
cargo build
from the top-level?
from amethyst.
I like @lschmierer's hierarchy. I would also recommend that the book reside in the amethyst
crate because the book describes the use of the top-level crate in particular, not necessarily all of the sub-crates. Where should we put README.md
, CONTRIBUTING.md
, etc?
Actually, looking at the workspace section of the Cargo Manifest Format and the linked RFC 1525, it appears that this is the idiomatic way:
* amethyst_config/
* examples/
* src/
* Cargo.toml
* amethyst_renderer/
* examples/
* src/
* Cargo.toml
* book/
* examples/
* src/
* Cargo.toml
* CONTRIBUTING.md
* README.md
I like that the amethyst_*
crates stay nicely towards the top since it's all in alphabetical order, and also there is no question of where to place the book and Markdown files. Therefore, I think we should use this method.
from amethyst.
Heads up, this will actually be landing as part of #233!
from amethyst.
Implemented, so I'm closing this.
from amethyst.
Related Issues (20)
- Pong game breaks when using Airpods Pros HOT 5
- Derive proc_macros unnecessarily require the user to import apparently arbitrary types HOT 1
- RenderingBundle has undocumented dependency when used with ApplicationBuilder HOT 2
- RenderToWindow::from_config_path - Parse Errors include filename that couldn't be parsed HOT 2
- Include brew dependencies for MacOS HOT 1
- update amethyst_rendy to use rendy 0.5.1 HOT 1
- Reduce friction to use register_asset_type! macro HOT 1
- Allow use of legion system macros without needing to manually add legion crate HOT 1
- Add example how to add thread local bundle / system with object which can not be send between threads HOT 3
- Most Examples Are breaking, With missing imports HOT 1
- supported platforms? HOT 1
- Examples fail to run second time with error: failed to load manifest for workspace member .assets_db HOT 1
- Custom pipeline properties for rendering (3D-related)
- [Question] is there a way to download all of amethyst for convenient offline use
- the focus screen functionality does not work at all HOT 9
- Amethyst rendy is broken, the build is broken and has been broken for more than a year HOT 4
- Amethyst Roadmaps not updated to reflect project discontinuation
- amethyst was deprecated? if yes, why? HOT 3
- Make tiled windows fullscreen
- Wide layout not resizing with new windows. Requires relaunching.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from amethyst.