Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
About the simplicity issue #1152
It's a rather broad opinion that Amethyst could be simpler to use. This makes our engine less appealing for smaller games. I'm hoping to bring in everybody who shares that concern, and to start off a discussion about how we can make Amethyst simple to use, while keeping the flexibility aspect.
This thread emerged from a discussion on Twitter.
A major goal of Amethyst is to be highly customizable for the individual needs of a project. This is what I just use "flexibility" for most of the time. This includes things like
That's one side of this. The other is: people want to make simple games, like Pong, Tetris, etc. Dealing with generics, multiple lifetimes, etc. is not what is expected for this.
A bit of history
Amethyst used to be a just a few crates (mostly just the main crate) a long time ago. At some point, the sub-modules mostly moved into their individual crates. It was clear at that point that any
Now, I think this was not communicated very clearly, and I understand it just makes sense that you want to continue using the main crate to have a certain feature. This has led to more flexibility being added to what used to be rather simple abstractions, and as such, the main crate became rather complex. We are providing a bunch of simplified variants for some things, but that creates its own problems, such as
I think this is a hard discussion and needs some thorough thinking. The solution for this is most likely far from trivial, but please don't hesitate to add your ideas here!
What exactly is the point here? What do you want to discuss? How to make Amethyst more appealing for a broader audience? How to improve communication/documentation?
imho, when making a simple game, Amethyst delivers a lot of things which are simple to use.... once you wrap your head around all the concepts. Amethyst is not like SFML or similar, which many people creating small games might be used to. It delivers very scalable architecture for games. And it is not C. It is Rust, and Rust adds many hurdles. Things which might be faulty, but still work in smaller applications are not possible in Rust, which might add to frustration. As such I never even considered Amethyst to be made for small games. If you want to create a Space Invaders clone, there are better solutions. And let's be honest here, none of them is native. Platform independence and system languages are a pain, when WebGL delivers on all modern browsers on all platforms and can be integrated into native apps if necessary (Electron, Cordova, etc.)
So, since you say that Amethyst does not appeal to creators of simple games, then yes, I never thought it should in the first place. Catering to everyone is impossible after all. If you want to appeal to game devs for very small and simple games, then you'd have to abstract a lot of things away and focus on a very different set of features.
As such, I think you should draw a clear line and decide on the audience for Amethyst. Which is not to say that Amethyst cannot cater to small games... just not as Amethyst itself.
Imho, if you want to appeal to game devs with simpler needs, a wrapper library may be created, which does the hard parts and implements the necessary niceties for simplicity, so that simple-game devs just call very simple functions in order to get up and running. Your typical example then should be <10loc to get a window open and render a triangle.
I believe what's being discussed is this publication: https://alexene.github.io/2018/11/15/Rust-and-game-development.html
Maybe the tutorial could be changed to actually make more mistakes on purpose, in the style of
I.e. start off with the simplest solutions that don’t actually scale but get things working in a way a beginner understands, and then gradually come back and fix those things as the tutorial progresses.
So I as I was asked to provide some further thoughts about it here.
I think the answer to this is: it depends on what the target audience / problem space is. To me, when I looked into rust engine space, it was unclear what the target customer/project is.
Most engines start as something specialized for a specific game or well defined use-case, and they get extended and so on as time passes.
And it's alright if it's not supposed to target the space Unity targets and it goes more towards Unreal. It's basically a choice that the maintainers have. And I do agree, there are always tradeoffs to be made and it's impossible to cover all use-cases.
I sort of agree with @minecrawler here.
Amethyst already provides some simplifications to reduce friction for basic games (also useful for tutorials) and most of them revolve around providing a "configured sensibly and ready to go" version of structures. But those are really spotty abstractions. Some things are simplified here and there but a lot of things aren't.
You essentially need to build a basic "surface" for people to interact with and the key here is wide coverage. Single spots don't help when users need to combine them with more advanced parts of the engine anyway.
A good place to start looking is all the utility functions and abstractions that people have started building for themselves. Perhaps one could compile them, generalize and harmonize them, and then release them as one package to provide this "basic interface".
I don't know how much of Rust itself you can easily hide though. I think many people are not just running into issues related to learning game development or learning the engine, but also Rust as a language.
"Entities, systems, components, state machines? Wow fancy stuff. Oh and then there are Traits, all these type parameters I need to put there, and why are these lifetime things here?
See what I mean?
Ultimately, I think the community will naturally acquire some common knowledge about pitfalls, generally applicable solutions etc. We already see it right now with people discussing and sharing their utility snippets.
I'm personally always been a fan of Correct Proper Examples, but if at all possible extract the repeated parts between examples into another shared file for them all to use after the example that introduces their concepts.