Questions and Congratulations 🎉

[zicklag]

Forgive my early accidental post, I need to finish writing this post. Coming soon! 😉

[zicklag]

First off, wow! 😍 I'm very impressed. You've combined tons of essentials in a cohesive manner with an inspiringly easy-to-use ECS. Congratulations on a great job!

To get right to the point, this is looking extremely promising as a foundation for Katharos Technology's Arsenal game engine. I'm the Chief Technology Lead at KatharosTech and we have been trying to find/develop the foundational tools/libraries necessary to establish Arsenal for about a year now. We initially started building on Amethyst but somewhat recently decided that Amethyst didn't share enough of our vision for Arsenal and that we wanted to start with a clean slate. We were entertaining the idea of building the engine components on top of the Shipyard ECS, but haven't actually done much work in that direction yet for lack of time.

Bevy, though, shares a lot in the way of our philosophies for the engine design. The biggest points over Amethyst for us is the short compile times ( yay! ) and the WGPU rendering backend. You're checking a lot of our boxes with things like customizable render paths, data-driven shaders, flex-box UI system, extremely ergonomic ECS, hot reload, etc. These are things that we frankly don't have a ton of time to develop ourselves, but we hadn't yet found any other options that satisfied us.

Additionally, you already have a nice website, a well defined "Why Build Bevy" ( along the lines of a project "vision" which is essential ), and we're totally on board with "documentation proportional to stability". We are rather inspired by how aligned with our goals Bevy is. It seems very well thought out and designed.

---

Here are some of the design aspects of Arsenal and how they might fit into Bevy:

What is Arsenal?

Aresnal is our vision for a game engine that is fully integrated with Blender, using Blender as the game engine editor. This is much in the spirit of the Armory3D but built on Rust and with a stronger focus on performance and usability. We hope to create an unprecedented user experience by riding on the prolific Blender user interface and completely eliminating the traditional import/export pipeline that can cause so much pain when creating games. Our vision is to create a game engine that is as approachable as possible to a large audience of both complete beginners and seasoned experts while still being able to produce games of any scale.

Arsenal is distributed as a Blender plugin which is written primarily in Rust with a little bit of Python glue code for the user interface components.

Scenes, Shaders & Render Paths

Scenes will be designed inside Blender and exported to gLTF automatically by Arsenal. We've already created a very basic but blazing fast gLTF exporter that can export Blender meshes to gLTF and run it inside of an Amethyst game almost instantly ( see the Arsenal Getting Started Guide ). With Bevy's hot reload, you could get instant updates to your scene simply by modifying them inside of Blender.

Shaders will be compiled to GLSL from Blender's built-in shader nodes, allowing you to develop materials inside of Blender and have them automatically exported to your game.

We can also build your Render Graph nodes into the Blender interface. Combining this with logic nodes you would then be able to sketch, model, sculpt, layout, paint, design materials, create the render graph, and program a game, all without leaving the Blender interface.

Scripting

Scripting is very important to us with Arsenal. We want you to be able to write games using at least Rust, Python, and Blender Logic Nodes. This is important to us for accessibility for beginners and to allow for modding in the future. Rust will also always be an option to allow for zero-overhead game logic, and you will be able to write different components in different languages.

Our plans for scripting most resemble the Amethyst Scripting RFC but I've been thinking about maybe some different approaches as well. The basic concept is to create a schema definition language ( or maybe use something like Apache Arrow )that can be used to represent ECS components in a language agnostic manner and to provide a C FFI to the ECS that allows for systems to modify the ECS world potentially from any programming language.

The FFI is not required for us to start experimenting, though. The most important feature not in any Rust ECS ( that I know of yet ) is the ability to register components and systems that are not known at compile time. If I can register dynamic components and systems at runtime using a Rust API, having a C FFI is secondary and a separate step entirely.

Also, the components that we register at runtime need to be able to be defined as byte arrays of a length that is determined at runtime. Essentially each scripted component will be a #[repr(C)] struct represented as a byte array in the component storage and each different component type could be a different length of bytes. This is our biggest question about Bevy: do you think it would be possible to allow dynamic runtime registration of systems and components with custom storages in the Bevy ECS?

Note: Also some reference on scripting ideas is the discussion on the Shipyard ECS: leudz/shipyard#96

Summary

When it comes to scripting and the editor, Arsenal takes a different approach than the ones you outlined in the "Why Build Bevy" section of your post, but I don't think that's a bad thing. Having Arsenal as a Blender interface for Bevy wouldn't preclude you from developing a Bevy based editor. Also I don't think that having scripting support would hurt Bevy, but you would have to answer that. If you are open to it and Bevy continues to look like a feasible option for Arsenal, scripting support is potentially something we could work on contributing.

Anyway, if you don't mind we would love to have a web meeting so we can talk about how we might be able to help each-other. If you are interested you can use our contact form and we can work out a time.

[cart]

Thanks for the kind words and the interest! I'm actually familiar with your project (and very familiar with armory) so thats convenient for both of us. I think the fully integrated approach Armory uses has worked really well for them, so i'm glad you've taken inspiration from it.

