Development Hell’ 2: Electric Boogaloo
Hang in there!
This one gets a tad more complex —
Designated System.Math for non-game-specific, Unity.Mathemathics for ECS-specific, and UnityEngine.Mathf for game-specific mathematics
Refactored LoadURI*(…) utilities
Shimmed init
Shimmed System.HashCode
Kept on digging at the C# core (not .NET) and yet left seeking more all the same. Must be a pretty good programming language or something…
If anything the hard part those two days was figuring out asynchronous programming with the LoadURI*(…) feature there. Lots on unexpected re-entrancies and desired idempotencies with that one, especially when considering multiple threads and caching.
“Why does it even exist as a feature?”
Maybe it’s time to consider the “why not?”
…
Nah, just kidding. It’s just for hot-loading assets stored with the game at runtime instead of build-time.
Basically, even if it got the job done, a singleton class holding a record to all a game’s assets didn’t sit right with me (and UnityEngine.Application.streamingAssetsPath seems to agree with me on that). Problem is, like with all things Unity, there’s many ways to mess it up
Developed Mono<T> structure for monostate (localized singleton) variables (imagine having static locals /s)
Developed Ref*Dictionary<…>, and Ref*List<T> classes to allow in-place value-type modification of dictionary/ list elements
Optimized out System.Array bounds-checking with ArrayReference*(…) utilities instead of ref array[index] (no segmentation faults here, no siree)
Shimmed System.Index, System.Range, and collection expressions
Use smaller-scale test Unity project to test smaller scale code i.e.
public static class Program {
[UnityEngine.RuntimeInitializeOnLoadMethod] // ::BeforeSceneLoad
private static void Main() => new UnityEngine.GameObject("…", typeof(MyMonoBehaviour));
}
Pretty neat idea for troubleshooting things when the codebase gets too large. Question is, though: “Why is the codebase so large for a this scale of project?” 👀
Speaking of over-engineered:
Is there an official one or it’s a historical mess at this point
Because I kid you not, it was easier to understand the ramblings of insane folks over at Unity Discussions and off-the-cuff platforms like ChatGPT or Reddit than to read whatever descriptions or explanations was overly engineered over there… engineer.
Added Event::epoch property to track initial time of signaling
Added Event::metadata field to store call-site arguments
Added ToString() method overrides to PatchOdyssey.Collections structures
Extended TrimExcess(uint) method for RefList<T> (and similar like SharedList<T>) classes
Sadly, all these except ToString() didn’t end up getting used to fruition, and the exception was only excess print debugging — which also got out of hand toward the end
Refactored Animation.UISequence from an internal System.Collections.ObjectModel.ReadOnlyDictionary<string, object?> to an internal System.Collections.Specialized.ListDictionary
EfFiCiEnCy
Maybe I should in more software-critical fields, like big finance or the military…? 🚀
Developed PatchOdyssey.Traits namespace for basic generic metaprogramming
Disregarded some null checks — responsibility is on the user’s end
Extended Fill(…) method for RefList<T>, System.*.IList<T>, and others
Extended TryAppend(…) method for RefList<T>, System.*.IList<T>, and others
Renamed Editor*DictionaryDrawer<…> to Ref*DictionaryDrawer<…>
Lots of refactoring, especially for Unity’s lack of System.Runtime.CompilerServices.Unsafe.Add(…) method
This was quite to refactor one’s entire codebase around, especially when it was built on the assumption of a standard .NET feature existing. Understandable why this wouldn’t be snooping around in the Unity engine given its audience, but man, does it feel needlessly restrictive as a low-level programmer. “Everything’s just an array of bytes, n’ah mean?” 💅🏾
So in all this, you might notice there’s a lot more PatchOdyssey than Patch Odyssey (the game), right?
Is it still foreshadowing when the reveal’s just out there? Onto the next scene of the crime