Thinking about migrating my game engine, misc questions

[viridia]

For the past 3 years I have been working on a game engine based on three.js. Currently it's about 70K lines of TypeScript code for both the engine and the editor. Here's a screen shot to give you a sense of what it looks like:

So, I'm considering re-writing the engine in either Unity, Unreal or Bevy, as I am finding more and more that I am pushing the limits of what three.js can do. However, there are a ton of unknowns - I don't know if it's even possible to port the game to Bevy at this point.

Here's a list of some of the unknown issues:

1. Reflection. The engine currently uses its own reflection framework called Reflex. One feature that Reflex allows is to annotate individual fields with custom metadata, which is used by the editor to decide how a given field should be edited. An example of this is the ResourceKey type, which is just a string that points to an asset. The editor puts up a chooser which allows you to browse through available resources. The field reflection metadata can include restrictions on what kinds of resource can go in that slot, such as an Actor, Quest or Dialogue resource.

Another example is editing of character color maps. Typically a parent archetype will specify how many color "slots" a given model supports, and then child archetypes will fill in those slots with specific colors. This allows, for example, to have a pack of wolves where each wolf has a slightly different fur color. The editor for the color choices field needs to know the color slot names, this is done via additional reflection metadata that contains the field name.

I don't know if Bevy's reflection framework supports anything like this.

2. Reactivity. The Editor is currently written in Solid.js, and makes heavy use of fine-grained reactivity. Most editing of objects is done via property-sheet widgets that build a UI based on reflection data. Note that the objects in the scene graph are not typically reactive and are not generally edited directly. Instead, reactive editing is generally used for "archetypal" data - game data such as actor archetypes, quests, inventory items and so on. Archetypes support prototype-inheritance, so for example "Goblin" inherits from "Monster" which inherits from "Actor". (I'm talking about data inheritance, not classes here.)

I expect that the UI data-binding paradigms in something like Bevy are very different from Solid, and would require a complete redesign of the editor.

3. Goals and NPC Behavior are also driven by reactive formulas. That is, the behavior of both NPCs and interactive objects (traps for example) are driven, not by scripts and events, but by formulas that recalculate in response to Solid signals. Unlike traditional event-driven scripting, there is no explicit subscribe / unsubscribe code, instead merely reading a signal automatically adds that component or task to a tracking list which re-evaluates the function when the data changes. A good example of this is a spreadsheet - if your formula depends on cell B2, the app knows when it needs to be recalculated and can do so efficiently.

In fact, my original motivation in writing my own engine (instead of using Unity) was to research the feasibility of this approach to scripting. There's nothing like this in the Bevy world so far as I know.

4. Asynchronous logic. A lot of the game engine's logic only happens rarely, rather than requiring an update every frame. Things like pathfinding, navigation mesh construction, terrain generation and so on all happen in between renders and typically take more than a single frame worth of time to complete. Also, the engine loads scenery data in the background as the player moves around the map, allowing worlds of nearly unlimited size, but the load operations are i/o bound and there is significant post-processing required when an scenery asset is loaded. The tutorials on Bevy schedules don't mention this kind of scheduling.

5. Instancing. The engine makes heavy use of WebGL instancing, so for example in the screenshot there are 16 chairs but only one mesh instance loaded. How this works in Bevy is to be determined.

6. Outlines. The game has a deliberate "Art Nouveau" visual style (more apparent in the HUD overlays than in the 3D scene) but you can see for example that objects have black outlines. This is done using the inflated-normal technique, so each model instance is rendered twice, one with front-facing polys and once with back-facing. So the question is how this sort of thing would work in a Bevy environment.

7. Dynamic color palettes. The game has hundreds of characters, but only a few dozen unique character models. Characters have a special GL shader that allows materials to be recolored on a per-instance basis, using the color slots mentioned earlier.

8. Editor UI. The editor runs in a browser and has it's own UI widget set. One possible approach for porting the engine would be to keep the editor as a web app written in TypeScript, and then use something like Tauri to allow the Rust game engine to export a service API which the editor could call. (WASM is also an option, but I don't want to be constrained by WASM limitations).

Re-doing the editor entirely in Bevy UI would be a huge task, especially given that game UI widgets are often designed quite differently than editor widgets and have different needs for things like layout, scrolling, copy and paste, keyboard shortcuts and so on.

To sum up, I'm not sure that porting the engine is a good idea, but I'm curious to find out more.

[nicopap]

Reflection (1)

