The constant cycle of rewriting and how we can put it to an end

(Jacob Kiesel) #1

I wrote a very general purpose blog post, and I’d appreciate it if you read it before continuing here.

Rewriting software and how to avoid it

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
biggest one.

  • specs

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.)

  • nalgebra

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!

  • winit

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.

  • serde

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.

  • rodio

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.

  • log

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.

  • gfx

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.

  • mio

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

  1. 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.

  2. 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.

  3. Dispose of any frameworks for which we can’t satisfy the prior two criteria.


Sorting Through the Mio Mess
(Lucio Franco) #2

I understand as we move forward this is important but what is the point if we literally have to rewrite all that code, then write the code we need?

Specs was originally and still is written by amethyst people, could be technically considered an amethyst project. It was built for and by amethyst pretty much, so its kinda unfair to say its external.

1 Like

(Jacob Kiesel) #3

Not entirely, the specs project is also shared with kvark and wadelma. In previous conversations with them I’ve been explicitly told specs has users that aren’t Amethyst and consequently it won’t change purely to suit us.

The point is to have a solid foundation. Something we can rely upon. I understand this comment is likely about the mio conversation, so what’s preventing an Amethyst person from going and fixing our problems in mio right now? Whatever the answer to that question is, that is why we shouldn’t use mio as a foundation imo. Now of course I do need to concede I haven’t researched these problems specifically and I’m not very familiar with them, but it sounds like getting mio working well on Windows could require some fairly significant overhauls, possibly even to the very model and API mio is using. Before we clog this thread with mio specific details I’d like to direct those kinds of comments back to Sorting Through the Mio Mess


(Lucio Franco) #4

There is nothing stopping us, in fact we have all the tools. We just need to spend the time. I have a very good personal relationship with the maintainer of mio. The thing is fixing mio would be way less work then us building our own epoll library that is fact.

Kvark was originally working on amethyst. but sure I get that point, ECS is very core to our product and thus this specifically makes sense to have under us. Others im not convinced.

1 Like

(Jacob Kiesel) #5

There’s not really anything for me to grab on here and discuss. Can you elaborate on this and convince me of your viewpoint?


(Lucio Franco) #6

I mean’t I believe what ever our ECS library is it should live under amethyst and we should have full control. Other libraries im not convinced need the same treatment.


(Jacob Kiesel) #7

I understood that, why do you feel other libraries don’t need the same treatment? I’m sorry I’m just a bit peeved I’ve written several paragraphs on this and all I’m getting feels like “eh”. Like do you not think the issues I’ve raised are important? Do you have experience to the contrary? Do you feel like simply the fact that you personally aren’t convinced means Amethyst must therefore ignore this?


(Kel) #8

I think in a way it might be a good idea to take on a far smaller API surface in terms of algebra/math data structures. nalgebra provides quite a lot which is nice, but it would be very beneficial if we could instead provide the structures ourselves, write the very little math we use from that library into the engine, and allow easy interop with nalgebra/cgmath if desired. The entire section of nalgebra we use is extremely small inside the engine already in terms of api surface. The most important common stuff is contained in num_traits it seems


(Khionu Sybiern) #9

Your points are very on the nose assuming a stable ecosystem. Rust… isn’t quite there. The shape is, in general, but it’s still settling down. There’s still the chance that something won’t quite fit into place and will be replaced by the Next Greatest Thing. There will be a lot of great things that are still being worked on and are on course to be worked on, without alternatives.

That last one is what got me typing this to begin with… as a team, we’re already writing two crates that are candidates to be the go-to for game development in Rust (rendy and laminar). One of the benefits of ecosystems like Crates.IO is the distribution of maintenance cost. We should be cautious about taking too much of that cost and responsibility on.


(Jacob Kiesel) #10

I believe the instability of the ecosystem actually amplifies my points, and I feel strongly about them because I’m tired of the rug being yanked out from beneath us. It does mean we have to take on more work, that’s true, though I view that as a front loaded cost, and not something we have to pay continuously. Constantly rewriting and following the hype does seem to be a cost we’re paying continuously. It’s lower at first, which is why the approach is attractive, but we keep finding ways in which our deps are inadequate and holding us back.

I want us to have the flexibility to get the job done, and I’m tired of trying to get developers outside of our org to care about our issues.

I want our own version of the following personally:

Low level audio interface
Thread scheduling
Low level input interface


(Khionu Sybiern) #11

I understand why that’s the direction you feel we should go in, but at the same time… this is part of being a part of OSS. We need to both consume and contribute, give back to the ecosystem we’re taking from. With that, we all learn. It will slow us down, it will get better with time. We need to hold out and help the process, not abandon it.

