Hello, my filesystem-biased friends. I’ve recently come to love writing bevy code – it’s a very clean ECS engine, it makes everything very simple and straightforward but I end up feeling lost in the tangle after a while. The “tangle” comes from the fact that I want to organize my data (components, events, etc.) so that they match the files they’re in, and this is hard. Overlap increases as code gets older, and time T+1 always sees more chaos than before.
I shaved some time off this last weekend to try and remedy that by creating a layer on top of the filesystem and see what it would be like to have an editor that isn’t obsessed with physical location, but rather intent. What if I could find all the systems that deal with input events? Wouldn’t this be more useful than having them be in one or more files? Of course, writing a full-fledged editor is out of the question (for now), so I made a VSCode notebook extension that could filter systems by various queries. Here’s a snip:
You can add arcane symbols to the start of your query for different effects – for example, < and > mark that you’re looking for event readers and writers, respectively. Use & to mean immutable reference to a component, and * to mean mutable. If you want to check if some system carries a marker on it (like saying With<Foo> without actually getting the data from Foo), use + (and similarly - for Without). It works with Option and should work with most everything else (but if not, open an issue, I want to make it work well for all usecases). It’s smart enough to skip including generic arguments, even. The function declarations returned are linked to the actual code so you can jump right in.
You can even add markdown, meaning that you can make live documentation that changes as your code changes. There’s an open issue that says that bevyrly doesn’t follow your code changes yet, but easy does it – I’ll get some time off next weekend, and for now – there’s a command in the palette called “Start Analyzer” that makes this work.
I hope this is useful to someone else too, and hope that it leads to us figuring out what editor would be best for this great engine and paradigm. I think a change is needed, in any case.
Leave a Reply