So rust doesn't have native reflection support, but bevy has its own library bevy_relfect, and it so happens you can do with it exactly what you describe! A similar technic of tagging fields with metadata is used by bevy-inspector-egui.

Note however that rust is a statically ahead-of-time compiled language, and has no built-in reflection support. So you'll have to go through bevy's library, and it's not as ergonomic to do that as in Javascript (or even Java).

Reactive UI (2)

Bevy is an ECS game engine. Every state goes into the ECS, either as component or resource. You use queries to access game state. End of story here really.

On top of this, bevy's built-in UI library is to UI frameworks what slings are to modern armament (primitive to say the least). So you are likely to need to go through a 3rd party plugin for UI.

• bevy_egui: EGUI being immediate mode, it's not that big of a deal to read data from the ECS with it, however it is not the easiest to customize, and personally I struggle a bit with their layouting system.
• kayak: A UI framework inspired by react. My understanding is that it tries to do state management itself.
• belly: I think it is similar to kayak, but delegates the state management to the ECS.

I've myself attempted to build an UI framework (or actually just a richtext library) that delegates state management to the ECS and I had to temporarily freeze development because of scope creep.

Game object API handling (2) (3) (4)

The main selling point of bevy is the ECS. All of bevy revolves around this. Bevy is not a rendering backend, but a game engine, and it requires control over your code flow. All bevy features such as rendering do depend and are extensively integrated with the ECS.

This is fundamentally in contradiction with your game engine. You either need to drop your reactive system or use the ECS. You can use events as a temporary band-aid, but your code is a round object, and bevy a square peg. You'll be constantly fighting bevy if you try to port your code to bevy as-is and preserve the reactive aspect.

If you want to "just" port your game engine to rust, you could go with a combination of wgpu (the WebGPU crate) and leptos_reactive. You can always copy/paste the bevy PBR shader if that's what you are after...

Please check leptos, it's very similar to your reactive formulas system.

The rest

