Jump to content
  • Advertisement
  • entries
    3
  • comments
    66
  • views
    5463

OOP is dead, long live OOP

Hodgman

68858 views

edit:

Seeing this has been linked outside of game-development circles: "ECS" (this wikipedia page is garbage, btw -- it conflates EC-frameworks and ECS-frameworks, which aren't the same...) is a faux-pattern circulated within game-dev communities, which is basically a version of the relational model, where "entities" are just ID's that represent a formless object, "components" are rows in specific tables that reference an ID, and "systems" are procedural code that can modify the components. This "pattern" is always posed as a solution to an over-use of inheritance, without mentioning that an over-use of inheritance is actually bad under OOP guidelines. Hence the rant. This isn't the "one true way" to write software. It's getting people to actually look at existing design guidelines.

Inspiration

This blog post is inspired by Aras Pranckevičius' recent publication of a talk aimed at junior programmers, designed to get them to come to terms with new "ECS" architectures. Aras follows the typical pattern (explained below), where he shows some terrible OOP code and then shows that the relational model is a great alternative solution (but calls it "ECS" instead of relational). This is not a swipe at Aras at all - I'm a fan of his work and commend him on the great presentation! The reason I'm picking on his presentation in particular instead of the hundred other ECS posts that have been made on the interwebs, is because he's gone through the effort of actually publishing a git repository to go along with his presentation, which contains a simple little "game" as a playground for demonstrating different architecture choices. This tiny project makes it easy for me to actually, concretely demonstrate my points, so, thanks Aras!

You can find Aras'  slides at http://aras-p.info/texts/files/2018Academy - ECS-DoD.pdf and the code at https://github.com/aras-p/dod-playground.

I'm not going to analyse the final ECS architecture from that talk (yet?), but I'm going to focus on the straw-man "bad OOP" code from the start. I'll show what it would look like if we actually fix all of the OOD rule violations.
Spoiler: fixing the OOD violations actually results in a similar performance improvement to Aras' ECS conversion, plus it actually uses less RAM and requires less lines of code than the ECS version!
TL;DR: Before you decide that OOP is shit and ECS is great, stop and learn OOD (to know how to use OOP properly) and learn relational (to know how to use ECS properly too).

I've been a long-time ranter in many "ECS" threads on the forum, partly because I don't think it deserves to exist as a term (spoiler: it's just a an ad-hoc version of the relational model), but because almost every single blog, presentation, or article that promotes the "ECS" pattern follows the same structure:

  1. Show some terrible OOP code, which has a terribly flawed design based on an over-use of inheritance (and incidentally, a design that breaks many OOD rules).
  2. Show that composition is a better solution than inheritance (and don't mention that OOD actually teaches this same lesson).
  3. Show that the relational model is a great fit for games (but call it "ECS").

This structure grinds my gears because:
(A) it's a straw-man argument.. it's apples to oranges (bad code vs good code)... which just feels dishonest, even if it's unintentional and not actually required to show that your new architecture is good,
but more importantly:
(B) it has the side effect of suppressing knowledge and unintentionally discouraging readers from interacting with half a century of existing research. The relational model was first written about in the 1960's. Through the 70's and 80's this model was refined extensively. There's common beginners questions like "which class should I put this data in?", which is often answered in vague terms like "you just need to gain experience and you'll know by feel"... but in the 70's this question was extensively pondered and solved in the general case in formal terms; it's called database normalization. By ignoring existing research and presenting ECS as a completely new and novel solution, you're hiding this knowledge from new programmers.

Object oriented programming dates back just as far, if not further (work in the 1950's began to explore the style)! However, it was in the 1990's that OO became a fad - hyped, viral and very quickly, the dominant programming paradigm. A slew of new OO languages exploded in popularity including Java and (the standardized version of) C++. However, because it was a hype-train, everyone needed to know this new buzzword to put on their resume, yet no one really groked it. These new languages had added a lot of OO features as keywords -- class, virtual, extends, implements -- and I would argue that it's at this point that OO split into two distinct entities with a life of their own.
I will refer to the use of these OO-inspired language features as "OOP", and the use of OO-inspired design/architecture techniques as "OOD". Everyone picked up OOP very quickly. Schools taught OO classes that were efficient at churning out new OOP programmers.... yet knowledge of OOD lagged behind.

I argue that code that uses OOP language features, but does not follow OOD design rules is not OO code. Most anti-OOP rants are eviscerating code that is not actually OO code.
OOP code has a very bad reputation, I assert in part due to the fact that, most OOP code does not follow OOD rules, thus isn't actually "true" OO code.

Background

As mentioned above, the 1990's was the peak of the "OO fad", and it's during this time that "bad OOP" was probably at its worst. If you studied OOP during this time, you probably learned "The 4 pillars of OOP":

  • Abstraction
  • Encapsulation
  • Polymorphism
  • Inheritance

I'd prefer to call these "4 tools of OOP" rather than 4 pillars. These are tools that you can use to solve problems. Simply learning how a tool works is not enough though, you need to know when you should be using them... It's irresponsible for educators to teach people a new tool without also teaching them when it's appropriate to use each of them.  In the early 2000's, there was a push-back against the rampant misuse of these tools, a kind of second-wave of OOD thought. Out of this came the SOLID mnemonic to use as a quick way to evaluate a design's strength. Note that most of these bits of advice were well actually widely circulated in the 90's, but didn't yet have the cool acronym to cement them as the five core rules...

  • Single responsibility principle. Every class should have one reason to change. If class "A" has two responsibilities, create a new class "B" and "C" to handle each of them in isolation, and then compose "A" out of "B" and "C".
  • Open/closed principle. Software changes over time (i.e. maintenance is important). Try to put the parts that are likely to change into implementations (i.e. concrete classes) and build interfaces around the parts that are unlikely to change (e.g. abstract base classes).
  • Liskov substitution principle. Every implementation of an interface needs to 100% comply the requirements of that interface. i.e. any algorithm that works on the interface, should continue to work for every implementation.
  • Interface segregation principle. Keep interfaces as small as possible, in order to ensure that each part of the code "knows about" the least amount of the code-base as possible. i.e. avoid unnecessary dependencies. This is also just good advice in C++ where compile times suck if you don't follow this advice :D 
  • Dependency inversion principle. Instead of having two concrete implementations communicate directly (and depend on each other), they can usually be decoupled by formalizing their communication interface as a third class that acts as an interface between them. This could be an abstract base class that defines the method calls used between them, or even just a POD struct that defines the data passed between them.
  • Not included in the SOLID acronym, but I would argue is just as important is the:
    Composite reuse principle. Composition is the right default™. Inheritance should be reserved for use when it's absolutely required.

This gives us SOLID-C(++) :) 

From now on, I'll refer to these by their three letter acronyms -- SRP, OCP, LSP, ISP, DIP, CRP...

A few other notes:

  • In OOD, interfaces and implementations are ideas that don't map to any specific OOP keywords. In C++, we often create interfaces with abstract base classes and virtual functions, and then implementations inherit from those base classes... but that is just one specific way to achieve the idea of an interface. In C++, we can also use PIMPL, opaque pointers, duck typing, typedefs, etc... You can create an OOD design and then implement it in C, where there aren't any OOP language keywords! So when I'm talking about interfaces here, I'm not necessarily talking about virtual functions -- I'm talking about the idea of implementation hiding. Interfaces can be polymorphic, but most often they are not! A good use for polymorphism is rare, but interfaces are fundamental to all software.
    • As hinted above, if you create a POD structure that simply stores some data to be passed from one class to another, then that struct is acting as an interface - it is a formal data definition.
    • Even if you just make a single class in isolation with a public and a private section, everything in the public section is the interface and everything in the private section is the implementation.
  • Inheritance actually has (at least) two types -- interface inheritance, and implementation inheritance.
    • In C++, interface inheritance includes abstract-base-classes with pure-virtual functions, PIMPL, conditional typedefs. In Java, interface inheritance is expressed with the implements keyword.
    • In C++, implementation inheritance occurs any time a base classes contains anything besides pure-virtual functions. In Java, implementation inheritance is expressed with the extends keyword.
    • OOD has a lot to say about interface-inheritance, but implementation-inheritance should usually be treated as a bit of a code smell!

And lastly I should probably give a few examples of terrible OOP education and how it results in bad code in the wild (and OOP's bad reputation).

  1. When you were learning about hierarchies / inheritance, you probably had a task something like:
    Let's say you have a university app that contains a directory of Students and Staff. We can make a Person base class, and then a Student class and a Staff class that inherit from Person!
    Nope, nope nope. Let me stop you there. The unspoken sub-text beneath the LSP is that class-hierarchies and the algorithms that operate on them are symbiotic. They're two halves of a whole program. OOP is an extension of procedural programming, and it's still mainly about those procedures. If we don't know what kinds of algorithms are going to be operating on Students and Staff (and which algorithms would be simplified by polymorphism) then it's downright irresponsible to dive in and start designing class hierarchies. You have to know the algorithms and the data first.
  2. When you were learning about hierarchies / inheritance, you probably had a task something like:
    Let's say you have a shape class. We could also have squares and rectangles as sub-classes. Should we have square is-a rectangle, or rectangle is-a square?
    This is actually a good one to demonstrate the difference between implementation-inheritance and interface-inheritance.
    • If you're using the implementation-inheritance mindset, then the LSP isn't on your mind at all and you're only thinking practically about trying to reuse code using inheritance as a tool.
      From this perspective, the following makes perfect sense:
      struct Square { int width; }; struct Rectangle : Square { int height; };
      A square just has width, while rectangle has a width + height, so extending the square with a height member gives us a rectangle!
      • As you might have guessed, OOD says that doing this is (probably) wrong. I say probably because you can argue over the implied specifications of the interface here... but whatever.
        A square always has the same height as its width, so from the square's interface, it's completely valid to assume that its area is "width * width".
        By inheriting from square, the rectangle class (according to the LSP) must obey the rules of square's interface. Any algorithm that works correctly with a square, must also work correctly with a rectangle.
      • Take the following algorithm: std::vector<Square*> shapes; int area = 0; for(auto s : shapes) area += s->width * s->width;
        This will work correctly for squares (producing the sum of their areas), but will not work for rectangles.
        Therefore, Rectangle violates the LSP rule.
    • If you're using the interface-inheritance mindset, then neither Square or Rectangle will inherit from each other. The interface for a square and rectangle are actually different, and one is not a super-set of the other.
    • So OOD actually discourages the use of implementation-inheritance. As mentioned before, if you want to re-use code, OOD says that composition is the right way to go!
      • For what it's worth though, the correct version of the above (bad) implementation-inheritance hierarchy code in C++ is:
        struct Shape { virtual int area() const = 0; };
        struct Square : public virtual Shape { virtual int area() const { return width * width; }; int width; };
        struct Rectangle : private Square, public virtual Shape { virtual int area() const { return width * height; }; int height; };
        • "public virtual" means "implements" in Java. For use when implementing an interface.
        • "private" allows you to extend a base class without also inheriting its interface -- in this case, Rectangle is-not-a Square, even though it's inherited from it.
      • I don't recommend writing this kind of code, but if you do like to use implementation-inheritance, this is the way that you're supposed to be doing it!

TL;DR - your OOP class told you what inheritance was. Your missing OOD class should have told you not to use it 99% of the time!

Entity / Component frameworks

With all that background out of the way, let's jump into Aras' starting point -- the so called "typical OOP" starting point.
Actually, one last gripe -- Aras calls this code "traditional OOP", which I object to. This code may be typical of OOP in the wild, but as above, it breaks all sorts of core OO rules, so it should not all all be considered traditional.

I'm going to start from the earliest commit before he starts fixing the design towards "ECS": "Make it work on Windows again" 3529f232510c95f53112bbfff87df6bbc6aa1fae

// -------------------------------------------------------------------------------------------------
// super simple "component system"

class GameObject;
class Component;

typedef std::vector<Component*> ComponentVector;
typedef std::vector<GameObject*> GameObjectVector;


// Component base class. Knows about the parent game object, and has some virtual methods.
class Component
{
public:
    Component() : m_GameObject(nullptr) {}
    virtual ~Component() {}
    
    virtual void Start() {}
    virtual void Update(double time, float deltaTime) {}

    const GameObject& GetGameObject() const { return *m_GameObject; }
    GameObject& GetGameObject() { return *m_GameObject; }
    void SetGameObject(GameObject& go) { m_GameObject = &go; }
    bool HasGameObject() const { return m_GameObject != nullptr; }

private:
    GameObject* m_GameObject;
};


// Game object class. Has an array of components.
class GameObject
{
public:
    GameObject(const std::string&& name) : m_Name(name) { }
    ~GameObject()
    {
        // game object owns the components; destroy them when deleting the game object
        for (auto c : m_Components) delete c;
    }

    // get a component of type T, or null if it does not exist on this game object
    template<typename T>
    T* GetComponent()
    {
        for (auto i : m_Components)
        {
            T* c = dynamic_cast<T*>(i);
            if (c != nullptr)
                return c;
        }
        return nullptr;
    }

    // add a new component to this game object
    void AddComponent(Component* c)
    {
        assert(!c->HasGameObject());
        c->SetGameObject(*this);
        m_Components.emplace_back(c);
    }
    
    void Start() { for (auto c : m_Components) c->Start(); }
    void Update(double time, float deltaTime) { for (auto c : m_Components) c->Update(time, deltaTime); }
    
private:
    std::string m_Name;
    ComponentVector m_Components;
};

// The "scene": array of game objects.
static GameObjectVector s_Objects;


// Finds all components of given type in the whole scene
template<typename T>
static ComponentVector FindAllComponentsOfType()
{
    ComponentVector res;
    for (auto go : s_Objects)
    {
        T* c = go->GetComponent<T>();
        if (c != nullptr)
            res.emplace_back(c);
    }
    return res;
}

// Find one component of given type in the scene (returns first found one)
template<typename T>
static T* FindOfType()
{
    for (auto go : s_Objects)
    {
        T* c = go->GetComponent<T>();
        if (c != nullptr)
            return c;
    }
    return nullptr;
}

Ok, 100 lines of code is a lot to dump at once, so let's work through what this is... Another bit of background is required -- it was popular for games in the 90's to use inheritance to solve all their code re-use problems. You'd have an Entity, extended by Character, extended by Player and Monster, etc... This is implementation-inheritance, as described earlier (a code smell), and it seems like a good idea to begin with, but eventually results in a very inflexible code-base. Hence that OOD has the "composition over inheritance" rule, above. So, in the 2000's the "composition over inheritance" rule became popular, and gamedevs started writing this kind of code instead.

What does this code do? Well, nothing good :D 

To put it in simple terms, this code is re-implementing the existing language feature of composition as a runtime library instead of a language feature. You can think of it as if this code is actually constructing a new meta-language on top of C++, and a VM to run that meta-language on. In Aras' demo game, this code is not required (we'll soon delete all of it!) and only serves to reduce the game's performance by about 10x.

What does it actually do though? This is an "Entity/Component" framework (sometimes confusingly called an "Entity/Component system") -- but completely different to an "Entity Component System" framework (which are never called "Entity Component System systems" for obvious reasons). It formalizes several "EC" rules:

  • the game will be built out of featureless "Entities" (called GameObjects in this example), which themselves are composed out of "Components".
  • GameObjects fulfill the service locator pattern -  they can be queried for a child component by type. 
  • Components know which GameObject they belong to - they can locate sibling componets by querying their parent GameObject.
  • Composition may only be one level deep (Components may not own child components, GameObjects may not own child GameObjects).
  • A GameObject may only have one component of each type (some frameworks enforced this, others did not).
  • Every component (probably) changes over time in some unspecified way - so the interface includes "virtual void Update".
  • GameObjects belong to a scene, which can perform queries over all GameObjects (and thus also over all Components).

This kind of framework was very popular in the 2000's, and though restrictive, proved flexible enough to power countless numbers of games from that time and still today.

However, it's not required. Your programming language already contains support for composition as a language feature - you don't need a bloated framework to access it... Why do these frameworks exist then? Well to be fair, they enable dynamic, runtime composition. Instead of GameObject types being hard-coded, they can be loaded from data files. This is great to allow game/level designers to create their own kinds of objects... However, in most game projects, you have a very small number of designers on a project and a literal army of programmers, so I would argue it's not a key feature. Worse than that though, it's not even the only way that you could implement runtime composition! For example, Unity is based on C# as a "scripting language", and many other games use alternatives such as Lua -- your designer-friendly tool can generate C#/Lua code to define new game-objects, without the need for this kind of bloated framework! We'll re-add this "feature" in a later follow-up post, in a way that doesn't cost us a 10x performance overhead...

Let's evaluate this code according to OOD:

  • GameObject::GetComponent uses dynamic_cast. Most people will tell you that dynamic_cast is a code smell - a strong hint that something is wrong. I would say that it indicates that you have an LSP violation on your hands -- you have some algorithm that's operating on the base interface, but it demands to know about different implementation details. That's the specific reason that it smells.
  • GameObject is kind of ok if you imagine that it's fulfilling the service locator pattern.... but going beyond OOD critique for a moment, this pattern creates implicit links between parts of the project, and I feel (without a wikipedia link to back me up with comp-sci knowledge) that implicit communication channels are an anti-pattern and explicit communication channels should be preferred. This same argument applies to bloated "event frameworks" that sometimes appear in games...
  • I would argue that Component is a SRP violation because its interface (virtual void Update(time)) is too broad. The use of "virtual void Update" is pervasive within game development, but I'd also say that it is an anti-pattern. Good software should allow you to easily reason about the flow of control, and the flow of data. Putting every single bit of gameplay code behind a "virtual void Update" call completely and utterly obfuscates both the flow of control and the flow of data. IMHO, invisible side effects, a.k.a. action at a distance, is the most common source of bugs, and "virtual void Update" ensures that almost everything is an invisible side-effect.
  • Even though the goal of the Component class is to enable composition, it's doing so via inheritance, which is a CRP violation.
  • The one good part is that the example game code is bending over backwards to fulfill the SRP and ISP rules -- it's split into a large number of simple components with very small responsibilities, which is great for code re-use.
    However, it's not great as DIP -- many of the components do have direct knowledge of each other.

So, all of the code that I've posted above, can actually just be deleted. That whole framework. Delete GameObject (aka Entity in other frameworks), delete Component, delete FindOfType. It's all part of a useless VM that's breaking OOD rules and making our game terribly slow.

Frameworkless composition (AKA using the features of the #*@!ing programming language)

If we delete our composition framework, and don't have a Component base class, how will our GameObjects manage to use composition and be built out of Components. As hinted in the heading, instead of writing that bloated VM and then writing our GameObjects on top of it in our weird meta-language, let's just write them in C++ because we're #*@!ing game programmers and that's literally our job.

Here's the commit where the Entity/Component framework is deleted: https://github.com/hodgman/dod-playground/commit/f42290d0217d700dea2ed002f2f3b1dc45e8c27c
Here's the original version of the source code: https://github.com/hodgman/dod-playground/blob/3529f232510c95f53112bbfff87df6bbc6aa1fae/source/game.cpp
Here's the modified version of the source code: https://github.com/hodgman/dod-playground/blob/f42290d0217d700dea2ed002f2f3b1dc45e8c27c/source/game.cpp

The gist of the changes is:

  • Removing ": public Component" from each component type.
  • I add a constructor to each component type.
    • OOD is about encapsulating the state of a class, but since these classes are so small/simple, there's not much to hide -- the interface is a data description. However, one of the main reasons that encapsulation is a core pillar is that it allows us to ensure that class invariants are always true... or in the event that an invariant is violated, you hopefully only need to inspect the encapsulated implementation code in order to find your bug. In this example code, it's worth us adding the constructors to enforce a simple invariant -- all values must be initialized.
  • I rename the overly generic "Update" methods to reflect what they actually do -- UpdatePosition for MoveComponent and ResolveCollisions for AvoidComponent.
  • I remove the three hard-coded blocks of code that resemble a template/prefab -- code that creates a GameObject containing specific Component types, and replace it with three C++ classes.
  • Fix the "virtual void Update" anti-pattern.
  • Instead of components finding each other via the service locator pattern, the game objects explicitly link them together during construction.

The objects

So, instead of this "VM" code:

    // create regular objects that move
    for (auto i = 0; i < kObjectCount; ++i)
    {
        GameObject* go = new GameObject("object");

        // position it within world bounds
        PositionComponent* pos = new PositionComponent();
        pos->x = RandomFloat(bounds->xMin, bounds->xMax);
        pos->y = RandomFloat(bounds->yMin, bounds->yMax);
        go->AddComponent(pos);

        // setup a sprite for it (random sprite index from first 5), and initial white color
        SpriteComponent* sprite = new SpriteComponent();
        sprite->colorR = 1.0f;
        sprite->colorG = 1.0f;
        sprite->colorB = 1.0f;
        sprite->spriteIndex = rand() % 5;
        sprite->scale = 1.0f;
        go->AddComponent(sprite);

        // make it move
        MoveComponent* move = new MoveComponent(0.5f, 0.7f);
        go->AddComponent(move);

        // make it avoid the bubble things
        AvoidComponent* avoid = new AvoidComponent();
        go->AddComponent(avoid);

        s_Objects.emplace_back(go);
    }

We now have this normal C++ code:

struct RegularObject
{
	PositionComponent pos;
	SpriteComponent sprite;
	MoveComponent move;
	AvoidComponent avoid;
	
    RegularObject(const WorldBoundsComponent& bounds)
		: move(0.5f, 0.7f)
		// position it within world bounds
		, pos(RandomFloat(bounds.xMin, bounds.xMax),
		      RandomFloat(bounds.yMin, bounds.yMax))
		// setup a sprite for it (random sprite index from first 5), and initial white color
		, sprite(1.0f,
		         1.0f,
		         1.0f,
		         rand() % 5,
		         1.0f)
	{
	}
};

...
  
// create regular objects that move
regularObject.reserve(kObjectCount);
for (auto i = 0; i < kObjectCount; ++i)
	regularObject.emplace_back(bounds);

The algorithms

Now the other big change is in the algorithms. Remember at the start when I said that interfaces and algorithms were symbiotic, and both should impact the design of the other? Well, the "virtual void Update" anti-pattern is also an enemy here. The original code has a main loop algorithm that consists of just:

    // go through all objects
    for (auto go : s_Objects)
    {
        // Update all their components
        go->Update(time, deltaTime);

You might argue that this is nice and simple, but IMHO it's so, so bad. It's completely obfuscating both the flow of control and the flow of data within the game. If we want to be able to understand our software, if we want to be able to maintain it, if we want to be able to bring on new staff, if we want to be able to optimise it, or if we want to be able to make it run efficiently on multiple CPU cores, we need to be able to understand both the flow of control and the flow of data. So "virtual void Update" can die in a fire.

Instead, we end up with a more explicit main loop that makes the flow of control much more easy to reason about (the flow of data is still obfuscated here, we'll get around to fixing that in later commits)

	// Update all positions
	for (auto& go : s_game->regularObject)
	{
		UpdatePosition(deltaTime, go, s_game->bounds.wb);
	}
	for (auto& go : s_game->avoidThis)
	{
		UpdatePosition(deltaTime, go, s_game->bounds.wb);
	}
	
	// Resolve all collisions
	for (auto& go : s_game->regularObject)
	{
		ResolveCollisions(deltaTime, go, s_game->avoidThis);
	}

The downside of this style is that for every single new object type that we add to the game, we have to add a few lines to our main loop. I'll address / solve this in a future blog in this series.

Performance

There's still a lot of outstanding OOD violations, some bad design choices, and lots of optimization opportunities remaining, but I'll get to them with the next blog in this series. As it stands at this point though, the "fixed OOD" version either almost matches or beats the final "ECS" code from the end of the presentation... And all we did was take the bad faux-OOP code and make it actually obey the rules of OOP (and delete 100 lines of code)!

dod-chart1.png.0c63b0194df0f816028ace719b898cd3.png

Next steps

There's much more ground that I'd like to cover here, including solving the remaining OOD issues, immutable objects (functional style programming) and the benefits it can bring to reasoning about data flows, message passing, applying some DOD reasoning to our OOD code, applying some relational wisdom to our OOD code, deleting those "entity" classes that we ended up with and having purely components-only, different styles of linking components together (pointers vs handles), real world component containers, catching up to the ECS version with more optimization, and then further optimization that wasn't also present in Aras' talk (such as threading / SIMD). No promises on the order that I'll get to these, or if, or when...

 



63 Comments


Recommended Comments



Maybe you're going to address this in the next part you mentioned, but languages could really use more neat tools to avoid all the boilerplate you have to write and read.

With methods like update and generic things like 'GameObject' you're tempted because you never have to touch that code again, and the codebase 'magically' accounts for everything when you add a new component type. And the 'main loop' that just calls the updates is never a real source of errors, as opposed to the specific style where you can (and this happens to me a ton) actually just forget to add the actual function call which may cost you a precious sanity on a bad day.

I guess a good metaprogramming language and a way to 'tag' functions/methods and variables/attributes (templates certainly aren't this) so you can look them up in the metaprogramming language later is all you'd need there, but C++ doesn't have it...

As you pointed out, the thing about 'static so a programmer has to change it' vs 'dynamic so designers can change it with a tool' is not really a thing considering the tool can theoretically spit out generated code in whatever language you need, but again the ecosystem bites you because actually doing that is a lot more complicated (if you want to be able to change stuff while the game/engine is running) than writing something data driven and loading/reloading a bunch of text files instead. 

Edited by agleed

Share this comment


Link to comment

I'd upvote this even more if I could. Thanks, Hodgman, you're a beautiful person for going above and beyond like this.

Share this comment


Link to comment

The trouble is that pretty much everyone I've talked to who learned OO in university learned the "bad" OO - and given that I've spoken to some fairly recent graduates, this is still ongoing. What do we need to do to remedy this? Do we need to get actual programmers applying to be "intro to OOD" guest lecturers?

Share this comment


Link to comment

Every "OO" codebase I've had the pleasure to work on in the last 6 years in the software industry has been a disaster of every form of "bad OO". And it hasn't been uncommon for me to be the only person on the project who has any recognition of that fact. Outside of GDNet I know... maybe 8-10 total software engineers who could name the issues with "java-style OO" that Hodgman lays out.

I'm not sure it's even feasible to tackle the university pipeline when so much of the software industry doesn't take this stuff as a given.

Share this comment


Link to comment

As a beginner, the only thing I can say is thank you for bringing this kind of content.

Share this comment


Link to comment
45 minutes ago, swiftcoder said:

Every "OO" codebase I've had the pleasure to work on in the last 6 years in the software industry has been a disaster of every form of "bad OO". And it hasn't been uncommon for me to be the only person on the project who has any recognition of that fact. Outside of GDNet I know... maybe 8-10 total software engineers who could name the issues with "java-style OO" that Hodgman lays out.

I'm not sure it's even feasible to tackle the university pipeline when so much of the software industry doesn't take this stuff as a given.

Maybe we just need a snappy new name. Natural languages being what they are, the meanings of words tend to evolve; if enough people agree that OO refers to what we're all calling "bad OO" in this thread, then that's what "OO" means, regardless of what we think of the matter. :(

Share this comment


Link to comment

Thank you for this very interesting article which points at a lot of valid concerns about poor OOP/OOD usage.

I understand it is still a work in progress but I am a bit concerned about cache utilization in the current proposed solution versus the ECS / relational model one.
I might have missed some details but from a quick glance at the code, it looks like game objects such as AvoidThis are laid out sequentially in memory.

 std::vector<AvoidThis> avoidThis;

and iterated to update positions like this:

for (auto& go : s_game->avoidThis)
{
    UpdatePosition(deltaTime, go, s_game->bounds.wb);
}

(and once again later to update the sprite data.)

With a definition like this:

struct AvoidThis
{
    AvoidThisComponent avoid; // 1 float = 4 bytes
    PositionComponent pos; // 2 floats = 8 bytes
    MoveComponent move; // 2 floats = 8 bytes
    SpriteComponent sprite; // 3 floats + 1 int + 1 float = 20 bytes
};

and with 64 bytes cache lines, we can fit less than 2 game objects per cache line.
To update the positions, we would only need the PositionComponent and the MoveComponent allowing 4 game objects per cache line.

Am I missing something? Is this something you intend to work on?

Another concern I have is about the disparition of the "Systems" (compared to ECS). By bringing the behavior closer to the data (i.e. by moving the update functions back into the components), you get further away from the "Where there is one, there are many." principle, making it more difficult to optimize with knowledge at a global level (e.g. use spatial partitioning for collision avoidance).

I am also a bit curious about the difference in memory size compared to ECS. Part of it lies in the extra entity sets (std::vector<EntityID>) maintained per system (which I think would also be needed in the OOD version if disjoint sets were not sufficient to solve the problem) but the OOD solution doesn't store a name per entity while the ECS one does. Doesn't this explain a good part of the difference?

Considering the amount of improvements you suggest at the end of the article, I am quite confident you are already aware of these issues and am eager to read the rest of the series.

Thanks again for a great article.

Edited by ozirus

Share this comment


Link to comment

A problem with your take on ECS-like in OOP:

Refering to this:

Quote

The implementation of an - let's call it - *entity*:

struct RegularObject
{
	PositionComponent pos;
	SpriteComponent sprite;
	MoveComponent move;
	AvoidComponent avoid;
	
    RegularObject(const WorldBoundsComponent& bounds)
		: move(0.5f, 0.7f)
		// position it within world bounds
		, pos(RandomFloat(bounds.xMin, bounds.xMax),
		      RandomFloat(bounds.yMin, bounds.yMax))
		// setup a sprite for it (random sprite index from first 5), and initial white color
		, sprite(1.0f,
		         1.0f,
		         1.0f,
		         rand() % 5,
		         1.0f)
	{
	}
};

The composition of the entity is fixed at compile time. Using pointers or booleans to invalidate a component, it is possible to enable and disable them at runtime.

However it is impossible to add or remove components other than those specified -> Runtime Composability is gone.

  • You have to add a member for every component you want your entity to ever have over the course of the game at compile-time - or you fall back on inheritance and add a Component class that every component needs to inherit, leaving you with run-time casts.
  • Some of these components might even only be used at one point under a certain circumstance, though, so that's wasted memory, even if you only use pointers.
  • Furthermore, if you end up implementing a new component later on, you have to revisit every Entity/Object/whatever that should have this component, and add it manually.

Some implementations of relational data/"ECS" rely on runtime composability, as they configure systems not by taking entities as input, or - worse - entities working on themselves, but by having e.g. a Storage-Vector (not necessarily a Vector, ... ). This Storage-Vector is coupled with a BitSet, holding all entity ID's that have this component, and when the system runs, it skims through the BitSets of the components it requests and finds those that belong to the same Entity, and ONLY picks them up if every component is present on this entity.

Edited by Iltis

Share this comment


Link to comment
51 minutes ago, Iltis said:
However it is impossible to add or remove components other than those specified -> Runtime Composability is gone.

I think this was specifically addressed in the article as a sort of downside - but then he made a point the c++ is not really meant to be an interpreted language like this and thats what scripting languages are for.

It would be cool to see (maybe in the next blog entry?) a way to do this where run time dynamic components are possible - maybe using lua or something

It certainly makes the code less confusing and is more commonsense to write it this way. Easier to debug and profile too. Lots of benefits - I guess you would have to decide if you want to give up the dynamic game object or not. It seems like it wouldn't be too difficult to implement that portion (for some kind of editor or tool) in a scripting language as he mentioned.

Share this comment


Link to comment
1 hour ago, Iltis said:

The composition of the entity is fixed at compile time.

You're presupposing that it shouldn't be.

I would say that having runtime composability as a default is overengineering as long as you're writing a game (not an engine). If you need runtime composability for something, you can introduce it in small, controlled amounts where it is appropriate to solve the problems at hand, and you can do it in better ways than "entities with pointers to components". An approach I've found works fairly well is to divide entities up into types based on which components I know they'll have at compile time, then use separate "services" (in ECS terminology, "component arrays" coupled with "systems") to decorate instances of those specific entity types with extra state they need at runtime. If taken to extremes, this can result in something that looks like ECS, but was designed with a different approach than "throw all the components for all the entities ever in their own arrays."

Edited by Oberon_Command

Share this comment


Link to comment
41 minutes ago, Oberon_Command said:

I would say that having runtime composability as a default is overengineering as long as you're writing a game (not an engine).

I was under the assumption that the code was meant to be reusable.

If you only want to write one game with it, then I agree, it is a bit much.

 

1 hour ago, EarthBanana said:

It would be cool to see (maybe in the next blog entry?) a way to do this where run time dynamic components are possible

Just to clarify: I meant adding and removing existing components at runtime, not creating completely new ones (although that might be interesting in some cases)

Edited by Iltis

Share this comment


Link to comment
2 hours ago, Iltis said:

I was under the assumption that the code was meant to be reusable.

If you only want to write one game with it, then I agree, it is a bit much.

Depends on your definition of "reusable." As a gameplay programmer, I find the important kind of reusability is being reusable in multiple situations in the same program, not reusable across projects. Concerns like rendering, audio, and  animation (ie. "engine code") are a different story. The reusable parts in the examples we're talking about would be the "components," in any case, not the entities. This would be true regardless of whether the composition was compile-time or run-time, or whether we were reusing them across parts of a game or across different games.

I would not expect games that aren't sequels, reskins, or mods to share a whole lot of gameplay code. Certainly not enough that reusing entity archetypes across projects would be of much interest to me, never mind a driving requirement of my gameplay architecture. Different gameplay begets different code.

Edited by Oberon_Command

Share this comment


Link to comment
7 hours ago, ozirus said:

Thank you for this very interesting article which points at a lot of valid concerns about poor OOP/OOD usage.

I understand it is still a work in progress but I am a bit concerned about cache utilization in the current proposed solution versus the ECS / relational model one.
I might have missed some details but from a quick glance at the code, it looks like game objects such as AvoidThis are laid out sequentially in memory.

I've already got more content in the Github waiting for blog text to accompany it. One of the first tasks is fixing the memory layouts, yes :)

Sourcing the components from a pool allocator results in pretty much the same memory layout as the ECS version. I'll also switch from using pointers to link components to integer handles at some point, as they're smaller and make the flow of control easier to reason about (important when we get to threading). 

7 hours ago, ozirus said:

Another concern I have is about the disparition of the "Systems" (compared to ECS). By bringing the behavior closer to the data (i.e. by moving the update functions back into the components), you get further away from the "Where there is one, there are many." principle, making it more difficult to optimize with knowledge at a global level (e.g. use spatial partitioning for collision avoidance).

Class static functions can be used to process many objects, while accessing private implementation details and preserving the public interface. This does have the downside that you can only peek into one class' internals at a time though... It's also good C++ advice to liberally use free-functions (in the style of systems!!) when possible. If it's possible to implement a procedure as a free-function instead of a member function (i.e. the algorithm only depends on the public interface), then you should use a free-function. Java and C# got this terribly wrong when they excluded free functions from their design and forced everything to be a member.
We'll get into this more as I try to catch up to Aras' "Update" perf numbers. 

7 hours ago, ozirus said:

the OOD solution doesn't store a name per entity while the ECS one does. Doesn't this explain a good part of the difference?

That's an honest mistake on my part. Because none of the game uses names at all, I didn't notice I'd culled that feature when deleting the EC framework... I'll recompile Aras' ECS code without support for names for make it an apple's to apples comparison. Thanks! 

5 hours ago, Iltis said:

The composition of the entity is fixed at compile time.  Runtime Composability is gone.

Yeah I mentioned this in the article but maybe didn't make a big deal about it enough. This game (and most games) don't need that kind of VM. I'll address this further in another blog. 

Note that even without this component VM, you can still get runtime composition if your language supports it. e.g. You could write your components in C and your entities in Lua! 

5 hours ago, Iltis said:

Furthermore, if you end up implementing a new component later on, you have to revisit every Entity/Object/whatever that should have this component, and add it manually.

That's the same no matter the language / VM that you're using. With a composition VM, you have to edit the JSON files or whatever you serialise your game object templates as... If you add a new feature, you have to plug it in.

4 hours ago, Oberon_Command said:

I would say that having runtime composability as a default is overengineering

^THIS^

If you're writing a magic buff system where you need to add N poison over time components, resistance to ice components, reflect damage components, bonus to fire damage components, skill boost aura components, etc, etc... Then fair enough - build a framework specifically for that situation. Don't use such a complex framework *by default* though -- that's just as bad as using inheritance by default. Write the specific code that you need. 

3 hours ago, Iltis said:

I was under the assumption that the code was meant to be reusable.

The fact that it's designed as many small components (i.e. Follows the SRP) means that the bulk of it is reusable. Whether you define game objects in C, Lua or JSON has no impact on whether it's reusable or not) assuming you have gameplay staff who are competent in C/Lua/JSON).

The SOLID-C rules are designed to encourage you to create code that's easily reusable.

Share this comment


Link to comment

From my experience, what data oriented design addresses is the optimizations of the high frequency codepaths. In regards to game programming, it's mainly about tasks that execute every frame or at a very high frequency, like unit movement, AI, animation. So it can be very useful to layout the data in favor of those operations because they run 90% of the time. increasing their cache coherency can improve the overall FPS greatly. As for lower frequency operations, like firing a gun, pressing the jump button, which accounts for 90% of the codebase, are easily written in the OOP manner without a huge performance impact. Can their data be grouped in a cache coherent manner? I don't know. Some ECS/DOD gurus might have the answer.

In short, DOD is at least about grouping high frequency data together.

Share this comment


Link to comment
12 minutes ago, Fulcrum.013 said:

Generaly it impossible to increase it chache coherency becouse size of most instances exids size of chache line. For some components its possible to increase code locality using a pools of same kind objects. It works well for passive objects like bullets and so on that can not change trajectory by its descigion. But again it have mach better architecture that not break common architecture with virtual Update. Just pull have a virtual Update method that called once per pool and run a loop to process each of its tiny instances using static dispatch. 

In my mind, if you're going to have a bunch of pools of distinctly-behaving objects, anyway, there's not a whole lot of point to making that Update method virtual, nor much point in calling it "Update." Just name it according to what it does - "MoveBullets" - and put a call to pool.MoveBullets at the appropriate place in the main loop. That way you can see in the code what each pool is doing when. 

Here's a few lines illustrating the principle from a side project I'm working on:

combat.resolve_attacks(collision, status);
hazards.apply_status_effects(status);
characters.update_sprite_data(sprites);
sprites.update_animations(dt);
particles.update_all_particles(dt);

projectiles.update_all_projectiles(dt);
projectiles.resolve_collision(status, collision);

Look how simple this is! I can control the order in which each of the steps happen. No PreUpdate or PostUpdate or deferred update queues. All I need to do to work out when something happens is look at my main loop code to see where it happens. If I had a "virtual void Update" thing going on this code snippet would be a bit shorter (and this is not the complete function!), but tracing execution flow and debugging would be a lot harder. The compiler could probably inline some of these shorter updates, too. Sometimes simple declarative-looking logic is nicer than a 6 line loop.

Edited by Oberon_Command

Share this comment


Link to comment
7 hours ago, Fulcrum.013 said:

If profile data will show that a virtuall calls actually a problem its will also show that its hardware not ready to games or other realtime simulations at all.

The (straw-man) data in the article shows a 10x performance improvement by removing virtual calls (i.e. 90% of the execution time was being wasted). This is running on a typical gaming PC from a few years ago (i7 CPU)... Definitely read for games.

Your other comments seem to be implying that if you don't use virtual / dynamic dispatch, then your alternative is to use static dispatch with O(log N) complexity (e.g. a switch)... That's just swapping the mechanism without fixing the underlying problem. For example in the code in the article, we've removed virtual without adding a switch -- we've gone from O(1) to O(0) by approaching the problem from a different direction.

6 hours ago, Yixin Xie said:

From my experience, what data oriented design addresses is the optimizations of the high frequency codepaths. ... As for lower frequency operations, like firing a gun, pressing the jump button, which accounts for 90% of the codebase, are easily written in the OOP manner without a huge performance impact.

OOP != slow. You can (and should!) use OOD and DOD at the same time. They're orthogonal concerns -- one on writing reusable and manageable software (fits well with human authors), and one on writing software that does the minimal amount of work (fits will with machine hardware).

6 hours ago, Fulcrum.013 said:

(1) Generaly it impossible to increase it chache coherency becouse size of most instances exids size of chache line. (2) For some components its possible to increase code locality using a pools of same kind objects.

(1) No, because (2) Yes.

Generally if you've split up your objects properly, you can (and should) create memory layouts based on the actual patterns of you flow of execution / flow of data.

Also, one cache line isn't the limit for locality. The prefetcher pulls in a lot more data than one line at a time, so it's important to have long sequential runs of hot data... 

Share this comment


Link to comment
10 minutes ago, Oberon_Command said:

If I had given a "virtual void Draw()" method to each of these, the main loop would have less code, but the flow of the rendering code would be a lot harder to follow and debug.

Yep. "virtual void Update" (or Draw) on a pool is 100x times better than doing it per object, but it's still obfuscating the flow of control, and still obfuscating the flow of data. If your main loop is just a loop that calls Update on a list of things, it's impossible to reason about which things have data dependencies on which other things.

By the time I get around to adding threading to this example code, I want to have it in a state where data dependencies are trivial to reason about.

Share this comment


Link to comment
6 minutes ago, Hodgman said:

 By the time I get around to adding threading to this example code, I want to have it in a state where data dependencies are trivial to reason about.

That's the other thing - notice that in my sample I'm passing the services/pools that each method needs directly to each method. The dependencies are injected to the method that actually needs them; the individual services and pools don't store them! This makes dependency reasoning really straightforward at the expense of having bigger function signatures (which, oddly enough, has been encouraging me to write updaters that have fewer dependencies).

Sometimes I wish the mainstream engines gave me control over their main loops so I could do stuff like this.

Edited by Oberon_Command

Share this comment


Link to comment
3 minutes ago, Oberon_Command said:

Just name it according to what it does - "MoveBullets" - and put a call to pool.MoveBullets at the appropriate place in the main loop. That way you can see in the code what each pool is doing when. 

Really i have for ecample up to 50 spaseships that each can fire up to 3000 bullets per minute. Each phisical/logical simulation onject have it own set of Update functions for some of actions like recalculate autopilots, recalculate engines, collide and so on. Each object just can unsubscribe action that it put to rest for now by its solo descign. Bullets pool is same object that contain for example a bullets and unguided missiles that run out of a fuel. Other pool contain a unguided missiles that have a working engines yet, from wich missiles shifted to bullets pool after run out of fuel/. Empty pool unsubscribed from any actions. But when it receive a conent it subscribed to required actions. obviously subscription/unsubscribtion works much rare than processing,and active missiles and bullets pools have to be subscribed to different set of actions.As result anything of it just processed as abstract object witout any problems for perfomance, but ready to put-in-model-and-forget objects managment scheme. Really virtual dispatch affect perfomance only in cases called function is tiny, but for heavy functions its just overhead that not worth to account.

Share this comment


Link to comment
20 minutes ago, Fulcrum.013 said:

Really i have for ecample up to 50 spaseships that each can fire up to 3000 bullets per minute. Each phisical/logical simulation onject have it own set of Update functions for some of actions like recalculate autopilots, recalculate engines, collide and so on. Each object just can unsubscribe action that it put to rest for now by its solo descign. Bullets pool is same object that contain for example a bullets and unguided missiles that run out of a fuel. Other pool contain a unguided missiles that have a working engines yet, from wich missiles shifted to bullets pool after run out of fuel/. Empty pool unsubscribed from any actions. But when it receive a conent it subscribed to required actions. obviously subscription/unsubscribtion works much rare than processing,and active missiles and bullets pools have to be subscribed to different set of actions.As result anything of it just processed as abstract object witout any problems for perfomance, but ready to put-in-model-and-forget objects managment scheme. Really virtual dispatch affect perfomance only in cases called function is tiny, but for heavy functions its just overhead that not worth to account.

It sounds to me like we're largely in agreement here. Sort your data according to its behaviour! :)

You can even use separate pools for the same "object" (as the user would see it) that's in a different state. Eg. from the same project as the snippet I posted earlier, instead of having a variable on my weapon class that indicates whether it is lying on the ground, being held by a character, or has just been dropped, and instead of representing that with a set of "weapon state" classes with virtual update functions, my "weapon pool" stores three vectors of weapons:

std::vector<WeaponDatum> FreeWeapons;
std::vector<WeaponDatum> BoundWeapons;
std::vector<WeaponDatum> DroppedWeapons;

Then it applies different logic to each one; free weapons just idle and wait for something to pick them up, bound weapons mimic their owner's animations, and dropped weapons start playing the idle animation, then enter the free state. Switching states means moving a weapon from one "sub-pool" to another one. I haven't yet, but there are some further optimization opportunities here - the "free" (ie. not being held or dropped) weapons don't need to store a reference to the character that owns them, for instance.

Edited by Oberon_Command

Share this comment


Link to comment

After reading most of the article, I felt I had two points to make:

1. I agree that object oriented design doesn't have to be as bad as it usually turns out, and DOD overlaps heavily with relational database theory. However, I think that the most important distinction here is that DOD asks that data (not code) is considered first, whereas OOP assumes data joined with and secondary to its code and asks you to compose them in some subjectively pleasing way.

Ultimately, code is the tool that transforms data, and not the other way around. That said, it is also a tool for communicating processes to various audiences, so I'm waiting for the day that we'll stop thinking in extreme principles and find a way to reconcile both (and possibly other) purposes so that they work together to the extent possible.

2. Can we finally drop SOLID(C) please? Should be obvious by now that some of the rules are vague and infeasible at best and self-serving at worst.

SRP - what is "single"? Is "game" single? Is manager single? Entity, vector, float, byte? Tree, node, part of node? Is multiply+add not single, and what about SIMD? Where do we vote about all of these? Principles that mean nothing specific are only used as a tool to justify screaming about how poor someone else's code is, regardless of whether that is actually the case.

O/CP - in my experience, when the data changes, the interfaces change as well (for optimal access). And similarly, I find implementations to be extremely difficult to substitute without side effects, since they themselves have often very different I/O constraints, performance characteristics and side effects. So I'm not sure in what fairy tale world is interface lockdown or trying to accomodate unforeseen implementations productive.

LSP - in general, there's nothing to object to and people generally try to do this. That said, interfaces are frequently used to bridge inherently incompatible constructs (such as different rendering backends) where support for certain features is limited and it would be pointless to go to extremes to provide perfect feature parity.

ISP - no objections here. Note that this is the only principle for which you have yourself provided a practical argument to support it.

DIP - interfaces exist to bridge multiple implementations, otherwise implementations could be used directly, which is also beneficial for performance due to inlining and lack of virtual calls, and greatly simplifies allocation of data. You say that a POD struct for communication is enough but how is a POD struct different from a regular function parameter list? And I can almost guarantee that a plain function won't be considered DIP-compliant by many people. I would argue that it's merely a somewhat obvious tool used to accomodate refactoring, definitely not a principle.

CRP - while seemingly nice in theory, there is the practical consideration of C++ multiple inheritance casting headaches as well as the issue of composing components that need to know about their parent objects or neighbors. Inheritance, while not without its numerous downsides, solves the parent object issue without extra pointers.

Since you only mention SOLID(C) in your code criticism, and not design, I would argue that the worth of most of these is limited to justifying being annoyed about someone's code, unlike a concrete code example, which also shows an alternative implementation, open to concrete and fact-based comparisons, reviews and future improvements.

Share this comment


Link to comment
1 hour ago, snake5 said:

DOD asks that data (not code) is considered first, whereas OOP assumes data joined with and secondary to its code and asks you to compose them in some subjectively pleasing way

OOP's joining of code + data isn't some subjective voodoo. The separation of implementation details from simpler interface declarations is meant to reduce coupling through thin interfaces (ISP) but also for the purpose of enforcing class invariant. e.g. in C++ vector::resize is a member function, because it alters the internal pointers. There's a lot of invariants involving those pointers, so they're hidden within the implementation so you can easily reason that any bugs with them are caused by that implementation and not user code. On the other hand std::find is not a member function, because it's an algorithm that does not depend on any internal details of a vector.

If the data needs to be controlled to enforce class invariants, then it's internal. If code needs to interact with that fragile data, then it needs to be a member. If code doesn't need to interact with that fragile data, then it should be a free function (not a member).

The Java school of OOP shits all over this idea though and decides that everything should be a member...
In C++ we're taught to try and make as much of our logic as free-functions (not members) as possible.

1 hour ago, snake5 said:

Can we finally drop SOLID(C) please? Should be obvious by now that some of the rules are vague and infeasible at best and self-serving at worst.

Uh, no.

1 hour ago, snake5 said:

SRP - what is "single"? Is "game" single? Is manager single? Entity, vector, float, byte? Tree, node, part of node? Is multiply+add not single, and what about SIMD? Where do we vote about all of these? Principles that mean nothing specific are only used as a tool to justify screaming about how poor someone else's code is, regardless of whether that is actually the case.

I, really don't get what you're trying to say here... If a class has multiple different invariants that it's enforcing, can you draw a line through the class that splits them cleanly, so that some members + invariants are on one side of the line, and other members + invariants are on the other side of the line? If yes, then you can split that class into two. If not, then you can't. If you don't know what invariants your class exists to enforce then, sure, get confused.

1 hour ago, snake5 said:

O/CP - in my experience, when the data changes, the interfaces change as well (for optimal access).

The entire std library would be one example. The interface is agreed upon but there's several different implementations of it that work quite differently.
Or in a game project one time, we ported an Xb360/PS3 game to XbOne/PS4 by isolating the interface between the game and the engine and building a completely new engine underneath that interface.
Or in general, any bit of software that has a public specification (GL, Vulkan, C++, ECMAScript, etc...) follows this guideline.

It's a pretty vanilla guideline really -- "specs are good if they don't change, try your best not to change the spec". Very bland and acceptable...

1 hour ago, snake5 said:

DIP - interfaces exist to bridge multiple implementations, otherwise implementations could be used directly, which is also beneficial for performance due to inlining and lack of virtual calls, and greatly simplifies allocation of data. You say that a POD struct for communication is enough but how is a POD struct different from a regular function parameter list? 

The problem that DIP is solving is layered software.

Typically when designing large scale projects you want to build it up in layers. Everything in Layer 0 only uses other code in Layer 0 ("the core"). Then, you build more specific modules that exist on Layer 1 -- code in those modules only accesses code within their own module plus code in Layer 0 (e.g. graphics depends on core, input depends on core). Then you build even more specific modules that exist on Layer 2 and use all the code below (e.g. the game depends on graphics, input and core).

Instead of building things in vertical Layers, DIP offers a way to build horizontally and shift code down one layer. e.g. if you make an "input data" module that contains a just simple interface (e.g. data descriptions), then the input module and the game module can both depend on the input-data module, and now game no longer has to depend on the input module -- it can be moved down a layer to be horizontal to input.

This isn't just subjective, vague, hand-waving so that people can feel smug in code reviews and tell you that you've been a bad boy. I mean, that's what it sounds like you're complaining about? Some design nazi has used SOLID as a rolled up newspaper to whack you, unproductively, in a code review? If so, yeah that sucks, but don't let that put you off actually learning the useful parts of the theory....

This kind of planning is important on very large scale projects to keep the amount of dependencies between different parts of the code-base low so that you down drown in technical debt later. Reducing the surface area of modules like this, and the connections between modules, is a real concrete outcome.

1 hour ago, snake5 said:

CRP - while seemingly nice in theory, there is the practical consideration of C++ multiple inheritance casting headaches as well as the issue of composing components that need to know about their parent objects or neighbors. Inheritance, while not without its numerous downsides, solves the parent object issue without extra pointers.

Honestly, having two-way dependencies between components and their parents/neighbors is a bit of code smell, and often indicates that there's a bit of a mess of dependencies and an unclear structure. Usually if this kind of data is needed, it can be passed as arguments to the functions that actually do work, instead of being stored permanently in members, which solves the issue without extra pointers too.

1 hour ago, snake5 said:

I would argue that the worth of most of these is limited to justifying being annoyed about someone's code, unlike a concrete code example, which also shows an alternative implementation, open to concrete and fact-based comparisons, reviews and future improvements.

Didn't I post a github link and numeric comparisons of several metrics at the bottom? The original "faux OOP" code is subjectively and objectively terrible.

Share this comment


Link to comment

I'm a big proponent of bad/faux OOP in C++...... I use multiple inheritance everywhere, class hierarchies 15 levels deep, templates with 20 parameters where the base class is often a template parameter and I pretty much never never use the standard library.  On top of that I tend to make everything pubic unless I know for sure it should be private upfront, and then I go back and privatize stuff and clean things up after it works (assuming I don't forget).

I prioritize in this order:

1) Elegant  algorithms & data structures

2) Robust memory management

3) Speed

4) The structure of the code an how lit looks to others.

Mind you I'm not trying to sell anyone on my approach :D

Share this comment


Link to comment
14 minutes ago, Hodgman said:

OOP's joining of code + data isn't some subjective voodoo.

I totally agree, though what I consider to be subjective voodoo are the relationships and structure of objects themselves. This seems to appear the most in classes that are effectively layers of managers, proxies and factories.

20 minutes ago, Hodgman said:

If a class has multiple different invariants that it's enforcing, can you draw a line through the class that splits them cleanly, so that some members + invariants are on one side of the line, and other members + invariants are on the other side of the line? If yes, then you can split that class into two.

The question I ask is, should you split that class? I don't question the ability, as you have defined it, but the productivity of always doing so. Say you have a "human" component with "health" member. Does it make sense to move "health" to a separate component? Even if there is no other component that would need it? Likewise, multiply-add are clearly two separate operations, but are joined for performance reasons.

28 minutes ago, Hodgman said:

It's a pretty vanilla guideline really -- "specs are good if they don't change, try your best not to change the spec".

And a lot of good that did for OpenGL... :) as a particular counterexample, I see AZDO which is almost a self-sufficient subset of the broader, bloated API, which makes it pretty hard to argue that it was merely an extension. STL is for the most part a reasonable example in favor of the principle, though I find that it likely wasn't aimed at STL developers. And it's not like the spec hasn't changed at all over the years. IIRC, string::c_str() was at some point allowed to add the terminating zero at runtime and range-for was changed to allow for a separate end type.