I would say any case where we cannot make timely communication with a developer, or their efforts start getting measurably stale, we can make exceptions to that, as we would then be filling in the gaps that they are creating, but we should make sure we’re not making this replacements just for us. That is as good as proprietary.


(Jacob Kiesel) #12

That’s fair. In this case I only have one real request then. For any officially supported platform a bug preventing high quality games from being published on it should be considered our highest priority within that sub-crate.

For audio, this means our highest priority should be getting rid of the glitching on OSX and Linux
For networking, this means our highest priority should be making Windows performance acceptable


(Joël Lupien) #13

I don’t want to go too much in depth, but I want to remind everyone that we aren’t any smarter than the maintainers of other crates.

We are bound to make mistakes too. Its easier to fix a code base than rewrite it from scratch.
If a maintainer is not cooperative, then we can just fork and continue using that dependency with our fix.

That’s why open source is so cool, we aren’t blocked by other people and their decisions for very long periods of time.

Also, I don’t care how many deps we have. As long as the “you don’t pay for what you don’t use” rust rule is respected (including compile time to an extent), then that’s fine with me and I don’t see how less dependencies would make sense, as you are just moving the code’s location in the end.


(Khionu Sybiern) #14

I agree completely. We should never knowingly push even a quality-degrading bug to release.


(Joël Lupien) #15

Or sound at all when you have jackd installed on linux :stuck_out_tongue:
cpal works but rodio doesn’t.


(Jacob Kiesel) #16

Googled “jackd” and got something very different :laughing: what is this? How is it impacting your experience?


(Khionu Sybiern) #17

Newer audio API on Linux


(Joël Lupien) #18

Clunky setup to get more control over the audio basically.
Amethyst (rodio) goes through pulseaudio, as a fmod virtual device. Its the same kind of device used with sdl based games. For some reason, rodio doesn’t play any sound through that device, but cpal does just fine.

(also totally offtopic, sorry)


(Erlend Sogge Heggen) #19

Here’s a quick “relations analysis” from my limited personal perspective (happy to make edits). Bear in mind that a weak relationship doesn’t necessarily matter at all so long as a dependency quietly does its job well and is sustainably maintained, e.g. as seems to be the case with serde and log for the time being.

However if a library is not working well for us in its current state and we have a weak relationship to its stakeholders, that’s a strong argument in favor considering other options. Rodio is currently in that intersection.

Very strong. We’re making it ourselves.

Good. Author is very responsive and holds the game development / Amethyst use case in high regard.

Okay. We don’t have much say in it and game development is just one of very many directions the project is being pulled in at the moment.

Weak. Nothing game-specific about it afaik. Very actively maintained.

Weak. Nothing game-specific about it afaik. Not very actively maintained.

Weak. Nothing game-specific about it afaik. Not very active, but officially supported.

Good. We are closely linked to it through Rendy, and several of our team members have also made meaningful contributions to gfx.

Okay, seeing as we’ve got at least one Amt member co-maintaining mio’s parent project of sorts, Tokio.

Maybe start separate topics for these so we can get into specifics? This topic should be kept to a higher level discussion of “what’s our policy on dependencies vs original libraries?”

(I excluded ECS since that discussion is already well underway.)

1 Like

(Lucio Franco) #20

First, I want to say, I am really sorry I should not have commented while tired and busy. I did not mean to come off as just saying “eh” youre wrong. Its been a long week for me.

Second, I 100% understand the pain you are feeling around this, we have changed our libraries many times. I’ve seen this project change things so often its crazy. That said, I do not think we would be anywhere close to where we are right now without any of those external projects. Even if we find they are wrong they have helped us move in the right direction. And that is okay, its okay to rewrite things, its okay to change paths. That is perfectly normal. To think that we will get it right on the first try is just not true.

What worries me is this. We are all volunteers, we burn ourselves out on our current path and method of writing amethyst. I feel the more we move to us writing, lets take for example, winit. A library that works for us we’ve had some differences with its maintainer, we’ve had things we have had to work around for it. But it works for us. If we spent all our energy rewriting winit right now we wouldn’t have energy to write features for amethyst. The most important thing we can do for our product is build features for it. Us developers like to rewrite things, we like to do things our way, which is fine. But when youre trying to deliver something, rewriting is not always the right thing to do.We need to get to a point where we have the opportunity to write things the way we want to and I don’t think we are there yet. The more code and maintainership we give to ourselves, the more burnout and the less amethyst actually moves forward.

That said, I do think there are points where we should rewrite, and I think rodio is a good example. Mio I do not think is.