2023 devlog 3
Third weekly devildahu devlog, the last one is available here.
This is going to be short, as I burnt a bit out and kept 3 days for myself.
bevy_mod_cuicui
As promised last week, I spent more time thinking about UI in bevy.
After the last post, which helped me better understand what I wanted, I quickly came to the conclusion that I didn’t want to make a UI framework.
I wanted to keep in the bevy spirit, create primitives and build UI on top of those primitives. An integrated framework solution, not only is antithetical to bevy’s goals, but also antithetical to my own principles.
I was designing the Prefab interface for bevy_mod_cuicui, but I came to
the conclusion, such an interface wasn’t needed (while not exactly useless). My
current assessment is that I just want several ways to “spawn” or “specify” an
UI:
- I want a way to define my UI through a simple text format, I want this to be
composable, and extensible through bevy’s
Reflecttrait. - I want a concise but beautiful by-default way of specifying a tree of UI elements. Ideally, this is composable, extensible and type-safe.
Those two ways are not mutually exclusive, but they are definitively unrelated.
This is pretty much the result of half a second of through after last devlog. It really took me more time to write this section than go to this conclusion.
So I went back to an older abandoned project of mine (I tend to accumulate those)
bevy-kdl-ui
bevy-kdl-ui was my first attempt at solving the bevy ui problem. The
premise was informed by insights that I seem to have forgotten:
- How great it was to use a LISP interpreter for defining state machines for project mushroom. As I could use LISP macros to make state machine declarations composable, without writing any parsing code. (for my defence, a similar system was used in The Last of Us)
Prefabs (meaning: a tree of ECS entities with collections of components) can be expressed as a macro, parameters as macro parameters, etc. All the work could be done before deserialization.
I actually spent a lot of efforts on bevy-kdl-ui before abandoning it.
But I still think this model may help, so I went to it and tried to at least
get a minimal working version (if even extremely buggy, slow and limited) to
see if I could iterate on it and start building a collection of widgets on top
of it.
In the space of 3 days, I gorked the code, then wrote a bevy loader for the deserialization format that already worked (thanks to an excellent test suit).
I wrote an example, but never ran it. It feels very unpleasant working on it. Every functionality I added needed very ugly hacks (for example, the loader doesn’t use bevy’s loading system due to dependency management, it also isn’t asynchronous, due to the complexity of managing a cache of loaded templates). So of course, most of the code I write is marked for refactoring, it just feels wrong.
As a result I didn’t do much more. I hope to get back on track for next week.
(you may be interested in this blog’s [rss] feed)