I wrote a very general purpose blog post, and I’d appreciate it if you read it before continuing here.
Back? Ok great, now that I’ve introduced my line of thinking I’d like to apply it to Amethyst specifically.
What are our frameworks?
Amethyst is composed of several crates, and each crate has external frameworks it relies upon. First, the
And unfortunately we’re getting started right away with the largest framework that’s currently in the process of being rewritten (nitric). Fortunately, that rewrite is going to live under Amethyst and change at our discretion. Hopefully this will be the last time we change our ECS framework. (It’s not the first.)
Previously for this we used cgmath. We switched to nalgebra when we realized making a physics engine was a lot of work, and we’d rather use nphysics instead. Except nphysics has to go through some pretty major interface changes before we can integrate it into Amethyst proper. Hey at least the devs of that project collaborate with us rather a lot though!
Probably the second most important dependency in the Amethyst ecosystem. We rely on it for input on PC, and windowing, which means it’s got a really close relationship with our rendering technology. Maybe we should seek to decouple winit from rendering in the future. Is that even possible? Seems like this needs more research.
Is this a framework? Probably not because it doesn’t control execution flow, but it is definitely a super ambitious project that has… mostly just quietly and correctly done its job? I like this one personally and despite it flying in the face of a lot of my previous thinking I think we should keep it around.
Audio hardware interfacing with this library on non-Windows systems has been a struggle. I love the API rodio itself exposes but man the low level interfaces on this need some work. This here is a great example of something we should consider going low level on and writing ourselves.
Similar to serde, this is another crate ecosystem that despite being pretty ambitious has actually served us really well. It’s easy to use, performant, highly flexible, not sure what else you could ask for from it. I don’t see any reason to ditch this, and that’s partially because it doesn’t really dictate how we use our data, or design our APIs.
This version of the ecosystem currently in use got deprecated before it even entered serious production use. Ouch. Sometimes when you’re on the bleeding edge you get cut I guess. We’re currently rewriting this ecosystem to use
rendy a lib started by @omni-viral. I don’t know enough about
rendy to make any good commentary on it, or how long we’ll be using it in Amethyst, but I hope the answer is for the rest of the Amethyst project. I’ve lost count of how many times we’ve rewritten the rendering code.
I don’t have anything more useful to add to this than can be read here: Sorting Through the Mio Mess
So what should we do to stop the endless cycle of rewriting?
I see there are a few major steps we can take
Before introducing a new dependency with strong opinions on a hardware interface, evaluate that dependency against our target platforms and determine if we like it on all of them. For these purposes “It’ll work better in the future” isn’t good enough. We need to demonstrate it works at the time of introduction. If it’ll work better in the future then we can integrate it in the future.
When introducing a third party dependency with a strong opinion on our execution paths or our hardware interface we must demonstrate a commitment from that third party to respond to our needs. This includes being open to enhancements to support additional platforms, and being willing to work with us on fine tuning the hardware use according to what we want to do. If this is accomplished with specialized configuration APIs that’s fine too. If such a commitment falls through, we should fork it.
Dispose of any frameworks for which we can’t satisfy the prior two criteria.