The "Blender for everything" approach is a non-goal for Bevy. I think a fully custom editor built in the engine significantly lowers the complexity and barrier to contribution (Bevy game devs are basically already engine devs ... they just don't know it yet).

That being said I'm totally cool with Arsenal building on top of Bevy. I know an alternative Blender-only workflow would appeal to many people and would certainly lower the barrier to entry for non-rust devs and encourage an artist-first workflow. I'm happy to help where I can (although I will be focusing most of my efforts on the Bevy side of things). And we should definitely coordinate to ensure we're building foundations that you can use (and vice-versa).

On the topic of scenes, we might have slight divergence here. The Bevy Scene format will be the official way of composing scenes, whereas it sounds like GLTF is the interchange format you would use. I definitely want full GLTF support, but the features available there will be a subset of the Bevy Scene format. For complete integration with Bevy, I recommend using GLTF for models and Bevy Scenes for full scenes + components. (but note that both gltf and scenes are still a WIP)

Scripting is an interesting conversation. My default answer is that scripting is a non-goal for Bevy, and is in fact maybe even an anti-feature. I want Rust to be the "one language" people use to build Bevy games. I think a cohesive ecosystem is an incredibly important part of an engine's success. If half of Bevy devs use rust and the other half use C#, then compatibility and interop become a huge problem. The Rust language choice does set a high bar, but Bevy doesn't need to be all things to all people. Additionally, the Bevy API is a Rust API. Defining FFI on top means we need a second api surface that is the "lowest common denominator" (aka a C api). This both increases maintenance burden and creates the "rust experience" and the "everyone else" experience.

Dynamic components are a good idea and I don't see anything that blocks them explicitly (although the current "strongly typed" ecs api might need explicit extensions to support dynamic components). Under the hood hecs treats everything as byte arrays anyway. Before adding support in Bevy, I'd need to think about what cases dynamic components enable vs the additional complexity supporting them would add.

I'm down to have a web meeting in the near future to discuss this more, but in the immediate short term I'm already 100% overwhelmed by the rapid increase in our community size, so coordinating with other projects will take some time.

[zicklag]

The "Blender for everything" approach is a non-goal for Bevy. I think a fully custom editor built in the engine significantly lowers the complexity and barrier to contribution (Bevy game devs are basically already engine devs ... they just don't know it yet).

Totally agree with the advantages of that model. I think it's useful that we can approach this from two different angles and hopefully share a lot of work to our mutual benefit.

And we should definitely coordinate to ensure we're building foundations that you can use (and vice-versa).

Absolutely.

The Bevy Scene format will be the official way of composing scenes, whereas it sounds like GLTF is the interchange format you would use.

If there's a format to use for scenes other than gLTF that's absolutely no problem ( and I think I might prefer using gLTF for models only anyway ). If the format is written in Rust then Arsenal can use it.

My default answer is that scripting is a non-goal for Bevy, and is in fact maybe even an anti-feature. I want Rust to be the "one language" people use to build Bevy games...Additionally, the Bevy API is a Rust API. Defining FFI on top means we need a second api surface that is the "lowest common denominator" (aka a C api). This both increases maintenance burden and creates the "rust experience" and the "everyone else" experience.

As long as there is a way in the Rust API to facilitate the amount of dynamism necessary for scripting, we should be able to take care of the scripting and any FFI from the Arsenal side so that you don't have to take on that burden or taint the pure Rust Bevy ecosystem with extra scripting concerns. It's mostly a matter of us being able to add systems with dynamic queries to the scheduler and components with dynamic storage. With those core functionalities I think that we can cover the rest of what we need to figure out how we want to manage scripting in Arsenal.

I'm down to have a web meeting in the near future to discuss this more, but in the immediate short term I'm already 100% overwhelmed by the rapid increase in our community size, so coordinating with other projects will take some time.

Cool. Whenever you are ready for it. 🙂 700+ ⭐ 's in 48 hours... Your project is about to get very popular. 😉

[cart]

Brilliant sounds like we're on the same page. I'll ping you in the near future when I have time to discuss this more in depth. (feel free to ping me if you haven't heard from me in awhile).

[JeanMertz]

Just wanted to leave a comment here saying 1) awesome project, really looking forward to playing with it, and 2) I too came here looking for an answer to dynamic component/system registration.

I have a proof-of-concept Wasm plugin/mod system that I would love to integrate into Bevy as an engine plugin, but a big requirement for that to be of any use is for the engine to have some kind of API to register components and systems that aren't statically typed.

It can work without this feature, but would be very limited, as the main game would have to define all components and systems, which the mods are then allowed to use.

[erlend-sh]

I have a proof-of-concept Wasm plugin/mod system

Is it open source yet? I’m aware of one other such system that’s already publicly available, explained here:

https://rr-docs.readthedocs.io/en/latest/technical-details.html

This issue already covers a lot of topics though, so it’d probably be better to start some new, more specific ones like “Dynamic components for FFI scripting”, “WASM plug-in/mod system” etc.

[cart]

@JeanMertz @zicklag maybe you could collaborate on an api proposal? It would help if you familiarized yourself with the bevy_ecs / hecs codebase.

[zicklag]

@cart Exactly what I was thinking.

@JeanMertz I created a new issue: #142. It would help to get some more details on how you setup your modding and how you are imagining it integrating with the ECS. I have a picture in my head of how I need to integrate my scripting setup in to the ECS but we'll want it to take into account both of our use-cases.

[zicklag]

I'll close this issue so that spin-off topics get their own issues.