Runtime Reflection and U(C)
There’s a certain beauty about runtime reflection. It’s not a reflection of our faces, so that’s probably part of it, but the dynamics and convenience it enables really stand out in all that gloss. If you can keep it to non-critical systems, where performance isn’t too much of a concern or frequency of use is relatively low, it’s a great tool to have!
Runtime reflection, for those curious, is the ability to get information about your code while it’s running. Variable names, class layouts, function signatures, figuring out which class an object REALLY is, etc... You reflect upon your self~ at run time. Depending on what language you’re coming from, this probably sounds like the norm. Unfortunately, I hail from the lands of low-level pretentiousness where this type of thing is sorely frowned upon for the sake of frowning (plus a bad first attempt), but I digress.
At my day job, I work in Unreal Engine 3. This old iteration of the now-famous game dev suite pushed its own scripting language, UnrealScript (UC), to ease gameplay development and support complex systems with simple keywords, automatic memory cleanup, and language-level features. It’s pretty cool, despite being a total mess and the worst. BUT it does provide one key thing: reflection! AND we can access this runtime reflection FROM C++!!! Which conveniently works hand-in-hand with UC.
So... We also work with this thing called Scaleform, which is the abysmal love-child of Adobe and Autodesk that puts Flash in games to use for user interfaces. THAT runs on Adobe’s language, ActionScript (AS). It’s like JavaScript, but somehow worse.
It has so many issues... Like the fact that there’s no project management, so whichever version of a script happens to load first is the one the game uses, even if it’s old. There’s no viable debugger for Scaleform, so you have to rely on old-school output logs to track issues down. Changing anything in Actionscript requires updating an Unreal package, which means it has to be processed for various test cases, doesn’t play well with source control, etc.. Not a fan...
And?.. What does that have to do with Reflection?
It all relates, promise! I despise the whole Scaleform process. ActionScript is workable, but everything around it and how it impacts our process really gets to me..
With C++ reflection of UnrealScript classes, we can subvert ActionScript in favor of UnrealScript and C++! Well, we could do that regardless, but this makes it way more convenient than having to manually setup the code for our scene to associate Flash objects with class members.
See, I made a base class (named FlashNativeWidget) that is associated with a Flash display object on creation. After creation, it uses reflection to check what object member variables it has; if there are any members that have flash object classes, it tries to get them from Flash by matching the variable name to display object sub-elements. ActionScript does this already- variables will auto-attach to objects in Flash that have the same name, so pulling this convenience up to C++ means that’s one less reason to use AS!
The nice thing about this reflection is that anything that inherits from that base class will just work with its logic. Any new member objects that they add will automatically try to associate with display sub elements because it’s reflecting over the most derived class’s members.
Previously, we would have to manually try to set up those associations on create, which lead to people being understandably resistant to the verbose mess needed to have multiple UC/C++ classes in a single Flash object. This resulted in what’re called “super classes”, which are massive chunks of code that, scientifically speaking, do way too damn much... Now, it’s just as easy as AS (maybe slightly easier) to associate with multiple classes, so hopefully we won’t get super classes as much (UC has it’s own headaches that contribute here, another talk).
Is that all? What’s Next?
It’s far from perfect, and far from ready to replace ActionScript. The real issue is that the game is so old that most of our controls / systems are AS-centered, so those will need to be transitioned over time. BUT being able to reflectively bind UC/C++ to Flash is a major win that’ll make the transition that much easier.
My next big plan with Reflection is to allow nested binding, where you can go into sub-elements of sub-elements without the need for an entire other class or manual load code. In previous C++-centric Flash scenarios this was a common occurrence, and provided the bulk of verbosity. Sometimes you just want to skip containers and get their children. I’m thinking about using data-only structures, where variables of struct types with Flash object members are treated as skipped containers and the members get populated. While the struct setup might be weird, it’ll make the access code mirror the scene layout, which can be great for logic!
Maybe after that, auto-bind lists of objects with dynamic arrays? Hmmm... The potential! I’m probably going overboard xD Time will tell
Will post an update on how poorly this goes, eventually~. Please drop any Reflection-to-the-Rescue’esque stories in reblogs / replies in the meantime!
dailybridgerton
vaporwave
origamiaround
baratheonpilled
blakekathryn
titsay
stormborns
snowghoul
kianamaiart
kaledo-art