43 minutes ago, Hodgman said:

The problem that DIP is solving is layered software.

Sure, I'm not against separation of software layers, but again, how does that make it a principle?

I'm not sure if there's a term for it, but there is a kind of dependency that is not explicitly written, but when a part is substituted for another with a fully compliant interface, something subtly breaks down regardless. Seems to be particularly common with computational geometry and image processing. Also observed with LLVM when manually specifying optimization passes to run. My point here is that no interface would help in this case, and making one only would cause performance issues (whether compile-time from templates or runtime from virtual interfaces), so how can something that doesn't always work be a principle?

52 minutes ago, Hodgman said:

Honestly, components needing to know about their parents or neighbors is a bit of code smell, and indicates that there's a bit of a mess of dependencies and an unclear structure.

I agree, but like I said, the issue here stems from practical considerations. When writing a game from scratch, all in the same code base and language, without data-driving anything, all such issues can probably be avoided quite easily, otherwise I'm not too sure.

 

All in all, my main point regarding SOLID(C) is that if some theory does not work always, without exceptions and provably so, it does not deserve to be a principle, and should not be applied unquestioningly. And this of course applies to the omnipresent horrible kind of OOP as well.

1 hour ago, Hodgman said:

Didn't I post a github link and numeric comparisons of several metrics at the bottom?

