Maybe a new beginning?
So! Here it is:
Everything I worked on to reach Patch Odyssey’s current state.
Configured C# from the .NET 10 runtime to the Unity’s Preview C# version i.e. /langversion:preview
Extended AddRange(…) method for EditorDictionary<…>, EditorReadOnlyDictionary<…> and System.*.IDictionary<…> types
Extended TryAdd(…) method for EditorDictionary<…>, EditorReadOnlyDictionary<…> and System.*.IDictionary<…> types
Implemented EditorDictionary<…> using System.*.IReadOnlyDictionary<…>?
Preferred user-defined delegates (e.g. Interpolator, RefAction, …) to work alongside standard System.Delegates (e.g. System.Func)
Shimmed required keyword
Getting my hands in deeper with C#’s uniqueness. I really just wanted to be able to edit struct — *unmanaged game data types — in-place instead of having to defer to classes (or really just admit defeat)
Was starting to get into the groove of C# scripting in the Unity Editor. Can say I’m a bit over “intermediate” level-experienced with it
Quite experienced with Unity, indeed :)
Developed PatchOdyssey.Util.HandlerInfo for handling events e.g. Load*(…), Wait*(…), …, e.t.c. like a fat delegate with additional data
Supplemented event properties with PatchOdyssey.Collections.EventHandler class — supporting System.Delegate invocation lists, operator overloads, …, e.t.c.
Supplemented System.EventArgs with PatchOdyssey.Collections.Event generic
At this point, I was able to get up and running to where I was with the older prototype.
Things were looking up, and it was actually fun to work on the Final Major Project for awhile. Plus, I can say it felt good to not necessarily have to using UnityEngine right before 20 lines of other dependent imports come after. “Which Math is it? I don’t know. It could be me, it could be you, it could be System.Unity.UnityEngine.Math.Mathematics.Mathf”
Not to worry by the way, we got photographic evidence for proof-of-work 📸
— or video evidence if the image takes forever to load: Event system in Unity
Attributed constructors as setting required members i.e. [PatchConstructor]
Refactored Wait*(…) and Util.WaitForTimer*(…) utilities
A [PatchConstructor] to go alongside your [PatchMethod(…)] (remember that?)
Essentially, it was at this point just a way to quieten down the very talkative C# compiler about my inexperienced misunderstanding of how convenient the required feature is supposed to be. Alright, I couldn’t have worded that any less biased but C# definitely doesn’t hold back with some of its weirder edge-cases e.g. new MyRequired {requiredField = …} doesn’t work, even when the user explicitly instantiates it (albeit after construction)
The next one’s just plain ol’ refactoring. Can’t re-invent wheels without spinning in circles (I joke, I joke, … or do I?)
Developed Util.WaitForCoroutine*(…) utilities
Learned Unity’s Entity Component System (ECS) feature using their Data-Oriented Technology Stack (DOTS) — https://www.youtube.com/watch?v=1gSnTlUjs-s (thank you, @CodeMonkeyUnity)
Learning about UnityEngine.WaitForSecondsRealtime(…) was fun and all, but damn does it hurt!
It hurts that I didn’t carve out the time to implement what Mr. Cardoso taught here on the Internet for free, even if it wasn’t the entire lecture, just this tutorial alone was plenty.
Reason I considered using Unity’s newfangled system instead of just spamming UnityEngine.GameObjects everywhere was because I had begun to develop doubt about the efficacy of my work making prototypes in Unity. Each one seeming to perform and run more slowly than the last, so this kinda was just a desperate to crank out some extra perf—
And there he goes again about with premature optimization without even testing a release version of a working draft of a vertical slice of a prototype! My only excuse? It’s not a good one, but I can tell you that constant iterative development on Unity sucks, especially when one gaslights themselves that 15-second wait times before thinking of a design change and seeing it implemented is part of a broader culture that accepts increasingly, well… less than capable software.
That’s a different topic on the other hand, maybe some other I’ll get to give Unity.Entities a fair shot. Certainly seemed more worthwhile than avoiding the (pedantic) trappings of UnityEngine.MonoBehaviours like caching their .transform member.
Refactored EventHandler<T>, HandlerInfo<T>, and other associated code —
— For the umpteenth time if we’re being honest. No big deal, that dogged pursuit of quality got us this far, let’s see how much further it gets us.