Bevy Editor

[cart]

Bevy should have an extensible visual editor capable of the following:

• Visualizing / editing scenes
• Visualizing / editing hierarchies
• Extensions
• Interacting with live app data

[DJaremko1982]

If this is similar to Godot its going to take off in a big way

[Joe23232]

Yep, this is going to make Godot obsolete then if it looks and functions pretty much identical to Godot.

On Thu, Dec 3, 2020 at 12:10 AM DJaremko1982 notifications@github.com wrote:

If this is similar to Godot its going to take off in a big way

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bevyengine/bevy/issues/85#issuecomment-737220439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIKO7IOJILRCOTK23O6X4RLSSY4CVANCNFSM4PU7YATA .

[DJaremko1982]

Yep, this is going to make Godot obsolete then if it looks and functions pretty much identical to Godot.

On Thu, Dec 3, 2020 at 12:10 AM DJaremko1982 notifications@github.com wrote:

If this is similar to Godot its going to take off in a big way

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bevyengine/bevy/issues/85#issuecomment-737220439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIKO7IOJILRCOTK23O6X4RLSSY4CVANCNFSM4PU7YATA .

I wouldnt want godot to be obsolete though as we all learn from each other help each other in an open source way, Godot is a really good game making engine by design and usability

[Joe23232]

Godot is a really good game making engine by design and usability

That is true, its pretty nice as well the editor, I would even argue it has the best game editor out there, much better than Unity especially.

On Fri, Dec 4, 2020 at 9:37 PM DJaremko1982 notifications@github.com wrote:

Yep, this is going to make Godot obsolete then if it looks and functions pretty much identical to Godot.

On Thu, Dec 3, 2020 at 12:10 AM DJaremko1982 notifications@github.com wrote:

If this is similar to Godot its going to take off in a big way

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub

85 (comment)

https://github.com/bevyengine/bevy/issues/85#issuecomment-737220439, or unsubscribe

https://github.com/notifications/unsubscribe-auth/AIKO7IOJILRCOTK23O6X4RLSSY4CVANCNFSM4PU7YATA .

I wouldnt want godot to be obsolete though as we all learn from each other help each other in an open source way, Godot is a really good game making engine by design and usability

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bevyengine/bevy/issues/85#issuecomment-738708746, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIKO7IJGEHHIJZN72WG3WRDSTC3VDANCNFSM4PU7YATA .

[zicklag]

Hey all, I had mentioned in a previous comment that there would be a post to explain what happened with Arsenal. It took much longer than we thought to get the announcement out, but it turned out much better than we thought, and we will be continuing development!

I don't want to clutter this issue so please redirect any comments or questions to this discussion, which also has a link to our public announcement: https://github.com/katharostech/arsenal/discussions/113.

[bjorn3]

I wrote a kind of design document for some features that will likely be needed to make an editor usable: https://hackmd.io/@bjorn3/Hy6jHgPAP

[DrewRidley]

This is probably too early to even consider, but will there be a way to extend the editor? Similarly, Unity offers some tools to extend the editor (albeit, Unity uses IMGUI). Could be useful in cases where the existing tooling isn't sufficient for a very specific game concept.

[bjorn3]

Yes, the idea is that plugins and games will be able to extend the editor. My proposal would be to have the editor be exposed in the code as a function returning an AppBuilder. The game would then have a binary that calls this function and can then extend it with plugins before starting it: https://discord.com/channels/691052431525675048/789987800014651412/798273060363829320

[dasifefe]

Here are my thoughts and a mockup I made.

• No text editor. Everyone likes to code in their favorite text editor and it is more likely that creating a text editor will only result in something subpar with what everyone is using. Godot is an example of editor that Godot users use because they need to use it (mostly), since they don't have something like Rust-Analyzer to work in external editors.
• No assets editor, only assets manager (add/remove assets). The same goes here, users like to use their favorite audio tool, favorite image editor, favorite modelling tool (focus on importers of GLTF files).
• Make full use of Cargo. When creating a new project, the editor calls Cargo to create a bare minimum template. Same for compilation.
• When adding entities and components, use Rust-Analyzer to extract information of what types in your Rust code are supposed to be for entities/components. Maybe Rust-Analyzer should only expose to the editor the types manually marked as such by the users with macros.
• In order to accelerate the process of creating these types marked to be used with the editor, maybe the editor should have buttons to 1) Create new component type, 2) Create new bundle, and others functionalities that will simply create a new Rust file (.rs) in the project folder. These files will contain the bare minimum template for these uses (let the user edit them with their favorite editor).
• Hot-loading, as far as I know, is not sound in Rust. So, the editor would be its own application, and the game a different application compiled by Cargo (called by the editor).

