The Joint AssetIO Framework is Born

General discussion pertaining to Elysian Shadows, ESTk, ESGamma, and the Adventures in Game Development series.

Moderators: News Mods, Elysian Shadows Team

The Joint AssetIO Framework is Born

Postby dandymcgee on Wed Aug 01, 2012 8:22 pm

Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches! :twisted:
User avatar
dandymcgee
ES Beta Backer
ES Beta Backer
 
Posts: 4911
Joined: Tue Apr 29, 2008 4:24 pm
Location: New Hampshire

Re: The Joint AssetIO Framework is Born

Postby Falco Girgis on Thu Aug 02, 2012 12:45 pm

This is definitely a rape post that is very close to my heart...

This was after we had finally decided to scrap the BlitzPlus level editor in favor of a QT-based Toolkit written in C++. We wanted to open up Toolkit development to the whole software team, because Marcel being the only person to know BlitzPlus previously was a complete pain in the ass.

I quickly realized that as far as Assets were concerned, the Engine and Toolkit were two sides of the same coin... The Engine needs to load the assets that the Toolkit saves and loads. It made quite a bit of sense to share this code between the two. This region of shared code became known as the "Joint AssetIO Framework." To this day, it was still a fantastic idea. Since the Engine and Toolkit share Asset code, managing, instantiating, loading, saving, and manipulating entities, data, terrain, etc is identical with the two. The same code also gets the living shit tested out of it, because it is being run in a Toolkit on Windows, Linux, and OSX and in the Engine on the same platforms plus the Dreamcast and PSP.

Over the years, my vision for the LibGyro framework has definitely changed, which slightly outdates the diagram that I drew. The original LibGyro was a series of C++ interfaces with a different implementation on each platform. As I grew as a developer, I came to realize that using runtime polymorphism like that (virtual functions) to implement system-level calls was a terrible idea. Not only that, but there was only ever one implementation instantiated at a time (you can't have a Dreamcast rendering system and an OpenGL rendering system simultaneously), so the design seemed even more bloated...

Another huge contributing factor was actually the design constraints imposed upon the application code by having a fully object-oriented API. You force the users to use your data structures and maintain a preestablished relationship between objects... As I became a more seasoned C developer, I came to appreciate the kind of simple elegance offered by a well-designed C API. It really frees application code from any design obligations by the lower level. Does OpenGL force you to implement a quad class in a particular way? Absolutely not. It only gives a shit about the lowest level of data required to hand off to your GPU. You are free to structure your engine as you please... So anyway, LibGyro is now a C API. I am much happier with it these days...

The only other large change to the AssetIO is the engine/toolkit inheritance paradigm for components. It honestly was a great idea... It made sense. The Toolkit only needed to know about "static attributes" of each component, while the engine needed both static and dynamic attributes... For example, the Toolkit would only need to know about things like moment of inertia, mass, size, and geometry for a RigidBody component. The engine needs to know all of this and "runtime" attributes like the RigidBody's current velocity, acceleration, and rotation. The hierarchial approach seemed very reasonable...

But over time this separation grew to be a pain in the ass... You will notice that there are still some preprocessor directives required for allowing both the Engine and Toolkit to refer to their separate levels of components ("RigidBody" vs "EditorRigidBody") as simply "RigidBody." It also required some preprocessor bullshit for the instantiation of these objects, as the Toolkit would instantiate them at the editor level of specificity and the engine would instantiate them at a different level... This design was originally created to avoid messy #ifdef ENGINE/TOOLKIT preprocessor directives, but it ultimately still wound up using them. In the end it simply made more sense to have a single layer of specification with preprocessor directives around engine-only attributes than it did to have BOTH multiple layers of specification and preprocessor directives...

This was a great example of an OO design sounding awesome and elegant on paper but winding up convoluted and cumbersome once implemented... It's the kind of thing that you can't really estimate while you're at a whiteboard. You just have to work with the code over time to realize how reested it is...
"So what happens if the Elysian Shadows Kickstarter fails?"
Image
User avatar
Falco Girgis
Elysian Shadows Team
Elysian Shadows Team
 
Posts: 10693
Joined: Thu May 20, 2004 3:04 pm
Location: Studio Vorbis, AL

Re: The Joint AssetIO Framework is Born

Postby dandymcgee on Sun Aug 12, 2012 5:13 pm

This was definitely a turning part for the engine-toolkit architecture relationship. Although this decision was made over two years ago now, we are still reaping the benefits of code reuse.
Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches! :twisted:
User avatar
dandymcgee
ES Beta Backer
ES Beta Backer
 
Posts: 4911
Joined: Tue Apr 29, 2008 4:24 pm
Location: New Hampshire


Return to Elysian Shadows Discussion

Who is online

Users browsing this forum: No registered users and 1 guest