00:00:00
00:00:01
Architecting a Rust Game Engine (with Alice Cecile)
1.3k Plays15 hours ago
This week we take a look at Bevy, a new game engine written in Rust. And in particular, we look at a core component of Bevy that has something to teach you even if you never write a game: its Entity Component System, or ECS. An ECS is an approach to managing complex systems with large numbers of moving parts, that takes some inspiration from the Relational Database world, and a little from Functional Programming to build something entirely unique and surprisingly high-performance.
Joining us to explain all is Alice Cecile. She’s part of the Bevy foundation, which is charting a course from data-management and rendering tool to fully-featured game development environment. A journey they’ve made huge progress on, but still expect to take another decade to come to full fruition. We look at the core ECS, and the wider project-management approaches they need to make the journey.
–
Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices
Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join
Bevy: https://bevyengine.org/
Bevy Examples: https://bevyengine.org/examples/
Flecs (C++): https://github.com/SanderMertens/flecs
Tiny Glade (game): https://store.steampowered.com/app/2198150/Tiny_Glade/
Alice on Mastodon: https://mastodon.gamedev.place/@alice_i_cecile
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Kris on Twitter: https://twitter.com/krisajenkins
Transcript
00:00:00
Speaker
One of the things I find endlessly fascinating about software is all the different ideas we've had over the years for organizing large systems. These mental models we've developed for trying to fit vast amounts of software into a single rational framework. We've come up with everything's an object, or it's all actors, or it's all basically relational databases at the core.
00:00:25
Speaker
these organizational stories we've told ourselves in order to fit entire worlds of software in a single program. Now, there's one approach to this that's incredibly popular in the gaming world, but outside of programming games, it's relatively unexplored. It's called ECS, Entity Component Systems. And what ECS does is it splits the world up into things the attributes of the things and the processes that manipulate them. And that kind of looks a bit like functional programming. It kind of looks like a relational database in memory, but it's very much its own thing. And this week we're going to explore ECS by looking at the Rust game engine, Bevy.
00:01:09
Speaker
I'm joined for this by Alice Cecile, and she's one of two full-time employees at the Bevy Foundation, which is currently on a vast journey. It's shepherding the software and a community of dozens, possibly hundreds, of contributors to make what must be one of the largest software projects you can imagine, a game engine. If you've never stopped to think about it, think about a game engine for a minute. It needs a core framework, sure.
00:01:37
Speaker
You probably also need an IDE and maybe be a dedicated language. You definitely need 2D and 3D rendering. You need a scheduler. You need probably 3D modeling software. The list goes on and on. It's a vast project.
00:01:52
Speaker
So, as well as talking about the ECS at the core of Bevy, Alice and I get into how they're marshalling this force of open source contributors they've got on building what's got to be at least a 10 or 15 year software project. And Alice has some really interesting approaches to this, to the kind of soft shepherding that makes for really, really nice long-term project management.
00:02:17
Speaker
There's a lot to learn here, so we best get started. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is Alice Cecile.
00:02:37
Speaker
Joining me today is Alice Cecile. Alice, how are you? I'm doing well. I just got i just got my COVID booster, so I'm ah i'm just just recently recovered from that, but doing well today. Excellent, excellent. And you're you're immune to any future problems. Oh, yes, exactly. That's the way you need to be as a programmer.
00:02:56
Speaker
So you are, let's see, you, I'm not actually sure what your job title is, but you are pivotal to Bevy framework, right? Yeah. So, ah so on paper, my, my job title is staff engineer, which is, which is very funny because I think, um, my last job title before this was a fast food worker. Um, uh, but the, uh, but in practice I end up serving as Bevy's lead, uh, technical project manager.
00:03:26
Speaker
OK, so then you're perfectly placed to explain something to me, because but Bevy kind of markets itself as an open source game engine written in Rust. And yet I know most of its funding comes from non-game related companies. So is there a gap between what it is in theory and what it is in practice?
00:03:46
Speaker
Yeah, so so there's a gap in terms of what it is in theory and what it is in terms of practice, and there's also a gap in terms of where the money is. um It turns out that um indie game companies are not exactly flush with cash and excited to to to to to fund you know tens or hundreds of thousands of dollars to the game engine of choice, ah as as you might be aware.
00:04:07
Speaker
oh Whereas on the other hand, if you have these startups, whether they're VC backed or not, Foresight is not, it's employee owned. But it's these companies say, okay, we we have plenty of money, we we we want solutions, we want you know this co-dependency out of ours not to die, here's some money. But more importantly, um live in terms of Bevy's current state, um Game engines are a very hard target and um the...
00:04:39
Speaker
ah So a lot of the companies that use Bevy that aren't game companies, they say you you if you're not familiar with the space, you might be like, why the heck would you use a game engine? But it turns out if you have a a lot of data that you want to process at reasonable speed, and you want to have you know interactions and GUIs and and have have this that have this data interact with each other in physical ways and render to it prettily and all of these things, like you're just making a game engine. And and so you end up with ah You end up with um companies that are doing computer-aided design, companies that are doing simulation, companies that are doing weird, enhanced, interactive machine learning stuff, all all kind of gravitating towards Bevy. And this is because the alternatives there are not as good.
00:05:23
Speaker
um so Because for a game engine for a game engine to make games, you need all of these this these complex functionality. Whereas to use a game engine to make not games, you actively don't want that kind of functionality. You want to be able to cut it out and strip it out. And so Bevy's ah bevy's fairly unique level of flexibility there is really valuable to these companies. um and and And simultaneously, they don't care about, you know,
00:05:50
Speaker
artist-friendly workflows, and editors, and and animation graphs, and like advanced spatial audio, or whatever all all these features that are critically blocking for our game companies. these are actively like the These industry companies don't care at all. So you're sort of saying like there are companies who want advanced 3D graphics rendering and a UI, but but they don't want things like keyframe animation on skeletons, yeah and you can uniquely target them right now. Yeah, so ah so this isn't totally unique to Bevy. like A lot of the other game engines, so everything from Unity to Unreal to Cocos, a lot of them make a lot of their lot lot of their money and a lot of their bread and butter off of these industry players.
00:06:36
Speaker
um But yeah, it's actually it's actually quite quite fascinating. But the way that they do that is by charging them exorbitant licensing fees. And so, people well because they have identified, as we have identified, that these companies have you know a lot more willingness to spend you know business-to-business level pricing on tools to make their stuff more easily. um And so, they charge them you know to tens of thousands of dollars a year for a seed.
00:06:59
Speaker
um or or whatever. um yeah Bevy doesn't. But more importantly, ah like that's just the cost of doing business but one point the Bevy is a lot more modular than these companies and so i ah ah because Bevy has been built from the ground up for modularity, whereas with Unity, you have to hack it apart.
00:07:15
Speaker
um That's where we'll edge lies. The other thing in this space that's quite popular is 3JS, which is a visualization framework for JavaScript, but this is less featureful and it's written in JavaScript, and sometimes it's nice to get your tools in Rust because it's a better and more reliable developer experience.
00:07:35
Speaker
Yeah, OK, I can see that. And I can also see then, you know, it feels like for a while, the only UI game in town has been browser JavaScript based. It's nice to know we've got some other upcoming options. Yeah, yes and no. Regooey is a very, very hard problem. It turns out it turns out that there is a lot of subtle things that you want to get right. And it's... you it's been ah It's taken a long time for the West ecosystem to figure out how to make
00:08:07
Speaker
um and how How to make all of these paradigms work within Rust? Because if you take a standard, okay, we're going to have callbacks and callbacks and reactivity, or we're going to model of of UI from like reactor React or something and and put it into Rust, it's horrific. like It's so so ugly and it's full of boilerplates. There's like explicit clone calls we everywhere and closures and async and like just incredibly complicated to work with. And so it's taken several several generations of integration both within the ecosystem and and within the language itself to get to a state where you can do that. And then once you have like you know a fundamental data model that plays nicely with the language, you have to go and build the rest of the GUI of the gui framework. like
00:08:52
Speaker
it's it it's There's so much There's so much bulk and so much complexity there to actually get something that's pleasant and usable and you know bug-free. And it's like, okay, yeah, if you're if you're off by a pixel in your physics engine, nobody cares. But if you're off by a pixel anywhere in in your UI layouting system, it exist like yeah ah drives people crazy.
00:09:12
Speaker
Yeah. I used to work with a graphic designer who was absolutely, he would freak out by one pixel. Yeah. And you're like, okay, ah so we, in order to fix that one pixel, we need to, we need to spend, you know, three weeks auditing our UI rounding code. Like it's kind of the state of FVZ UI right now. um So this raises the question that if you, if you spent a lot of your design time figuring out the right space for a Rust graphics-y framework, where have you ended up?
00:09:43
Speaker
Yeah. So, and do you mean in terms of rust, gooey sort of space? Yeah. So like, I mean, I think most people have a sense of what the what the fundamental model of something like React is. Yeah.
00:09:56
Speaker
And Bevy is a completely different model to that. Yeah. So so Bevy's GUI framework, it's still still like somewhat under development. But it's it's really quite interesting. So ultimately, so Bevy bevy is a game engine. and And in particular, it's an ECS-backed game engine. So the way that the ECS works is it's it's kind of like an in-memory database, you know very roughly, where you have entities acting as rows and the different components that they have serving as the columns. OK? OK.
00:10:25
Speaker
And so all of the data ends up being stored like this, which which works very conveniently for for things that are you know flat. um But it gets a lot more complicated when it comes to modeling tree-like data structures. but Because if you're trying to model your tree-like data structure within within a tabular data structure, you start to end up with these complex interrelations. But on the other hand, you can iterate through a table very quickly.
00:10:49
Speaker
And so you can do so you can do bulk ah bulk updating processes like super smoothly. And so forth for like the UI layout and so on, and like and like the, okay, I changed the color of everything that's hovered, whatever the sort of operations, that's that that's quite natural and quite quite nice and in Bevy.
00:11:06
Speaker
um It turns out that the ECS ends up really struggling when you have these weird one-off interactions. Things like, okay, I click this button, what does it do? and and that's and that's where where bey starts to move into sort of into it So the classical ECS frameworks, so things a thing things like entity, or or like or like it dots, or like Unity, or Overwatch's original ECS, um these things are very much structured in terms of you have components, you have systems. The systems operate over ah and lu loop of all of the all of the entities with imagined components and do an operation in a hyper-embarrassingly parallel way.
00:11:51
Speaker
um Bevy has found, as has Flex, our C++ sibling and research companion, that this is not sufficient. There are real things that you want to do within while making a game or while making a GUI framework or while making a piece of CAD software that doesn't map nicely towards this paradigm. And so you end up adding all sorts of ah interesting tools. You end up adding um you end up leaning for learning from the from the database the database literature and you would start adding relations where you where you have these mappings from one entity's components to another entity by you can start with by just storing the entity key within a component and then and then mapping that. And then you're like, okay, how do we make this more robust? How do we make this more but pleasant to work with?
00:12:37
Speaker
or you start destroying callback sort of behaviors on the components where you say, okay, when when when this happens, do you do this thing. And then you start adding events so then you don't have to loop through loop through all all of these different things. And so you end up with this second but Another couple of layers of layers of behavior on top of this traditional database model in order to get the benefits of both a kind of polling-based and a kind of push-based approach, depending on what the needs performance needs and the ergonomic needs of your program are. I sort of need to make sure I've got this right. so So an ECS system, I think of it as one big table. Yep. And each row is a different thing that I might see on the screen. Yep.
00:13:23
Speaker
And then there's like a column that says, is button, where some of them are true. So you'll have an is button or you'll have like a, here's a border color thing, or here's what the size is, or here's where it's positioned on the screen or so on. And so you'll be asking,
00:13:41
Speaker
um And so you'll be writing queries over this, which will then say, and it work just like SQL, you'll say, find me this thing with this other thing, but not this thing, and one of these two things. And then and then you search through that. And then your systems operate basically in a row-wise way over each of these over each of these elements. And then that's a standard system.
00:14:07
Speaker
And are we saying like that a UI maybe has a few thousand tops elements, so you can just kind of full table scan? Yeah, exactly. and and so And so for a lot of things, you can do it get away with this table scan. um But in terms of ergonomics and and and so on, you you often want to break out of that table scan to add table scan methodology and you want to have Also we have in bevy we have a fancy new thing called observers which which will go and listen for events targeted at specific entities and then and we' we'll have bubble and we we're we're about to add event bubbling where it'll it'll propagate up a hierarchy which which is defined via components linking these entities together. um Okay. So each row has a unique ID, and there's a column yeah component that says parent ID is. The parent will will will store that unique ID, and it'll at all basically act like a linked list. Well, actually, like like like like like one of like a traditional C-based tree, where you you just store pointers to other things, except and instead set of pointers, it's entities. So then you don't get UB, you just you just panic ah when your pointers are messed up.
00:15:17
Speaker
Right, yeah. Okay, so I kind of get that. So I'm thinking of one big table for the entire UI, but it's also reactive because you're adding event handlers into that table. Yeah, exactly. And and so in terms of figuring out how to do reactivity and how to do incrementalization, that's ah that's but one of our big and current pushes.
00:15:38
Speaker
and so And Cote, and Cote's been learning a lot from Dreamer Talent's work, who's who's been who's been a prolific contributor, loves writing essays, um and they've been doing a fantastic job exploring the exploring the existing GUI space and saying, okay, here are the patterns, here are the key requirements, how do we map the module lesson, doing a ton of experimentation.
00:15:59
Speaker
um but but So the reactivity has has kind of two components to it. like why do Why does Bevy UI care about reactivity? And there's There's two reasons for it. So one of them is performance, which which is so then you're not you know constantly doing table scans, constantly re-computing everything, kind kind of acting in a quasi-immediate mode where you're constantly re-computing things.
00:16:22
Speaker
um yeah the Largely reason is so then you can have complexity management because right now like it's based by the UI is just you know this big ball of beautiful state that anybody can reach in and touch wherever they want and however they want and you know we have we have lots of tools to manage this sort of complexity within games but it's just like Oh, boy, there is a lot of there's a lot of ways to screw this up and to really tangle yourself up, especially like if you're like you know're trying to make widgets for people and then you have certain assumptions and then they go and try and modify it and make it interact with other widgets. And like it can end up very chaotic. And so having a single place to say, OK, here's what the initial state is and here's how is it how it is updated and computed is really nice. um and And so trying to <unk>re trying to do that sort of
00:17:07
Speaker
define what the know what the widget's behavior and what the widget state will be when you actually initialize it is really, really useful. So like adding a lifecycle to custom components. Yeah, exactly. How do you do that with that kind of model? How does that play out? Yeah, so this is probably an open research question. But on the other hand, it's and it's kind of not. um So Bevy's ECS, learning from Flex, um has has this idea of hooks um and the corresponding observers. um And these these are basically tools that say,
00:17:42
Speaker
Okay, when you when you observe this lifecycle thing happening, so whether it when it's created when it's um know when it' and when it's destroyed, when it's um or like custom things like when ah when when this entity is hovered over, when it's pressed, do this thing to it. And so you can do and so you can add this sort of reactive hook-based behavior just kind of in a relatively passive way because you have you have these observers which are basically ah watching for these sort of changes and then responding to them. um
00:18:16
Speaker
and these are And these are targeted to specific entities. um and And it ends up acting very like much more in much more traditional, gooey programming sort of way, rather than the standard ECS. You know you go and you loop through your systems once a frame.
00:18:34
Speaker
um Right, so I have to ask them, what what's the big upside of approaching um graphics in this way? i mean what's What's the real selling point of ECS?
00:18:47
Speaker
So the real selling point of ECS, there's two of them. So one of them is is you get performance. um And this is the one that everybody talks about. You you have your data nicely organized. And when when you need to do those huge bulk updates where you're you' iterating over all of the all of this data ah um one entity at a time, you can trivially paralyze that. you have All your data is nice nice and localized. And you get really, really, really fast updates.
00:19:10
Speaker
which is great because, overwhelmingly, yeah the things that are actually taking your time aren't responding to a button click because you know you're getting one of those every five frames. It's dealing with transform propagation. It's dealing with frustum from culling that you're doing for ten tens of thousands or millions of entities every single frame on a very tight clock. The other benefit um is that is that you end up with a really unified approach to to understanding your data model, rather than saying, okay, we have we have all of this state kind of buried in these in these objects nested and nested all over the place. You have an interested database, and you can ask for whatever data you want from anywhere within your code, and you can say, okay, please give me this data, please give me this other data, and then you smoosh them together.
00:19:58
Speaker
and And so there there's this it enables these really powerful dependency injection patterns and the and these really powerful ways to write these abstractions. So like observers, you can use observers for anything. You can use ah you can define custom system parameters that that take multiple sources of data and merge them together and and interact with them. And and you you get this wonderful which like abstraction layer to to create these reusable, powerful tools that just work everywhere because your whole data model is unified.
00:20:29
Speaker
Right, yeah. Yeah, can you also like, I mean, presumably if the entire state of the system is effectively a single table. You can do introspection on it for like performance or just trying to not not actually being a part of the game or the UI, but just trying to understand what the space of the thing is. Yeah, exactly. And and and so there's kind there's kind of two two angles. Well, there's at least two angles to this. um So one of them is is you can get super easy automated like performance analysis. and we We integrate with tracing. And so you can just say, OK,
00:21:00
Speaker
ah you You can take a stock Bevy game that you haven't done done any annotations to and you say it can say, okay, please give me the spans that show me the performance of each of the systems and which threads they're running on automatically. And like we'll have automatic parallelization of the different workloads because we can tell what data is accessed by where and we can just spin it off. And it and and so all of the work that you're doing is just automatically parallelized in Bevy.
00:21:22
Speaker
um And we can just go and we can tweak this and tune this without well being completely invisible to the user code. And we can say, okay, now we're going to try a different parallelization algorithm and which one works better. um oh yeah um And so the unified data model like brings a ton of benefits like this. But the other thing that it does is it allows us to do things like reflection. um yeah into which is a way to investigate at one time the the type information of the types. And so we can do things like automatically generate you generate you debugging UIs that'll go and investigate, go and display the component values of
00:21:56
Speaker
of everything or you can go and you can open up a little ah little widget on the side. and You can say, I want to tweak this value. I want to move this guy's transform. And then, OK, I've added a new property that's an enum that tells me what type of enemy he is. So you can tweak that and you can have it live in real time in your game. Just go and do this with with like a single macro annotation. And it's and it's really, really powerful.
00:22:17
Speaker
Yeah, I can see that. Because it's basically saying select star from where entity ID equals blah. And then you get the whole thing. And and you get the whole thing. And then and then you and then we have the ability it to to understand at one time what the type information is. And then we would see what the possible valid values are. And then and then tweak them and refine them. And then we can also do like automatic serialization and deserialization, rather than having to go and manually rate this for each of our types. And so like the the unified data model makes adding complex features and leveraging complex features so much easier. And it's a also a way to keep the you know overwhelming cognitive complexity of you know a whole goddamn game engine intact. Yeah, yeah, yeah. It's it's kind of reminded me a little bit of um the Elm architecture in which there is one central core data type off which everything runs. Right. Okay. That makes sense.
00:23:07
Speaker
Yeah, yeah. but And the idea of um one of the great features of that is you can snapshot the entire state of the system just by looking at one day structure. Yeah, exactly. table yeah And and like there was ah that there's there was people doing rewind playback of Bevy gaps and and like we have like a system stepping feature. And like like there's there There's a ton of potential for these really, really powerful like introspection and debugging and meta-modification tools because ah because we've been so diligent in saying, no, no, no, this is the standard way to do it. and like In some ways, it doesn't matter at what the standard standard tool is. like We happen to choose an ECS because it has has good performance characteristics for what Bevy needs, and it also plays play nice with Glass Borrow Tracker.
00:23:53
Speaker
Simply having a standard unified data structure that's the that that's very flexible and very powerful has huge implications for app architecture. yeah Yeah, I can see. so Give me some clues about how I would use this architecture. because it's um I can see parts of it that are familiar. like It feels a bit like Helm. It feels a bit like a relational database table. Can you give me some hints on how I might translate something I might write and react into Bevy?
00:24:22
Speaker
So I'm not a React dev, so maybe help ill I'll pick something but is something from game dev. from game dev okay okay okay So suppose you have... um What do we want to do? Let's like ah let let's do enemies enemies attacking each other. okay so So suppose you have... um ah Suppose you're making a combat-based game. say just but Let's say you're making a... um you know an auto battler okay and yeah're you're having these enemies these objects attack each other so first you might want to say okay we'll we'll have a creature component and this all this does is says ah here these objects are creatures it's it's a data list microstruct okay.
00:25:06
Speaker
But it's it's it's a marker component. And ah you slap this on, and then you say, OK, we can say what side they are. So we might have ah a side enum that's either yeah friendly or hostile. And then you go through, and you write your systems, and you say, OK, check to see what what what side all of the units within range are. And then you you'll have you'll need a position component. And you'll say, OK, here's this component with ah with ah with like an XY position for for them that you'll go and look over. In my head, every time you say that say component, I'm adding a column to the table. Yeah, so you're adding a column to the table and and so and then you might add you know life and how much damage they do and and so on.
00:25:51
Speaker
but then u but But then you might decide that, okay, well we want to have really complex effects, and we want to break out of this table-based paradigm, and we want to start adding adding events. And we we want to start handling this um yeah using using observers, where you say, okay, we're going to send that we're going to send an event to deal damage, but and we'll we're going to target at this entity. And then we're going to have an observer that listens to ah that that listens to events targeting entities, um and it says, OK, here's how you handle it. And then it takes like that event, and it transforms it into another event, which might be you know checking if it's a critical hit, or they might be checking to see how IMO affects it, or it might be you know duplicating the projectiles, or so on. And and you'll get these and that this web of yeah that this this bubbling
00:26:38
Speaker
um the kind of forking and branching branching web of of events being handled. And then they'll just propagate propagate over and over recursively like within ju ah yeah and until it comes to rest. And then control flow will be handed back over to your systems, which will go and do their once per frame loop again.
00:26:58
Speaker
The question that raises for me is, okay, so enemy A shoots friendly B. I model that as an event, which is effectively a bullet, let's say. what How do I know that that bullet is an event and not another entity with components?
00:27:18
Speaker
so Ultimately, what you want to do is ah so in real get video games, you actually do something a little bit more subtle. So what you do is you'll say, um because yeah because the events don't have any like you know physical representation, so what you'll what you'll do is you'll as you'll send an event to say,
00:27:35
Speaker
ah at least in terms of my what I've been doing in my games, is is you'll go and you'll spawn a bullet with with with the projectile or whatever. And then yeah those entities, will will you'll have ah you'll have a million bullets on the screen and you'll be you'll be calculating calculating the positions and and collisions really efficiently. And then once it hits, ah you'll say, okay,
00:27:53
Speaker
It's time for a time for highly complex logic. And then you say, we're going to go and we're going to go and create an event to say, how is this going to be handled? Just like you might create an event when a button is clicked. And then and then you can have that propagate and bubble and react. And then at the end of that, yeah one of the events that you that you spit out of from that to stream is destroy the entity that created me because it's been handled and then or spawned a death animation for it or whatever.
00:28:22
Speaker
Okay, so would I be right in thinking that the entities here are basically nouns and events of the verbs? Yeah, that that that that's a good way to good way to describe it. And then you can also have these yeah these scheduled batch tasks, which which are systems to to update your nouns in and a and a bulk um in an efficient bulk way. Yeah, yeah because have i've got if I've got a thousand things with XY position that all are moving in a certain direction,
00:28:52
Speaker
yeah I need to cycle over those thousand things and update their new position depending on their speed, which is trivially parallelizable, as you said. Yes, trivially parallelizable, but but also involves less overhead as you as you're jumping through, because you can say, ok okay, I want to fetch everything in this column, and then it's all you know within a nice little cache line, and then you can go and we go and update that rather than jumping in and out and in and out like you do with the like you do with observers.
00:29:17
Speaker
Right, yes. OK, so that that gives me two questions. And the first one I'm going to jump on is cache lines. I'm imagining like i'm imagining a table that has lots and lots of rows because of all the entities. yep And lots of columns for the things they may ah properties they may or may not have, right? yeah Has laser rifle. Well, most things don't have a laser rifle. So is it like a huge 2D array in memory? Or is it sparse?
00:29:45
Speaker
ah So it ends up working such that um entities that are in the that that share the same components um have end up getting placed together into a single table. So it ends up being ah ah being a set ah like multiple distinct tables where entities that have the exact same set of components end up being clustered together into into a table. um there's There's also a Sposet component, so then you would have a distinction between an archetype and a table, but that's kind of getting into the weeds.
00:30:18
Speaker
is there um is it predictable which um which tables will be made. I mean, you say when when entities all have the same components, but that presumably you can't predict that at writing bevy time. Yeah, exactly. And and so so bevy, at at least bevy bevy as it stands, doesn't have predefined database schemas and like distinct hard tables. it's all it's It's all done dynamically ad hoc. And you'll basically end up right
00:30:50
Speaker
that There's this thing called an archetype graph which which shows ah which records how to efficiently move and move entities from one archetype table to to another um under the hood and so.
00:31:04
Speaker
And generally speaking, these archetype moves, where where you're moving from one table to another, ah and are very expensive, at least like you know on on relative scales. And so you ought to be but yeah you want to avoid constantly changing archetypes at one time um as part of your like ordinary operations, unless you know your N is you know smaller than 10,000. Right.
00:31:29
Speaker
This is one of the things that often gets lost in terms of discussion. It's, okay, yeah, sure, this is slow, and this might be five times, 100 times slower, but if your N is smaller than 100,000, smaller than 10,000, smaller than 100, you don't care at all.
00:31:48
Speaker
And so you end up getting like yeah the these intermediate intermediate-level programmers who are really, really incredibly bright and like so excited about the the the, oh, I'm understanding performance. I understand performance now. like And they've done so they've even run some of their own benchmarks and they said, oh, yeah, this operation is very slow and and so on. But they're not actually profiling real applications.
00:32:09
Speaker
Because yeah yeah yeah because it'ss it's it's like what and when you're making video games, you have 16 milliseconds frame budget. And as long as you're within that 16 millisecond frame budget, like it doesn't matter. It doesn't matter that your app can run at 4,000 frames per second. like this is This is completely useless. um ah But if you're starting to run into those into those frame time budgets,
00:32:35
Speaker
It's not, okay, I'm going to go over my code base and and you know do it do a blind pass. it's it's You go and you open up those built-in profiling tools and you say, okay, what what is slow? And then you optimize there. um Yeah. You've got to look where time's being spent before you start optimizing the algorithms. Exactly. yeah and that's and that's that That's a painful lesson that that I think every junior programmer needs to learn. so We try to preach this religiously and in the Discord. hu I'm sure I've learned that that's the hard way in the past. Yeah, you're like, oh, it was really clever optimization and then you try it and you're like, I didn't save us any time. God damn it.
00:33:14
Speaker
Yeah, it's like order n squared is terrible performance unless n is 5. Yeah, exactly. And and so you end up with you end up with a lot of cases like that. um So what do you do in the game engine? then do you like when i add it I add a new surprising entity at runtime yeah that has this particular set of components that makes you wish you'd split it off to another archetype, as you say.
00:33:39
Speaker
Yeah. do Are you dynamically monitoring that runtime and yeah so estimating the cost of moving? ah so so so these ended up and So right now, the way that it works is that they if they have a different set of, um if they're in a new table because of because of the because their table component set is is distinct, they always get assigned to a new table. And we currently don't do any cleanup or or any like ah mixed hybrid tables or any shenanigans because We end up... ah like Bevy ends up packing its data extremely efficiently with like with with unsafe pointers and and absolutely no space between it. So there's so there's really no space for, okay, weird word we're we're going to ah you know allow this ah this thing to come in, yeah even though it doesn't quite fit. So so it's really quite naive. You say, okay, does this match any of the existing tables? No, make a new table for it.
00:34:33
Speaker
OK, and then when I run the query, you're transparently joining several different tables. Yeah, exactly. You end up joining it by saying, OK, which of these tables match the query? And then and then you'll you'll have an iterator over iterators, where you'll be iterating over each of the each of the tables and and then within there. And so as a result, ah we don't make strong guarantees about the iteration order of your entities, because it's it it really depends on the like fairly internal details of which tables they end up getting stored in.
00:35:02
Speaker
Right, yeah. but But that's the old relational database guarantee that it's an unsorted set. Yeah, exactly. Yeah. OK, so that relates to my other question then, which was um you're talking about like bullets detecting whether they've hit the enemy or mice tote mye pointers mouse pointers detecting whether or not they've clicked a particular space. How does this query iterate over a BigQuery thing work when you're trying to say, are there any x's that overlap with y's?
00:35:31
Speaker
Yeah. And so there's a couple of different approaches here. So the most naive one is you just do a table scan. You say, OK, yeah here's my mouse button. Here's all the access line bounding boxes. go Go and check this. And it turns out table scans could be can be pretty robust. They can be pretty fast. like You can have tens of thousands or hundred even like low hundreds of thousands ah of entities. and a table scan is still fast and it's simple and you're not going to screw it up. like like then there There's no no room for programmer error. in like you know just just Just compare the the pointer to the AABB.
00:36:03
Speaker
um and But as you start as you start getting into more more performance-demanding ah and applications where you're trying to you know write write a full physics engine for for for a physics-heavy game, you end up wanting to say, okay let's store a spatial partitioning data structure there' some somewhere in here. so you say yeah ah we have We have a quad tree, we have an ox tree, or we have a bounding volume hierarchy, or whatever, and you store that you stick that into a resource, which is basically ah a a global singleton and and within Bevy VCS. And you say, okay, whenever whenever things are changed, or that that respond ah the the but whenever like you know the position or whatever whatever other indexed characteristic has changed, you have to go and you have to re-update your index. and so yeah so You end up building building these indexes and then working in know know using using these queries and in combination with with these with these computed indexes in order to go and efficiently query this. and and This applies to
00:37:05
Speaker
you know This applies to to more than your spatial ah spatial querying. it like This applies to, you know you can do you can do this for a name lookups. You can do anything that you might possibly want to use a database index for using this pattern. um And did that this was one of the things that ah that like willie that I really got... One of the very first things that I really got interested in in Bevy was trying to understand how do we make it so then the source of truth problem for this is is less bad because and because it's really easy to say, oh no, I'm querying on on a stale index and I didn't know it. Oops. And and like ah yeah you have all of these systems running and and mutating state and then so on. and so And so it becomes, and you're not you don't want to do a full reconciliation step too often because it yeah because it's expensive, but you want to make sure that
00:37:52
Speaker
and that that it's always done before that you before you're using it. and so That sort of scheduling ah dynamicism it is is one of the hodo-poets with maintaining these indices. I can totally see that. Are you telling me there's a separate scheduler in Bevy?
00:38:09
Speaker
Well, so, yeah, so so that's so that's how Bevi systems run. So Bevi systems i run via scheduler that says, OK, do this job, then do this job, then do this job, except it's all being done in parallel, according to a greedy algorithm.
00:38:24
Speaker
where they say, OK, well, ah there the component the commo data that you need access to is free. So go go ah go ahead and start. or Or this other system is right into this component that you need to read. So you you go to the back of the queue, and then we'll try try you again later. And so it's constantly trying and retrying. And then you have ah you have this web of of scheduling constraints to make sure that the invariants that you actually care about aren't violated.
00:38:49
Speaker
um Right. So hang on. I need to make sure I've got, so I think we've got what an entity and a component is. And the system is the thing that's running over this table and doing stuff. Yeah, exactly. but You can kind of think of it like a, like a job in terms of, in terms of relational database terms. Yeah. Okay.
00:39:10
Speaker
Because this is such an unfamiliar model to me as an industrial programmer. Yeah, exactly. well and And you're like, OK, we we have ah we have these these jobs that just kind of like run automatically in in parallel in whatever order they they feel like. and And it's fascinating, because you know for any arbitrary pair of systems, it doesn't like it's literally unobservable what difference like ah which which order they would they run in, because they're touching completely disjoint sets of data.
00:39:37
Speaker
um
00:39:39
Speaker
Yeah. Yeah. That makes sense. But are you, how does that play out with them? Like if you've got, we talked about having different tables that end up being joined together to present the same virtual column.
00:39:53
Speaker
Do you have one system that gets access to one underlying table and then blocks while it waits for the next underlying table? Yeah, exactly. And so we'll have a at-run time bitmask saying, okay, here are the tables that are in use. And then once the system completes, it goes and subtracts one from the bitmask and says, okay, here's what we and now these resources are free and then the scheduler goes and says, okay, but but let but let let's compare this new system's access against that bit mask and then it'll say, okay, yep, it's good and then it adds it or nope, it's not and then and and then it and then and drops back down and then the system gets put back put back in the queue.
00:40:33
Speaker
Why is it that this starting to sound less like a UI framework and more like somewhere between a database and an operating system? Yeah, exactly. like It's absolutely fascinating. like There's there's somebody so many cool rabbit holes of just like of just like in order like inorate complexity. But like it bevy Bevy really kind of brings together all of these really disparate paradigms and disparate um ways of doing things in different fields in in a way that's like completely unique. it's it' it's I wake up and I'm like, well, I guess I'm going to i guess i'm going to go and analyze this scene to to see if its shadows look nice. And then and then I'll be you know working on the parallel parallel schedule then scheduler the next day. And then and then the day after that, I'll be like, OK, how do I design like a nice style system for for UI? and then And then I'll be like, OK, how do we write gameplay code? And then like all of it just kind of like
00:41:31
Speaker
wing back and forth and back and forth. And it's it's so fascinating. How on earth do you stay focused on any one thing? um I don't. That's the trick. You're highly parallelized yourself. yeah it's to do To do my particular job, I need to be highly parallelized. Cote tends to work much more effectively in in series. um he He's very much a focused engineer who who says, I'm going to tackle the hardest problem that we have, and I'm going to sit down for three weeks and and solve it. And I don't get that luxury. um I was hired to to to to make sure that Cote can do that. and so
00:42:05
Speaker
My day-to-day job is all about is all about review and unblocking things and providing ah providing direction and ensuring ensuring things are moving and ensuring people are talking to each other and creating a culture that's conducive to to high quality work. um And as a result, i'll i I'll say, okay, I'm going to have you know one or two one or two like active projects that are that I'm like really like focused on and I'm actually waiting code for. And then the rest of it, it's just yeah it's just code review and it's struggling things and it's keeping track of discussions and and and connecting the dots for people.
00:42:45
Speaker
Right. So is it is it mostly in-house people that you're directing discussions, or is it open source contributors? so Yeah. So in-house means me and Cote. We have two employees. Oh, OK. Although I think Cote's not technically an employee yet. We have to start some paperwork. But fundamentally, Bevy has two ah paid full-time of full-time employees, Cote and myself, and the rest of it, which is a team of ah somewhere between dozens and hundreds ah hundreds of contributors, depending on how you measure, are all open source volunteers. and and
00:43:20
Speaker
you know they they They'll range from anywhere from one hour a week to 30 hours a week or or whatever, um depending on like their level of passion and time and and interest. um and Somehow, I need to coordinate them all and i need to tell them and I need to make sure that they're doing good stuff and make sure that they don't fight and and to slowly nudge them towards useful goals. Do you think part of that is, I mean, there's a lot of excitement around Rust. do you think Is it the excitement around Rust that brings you that many contributors or the excitement around games? or
00:43:55
Speaker
ah So I think that there's an excitement around Rust. There's an excitement around games. but But at the same time, you don't see this phenomenon happening like among all open source game engines, or among all open source Rust projects, or even among all open source Rust game engine projects.
00:44:10
Speaker
and so there's ah So it's it's I think that there's a couple of technical elements that make it easy for people to contribute um and make it better appealing to contribute. So part of it is all of the like lovely, interesting technical country details that we've already you know i spent most of this time talking about. They're really cool. But a lot of it is having having clear frameworks for for supporting contributors, making sure that you're you're welcoming to people, making sure that you're encouraging and offering feedback and in a timely fashion. um But also, we've we encourage contributors to help contributors. when it were we We'll say, okay, contributors, PR reviews count. um where If you can convince two other people of the community who, you know as as far as we know, are just like completely randoms from across the world to approve your PR, we'll take a look and we'll probably merge it.
00:45:02
Speaker
um and And so we we end up kind of yeah kind of bootstrapping the problem by saying, okay, we have so many contributors, how do we turn this into more throughput when we have very limited time? and you you You use the you use this this problem that you have and turn it into a resource by by having it feed on itself.
00:45:23
Speaker
And so you end up with this really cool self-sustaining loop of of a community of contributors that's empowered to do things um because because they're helping each other and and they're vetting their stuff in a way that makes it reviewable and possible and like a high enough quality for us to say quickly to do a quick Passover and say, yeah, this looks great. Let's merge it.
00:45:44
Speaker
This makes me wonder something, because clearly, from what we've already talked about, you're thinking a lot about how you can optimize computer systems, processing systems. ah you excuse me Are you also spending a lot of your time thinking about how you can optimize human systems, and does it end up being a similar kind of work?
00:46:03
Speaker
Yeah, so well as so optimizing human systems is is a lot of a lot of what I do and why I specifically was Bevy's first hire, um where my mother my mother mother was a project manager and I learned a lot from her. um And my ah my background is in complex systems ecology. and so and trying to figure out how do we and so I've always been obsessed with systems, and ah like you know in the world sense, and and incentives and structures and and ways to ah to design systems so that it naturally just kind of falls into the right shape.
00:46:39
Speaker
um and so and it's just It's kind of Machiavellian, where you say, rather than rather than trying to boss someone around and tell them, hey, you must work on this. You can't do that. um This doesn't work. They're volunteers. And even if it did work, it's ah like i can't I can't micromanage um i can't back a manage two dozen direct reports, much less 300.
00:47:04
Speaker
yeah and so and so when i know When there's a problem that needs fixing within within the community or within within within the contributor base, within the code base, it's ah You have to look for the changes that you can make that structurally incentivize the behavior that you want. so One of the things that we that we found was people would be tackling these wildly ambitious projects on their own. and They'd say, okay, well, I have this really cool idea. I'm going to tackle it. and It would just be this one guy's job to like just just just be a hero and finish it. and This was really hard because it was hard to review. It was hard to get design feedback on. and then
00:47:41
Speaker
And then they they would they would burn out and then the project would languish and die. And so what I said is, okay, we're going to go and we're going to make a new process. It's going to be nice and lightweight. We're going to have working groups. And these are going to be ad hoc ad hoc things that where you say you get yourself and a couple of buddies together and you say, we want to go and tackle this broad, ambitious project. And Yeah, and and this is your due responsibility collectively. and By making it people's collective responsibility, and and by making it an open group, and by making it dissolve at the end, like all of these factors contribute to to the sort of collaborative well-reasoned, scoped behavior that we want to see. and so
00:48:21
Speaker
yeah and And so you go and you set up these processes, and then you promote them, and then you yeah you know you you you you you thank them vocally, and yeah and you promote their stuff as, this is the cool stuff, this is what this is where all the exciting stuff happens, and then people funnel into it, and then they work in the way that you want them to work without you ever having any authoritar like a without you ever having any authority over these people that you are managing.
00:48:44
Speaker
um right yeah You just give them the framework to pour themselves into. Stochastically, grains of sand. like like like Some people won't want what won't want to work with like like this, and they'll bounce out. you know Overwhelmingly, like people will follow the structures and and patterns that you lie in place, to too. theyll They'll follow the incentives. and so You set up the incentives, and then and then you sit back and you watch. And then and then you you say, OK, that didn't quite work. and then you And then you suddenly tweak one of these rules or one of these things of how you're doing stuff, and then and then you watch. And and so it's very it's very much about trying to trying to model how humans work and trying to model how how these dynamics work, and then and then setting up the structures to enable this enable this to be successful.
00:49:29
Speaker
Yeah, without without material reward. Yeah, without material reward and without and without any actual authority over anybody. And and so it's it's really fascinating to me because i'll i'll look I'll look at traditional managers and they'll be like, oh yeah, my my job is to boss people around. And I'm like, no, your job is not to boss people around. Your job is to do what I do, where where you go and you subtly set things up for success. And and being and And I think this is a better way to manage in general and a better way to to you know run teams. But when you don't have any don't have any budget to give people and you don't have any authority over anybody, you really, really have to have to learn to get good with the very lightest of touches.
00:50:10
Speaker
yeah Yeah, I can totally see that. Does it lead to the problem, though, that like you you come into the year ahead with one agenda for where you want to get to, and the community quietly, happily organises themselves to go in a completely different direction?
00:50:25
Speaker
Oh, yeah, absolutely. um and and And so this is why we have like all these fancy 3D rendering features. And like we we have like a Nanite equivalent for from Unreal, which is like absolutely incredible. um ah yeah Jasmine's been working on meshlets, which are that. um But we we have this, which is like this like absolutely incredible, ah highly advanced specialized feature. um And we don't have a basic editor.
00:50:50
Speaker
um and so and so The community will go off in their own directions. and like we We quickly gave up on having a world map because like it was just wrong. It was just a lie. and you know It's better not to lie to people. It's better to have no information about this and speak in vague. vague here's Here's what I want to do. here Here's my directions. Here's here's oh yeah heres kind of the stuff that we're working on kind of descriptively rather than trying to give normative guidelines that are just wrong.
00:51:17
Speaker
um I could see that working well if the people organizing themselves to develop tend to be the end users. yeah I see it being a lot more tricky when it's like asymmetrical. Yeah, exactly. And well and and this is part of why I think Bevy works so well is because the but The contributing experience is very, very approachable for for the end user. So like when you're writing in Godot, for example, you'll have ah the experience of writing writing a good game in Godot. It ends up using GDScript and in these node editors, and then you you end up getting into the core of the editor and it's all C++. plus plus And it's a totally different paradigm. With Bevy, and ah Bevy uses Bevy systems to make Bevy. like there There's only a couple of like
00:52:01
Speaker
There's only a couple of little bits of the core, like BevyUCS and Bevy Reflect, that are actually distinct. And even then, it's still just Rust.
00:52:09
Speaker
Right, right. So you're dogfooding it. Yeah, so's so you dogfood it. And and and this then this is why, say, the Bevy editor is made in BevyUI. Despite the fact that BevyUI, especially like when we started, was not the most competent framework. Like, we could make an editor, you know, 10, 100 times faster and eagerly. But then if we do that, then we're not dogfooding it. And then BevyUI never improves because the people contributing to the edit to to the engine aren't using it.
00:52:35
Speaker
Yeah, OK. So this raises the question, if you're not entirely sure how you can direct the flow to where you're going, is there an end destination? Are there obvious pieces that you somehow need to find to bring in to the system? Yeah, so in terms of what does Bevy need desperately and urgently? And what are the most important bits? So one of them is we need a better UI framework. In particular, we need a way to generate widgets and define widget types and avoid boilerplate. And so what will often happen with this is when we have these really tricky technical challenges and these key directions, we'll either form working groups or a cart or myself will go and take the lead on this.
00:53:25
Speaker
And so this is what Kite's been working on. Kite's been kiten working on on the UI side, both in terms of the boilerplate with with his Bevy scene notation stuff, and also in terms of the reactivity. So that's one part of it. The next part of it is we desperately need an editor. So then people can go and and author content for for Bevy. So things like they can make levels, and they can can preview how scenes look, and and all of that um in a way that is oh that is easy to manipulate, and that is artist-friendly.
00:53:54
Speaker
um But so we also have have areas of the engine that are that are remarkably weak, like um like audio, because Bevy bey just said, okay, here here's the best audio and framework. We can play a sound. Great. That's that's fine. um It turns out like game audio actually has quite demanding needs, and the existing 10-year-old 10-year-old project, which is which is lovely. Rodeo is a nice library. But it's it's very much not targeted to game audio, and it's not targeted for professional game audio. um And so it doesn't have the you know highly demanding performance characteristics and like yeah all the features and like the nice nice integration and so on that that that we expect. and so And so we have a working group of ah where where a couple of experts have kind come in, and they said, hey, I want to do this. And we said, great. yeah yeah yeah we we we We trust you to do this.
00:54:42
Speaker
Here's a space for you. but but we We have blessed this effort and we will we will review it and give you feedback at the time. um
00:54:52
Speaker
I have to ask out of curiosity then, what are the headline features of an audio system for an engine like this? That's a good question for for an audio engineer. um But from my understanding, um there's and there's kind of two different ah categories ah categories ah of demand. So one of them is Audio is real-time. Audio is not... It's not even soft real-time, like GUI or video games. Audio is high in real-time. You cannot screw up yeah so screw up your timing on the audio or it will sound horrible. And so yeah like yeah you cannot allocate. like you you you You cannot dynamically allocate when doing audio or or your timing will be screwed up. You you must minimize latency at all costs. so ah so so the One of the sides is the performance side, in fact particularly in terms of latency and in terms of in terms of reliability. um and This is a very, very hard technical problem to get right. And then simultaneously, you have all of these features for
00:55:50
Speaker
mixing for mixing audio audio sources together and for blending them and for doing things like spatial audio and for doing things like a fax and so on which which which all need to have you ah you know a nice pretty api and then also interact with this level level just play ah play a sound without screwing up a latency without.
00:56:08
Speaker
and we with nicely with that we're without without actually ah messing up the latency because you're you know mixing mixing some sound effects in. and so that's where the but Getting both half of the halves of those together is really why why it's there and why I'm really, really glad we have i think at least three like professional audio engineers just kind of slowly slowly chewing away on this project. I'm like, great, this would have taken me like five years to learn. That could be a separate podcast in itself.
00:56:35
Speaker
but why Don't you have this problem then that you you make it sound like audio is like the king of the scheduler, right? It has to get first dibs on everything. so ah so my audio would but Does that make it hard to like, isn't everything else you're doing? There's a chance that everything else you're doing is going to interfere with what they're trying to do achieve and they should win.
00:57:04
Speaker
Yep. And so ah for audio specifically, what what what what games will do is and what what web does even is it says audio gets its own thread. ah Audio has its own real thread and nobody is allowed to touch it. They're allowed to like send data in and they'll get to it in its own time, but it just has its own thread. And it even if it's only using, you know,
00:57:24
Speaker
5% of that core, five but like it just gets it because it's so latency sensitive. um So so so this this is where they like the multi the modern multi-CPU architecture really, really helps is because you can just be like, yeah, here, have a core. Oh, right, yeah, yeah. So it's a king of its own domain rather than a shared domain. Yeah, yeah. And and audio and sometimes input handling are basically the two exceptions to ah to win into that because they're so so latency sensitive.
00:57:54
Speaker
Yeah, that makes sense. Okay, so another question about the scope of this project is like, it's huge. You've got lots of people working on it. There are many disparate kinds of features. I'm just thinking how you possibly, I mean, you've got a colossal documentation problem on top of that, right? yeah you I remember game engines of old coming with big thick two inch manuals. Yep.
00:58:19
Speaker
How do you corral all these hundreds of contributors to write decent up-to-date documentation when developers generally hate writing documentation? Yeah, so so know there's there's a couple of different ways. um So, Beverly's documentation in this story is uneven. um So what we've done really well is we've managed to get really good um API docs for 90% of the engine. And this is because Rustdoc is incredible. like So Rust has its own built-in documentation tool where you just write comments ah you write special comments just above your code, and then it goes and shows up in these automatically generated HTML documentation. And it's great. And there's all sorts of conventions. And there's links to enforce this. And you can just say, oh, yeah, this is just a standard expected part of code quality.
00:59:06
Speaker
and every time that you know a function gets changed or a function gets written, it gets API documentation. And and by and large, this works great. um the ah The other thing that works great are examples, because examples end up in Rust can be automatically compiled and can be can be easily run, and so they end up acting as hybrid ah hybrid interactive tests and documentation and ways to to learn how to use this. um okay and and so so That ends up working really well. Where we end up struggling, ah to a to a fair degree, is
00:59:41
Speaker
when it comes to writing and updating high-level documentation where you say, OK, here's what this module does. Here's how you use this library. Here's the core concepts of of the ECS. And so rallying rying energy towards that and and keeping that up-to-date is is an effort. um And it's I think that we do better than average in terms of like programming languages, but definitely nowhere near as well as as as we need to. um and And I think that part of the reason we do we do better than average is because we can have um is we can embed Westcode and like automatically test it, which is which is great because then it like at least gives you some warning that this thing that you're saying is is totally wrong and you you use a literate programming sort of style.
01:00:21
Speaker
right But part of that is culture, um because I'm one of the more important people people within the Bevy ecosystem, and I love reading docs. I love reading docs. I praise people who who who make good docs. And so and so you say, yeah I kind of embody this cultural value that good documentation and listening to users and so on is important to us. It's important here. It gets rewarded. It gets praised. It gets you gets you attention and recognition and all these things that are the actual currency of the project. And so you kind of shift towards that. um I think that in the long term, we're probably going to want to ah we're probably going to want to hire people to ah did to you know write documentation and wear stuff. ah But that's a question for as our budget grows. Right. In that case, I'm going to ask, how what is the plan for your budget growing? Because you've got a large scope of things left to do.
01:01:14
Speaker
Yeah. So right now, we're ah we're we're honestly like relatively happy with with with our current level of funding. um it would be you know It would always be nice and nicer if it was higher, and we we we we could end up turning into it. But it's like, yeah are we dying for money? No. where did it's It's, I make a respectable salary. Respectable if not a salary. Kurt makes it respectable if not a salary.
01:01:35
Speaker
and ah like we are The community does a good job but we're we're stepping in and providing leadership and providing a review when needed. um and And ultimately, like I think that there's there's kind of a self-limiting effect there, where if if the community gets too big, people burn out faster. And and and if it's a if we end up having more review bandwidth, then then we have contributions, then the community that the community grows and contributes stuff to fill the space. um um but And so you know moving along sustainably and and steadily adding the features and and working carefully, to me, feel it feels like the right play for Bevy right now, ah because the alternative is, okay, we we go and you know we we sell it and we seek VC funding, and then we say, okay, how do we...
01:02:22
Speaker
like It's just endless stress and really a betrayal of of what the of why Bevy exists. Karch told the story a few times where he's been approached repeatedly for with offers of VC funding, especially like before Bevy as a nonprofit existed because they saw this with this this and this commercially viable project just absolutely catch fire with like thousands and tens of thousands of users basically overnight and tons of enthusiasm. They're like, hey, you want you want a couple million dollars of a funding?
01:02:50
Speaker
And he's like, oh I'm happy. I'm good. yeah And so kind of ah kind of in terms of like longer term, I think that I'm very happy to have a model where we're successful if our users are successful, where we say, OK, let's go.
01:03:08
Speaker
and make something great and make something that people can make money with and then and then talk to them and build relationships with them and say, hey, ah we're doing great work. Do you want to fund us? Do why do you want to support us to expand this area that that you're interested in or to you know keep the lights on or whatever? um and And the commercial users are obviously the most important there because you know they can donate thousands of dollars a month rather than you know tens of dollars a month.
01:03:31
Speaker
But yeah the hobbyist users are important, too. like we we We have a non-trivial portion ah avo of our funds come from hobbyist users. And like that's a really important vote of confidence to me, as well, to say, hey, this this is something that you care about, with that you love, that you're passionate about, that you're excited enough about. you know give give away give Give us $5 a month. Give us $10 a month. Give us $50 a month. like it's It's a wonderful feeling. yeah Yeah, I know that one well.
01:03:58
Speaker
so then What is the biggest missing resource for Bevy? Is it time? and So the biggest missing resource for Bevy is decision making. Oh, OK. Yeah. So seemed you and Kurt were like benevolent dictators. Well, yeah no, actually. But yeah, well, a quasi benevolent, a quasi dictatorial. But ultimately like making good decisions requires time and requires energy and requires a Very specific sort of it's emotionally taxing in a very specific sort of way where you because you're constantly like navigating conflict and like taking on responsibility and like and like listening to people and so it's emotionally exhausting and so the the the throughput of critical contentious decision-making decisions as you know, we're limited to
01:04:53
Speaker
you know optimistically, five were five contentious decisions per day each per per person. if I thought you were going to say per year, per day, that's pretty hard. But like but like in terms of like in terms of like truly controversial, like like if we have like a big argument argument over like, okay, should we do this? Should should should should we do this other thing? like We get like one a week.
01:05:14
Speaker
and so yeah And so, and but in terms of like, okay, should we merge this type of experience? Like this doesn't require any emotional energy. this This barely requires any judgment. Like anybody in the community can say, oh yeah, that that that type of fix would make sense. This is did this bug fix makes sense. This like refactor makes sense. This like uncontroversial feature makes sense. And so,
01:05:35
Speaker
As a result, the actually progressing requires requires people who are trusted to make decisions making those decisions. And for us to say, you know what, I trust you yeah i trust that that you've made it you've made the right call here, and for them to have built that consensus in order to move forward successfully. Right, yeah. And that is a slow process to grow that kind of trusted community. Exactly. And Bevy's done a really good job over the years. And like we have we have a whole like framework of SMEs. And like generally speaking, Bevy has very much a respect-based hierarchy, where you know even when even though there's not formal rules for a lot of these people, like yeah you'll you'll walk and you'll walk into a room, of a virtual room on Discord, and you'll say, yeah you can tell. Oh, yeah, this ah this person is respected. This person has as the area of the community. they They make reasonable points. They're kind. They're they're patient. They're technically skilled. the you know
01:06:28
Speaker
And this kind of emerges. The people who are respected end up being able to get their agenda through because they're able to build consensus. And if they're able to build consensus, then the decisions are no longer controversial. And then it's easy for a cartoonist to come in and say, you know what? That is a good call.
01:06:48
Speaker
let but let's Let's move forward with it. and so This is why the editor and the UI take so much longer. is because It's not because it's technically harder, even though it is like you know a very challenging technical technical project. It's because there's so much disagreement, there's so much contention, because every and everybody is we like really emotionally invested in it because they they know it's important, and because there's so many different ways that could work.
01:07:07
Speaker
whereas yeah and and so Bevy's limiting resource in terms of like actually making progress on our core goals is is very much decision making and very much is is fighting through that controversy. Yeah, yeah I can see that'd be the hardest. I don't quite want to use the word bike shedding, but as soon as you get to something like how user interfaces should work,
01:07:29
Speaker
A lot of people have opinions, and many of them are right just in different ways. Yeah, exactly. And and you'll end up with people who are like, oh, yeah, were like we it's we can't move we can't mo borrow from CSS. like it's a It's an and antiquated bit like piece of trash. And I'm like, yeah, I mostly agree with that. um And like it it's barely designed. But ah simultaneously, you'll be like, oh, we we've got to use CSS. everybody Everybody knows how to do it. We should just follow the standard. like Why are we reinventing this? and it's like I agree with both of these. And neither side is clearly correct. And so they'll argue about it that forever. And so eventually, the you code eye or I will need to step in and say, OK, no, we' we we've heard your arguments. We understand it. here's Here's the summary of each of your positions. And but we've decided to go with this for this reason. And we'll it'll be a big deal. And then you know yeah you you do this 500 times, and you have a UI framework. And you do this 5,000 times, and you have a whole editor. And it's like.
01:08:24
Speaker
Yeah, ah but if you're if you are still left standing at the end of the process. Yeah, exactly. and And even beyond our capacity, like you need to be but you need to kind of pace pace out these but these decisions ah and and move move relatively slowly for the sake of community trust and for the sake of ever but of the contributors' ah contribut to patience and frustration and and like but and and happiness. Because if you if you're constantly on the losing side of these battles or or even if youre if you're just exposed to the conflicts, it's exhausting. it It causes you to burn out, it causes you to say, hey, I'd rather do do other things that are fun with my time. But on the other hand, you can't move too slowly because then they're like, man, we've been talking about this in circles for months. like Why don't we just make a decision? And so like so like yeah you have to kind of like slowly trickle out these
01:09:13
Speaker
these controversial decisions and then go back and forth. and so yeah yeah It's really fascinating because it's it's in terms of like what is the hardest part of your job, Alice? and it's like it's It's the human factors. It's trying to trying to get these things and get these things right and to be a good leader and to be a good person and to to listen to people and make the right decisions without without burning anybody out.
01:09:38
Speaker
Yeah. Yeah. Okay. It sounds like, I mean, there's a problem with no easy answers, but it sounds like you're on top of it and aware of the problem, which puts you ahead of a few Silicon Valley CEOs, I can think. Yeah, absolutely. Well, and it's nice because like, I feel like I'm able to talk openly about these meta-problems. How am I manipulating people? How am I coordinating people? How am I thinking about how to resolve these people problems? And that reduces the stress tremendously. Because if you're feeling like, oh yeah, this is a secret. They can't know that I'm trying to resolve their conflicts. It's just exhausting. It makes you feel like such a terrible person. It makes you feel so alone and isolated. But if you can say,
01:10:24
Speaker
Okay, here's what we're doing and you you can you can instead go and spread your values within it within the community and then other people will will come and show up and they'll they'll try and do the same thing for you even if they don't have official power. Because that's how I got started. I showed up and I started it trying to build consensus and I try to started trying to align people on valuable work and trying to do all these things despite the fact that I was just a random contributor.
01:10:47
Speaker
Yeah, yeah, yeah. Well, I hope you stay un-VC funded, because I could see that changing if you took that $2 million dollars with apparently no strings attached. Yeah, well, exactly. And it's... it's I really like that Bevy is bevy is a non-profit, Bevy is a community-run project, and I really like that Bevy's open source is truly open, where the community is a huge and critical part of not only like the implementation process, but also of the decision-making process, where we we we care about and we care about their voices, we care about their feelings, and we want to include them in every single step of the design, um rather than saying, here's a design from on high, you deal with it. Yeah, yeah. Despite the cost of that.
01:11:32
Speaker
Yeah, exactly. But i I think it makes a better product, especially because, you know, our ah bevy bevy developers, our bevy engine engineered developers, like it's it's having having a really strong connection with the people who are actually using your product is really, really important to making the right decision. that there Yeah, yeah, yeah, I can totally say that. Okay, so, but that's Let's move on from there, because that's all about how you're going to get to where you're going. But tell me, to begin to wrap up, what's Bevy good at right now? What's the current set of play?
01:12:07
Speaker
ah So, ah Bevy right now is great as a hyper-flexible platform for building game-like things. um Not necessarily for building games, but for building things that have a lot of the same requirements as games. So, things like cat applications, things like scientific simulation software, where you want GUI, you might want a little bit of sound, you you want ah ah you want high performance simulation of of large quantities of objects you want rendering, you want you want picking. it's It's great for that. And honestly, if you if you're building like a factory simulator or something where where you need to hide where we need high performance and lots lots lots of objects and you don't have like complex hand-authored levels, Bevy is great for that. um Right.
01:12:51
Speaker
bey is Or or but Bevy is pretty good if you're building a game that's largely procedural. If you're like, OK, I'm going to build something you know like Tiny Glade, the standout success Bevy game that's basically just a it's just a sandbox toy. And it says, OK, we're going to build something something beautiful. And it's and it's flexible. and And you don't need a lot of like ah hand-authored content. um I knew that was written in Rust. I didn't know it was Bevy. Yeah, so it's Bevy with a custom window here, which is you know a great example. so
01:13:22
Speaker
Do you talk to people who are aren't in the game industry and and they'll be like, oh, it uses a custom renderer. And they'll be like, oh, that's the such a diminishment on Bevy. like a but Bevy can can't make anything that beautiful. um But if you talk to people in the game industry and they're like, holy shit, you could just replace the renderer just like seamlessly? but That's not how this works. um ah Yeah.
01:13:44
Speaker
but so So if you're doing something weird like that, Bevy's a pretty decent choice today. ah But if you're like, I want to build and Call of Duty where you have... So the things that Bevy really struggles with are high-fidelity graphics, their complex, high-polish UI, and their hand-authored content.
01:14:05
Speaker
um So where you say, okay, I want to build this level that looks exactly like this, yeah you're going to have to build your own tooling to make sure that but that works. and And that might just be you know integrating with LDTK or integrating with Blender or so on, but you have to build that whole pipeline yourself and you need to have that in place before your artist can really start to work effectively. And so and so for you know a small team for for solo devs who are who who are mostly programming with a splash of art or for the teams where you're like,
01:14:35
Speaker
you know two or three two or three programmers with with with it with with with with with one or two artists, like that that works fine. um Especially if you're building a semi-procedural game. But if you're like, I want to build Call of Duty, I want to build the next Mario game, like it's what what are you doing? like you go go Go use Godot. Right. And how long do you think it will be before Bevy's a serious contender in the general game space?
01:15:02
Speaker
Yeah, so I think that Bevy is going to end up so bevy iss going to end up targeting, it's I expect, the you know technical technically-oriented indie space um relatively soon. We're starting to to're trying to see a few of those. we have I think probably about a half dozen like commercial commercial game projects that that that I think have have a shot at like making real money um and like sustaining sustaining people's livelihood. um But I think that we're a couple of years out from and from being able to say, okay, yeah hey random indie studio, you should you should genuinely give Viv your try. And then we're like five, 10 years out from saying, hey, trip AAA studio, we're ready.
01:15:45
Speaker
Right. Because the AAA studios, like the thing that they want is they want they want reliability, they want stability, and they want really, really good asset processing pipelines and and ways to do ways to coordinate large teams to generate huge amounts of assets and import them into the engine and and have them test them out and integrate them all. um And that yeah that sort of workflow is very different and very complicated.
01:16:08
Speaker
Yeah, you you end up needing things really change when you have like an art department of 100 people and a QA department of 30 people. Yeah, exactly. Rather than you have, you know, the one guy and the the he he he sometimes goes and imports his sprites. Yeah.
01:16:23
Speaker
Well, in that case, given how much how much of a roadmap you have to get to, I should probably let you go and ah start building the next 10 years. Yeah, thank you so much. Thank you so much. Yeah, that was that was very interesting and went in a lot of places I didn't expect.
01:16:39
Speaker
I'm now going to go and think of my my apps in terms of huge tables and see what that gets me mentally. Absolutely. Alice, thanks very much. Awesome. Take care. Thank you, Alice. you know In researching and recording this episode, I've basically fallen down the bevy rabbit hole, yet another rabbit hole in my life. That's the biggest danger of doing this podcast. I end up with so many open repos.
01:17:01
Speaker
But I've been trying to get ECS under my fingers from the idea to the keyboard, you know? Because the only way you really understand something is to try it out. And it's interesting. I can't say I've quite got it yet, but it's definitely very good brain food. So if you want the same brain food, head to the show notes. You'll find links to Bevy, the tutorials, the examples, and the C++ plus plus equivalent that Alice mentioned if C++ plus plus is your jam.
01:17:30
Speaker
While you're there, if you've enjoyed this episode, please take a moment to like it, rate it, maybe share it with a friend. If you want to catch next week's episode, make sure you're subscribed because we'll be back soon. And if you want to support future episodes, please take a look at us on Patreon. But until then, I've been your host, Chris Jenkins. This has been Developer Voices with Alice Cecile. Thanks for listening.