This is the early mockup that I made.

Same image in 4K.

I like single-window designs and I am thinking of a design with no popups (only expand buttons and tabbed pages). I think it's nice to have less shown on the screen and show only when in use.

The Settings tab could have the overview functionalities of the editor. Save/Open/Close a project, theme, compiling configurations. When no project is open, the other tabs would disappear.

The Assets tab would contain audio, text, video, pictures, and scenes. Scenes would be organized as assets, and when double clicked, the inspector would change to that scene. Scenes would then be the only asset that the editor would modify.

In the Inspector tab, the Scene frame would be expansible and properties intrinsic to the scene could be edited. The Entities frame would contain the list of entities and the Components frame would contain widgets that represent each component of the selected entity. The headers (Scenes, Entities and Components) have a drop-down arrow that, when clicked, expand to show some extra options, such as filtering entities/components, mass addition/deletion of entities/components (the same way the headers of the columns on TweetDeck work). I don't know what the list of entities should display besides the UUID. Entities would need a sort of label, or the bundle name could be used if it exists.

The bottom status bar would show progress of compilation, possibly expanding when clicked and showing the output of Cargo, and other contextual details.

Inspirations are Blender, Godot, Unity, VS Code and TweetDeck. If this is of interest, I will continue developing mockups.

[Joe23232]

Did you make this yourself?

On Fri, Jun 25, 2021 at 10:56 AM Fel @.***> wrote:

Here are my thoughts and a mockup I made.

• No text editor. Everyone likes to code in their favorite text editor and it is more likely that creating a text editor will only result in something subpar with what everyone is using. Godot is an example of editor that Godot users use because they need to use it (mostly), since they don't have something like Rust-Analyzer to work in external editors.
• No assets editor, only assets manager. The same goes here, users like to use their favorite audio tool, favorite image editor, favorite modelling tool (focus on importers of GLTF files).
• Make full use of Cargo. When creating a new project, the editor calls Cargo to create a bare minimum template. Same for compilation.
• When adding entities and components, use Rust-Analyzer to extract information of what types in your Rust code are supposed to be for entities/components. Maybe Rust-Analyzer should only expose to the editor the types manually marked as such by the users with macros.
• In order to accelerate the process of creating these types already marked to be used with the editor, maybe the editor should have buttons to 1) Create new component type, 2) Create new bundle, and others functionalities that will simply create a new Rust file (.rs) in the project folder. These files will contain the bare minimum template for these uses (let the user edit them with their favorite editor).
• Hot-loading, as far as I know, is not sound in Rust. So, the editor would be its own application, and the game a different application compiled by Cargo (called by the editor).

This is the early mockup that I made.

[image: Bevy_UI] https://user-images.githubusercontent.com/59259533/123352269-56bad580-d535-11eb-8887-b34c48346722.png Same image in 4K. https://user-images.githubusercontent.com/59259533/123352282-5cb0b680-d535-11eb-818e-b91ca730ca4d.png

I like single-window designs and I am thinking of a design with no popups (only expand buttons and tabbed pages). I think it's nice to have less shown on the screen and show only when in use.

The Settings tab could have the overview functionalities of the editor. Save/Open/Close a project, theme, compiling configurations. When no project is open, the other tabs would disappear.

The Assets tab would contain audio, text, video, pictures, and scenes. Scenes would be organized as assets, and when double clicked, the inspector would change to that scene. Scenes would then be the only asset that the editor would modify.

In the Inspector tab, the Scene frame would be expansible and properties intrinsic to the scene could be edited. The Entities frame would contain the list of entities and the Components frame would contain widgets that represent each component of the selected entity. The headers ( Scenes, Entities and Components) have a drop-down arrow that, when clicked, expand to show some extra options, such as filtering entities/components, mass addition/deletion of entities/components (the same way the headers of the columns on TweetDeck work). I don't know what the list of entities should display besides the UUID. Entities would need a sort of label, or the bundle name could be used if it exists.

