Programming isn't enough
I've been working on a digital, competitive card game for a year now. I started this project with intent to illustrate how to do this kind of thing via some kind of blog post series, but it got out of hand and now it's a "commercial project."
Fundamentally this is me falling back on my old compiler and execution model design habits. The technical work has been very intense and somewhat experimental. I have not found any helpful information on how to do this kind of thing in the wild.
This is also a "Rust Project", it started out as such because rust has algebraic data types which is great for engineering formal languages and also my 9 years or so of hands-on experience with the language mean it's fully within my comfort zone.
In the last 5 months I've ported both the client and server to Bevy, having previously relied on a Big Game State Struct which was gradually getting more and more difficult to deal with because of rust's messiness around partial borrowing rules, as well as a Godot client that got out of hand in terms of trying to keep up with the Serde json output of the server.
This jump felt like a mistake at the time, but the gains have genuinely been worth it. Bevy sidesteps a lot of rust's issues in really interesting ways. I worry I come across sycophantic when I say that. I am deeply philosophically critical of the ways we develop and use technologies, but I am impressed with the ways this one has been designed. Additionally, it has meant I can simply and portably "import typesetter" for my card faces and then rely on Typst for my procedural graphic design needs.
Programming really, really isn't enough
Bevy solves a big problem in managing complexity – isolating what you want to access and change and when in a large project – but at this moment in time it trades it for another: knowledge of what makes up your project is tied up almost entirely in your code base, and the primary piece of design tooling you can use to interact with bevy right now is a text editor. A text editor can technically achieve everything that "an editor" can do but "technically" is doing a lot of heavy lifting here. This isn't to say Bevy is fundamentally tied to making this trade-off, but instead it is stuck in an in-between right now.
Meanwhile, for many years you've been able to set up physics simulations, entire complex scenes, UI design in Godot without touching gdscript. When it comes to game development, programming needs to at the very least be able to be incidental as an action a game developer takes. Many programmers love game development as a programming activity, but this does not mean all game developers love programming as a game development activity.
Programming, outside of tools for programmers, will never be the whole of what needs to be worked on. Embedding as much as possible in code only makes things immediately easier for people who use programming as the whole of their workflow. It will not help people who view programming as a means to an end or a frustrating part of their day. Sometimes the person using or pining for design tooling is also a very experienced & knowledgeable programmer who does not want to spend her time knee-deep in code alone.
What an editor actually is
A "game editor" is not only a program that lets you design and manipulate data but also a library of what you've worked on and a method of organising and viewing those things. A museum of you and your collaborator's design, asset, and architectural decisions. Folder structure, UI prefabs, shader graphs, relational graphs of what assets are used where and if there's any preprocessing applied, schedule orderings, system graphs, etc.
An editor is a piece of software that aids in the management and creation of relationships1 between assets and behaviour. There are ways to design game production that are behaviour-first, with assets and relations a distant concern, but for many projects (especially hubristic, technically over-ambitious ones with solo developers) this is not really tenable. For those who do think it is tenable: how big is your project, how much of your time can you devote to it, how many other responsibilities or stressors do you have besides it, and is it your grand finale magnum opus or do you want to work on things afterwards too?
This is the main point I want to convey: It's not just the individual files and their contents that matter, but the relations between them. Being able to display a scene that consists of nested prefabs means being able to display a bunch of relations between different bits of data across different files. This relational view is what makes "editors" powerful.
Waiting for BSN / The Editor / game development salvation
I want bevy to succeed. I want it to succeed from an engineering perspective. I want it to succeed from a design perspective. I want it to succeed from a community perspective. I want it to succeed because I am personally invested in ways I can't easily extract myself from, I think the things it does to extensibility within an infamously inextensible language are incredible. But I've hit a limit I can't really ignore.
What I need is design tooling. I think a lot of what people need is design tooling. I have commented ephemerally on platforms that don't matter that my notebook has taken up what was previously accomplished with an editor, but it can only do so to a certain extent.
I know that game engine scene formats are often grotesque. That the values internalised in rust communities tend towards a slowly designed but sturdy standard being far better than a quickly assembled thing that works but spaghetti's out once design constraints change at all. But it does suck to be in a position where my project complexity outweighs what a single person can accomplish without the knowledge/recall and design tooling available in other projects.
I'm not sure if this is "bevy in anger" or if it is "bevy in burnout" – most of my project is done, at least on a technical foundations level, but it's these things where the breadth of the rest of the project becomes overwhelming when I'm asked to implement something like a UI slider from first principles. Or wanting to change things that would be basic asset-based preferences in other toolchains but here is "hard code your preferences or come up with your own system for loading preferences."
A wishlist for design tooling and editor features
I don't want this to be an inactionable, grumpy polemic. I know there's a dependency tree on even an experimental canonical editor for Bevy. So I leave here what I'm waiting for, in a rough order. But really what I want is "an editor" that also acts as an aid in project knowledge management. The ways complexity does grow out of bevy/ECS-first projects is not something I'm used to, and managing that complexity is going to need to be a big part of how design tooling ends up looking.
Design tooling:
- BSN, the file format, which I am aware is the linchpin on all this
- Visual UI design tooling built on top of BSN.
- Input widgets, which I am aware needs some kind of canonised BSN macro for directly tying structure and behaviour in these fundamentals in either a reactive-style way or Some Other Way.
Editor "knowledge management":
- Visual Schedule viewing and manipulation.
- Visual System viewing and manipulation.
- Visualised in-code relationships – which system calls what methods on what other types. This isn't even a Bevy ask, just a general rust tooling ask. I've thought about how to do this with rust-analyzer but I've yet to act on it. In large, complicated projects it would really benefit to see even a messy graph of what functions use what methods from what other types.
That's it really. This is an expulsion and a request. A cry for help and a resolution towards what I need to do once I come back from a short gamedev break. I'll have another blog post sometime in the next month as a text version of a talk I'm giving in a few weeks, too.
Not the Bevy feature "relationships" but instead the general idea of relationships between things.↩