• async tasks: Bevy exposes an API for async task pooling, but you'll need to bridge it with the ECS, usually through events
• instancing: Bevy hasn't automatic instancing (boo, bad), but there is an example in the repo showing how to do it manually
• outlines, dynamic color palette: Bevy supports user-provided shaders, you could create a custom material for this. (there is a 3rd party outline plugin based on inflated-normal, another uses jump-flooding, but that one is outdated I think)
• editor UI: Godot uses its own UI toolkit, and bevy aims to do the same thing (note that bevy doesn't have an editor) and as said earlier, the bevy UI lib is so primitive it's not even worth considering.

[viridia]

Thanks for the detailed reply, that was very helpful.

I want to dig deeper on a few of your answers.

For games which have complex, high-level behavior, what is the typical design pattern used in the ECS world? I can see how ECS makes sense for high-performance objects which are animating or interacting in real time. However, for complex, long-term behaviors (dialogue trees, quests, stories, puzzles, character goals), these are typically authored in data rather than code - it would be too cumbersome, for example, to write a character dialogue tree in rust. The runtime code is merely an interpreter for that data.

Or is the case that Bevy simply isn't intended for creating those kinds of games?

On the topic of editing: I had thought that perhaps a hybrid model of some sort would be possible. Virtually all of the data produced by the editor is a static constant during play. What the editor creates is effectively a template for constructing a new game, but that template itself is not modified by player action (saved games are essentially a diff between the template and the current state of the game). So one could envision a framework whereby ECS is used to represent the mutable state, but all of the data produced by the editor is effectively Bevy resources or something similar. The game only needs to know when the editor changes something in order to reload the scene, although it's better if these updates can be fine-grained in order to avoid screen flash during edits.

(This is not that different in concept from the way that I interface with three.js. The editor never touches the actual three.js scene graph.)

Here's a screenshot that shows what the editor for character dialogues looks like:

With respect to simply porting my engine to rust - I really, really don't want to have to implement things like GLTF loading or point light shadows.

[rlidwka]

it would be too cumbersome, for example, to write a character dialogue tree in rust. The runtime code is merely an interpreter for that data.

That question is unrelated to ECS model. Bevy is as good at this as any other engine would be.

The way I'd do dialogs is this:

1. let user write them in a text file (perhaps, you can look at jomini crate for this, that's a format for events that Paradox games like CK2, EU4 use)
2. load all of these to ECS as a resource (smth like HashMap<DialogId, Dialog>, where Dialog is a data structure that can represent any individual intro/option)
3. add "current dialog option" as a component for player entity (there are usually multiple players, be that multiplayer scenario or NPCs)
4. then evaluate each frame whether you should advance dialog to next state (with immediate-mode library like bevy_egui that's pretty simple)

[viridia]

Thanks for the response. I'm starting to get the picture as to how difficult this will be (I knew it would be hard, just not sure how hard). I still haven't decided if doing this is a good idea. (An alternative is to port my game to Unity, but I have zero Unity experience, and there are problems that are equally as daunting as the ones mentioned above.)

You mentioned dialogues (BTW, I always use the spelling "dialog" to mean a modal UI element, and "dialogue" to mean a body of spoken text). I already have my own dialogue serialization format, which is based on JSON and works pretty well. This not only includes prompts and responses, but conditions as well - a lot of dialogue is conditional, especially quest dialogue which changes based on which stage the quest is in.

Fortunately, dialogue conditions are pretty easy - there's only a small number of predicates (about a dozen), and these only need to be evaluated when displaying prompts, they don't need to be evaluated continuously.

Quest stage predicates are a bigger problem, since quests can advance based on mutations in the game world. An example is a quest which advances when the character acquires a key quest item - essentially the predicate needs to watch the player's inventory for changes, and advance when the specified item is present. Other quest predicates can trigger based on NPC or environment states, which is tricky given that those entities aren't always loaded in memory.

Slight digression for a moment: I have a long history of working with game scripting languages, I developed SAGA and SAGA 2 in 1992 (which are still supported in the SCUMM VM), I also worked with scripting languages at a number of game companies, including Edibles, which was the language we used while I was on the Sims 2 team. I'm also familiar with UnrealScript (circa 2002) and Bethesda's Papyrus / Creation Kit. What may be surprising, then, is that I am not very impressed with any of these languages - I have long felt that there must be a better way to script game behavior than writing imperative functions in languages which aren't far removed from Visual Basic.

So part of what I set out to do in creating this game engine was to see if I could develop these ideas into something practical. The Solid.js / MobX style of reactivity seems to fit the bill - it means we can stop worrying about events and instead concentrate on what we really care about, which are intuitive notions of game state ("Am I hungry?" "Does this faction hate me?"). Turns out that using reactive formulas means that most traps / puzzles / mechanisms can be done in a single line of code. NPC AI is more complex since you have to deal with competing goal priorities, but the same principles can be applied.

Given that, how does this apply to quests? Well, one could simply poll the quest transition predicate every frame, but if the game has a lot of active quests this is not very efficient. It's better if the trigger condition automatically subscribes to the data sources referenced by that condition, and only re-evaluates the condition when one or more of those data sources changes.

This is not the way ECS does things, but that might not be important - because all of this logic is happening at a level above what ECS is doing. None of this stuff needs to execute every frame, and quests aren't game objects in the sense of being something that exists at some location within the game world - they are abstract global thingies. They influence what happens in the 3D scene, but are not part of it. There are a lot of objects which have similar status, such as experience points, tech trees, or entries in the player's spell book.

Also, one can certainly bridge between the ECS and reactive worlds, similar to the way Redux selectors work - that is, if you can get some signal that an object has changed, and you have a comparator that checks to see if field X of the previous state equals field X of the new state, you can then trigger a callback - giving you fine-grained notifications of changes.

[viridia]

Digging into Unity, I can already see a number of show-stoppers. For one thing, my game makes extensive use of "cutaway" views, so when you go into a building the upper floors are removed so as not to obscure the action - but the physics are not disabled (otherwise the actors on the top story would fall through the building). Unity's "layers" allow you to selectively remove objects from rendering, but there's a limited number of them (it's a bitmask), and in a large world of multi-story buildings you quickly run out of mask bits.

Similarly, my game has its own portal system which allows connections between different independent worlds or "realms". This requires being able to render different game levels on different cameras. Unity has multiple "scenes", but the only way to render scenes selectively is to use the aforementioned layer mask, which puts even more pressure on the number of bits.

Both of these issues are trivial to solve in a system like Bevy.

On the other hand, the biggest obstacle with Bevy is the editor UI which was mentioned previously. I thought about doing a hybrid where the editor is a web app and Bevy is embedded as a sub-pane via WASM, but this is a horrible developer experience - when Rust panics you get almost no diagnostic information in the Chrome debugger, or at least that's been my experience when using Rapier. Developing under that kind of environment would be hell.

Writing my own UI toolkit is not out of the question - back when I was at EA (2006-ish) I wrote an entire browser that ran on the XBox and PS2. However, that's a daunting amount of work that I would prefer not to do. I'd much rather focus on the game logic and character AI and let someone else do all the UI and rendering stuff...