The bottom status bar would show progress of compilation, possibly expanding when clicked and showing the output of Cargo, and other contextual details.

Inspirations are Blender, Godot, Unity, VS Code and TweetDeck. If this is of interest, I will continue developing mockups.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bevyengine/bevy/issues/85#issuecomment-868103713, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIKO7IP6AHUCLEDX4W64CADTUPH4LANCNFSM4PU7YATA .

[dasifefe]

Yep. Took some ready assets (Google Icons) and a screenshot from Blender's viewport :smile:.

[Joe23232]

Oh lol nice mate it looks good I hope it can actually be made mate :)

[midnadimple-zz]

I think the editor should be called Flock (as in a flock of birds.) Just a funny thought I had.

[zicklag]

Worth noting that there is a chat software called Flock already: https://www.flock.com/. Not that that's necessarily a deal-breaker or that it's a bad idea.

[Nilirad]

If it was for me, I would avoid giving it a proper name, since most people identify the editor with the engine itself. They do it erroneously, but they do it, and for Bevy it will be no exception.

[GameDevBhavesh]

What if bevy editor is made with bevy itself? something like Godot did.

[bjorn3]

This is already the plan.

[kirawi]

I think Blender has a fantastic UI, and taking after it will probably be welcoming to people familiar with the tool while still being aesthetically appealing to everyone else.

[ValeriaVG]

I love Bevy's modularity and I think the editor should also be modular and beginner-friendly. And I don't think Blender is a good example for either of those.

Maybe the editor should not be an executable binary, but rather a collection of plugins that can be used from inside the game itself.

Here's how a development flow with such an editor would look like:

• User starts a Bevy project
• User adds e.g. a 2D scene editor and sets it to be toggled on ~ press
• User builds the game
• User presses ~, edits the currently loaded scene, presses ~ again to close it and play the scene, etc.

There can be an isometric editor, voxel editor, a platformer editor or even something custom made for a particular project.

Of course, the editors themselves can be composed out of modules, allowing different types of animation editors, mesh editors, material editors etc.

Just imagine the debugging possibilities with such a tool!

[djeedai]

Maybe the editor should not be an executable binary, but rather a collection of plugins that can be used from inside the game itself.

I disagree with that one. This sounds appealing at first, but the editor and the game itself have conflicting objectives, and pulling that kind of architecture is extremely difficult. There's also a stability concern, in that crashing the game makes you lose all your data. That's also true for a separate editor, but if it's a different app you can afford different tradeoffs and focus more on "stability at all cost", even at the cost of performance (something you cannot do in the game itself).

A better alternative I think is to embed the game window inside the editor. This is doable in Windows, pretty sure in Linux too, and probably on macOS. This ensures that what you see "in the editor" (which really is the game process running) is what you see in the standalone game. This also allows restarting the game if it crashes; the "game view" just goes black for a second or so while restarting, but that's the only thing affected. And the complexity of editing is left in the Editor app itself. This can be augmented with live editing as scene in this tech demo (RIP BlitzGames), which allows some sort of "in-game" editing without reloading, including on consoles, but retain (almost) all the benefits mentioned above.

[midnadimple-zz]

I think implementing the editor as plugins could lower the complexity that making an editor would entail.

For example, @johannesvollmer said an external camera would be needed to view the scene in the editor, however, with the plugin approach, this wouldn't be necessary as you could just view the scene using the main camera. This would benefit especially from live reloading, to prevent the end user from restarting the app every time a change is made.

This could also provide a large amount of customisability. Previously, @dasifefe mentioned that the editor should not include a text editor since it could result in a less quality experience. While targeting the text editor for everyone would indeed result in a worse end product, if someone finds using a built-in editor more convenient. So, they can just optionally add the text editor plugin.

Finally, this approach could instill more creativity in the community, if someone feels that a feature in an editor is missing, instead of just filing an issue here, which would increase workload in this repository, they could create a simple plugin for that feature, and publish a crate. This would also mean that the footprint of the editor would be smaller.

I wonder what @cart thinks of this.

[Conando025]

