TaleSpire Dev Log 498

Heya folks,

Busy week so far.

Monday was mainly spent on getting things compiling again in the effect system project. With that done, I got to fixing the logic bugs from the massive refactoring.

This is going well and, other than having to spend hours wrestling with Unity in order to get the editor behaviour we want[1], things look good. The next step (and what I'll be doing today) is to keep working on the effect-driver (the monobehaviour that runs an instance of a specific effect). More specifically, I need to add the code that saves any user changes of the uniforms (a kind of information passed to the GPU code running the effect) back to the driver object. Shouldn't be hard, just needs doing.

Yesterday though, I had to take the car in for repairs and wait in town most of the day while they worked on it. This meant I couldn't work on the particle system easily, but it was a great time for design work.

One of the upcoming engine internals projects I have is revisiting how I define systems in TaleSpire. This is not something that is visible to players, it's all about how we structure the code and how easy it is for us to make changes. When I joined the team, I was not that experienced with Unity, and so TaleSpire is where I've made every mistake as I've gotten better. There are plenty of places in the code where it shows!
The new approach I've sketched out should massively reduce coupling between systems and (hopefully) make it much easier for us to make test scenes which only use a few systems.

This is not all for pretty code, and good feels though. A much bigger part of this is exposing more of Unity's low-level features (custom frame loop, burst compiled functions) in a way that feels natural to Unity devs. Unity's job-system is very cool, but they have not made it feel at home in Unity. By taking explicit control of the order things are happening in the frame, and moving more work across threads, we should be able to improve performance in ways that haven't been feasible before now.

All that is big picture though. The work to get there is far more down-to-earth :). Yesterday I worked out and prototyped the Unity Editor UI that lets devs pick the callback methods for frame events, both for Burst compiled callback handlers and standard C# ones. I've still got to experiment with Burst compiled function pointers to see what restrictions they have. Some of them are non-obvious and often only lightly documented.

Well, that's all from me today. Hope you are having a good one.

Peace.


[1] Normally, you subclass Unity.Editor and make custom editors in Unity, which is fine. But when you have a custom file type you use an asset-importer to bring it into Unity's scriptable-object format, fine. But if you define a custom editor for that imported type, the UI elements are disabled. Ugh. So, as a hack, you use `GUI.enable = true` and they work again...fine, I guess. But then you use a PropertyField in order to get a custom property-drawer you defined for some serializable class, and that is disabled, and the hack doesn't work. Balls.

But there is asset-importer-editor, great. But this is for making a custom editors for the importer, the same issue as above still holds. In the end, I worked around it as the core info that is important in my custom asset is contained, so I copy that object, modify it, and apply it back to the scriptable-object wholesale. It works but man, it wasn't fun.

Tips welcome :P