Please don't get me wrong, I did notice it and appreciate that a lot. I'm just saying that in my opinion, it has a great deal more value than all the criticism of original code, and so there should be even more code changes, metrics and reasoning behind the code changes.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Harry Loretz
      Hello everyone, 

      I appreciate any help i can get. So i recently started getting this message listed bellow in visual studio when i would compile any game i have for UE4.23.0. 

      1>EXEC : [1/28] error : Unable to create child process
      I have no idea how to fix this, and also i really don't want to have to set all the classes again in a new project.

      Second thing is that i can not move my Character on the Sever when testing multiplayer after adding "Role = ROLE_Authority" to sections in an AI Tracker bot class that i created as a part of Tom Loomans Course on Udemy. I am not following Tom Loomans course 100%, Do i need to add sever implementation to my character because i am using different movement code then what Tom uses? I Am happy to share some screen shots if needed. 
       
      Please help, thankyou for your time.
    • By bzt
      Hi,
      I was looking for a way to effectively interpolate between skeletons represented by list of bones with position vector + orientation quaternion pairs. To my surprise, I couldn't find any good solution, not to my taste that is. I can't use NLERP because I need a general solution, and NLERP is only good for small distance interpolations. SLERP would be perfect, but I couldn't find a decent implementation, only slow ones, so I spent a lot of time looking at game engines and quaternion libraries and reading academic articles on the topic. Finally, I decided to collect my findings and write my own optimized version of SLERP, which focuses on performance over precision, and which I now would like to share with you.
      Optimized cross-platform SLERP
      I've started from the well known formula, as implemented by most C++ libraries, and used all the tricks I could find on the net. Then I took it to the next level, and made some more adjustments on my own speeding up a little bit more. Finally I ended up with two solutions:
      1. one that is cross-platfrom, ANSI C solution that is easily embeddable in C++ and compatible with any C / C++ quaternion class (provided their data can be seen as 4 floats), very simple, very minimal. Use it freely if you want, MIT licensed
      2. a SIMD version, which I had to leave half-ready, because my compiler and Intel disagree on what intrinsics should be provided for SSE, moreover the compiler does not work the way its documentation say it should :-( Shit happens. I would only recommend this for experimental purposes, also MIT licensed
      Both versions are simpler and much faster than any implementations I could find, designed to be called in a loop several times. The only dependency they have is lib math (acosf, sinf). The SIMD version is half-ready, but even in this form it's almost 1.5 as fast as the other one, especially if you call it in a loop with memory prefetch on the quaternions.
      If I made any mistake, miscalculated or mistyped something, let me know. If anybody has an idea how to overcome that intrinsics blockade I have, that would be appreciated very much, because I can clearly see the path how to make the code several times faster, only if I could get rid of the library calls. I also plan to create an ARM NEON port once I have that.
      Cheers,
      bzt
    • By phil67rpg
      I have a very simple question, I am trying to rotate some vertex's around an arbitrary axis. basically I want to use glRotatef and glTranslatef to rotate a space ship I have drawn on the screen. here is my code of my  ship. what it does do is rotate around the origin when I  use the arrow keys left and right.
      void drawShip() { glPushMatrix(); glColor3f(255.0f, 0.0f, 0.0f); glTranslatef(-50.0f, 0.0f, 0.0f); glRotatef(rotateship, 0.0f, 0.0f, 1.0f); glBegin(GL_LINE_LOOP); glVertex3f(50.0f, 0.0f, 0.0f); glVertex3f(45.0f, -5.0f, 0.0f); glVertex3f(50.0f, 10.0f, 0.0f); glVertex3f(55.0f, -5.0f, 0.0f); glEnd(); glTranslatef(50.0f, 0.0f, 0.0f); glPopMatrix(); }  
    • By Ruben Torres
      [This post was originally posted with its original formatting at The Gamedev Guru's Blog]
      If you've been following me, you will probably know my interest in Unity Addressables. That is for a reason.

      Unity Addressables is a powerful Unity package that upgrades the way you and I have been tackling some of the most important challenges in Game Development: efficient, pain-free content management.
      When managing your game assets, it's hard to keep good standards that prevent our project from becoming a disgusting pile of mess. A big issue there is the coupling between the different responsibilities of our asset management systems.
      The way we store the assets in our project has way too much to do with the method we load them, and later use them.
      For instance, you may decide to store an innocent sprite in the Resources folder. This, in turn, will force Unity to build the player in a way that that sprite is put into special archive files. And the fact that it was put there, will corner you into loading it through the Resources API.
      Things get messy quicker than you can realize!
      One choice, multiple long-term consequences.
      A good system will prevent you and me from easily making sloppy mistakes like that. A great system will be that, and also easy to learn and use.
      With Unity Addressables, we separate the asset management concerns. Our goal is to remain flexible and to keep our project maintainable.
      Here are 3 proven ways Unity Addressables will help you and your games:

      1. Reduce Your Game's Memory Pressure
      When you publish your game, you'll be required on most platforms to specify the minimum hardware specifications your players must meet to buy and play your game.
      The math is easy here: the more hardware power you demand, the fewer will buy your game. Or, seen from another perspective, the better memory management you do, the higher the amount of content and fun you can offer in your game.
      Unity Addressables helps you in this regard enormously!
      To give you a brief idea, converting this kind of code:
      public class CharacterCustomization : MonoBehaviour { [SerializeField] private List<Material> _armorVariations; [SerializeField] private MeshRenderer _armorRenderer; public void ChangeArmorVariation(int variationId) { _armorRenderer.material = _armorVariations[variationId]; } } Into this other one:
      using UnityEngine.AddressableAssets; public class CharacterCustomizationV2 : MonoBehaviour { [SerializeField] private List<AssetReference> _armorVariations; [SerializeField] private MeshRenderer _armorRenderer; public IEnumerator ChangeArmorVariation(int variationId) { var loadProcess = _armorVariations[variationId].LoadAssetAsync(); yield return loadProcess; _armorRenderer.material = loadProcess.Result; } } Will bring you these results:

      Easy gains I'd say.
      -> Read more on Unity Addressables for better memory management in Unity Addressables: It's Never Too Big to Fit (opens in a new tab)
       

      2. Sell Your Next DLC - Quick and Easy
      The fact that Unity Addessables gives you full control over how, when and where to store and load your game assets is incredibly useful for implementing and selling Downloadable Content.
      Even if you are not thinking of releasing DLCs any time soon, just by using Unity Addressables in your project, you will have done already a big chunk of the work ahead.
      Other approaches for selling DLCs, such as Asset Bundles, are a very deprecated way of doing the same thing but at a much higher cost. Maintaining a well-functioning Asset Bundle pipeline is painfully time-consuming and requires a high degree of expensive expertise.
      There are many ways you can approach implementing DLCs in Unity, but for starters, this is a good starting point:
       
      public class DlcManager : MonoBehaviour { // ... public IEnumerator TryDownloadDlc() { if (_hasBoughtDlc && _dlcDownloaded == false) { var operationHandle = Addressables.DownloadDependenciesAsync("DLC-Content"); while (operationHandle.IsDone == false) { _progressText.text = $"{operationHandle.PercentComplete * 100.0f} %"; yield return null; } } } } You get the idea.
      Why would you say no to selling more entertainment for your players at a fraction of the cost?

      3. Reduce Your Iteration Times
      Using Unity Addressables will reduce the time wasted waiting in several areas.
      Tell me, how frustrating is it to be blocked for half a minute after pressing the Unity play button? And it only gets worse if you deploy your build on another platform, such as mobile or WebGL. This all starts adding minutes and minutes to your iteration times. It gets old so quickly.
      I don't like waiting either.
      But do you know what I like? Unity Addressables, my long-awaited hero. This is how Addressables will help you:
      A) Reduced Build Size
      Your game has a lot of content, I get it. Gamers love enjoying content. Developers love creating content.
      That doesn't mean, however, that every single asset you produced has to be included in the build your players will install. In fact, you should remove as much as possible.
      Players want to start playing ASAP. And they're not happy when your game steals 2GB of their data plan and 30 minutes of their gaming time. They'll just keep downloading Candy Crush kind of games that install well under 50MB.
      One strategy is to include only the assets needed to run your game up to the main menu. Then, you can progressively download the rest of your content in the background, starting, of course, downloading the first level of your game.
      It's also neat to realize that your deployment times during development will be much faster. You'll be able to iterate more times each day; this benefit quickly adds up in the long term.

      Unity Addressables - Reduced Build Sizes
      B) Reduced Load Times
      We, both as game developers and as players, hate waiting. Waiting takes us out of the zone and before you realize it, it is time to go to bed.
      Unity is working hard towards reducing the time it takes us to start playing our games, both in the Unity Editor and in the games we distribute.
      But not hard enough.
      Things look promising in the future, but not without side effects. Avoiding domain reloads in Unity 2019.3 looks promising, but as of today that's still in beta and not everyone can profit from it.
      In the mean-time, we can do better than just being frustrated.
      Let's say you're working on a medieval game. Several months ago, you implemented armor types for your game. You did a pretty damn good job and generated over 100MB of content.
      At some point, it was time to move on and right now you're working on something else, let's say sword fighting.
      Realize that, every time you press the play button to work on your features, you are loading an insane amount of data coming from all the already developed features, and loading this data takes a massive amount of time. You press play to test your sword fighting animations, and you spend 5 seconds waiting due to loading the armor features you implemented.
      The time wasted in loading is mostly spent on I/O (Input/Output), because memory bandwidth is expensive. And, on top of that, your CPU has to process it. You, as a developer, pay this time penalty while developing in the Unity Editor. But your players pay it as well in the games you are distributing.
      Knowing how big of a deal this can be, let's ask ourselves: which shortcuts can we take here?
      It turns out that Unity Addressables can help us here in two ways.
      1. Unity Addressables will reduce your Players' Loading Times
      We can alleviate some of our players' pain.
      Keeping indirect references to our assets instead of direct references will drastically improve your loading times.
      By using indirect references (AssetReference), Unity will not load everything at once but only what you tell it to. And more importantly, you have direct control over when that happens.
      2. Unity Addressables will reduce your Unity Editor Iteration Times
      How much do you know about the play mode script in the Unity Addressables Window? The play mode script defines how the Unity Editor should load the content marked as Addressable.
      With Packed Play Mode selected, Unity will directly load your pre-built addressable assets with little to no processing overhead, effectively reducing your Unity Editor iteration times
      Just do not forget to build the player content for this to work

      Unity Addressables - Build Player Content
      What if you applied these strategies to your most demanding content?
      4. Extra: Are You There Yet?
      It is true. Unity Addressables is very helpful. But this package will help only those who want to be helped.
      After reading how Addressables will help you producing better and selling more to your players, you probably want to start with it right away. However, starting in this new unknown area may be challenging.
      To make the most of your chance, answer these questions first:
      Where are you standing right now? Are you just starting, or are your skills production-ready? When to use indirect references, when to use direct references? What's the bigger picture? What is your next logical step? → Take this short quiz now to test your answers ← (opens in a new tab)

    • By Ruben Torres
      [This article was originally posted in The Gamedev Guru's Blog]
      You are leading a team of a handful of programmers and artists to port a good-looking PS4 VR game to Oculus Quest. You have six months to complete it. Well? What's your first move? Let's bring Unity Addressables to the table.
      You do realize you have to tackle quite many challenging tasks at once. I bet some might be personally more concerning than others, depending on your expertise level in each area. If you had to pick one that robbed your sacred sleep the most, which one would it be?
      My initial guess would be this: above 70% of the readers would say CPU/GPU performance is the biggest concern when porting a title to Quest. And to that I say: you can very well be right. Performance is one of the toughest areas to improve on in a VR game. For optimizations of this kind, you require in-depth knowledge about the product, which is a time intensive process. Sometimes you even cannot just optimize further, which usually ends in dropping expensive gameplay or graphics features. And not meeting people's expectations is a dangerous place to be.
      Performance, performance, performance.. The word might let some chills go down your spine. What can you expect in this regard from the Quest platform? How does it perform? The thing is, if you have had some development experience in it, you will probably know that in spite of being mobile hardware, it is astonishingly powerful.
      But Ruben! Don't give me that crap. I tell you my phone slows down significantly the time I open a second browser tab. How dare you say mobile platforms can be so performant?
      I read your mind, didn't I? The massive difference lies on Quest's active cooling system, which gives it a huge boost on its attainable CPU/GPU hardware levels that no other mobile platform can offer. It is a powerful fan that will prevent your hair from gathering dust and avoid melting the CPU together with your face (the GoT crown scene comes to mind).
      Additionally and on the side of the Quest software, the more specialized OS is better optimized for virtual reality rendering (surprise) than the generic Android variant. Mobile hardware has been catching up with standalone platforms so quickly in the last few years.
      But, at the same time, I cannot deny that our task of constantly rendering at 72 fps will prove to be challenging, especially for VR ports coming from high-end platforms. To be more precise, when we talk about the Oculus Quest, you have to picture yourself a Snapdragon 835 with a screen, a battery, four cameras and a fan.
      What could look like a disadvantage can actually be thought of as an edge. This mobile platform is a well researched piece of s*** hardware. One can say there are a myriad of known tricks you can pull off to quickly reduce the CPU and GPU load up to an acceptable point. If it is of your interest, you will be able to read about it in upcoming posts. As of now, we will take performance out of the equation for this post.
      What might catch your attention in our challenge is that, compared to the PS4, there is a single hardware characteristic literally halved on the Quest: the RAM capacity. That's right, we go from 8 to 4GB RAM. This is an approximation since, in both platforms, the operating system does not allow you to use it all so it can keep track of a few subsystems for the ecosystem to work. On the Quest you will be able to roughly use up to 2.2 GB of RAM before things get messy.
      Ruben, what do you exactly mean by messy? The thing is, proper memory handling is crucial for your game. This is so because you have two constraints:
      Hard memory constraint: if you go above a certain threshold, the OS will just kill your game Soft memory constraint: above another certain limit, the OS might decide to kill your game when your user minimizes your game, takes the headset off or you go out of the Oculus Guardian area Obviously, you do not want any of the two to happen in your game. Can you picture an angry player who just lost his last two hours of gameplay? Yes, they will go to your store and nothing pretty will come out of their mouth.

      Disgruntled Player - RUN!
      The thing is, the guaranteed availability of 2.2GB of RAM is not much, honestly. It's usually not a problem for new projects where you track your stats constantly from the beginning, but it definitely is an issue for a port to a severely downgraded hardware.
      If you dealt with similar ports in the past, you will quickly realize how extremely challenging it can become to decrease your game's RAM budget by half. It grandly depends on how well the game architecture was prepared for such a change, but in most cases this will temporally transform you into a tear-producing machine.
      The most popular strategies to reduce memory pressure include tweaking asset compression settings, optimizing scripts, reducing shader variants, etc.. Depending on the specifics of your project, tweaking texture import settings is your first go-to solution, but if you need to you can also resort to compressing meshes, animations and audio. The problem is that those techniques are usually complex in nature and will have a ceiling limit.
      Not all platforms support the same import settings; targeting several devices will dramatically increase your build pipeline overhead, not to mention QA, art, design and programming complexity. Does this Android device support ASTC, or just ETC2 (if at all)? Oh, we also want to build 64 bit builds, but also keep the players on the 32 bit versions. How many split-APKs should we create, and worse, manage and test, for each update we do on the game? You want to make your life easier, so you should not rely exclusively on these techniques.
      We would like to go further. As usual, we want to keep things as simple as possible (TM), especially if you are doing a port. Redesigning the entire game for performance's sake is a worse option than just not porting it. For that matter and in today’s topic, I will offer you one of the biggest gains for the buck: I will show you how to halve a project's memory budget in matter of hours. Boom!
      Wouldn't that be awesome?
      Go ahead, go ahead... ask me: is it really possible for me? The answer is: it depends on your starting point, but in my experience, YES. Unity Addressables can be of a great value here. The catch? You must be willing to put in the work and to master the process. But this workflow will earn you the title of employee of the month. 
      If you are interested, keep reading.
      In this post you and I will go through the journey of moving from a traditional asset management to an addressables-based asset management system. To illustrate the process,  we will port a simplified old-school project to the new era of Unity Addressables.
      Now, you might ask me: why don't you just show me the real-life work you did?
      In a non-competitive world I would just show you all the material I created. In the real world though, that is likely to get me canned. And worse, busted.
      What I will do instead is to offer you my guidance so you and I iterate on project that absolutely represents the difficulties you could find tomorrow in your next project. And we will do so by first welcoming Unity's Addressables to our family of suggested packages.
      In this blog post I will get you started in Addressables ASAP so you can implement your own Unity Addressables system in a matter of minutes.
       

      Unity Addressables: Why?
      Time to pay attention to this very important section. Our goal is to diagnose easy memory gains and implement them fast. There are several ways to do this, but one of the most powerful yet simplest methods to pick the low-hanging fruits by loading the initial scene and opening up the profiler. Why this?
      Because an unoptimized game architecture can frequently be diagnosed at any point during gameplay, so the quickest way to check this is by profiling the initial scenes. The reason for this is the common over-usage of singleton-like scripts containing references to every single asset in the project just in case you need it.
      In order words, in many games there is usually an almighty script causing an asset reference hell. This component keeps each asset loaded at all times independently from whether it's used or not at that time point.
      How bad is this?
      It depends. If your game is likely to be constrained by memory capacity, it is a very risky solution, as your game will not scale with the amount of assets you add (e.g. think of future DLCs). If you target heterogeneous devices, such as Android, you don't have a single memory budget; each device will offer a different one, so you settle for the worst case. The OS can decide to kill your app at any point if our user decides to answer a quick message in Facebook. Then the user comes back and surprise, all their game is gone for good.
      How fun is that?
      Zero. Unless you are overworked and sleep deprived, situation which might grant you a desperation laugh.
      To complicate matters further, if later on you decide (or someone decides for you) to port your game to another less powerful platform while keeping cross-play working, good luck. You don't want to get caught in the middle of this technical challenge.
      On the other side, is there a situation where this traditional asset management solution works just fine? The answer is yes. If you are developing it for a homogeneous platform such as PS4 and most requirements are set from the beginning, the benefits of global objects can potentially outweigh the extra added complexity of a better memory management system.
      Because let's face it: a plain, good old global object containing everything you need is a simple solution, if it works well enough for you. It will simplify your code and will also preload all your referenced assets.
      In any case, the traditional memory management approach is not acceptable for developers seeking to push the boundaries of the hardware. And as you are reading this, I take you want to level up your skills. So it is time for just doing that.
      Greet Unity Addressables.
       
      Requirements for our Unity Addressables project
      If you are planning on just reading this blog entry, your screen will suffice. Otherwise, if you want to do this along with me, you will need:
      Functional hands Overclocked brain Unity 2019.2.0f1 or similar The level 1 project from GitHub (download zip or through command line) Willingness to get your hands dirty with Unity Addressables The git repository will contain three commits, one per skill level-up section in the blog (unless I messed up at some point, case in which I will commit a fix).
       
      Download the project in ZIP format directly from GitHub
       

      Level 1 developer: Traditional asset management
      We are starting here with the simplest asset management method here. In our case, this entails having a list of direct references to skybox materials in our component.
      If you are doing this with me, the setup is a simple 3 step process:
      Download the project from git Open the project in Unity Hit the damn play button! Good, good. You can click a few buttons and change the skybox. This is so original... and boring. I take it, no Unity Addressables yet.
      In a short moment you and I will see why we need to endure this short-lasting boredom.
      To start with, how is our project structured? It pivots around two main systems. On the one side, we have our Manager game object. This component is the main script holding the references to the skybox materials and switches between them based on UI events. Easy enough.
      using UnityEngine; public class Manager : MonoBehaviour { [SerializeField] private Material[] _skyboxMaterials; public void SetSkybox(int skyboxIndex) { RenderSettings.skybox = _skyboxMaterials[skyboxIndex]; } } The Manager offers the UI system a function to apply a specific material to the scene settings through the usage of the RenderSettings API.
      Secondly, we have our CanvasSkyboxSelector. This game object contains a canvas component, rendering a a collection of vertically-distributed buttons. Each button, when clicked, will invoke the aforementioned Manager function to swap the rendered skybox based on the button id. Put in another way, each button's OnClick event calls the SetSkybox function on the Manager. Isn't that simple?
      Unity Addressables - Scene Hierarchy
      Once we're done daydreaming how immersive it was to play X2, it's time to get our hands dirty. Let's launch the multisensory experience and open the profiler (ctrl/cmd + 7; or Window - Analysis - Profiler). I take you are familiar with this tool, otherwise you know what to do with the top record button. After a few seconds of recording, stop it and see the metrics for yourself: CPU, memory, etc.. Anything of interest?

      Performance is pretty good, which is nothing surprising considering the scope of the project. You could literally turn this project into a VR experience and I assure you that your users will not fill any of the bile buckets that so many players filled when playing Eve: Valkyrie.

      In our case, we will be focusing on the memory section. The simple view mode will display something as depicted below:
      Level 1 Asset Management - Simple Memory Profiling
      The numbers on the texture size look pretty oversized for just displaying a single skybox at any given time, don't you agree? Surprise incoming: this is the pattern you will find in many unoptimized projects you are likely to suffer lead. But heck, in this case it's just a collection of skyboxes. In others, it will be more about characters, planets, sounds, music. You name it, I have it.
      If dealing with many assets falls under your responsibility, well, then I am glad you are reading this article. I will help you transitioning to scalable solution.
      Time for magic. Let's switch the memory profiler to detail mode. Have a look!
      Level 1 Asset Management - Detailed Memory Profiling
      Holy crap, what happened there? All skybox textures are loaded in memory, but only one is displayed at any given time. You see what we did? This rookie architecture produced the whoooooooping figure of 400mb.
      This is definitely a no-go, considering this is just a small piece of a future game. Addressing this very problem is the foundation for our next section.
      Come with me!
      Summary:
      Traditional asset management entails direct references Therefore you keep all objects loaded at all times Your project will not scale this way  
      Level 2 developer: Unity Addressables workflow
      In video- games you start at level 1, which is great, but once you know the gameplay rules it is time to leave the safe city walls in our quest to level up. That is exactly what this section is about.
      Grab the level 2 project now.
      As we previously saw in the profiler, we have all skyboxes loaded in memory even though only one is actively used. That is not a scalable solution, as at some point you will be limited on the amount of different variations of assets you can offer to your players. An advice? Don't limit the fun of your players.
      Here, let me help you. Take my shovel so we can dig the so needed tunnel to escape the prison of traditional asset management. Let's add a new fancy tool to our toolbox: the API of Unity Addressables.
      The first thing we need to do is to install the Addressables package. For that, go to Window → Package Manager, as shown below:

      Unity Package Manager - Unity Addressables
      Once installed, it's time to mark the materials as addressables. Select them and activate the addressables flag in the inspector window.
      Level 2 Asset Management (Unity Addressables)
      What this will do is to ask Unity politely to include those materials and their texture dependencies in the addressables database. This database will be used during our builds to pack the assets in chunks that can easily be loaded at any point during in our game.
      I'll show you something cool now. Open Window → Asset Management → Addressables. Guess what's that? It's our database screaming to go live!
      Level 2 Asset Management (Unity Addressables) - Main Window
      My dear reader: that was the easy part. Now comes the fun part.
      I want you to pay a visit to an old friend of ours from the previous section: Sir Manager. If you check it, you will notice it is still holding direct references to our assets! We don't want that.
      We are teaching our manager to use indirect references instead - i.e. AssetReference (in Unreal Engine you might know them as soft references).
      Let us do just that, let's beautify our component:
      using UnityEngine; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; public class Manager : MonoBehaviour { [SerializeField] private List<AssetReference> _skyboxMaterials; private AsyncOperationHandle _currentSkyboxMaterialOperationHandle; public void SetSkybox(int skyboxIndex) { StartCoroutine(SetSkyboxInternal(skyboxIndex)); } private IEnumerator SetSkyboxInternal(int skyboxIndex) { if (_currentSkyboxMaterialOperationHandle.IsValid()) { Addressables.Release(_currentSkyboxMaterialOperationHandle); } var skyboxMaterialReference = _skyboxMaterials[skyboxIndex]; _currentSkyboxMaterialOperationHandle = skyboxMaterialReference.LoadAssetAsync(); yield return _currentSkyboxMaterialOperationHandle; RenderSettings.skybox = _currentSkyboxMaterialOperationHandle.Result; } } What happens here is the following:
      A major change happens in line 7, where we hold a list of indirect references (AssetReference) instead of direct material references. This change is key, because these materials will NOT be loaded automatically just by being referenced. Their loading will have to be made explicit. Afterwards, please reassign the field in the editor. Line 13: since we are now in an asynchronous workflow, we favor the use of a coroutine. We simply start a new coroutine that will handle the skybox material change. We check in lines 18-20 whether we have an existing handle to a skybox material and, if so, we release the skybox we were previously rendering.  Every time we do such a load operation with the Addressables API, we receive a handle we should store for future operations. A handle is just a data structure containing data relevant to the management of a specific addressable asset. We resolve specific addressable reference to a skybox material in line 23 and then you call its LoadAssetAsync function, over which you can yield (line 25) so we wait for this operation to finish before proceeding further. Thanks to the usage of generics, there's no need for sucky casts. Neat! Finally, once the material and its dependencies have been loaded, we proceed to change the skybox of the scene in line 26. The material will be offered in the Result field that belongs to the handle we used to load it. Level 2 Asset Management (Unity Addressables) - AssetReference list
      Keep in mind: this code is not production-ready. Do not use it when programming an airplane. I decided to favor simplicity over robustness to keep the matter simple enough.
      Enough with explanations. It is time you and I saw this in action.
      If you would be so kind to perform the following steps:
      In the addressables window, cook the content (build player content) Then make a build on a platform of your choice Run it and connect the (memory) profiler to it. Protect your jaw from dropping.
      Level 2 (Unity Addressables) - Build Player Content
        Level 2 Asset Management (Unity Addressables) - Memory Profiler
          Isn't asset cooking delicious?
      I like happy profilers. And what you saw is the happiest profiler the world has ever seen. A satisfied profiler will mean several things. For one, it means happy players playing your game in a Nokia 3210. It also means happy producers. And as of you, it means a happy wallet.
      This is the power of the Addressables system.
      Addressables which comes with little overhead on the team. On the one side, programmers will have to support asynchronous workflows (easy-peasy with Coroutines). Also, designers will have to learn the possibilities of the system, e.g. addressable groups, and gather experience to make intelligent decisions. Finally, IT will be delighted to set up an infrastructure to deliver the assets over the network, if you opt to host them online.
      I have to congratulate you. Let me tell you what we have accomplished:
      Appropriate memory management. Faster initial loading times. Faster install times, reduced in-store app size. Higher device compatibility. Asynchronous architecture. Opening the door of storing this content online → decoupling data from code. I would be proud of such a gain. It's for sure a good return on investment.
      Oh, and make sure to mention your experience with Addressables in job interviews.
       
      INTERMEDIATE: Instancing and reference counting. Read on it my blog post for information on this topic.
      OPTIONAL: Alternative loading strategies. Read on it my blog post for information on this topic.
       
      Summary:
      Addressables-based asset management scales just well Addressables introduces asynchronous behavior Do not forget to cook content on changes or you'll give your game a pinkish tint!  

      Level 3 Asset Management (??) - Content Network Delivery
        Level 3 Asset Management (??) - Content Network Delivery
      In the previous section, we achieved the biggest bang for the buck. We leveled up our skills by moving from a traditional asset management system to an addressables-based workflow. This is a huge win for your project, as a small time investment gave your project the room to better scale in assets while keeping your memory usage low. That accomplishment indeed made you step up to level 2, congrats! However, one question is yet to answer:
      Is that it?
      No. We barely scratched the surface of Addressables, there are further ways to improve your project with this game-changer package.
      Of course, you do not have to memorize all the details regarding Addressables, but I highly suggest you to have an overview of them because down the road you are likely to encounter further challenges and you will be thankful to have read a bit further. That's why I prepared an extra short guide for you.
      There you will learn about the following aspects:
      The Addressables window: the details matter Addressables profiling: don't leak a (memory) leak ruin your day Network delivery: reduce the time-to-play user experience Build pipeline integration Practical strategies: speed up your workflow, trash your 10-minute coffee breaks  
      And more importantly, answer questions such as:
      What is the hidden meaning behind Send Profiler Events? How useful is the AddressableAssetSettings API? How do I integrate this all with the BuildPlayerWindow API? What's the difference between Fast Mode, Virtual Mode and Packed Mode? In order to grab the level 3 guide check out my blog post
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!