What about a hybrid approach? I mean I'm not sure if it does work like I'd imagine but I'll just propose that anyway. What if we make some plugin so that you can compile the editor yourself and for people that don't wanna go that in depth we can provide executables. So you have the benefits of the of the executable and you can still adept the editor to your needs.

[caperaven]

Has someone formally started on a design for this? From the outside, it looks like there are a lot of ideas but not much direction on this. Is there a responsible person actively managing this?

[djeedai]

As far as I know this won't start until several other major changes landed.

[caperaven]

I can understand the development being on freeze until the ui tech is formatted but would be great to have a style guide and mock-ups so long. I think there was a designer who showed interest but not sure what came from it

[SamPruden]

Uninformed Bevy newb with dubious opinions checking in.

Unity's ECS editing experience is currently Bad, but has a couple of interesting ideas. They have this concept of separating authoring data from runtime data. The idea is that in a data driven design, component data layout is chosen based on engineering concerns which are often not the right level of abstraction to surface in an editor. For example, the physics state of an entity may be controlled by five different small components, but in the editor we just want to expose a monolithic rigidbody. A single authoring object can correspond to multiple components, or even multiple entities. Creating a good editor experience should never force a trade-off with good runtime engineering.

Unity does this by using their pre-ECS GameObjects for authoring in a way that I find very clunky, but I think the idea here is good. Essentially they have entities and components which are designed to be exposed in the editor, and "Conversion Systems" which process that authoring data and produce the corresponding runtime data. They do this conversion process live. The editor hierarchy shows the authoring components, but the scene view can be toggled to show the converted state.

One notable advantage of this is that the runtime representation behind a feature can be completely refactored and re-engineered, but as long as the associated authoring tools are kept up to date with these changes, existing scenes will continue to work.

I believe Unity's Joachim Ante commented that he thought one of his biggest mistakes with Unity was taking so long to realise that editing and runtime data should be separate, although I can't find that quote at the moment so don't attribute it to him.

Is this an approach that we think a Bevy Editor should take?

[djeedai]

Not-so-informed ever-so-slightly-less-newb here. I haven't seen that idea yet surfaced for Bevy, but it makes tons of sense to me.

[cart]

Definitely worth bringing up! Decoupling runtime components from editor widgets definitely seems valuable. What this looks like in practice (1 component -> 1 widget, many components -> 1 widget, many components -> many widgets, do things like Bundles and/or Prefabs inform editor state, etc) will require some discussion, but we should definitely try to learn lessons from prior art like Unity (and other engines).

[SamPruden]

I think it's important that an engineer can do a refactoring like splitting one component into two smaller components without having to worry about breaking compatibility with existing scenes/assets built by the level designers. The obvious way to do this is to expose a more stable authoring data representation that's used in editor scene files, that the runtime can interpret into entities however it wants.

My first pass at a design would be:

• A one-to-one relationship between UI widgets and authoring components - UI is customisable but has a sensible default implementation based on the fields
• Arbitrary conversion logic between authoring components and runtime components, where simple one-to-one and one-to-many cases are trivial to setup

That arbitrary conversion gets a bit complicated when you want to be able to keep authoring and runtime representations in sync in the editor for realtime preview, but Unity pulls it off. Their API for it is a bit of a nightmare, but I think there's a good version of this that's possible.

[caperaven]

What is your feelings on the blender 3.0 assets repo. It seems rather useful to have the 2d, 3d and material assets available for drag and drop. It also seems very cool that you can have user defined asset repos.

https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Asset_Browser

[sonicXconst1]

Hello! Has anyone started prototype yet?

[Nilirad]

Hello! Has anyone started prototype yet?

First #254 must be resolved. The journey is still long. Nobody can confidently establish an ETA at this point. Fortunately the ride is quite enjoyable 😄

[C-BJ]

I think the Bevy editor needs to allow non-programmers on a team to implement their work without touching the Rust code. Localization of the editor UI also needs to be considered

[sullyj3]

I wouldn't want to speak out of turn, but I don't think complete non-programmers are really in the target audience for Bevy

Localisation does seem important though

[C-BJ]

I wouldn't want to speak out of turn, but I don't think complete non-programmers are really in the target audience for Bevy

Localisation does seem important though

I mean non programmers on a team

[thraidh]

After having read through this issue there does not seem to be a clear vision what the Bevy Editor should actually do or what exactly the output of the editor should be.

There seems to be a consensus that it should be a scene editor, which would mean that you have a bunch of assets that you can place in a scene and the editor would render that scene. That can be done with just reading and writing one or more files, which would also be read by the final product (which may or may not be a game).

At that point the question is, what exactly is an asset? Is it just a 3d model or 2d tile? Or is it something that does have more properties or even behavior? If it is the latter, then the question would be how those properties and behaviors are described. Do we need an extensible data format that describes assets, which may be represented as one or more entities with many components? Or do we prefer a code-first model, where things are set up in Rust, parsed by the editor and form editors are automatically created? Or does that not even work and assets need to be hand-crafted anyway and later converted into entities and components?

Given a team with developers and designers, do the designers even need to know about entities and components? Or will they have a totally different world view, where a component is something like a wheel of a car, which might be an technically entity with lots of technical components, but the designer does not really care.

Then there is behavior. Would the systems be run in the editor to preview animations, physics, particle systems, etc? If yes, the editor cannot be a standalone product, as it would have to contain product-specific code to run all those things. It would also have to be recompiled, if behavior changes.

Would the editor generate Rust code? If yes, what type of code? Just a general boilerplate, which can then be extended by developers or would it rewrite existing code, e.g. to add (technical) components?

I believe, to make a full-fledged editor there needs to be a concept of an asset that contains multiple parts (to avoid reusing the term "component"). Each part can be a visible thing (like a wheel) or something else (like an AI path finder).

Ultimately those would all be converted into entities and components, but the concept of assets and parts might have to be part of the engine, because if you have a car, where the user can choose the type of wheels, your code needs to create those during runtime. As the designer would have set the mesh, materials, physical properties and game relevant things like price and car model compatibility, you would want to have something like .spawn_part("pirental-245-60-19") and not special code for each thing that your designer made.

That might require two layers of Bevy. The core layer that we have now that only knows about entities, components (and bundles) and a layer above that, which knows about assets and parts, which would be something like hierarchical bundles.

This would shrink the space of possibilities but would (from my point of view) be necessary to implement a usable editor.

[SamPruden]

Given a team with developers and designers, do the designers even need to know about entities and components? Or will they have a totally different world view, where a component is something like a wheel of a car, which might be an technically entity with lots of technical components, but the designer does not really care.

See #3877 for some discussion on this.

[StarLederer]

That might require two layers of Bevy. The core layer that we have now that only knows about entities, components (and bundles) and a layer above that, which knows about assets and parts, which would be something like hierarchical bundles.

I agree. I think the editor and all design patterns/structures it brings should stay separate from core Bevy engine, perhaps even be marketed separately and even have competition. We can learn from the Javascript front-end community here in how they separate UI frameworks from site/app building "metaframeworks". Let me explain what I mean.

If we look at all major front-end JS tools we will find that they are somewhat minimal and unopinionated but when they get big enough, someone builds an all-in-one opinionated metaframework around it (e.g. Svelte and SvelteKit, Vue and Nuxt, React and Next, or React and Remix). That allows the UI framework to focus on UI and the metaframework on site generation, code structure routing etc., as well as gives more choice to developers (e.g. use plain Svelte or use SvelteKit) and encourages competition (Next vs Remix).

Another case of good DX I found is ReactNative and Expo. Expo calls itself a code management tool and it essentially hides all low-level code that ReactNative exposes by default and when libraries need to modify native code, Expo does it for you.

What these two cases have in common is:

• they do code management,
• they keep "bloat" and opinions out of core libraries,
• they give developers more choice.

If we adopt that in Bevy we would not actually make a Bevy editor, we would make a Bevy game metaframework with a GUI. Let's call it Bext (like Next but for Bevy 😄)

Bext would:

• define what assets are,
• have a GUI,
• manage code behind the scenes,
• define how code should be structured (maybe),
• hide a lot of Bevy code from developers (maybe),
• have other competing metaframeworks / GUIs / code managers (hopefully).

Bext would not:

• impose its opinions on Bevy,
• need integration of any of its decisions into Bevy.

[djeedai]

I've started writing my own vision of a Bevy Editor in #5043, sharing it for discussion. I tried to collate some of my thoughts and some of the things @cart already stated in the past about what the Editor should and should not be.

[floppyhammer]

Check this out https://github.com/lain-dono/shaderlab. It might be instructive.

[FuaadHi]

Check this out https://github.com/lain-dono/shaderlab. It might be instructive.

This is impressive💥💥 I know that the team focus on important things first. But it will be encouraging if there is a road map showing rough expected time of implementing things like the bevy editor. I felt with Greatness from the first time I checked bevy engine, and I think that the bevy Editor will complete the Greatness loop (greate core framework and Great editor). I hope considering the well designed Blender GUI because this will make the work Flow more comfortable because blender is used intensivly in making games art so the presence of common concepts (if they benifitial for the dev process) between blender and bevy engine editor will make it easier for game artist to adapt with bevy faster. All these things are personal openions😇. I expect that the comunity who made this amazing engine will also make an amazing editor. Thank you.

[preland]

Just a quick checkup- any progress made or notable projects addressing this yet?

[radlotus]

Yeah, Blender has one of the most superior looking and working UI among all software in the world. It should serve as a guide.

[preland]

Blender is very well designed, considering the sheer number of options that it has. However, its design still has a very high learning curve, one that is arguably unnecessarily difficult. I would say something like SketchUp would be good to emulate.

[preland]

Though, let’s be honest: the UI stuff is incredibly easy when compared to the backend work, which I’ve noticed a complete lack of.

Has anyone created a Scene viewer? This is a big one—due to how Rust’s compiler works, it may be difficult to even view a project before it’s been compiled and ran. This issue needs to be addressed. A (somewhat?) simple solution would be to read the Rust file for the project like a markdown file, and then parse the text to show the correct objects in the editor. Of course, this would be somewhat…. Sketchy

In my opinion, the UI theory should take the most inspiration from other open source projects like Linux and Atom(now Pulsar), where everything can be customized to the user’s liking. That way, you can have the editor feel like Unity, or Unreal, or Blender, or Microsoft Paint or whatever else someone may want.

[StarLederer]

Just a quick checkup- any progress made or notable projects addressing this yet?

I am very enthusiastic about Bevy UI but the core engine has a lot to implement still so I find the delay on this fully justified

UI theory should take the most inspiration from other open source projects ... where everything can be customized to the user’s liking

I've been working on one Tauri app which has a pretty clear destiction between rust core and WebView frotnend. I wonder if we can use Tauri for our editor, that way the fontend will be essentially a website and the community will take care of Unity and UnrealEngine looks as well as 50 wacky styles on day one (i'll surely be making a wacky preset 😅)

[Aceeri]

Has anyone created a Scene viewer?

There is a scene viewer in the tools examples of bevy.

[preland]

Has anyone created a Scene viewer?

There is a scene viewer in the tools examples of bevy.

Out of curiosity, I looked, and there is a “scene viewer” example under tools. Unfortunately, looking further into it shows that it can only explore a single .gltf file, instead of a scene from a project (ie. a main.rs file or otherwise)

[preland]

Honestly, the only hitch at the moment for an editor is the capability of viewing a .rs file without having to constantly recompile. If that issue is figured out, everything else will simply fall into place.

[minecrawler]

Wouldn't that be a lot easier if we didn't have to parse a programming language, but instead data? Bevy is data driven. So if the editor would create a standard way to manage plugins, assets and the ECS side, it might deliver the entire programming part as a generated .rs, which reads everything else from data files (e.g. toml, json, etc.). Then scene-viewing would be incredible easy, and the only thing which needs compilation to work is real game logic from systems.... which may be written in pure Rust, or be implemented in a hot-reloadable scripting language.

Why would I, given an editor, want to implement all these things myself? I want to slap my assets into the editor, write some game logic and then fine-tune things at runtime. I don't want to write App initialization or the system which loads my assets - hell no!

And even then, lots of optimization can happen, so that it's easy to change values. For example using Reflection and a MIDI interface for a sound board with turning nobs. Just bind 3 nobs to R, G and B and then you can create the perfect color during a run. Or put an algorithm into a script, so you can do something based on the algorithm's result in game and have it be hot-reloaded.