Mana Engine: Achieving thread safety

I've recently been talking more about the engine I've spent a few years developing. It's been through a lot of revisions, entirely dumping the core of how it works a time or two.

It's most recent iteration has been developed by myself and Rob Brink (@rob_brink on twitter). We both have a bit of experience developing game engines at this point and wanted to really push a core-neutral, thread-safe, easy to use engine. As Rob has often said (in some variation or another) "It needs to be easier to use than falling on your face."

There is a great talk in the GDC vault by the tech director of Overwatch, where he goes over the ECS of their engine. At some point he mentioned that some systems can run in parallel, because you can statically know that they won't ever touch the same component data.

We wanted to take this to the next level by letting the engine handle all of that for you.

What we came up with (and Rob did most of the implementation of) was a way to generate a graph of dependent tasks. We would statically enforce access to components by type, so that we could guarantee that the engine knew when a component type was being read from or written to. Using this knowledge, it could then build the graph.

A system ends up looking something like this:

class MySystem : public AuthorizedSystem< const MyComponent1, const MyComponent2, MyComponent3 >
{
    void Update()
    {
        //operate on the data.
    }
}

There's a bit more to it than that. For instance, accessing components requires some special syntax so that the engine can know whether this system is allowed to use the data or not. But ignoring those details for a moment, lets see how this helps us write thread-safe code.

AuthorizedSystem is a special type of system that is templated in a similar way to a tuple. Using some typetraits similar to std::is_const and some other static helpers, we can identify which ones are allows to be written to or read from. The scheduler knows that when two systems don't access the same data, or only read from that data, they can be run in parallel. It also knows that any writers need to go before any readers. There ends up being some possibilities of circular dependencies, and I'll discuss more about resolving those later.

Currently, in the test game we're making to prove out the engine, this is what our dependency graph looks like.

Side bar: If you're not familiar with webgraphviz.com, it's a very worthwhile and easy to use tool.

In reality, this is a pruned version of our dependency graph. We have some other systems that I didn't include in this run because I'm not testing them. Rob wrote a nice Boids system that I didn't want to use in this run because I was testing other things.

And here's a delicious bonus to all this. Want to know what it took to remove the 5 Boids systems? In my main initialization function, I just had to comment out this line:

Boid::RegisterSystems(world);

We also have some auto generated systems that helps do some bookkeeping around components that I've omitted from the graph for the sake of simplicity.


Okay, so this looks neat and all, but why does it matter?

One thing I've noticed over the years as a developer is that some programmers tend to have an affinity for the harder problems, often within a specific domain. We have graphics programmers, engine programmers, gameplay programmers, networking programmers, audio programmers. The list of specializations goes on. Often enough, especially now when multi-threaded programming has yet not been a must-have understanding to write game code, programmers of all sorts of specialties have not needed to know how to deal with multi-threaded problems.

And in the Mana Engine, they don't have to. The engine is built to help you deal with multi-threaded problems and whenever possible, statically assert that you'll never run into race conditions or performance problems because of things like false sharing.

Recently, Monster Hunter World on PC was revealed (unconfirmed by the developer) to spend a quarter of it's processing time just managing thread overhead, and had around 100 or so of them. Lock-free and wait-free programming isn't easy. And even if you've solved it before that doesn't mean you won't mess up if you need to do it again.

Riot's recent engineering blogpost about performance shows a graph where the main thread is waiting on the particle thread before it can continue. It'd be nice if, in cases like this, instead of waiting the main thread could assist on some of the work the particle thread is doing. But then you get into other issues where now particle work is being done on the main thread and locking might get screwed up. Rob and I have both seen our fair share of bugs and deadlocks caused by the pattern of letting threads "assist" with another thread's work.

In the Mana Engine, we don't even have a main thread. We've chosen to solve the problem before it even happens.

In the Mana Engine, there are always the same or fewer threads than the computer's logical cores and the overhead is absolutely minimal. Solved that problem before it even happened.


In future posts, I hope to cover some more details about the Mana Engine, some of the problems we've ran into, and how we've solved them.

In the mean time, if you have any interest in the Mana Engine and it's details, message me on twitter and I'll be happy to share what we've learned.

The Data You Don't Care About

If you haven’t read this post, you probably should before continuing. It kinda sets up everything.

In the last post, it was all about the Data You Care About and making sure that your methods are only bothering with such data. This post is about the other data – Data You Don’t Care About. It begs the question – if you don’t care about it, why am I even writing about it?

Data You Don’t Care About is all about bookkeeping. It facilitates doing things to the data you do care about. As in the previous post, the m_Count and m_Space data members of the example array class is this type of data. I really want to push a point here – it’s data that help you do things to the data you care about. As a result, this data is intrinsically tied to functions.

Enter, the Doer classes.

Okay, okay. So there’s a bad stigma around Doer classes. They have long names, they often wrap only a single function, and can actually make your program harder to reason about. Yes, I agree, if done poorly, Doer Classes are all those terrible things. In fact, the very video that started me on these blog posts explicitly says they’re ugly and bad. In the context he’s talking about they are bad – I’ve seen that kind of code first-hand. What I’m proposing is a way to go about it that really… isn’t bad. Because really what we’re doing is associating bookkeeping data with the functions that do the bookkeeping. Classes just provide us a way of controlling access to that bookkeeping.

In the last post, I gave some examples of game systems that might want to respond to changes in data. These systems are doers. They can very often start as just a single function, but when you need to introduce bookkeeping (often for the sake of optimization, but sometimes other reasons) keeping the bookkeeping data with your function is quite useful.

Let me just throw out an example to make it a bit easier to grasp. Let’s say you have a system for rendering 3D objects in your game. You could loop through your Model components and let each one be a draw call, but there’s a better way to do it. You could organize them by mesh, so that you render all of one type of mesh all at once – probably using hardware instancing. Doing this organization will cost us a bit on the CPU, but will save us far more on our draw call count and the GPU.

// The below code depends on the understanding, so here's a quick low-down of some of the objects and methods in the example:
// Declared elsewhere:
// Model: A Component that has data related to a model (ie, mesh, material, etc).
//     ModelId Model::GetModelId(): returns the ModelId.
// Transform: A Component that has data related to position, orientation, and scale.
//     const Matrix44& Transform::GetWorldMatrix(): returns a Matrix44 that represents the transform's world matrix.
// ComponentId: A shared ID for all components that belong to the same entity. Ie, the key that binds them together.
// ModelId: An asset ID for the model.
// Set: A Hash set.
//     void Set::Insert(key): Inserts a key into the set.
//     void Set::Remove(key): Removes a key from the set.
//     size_t Set::Count(): returns the number of keys in the set.
// Map<T_Key, T_Value>: A container of Key-Value-Pairs.
//     T_Value& Map::FindOrCreate(T_Key): finds the value mapped to this key. If it doesn't exist, it creates it.
//     T_Value* Map::Find(T_Key): Finds the value mapped to this key. Returns nullptr if it doesn't exist.
// Array<T>: A generic dynamic array class.
//     void Array::Reserve(size_t count): reserves count spaces in the array. Good for making sure growth happens only once. 
//         Will not shrink the array is count is already less than the Array's space.
//     void Array::Clear(): removes all elements in the array -- does not shrink the array's allocated space.
//     void Array::Push(const T&) pushes a copy of T onto the array.
// Matrix44: A 4x4 matrix.


class RenderingSystem
{
    typedef Set<ComponentId> ModelInstanceSet
    Map<ModelId, ModelInstanceSet> m_ModelInstances

    void OnModelCreated( Model& model )
    {
        //Create a new entry in the ModelInstanceSet if there is an associated transform.

        ComponentId compId = GetComponentId(model);
        ModelInstanceSet& instanceSet = m_ModelInstances.FindOrCreate(model.GetModelId());
        instanceSet.Insert(compId);
    }
    
    void OnModelDestryed( Model& model )
    {
        ComponentId compId = GetComponentId(model);
        ModelInstanceSet* pOldInstanceSet = m_ModelInstances.Find( oldId );
        if(pOldInstanceSet)
        {
            oldInstanceSet->Remove(compId);
        }
    }
    
    void OnModelIdChanged( Model& model, ModelId oldId )
    {
        ComponentId compId = GetComponentId(model);
        ModelInstanceSet* pOldInstanceSet = m_ModelInstances.Find( oldId );
        if(pOldInstanceSet)
        {
            oldInstanceSet->Remove(compId);
        }
        ModelInstanceSet& newInstanceSet = m_ModelInstances.FindOrCreate( model.GetModelId() );
        newInstanceSet.Insert(compId);
    }
    
public:
    //All systems get a few virtual functions like this. Update, FixedUpdate, etc.
    void Draw() override final 
    {
        Array<Matrix44> transforms;
        for(ModelInstanceSet& instanceSet, m_ModelInstances)
        {
            transforms.Reserve(instanceSet.Count());

            for(ComponentId compId, instanceSet)
            {
                Transform* pTransform = GetComponent<Transform>(compId);
                if(pTransform)
                {
                    transforms.Push(pTransform->GetWorldMatrix());
                }
            }
            // And then here to do the rendering part where you bind the model buffer, the instance buffer (the transforms)
            // and make the drawcall using your favorite Graphics API's instance drawing method, such as D3D's DrawInstanced() 
            // method or OpenGL's glDrawArraysInstanced() function.
        }
    }
}

Of course the real advantage to this set up isn’t that a single system can do this. It’s that this system can operate and never had to know about any other system. Dozens of other systems could manipulate the transform data and the RenderingSystem would never know and would never need to know. That’s the beauty. You can add a PlayerControllerSystem, PhysicsSystem, AIControllerSystem, or whatever else to push and pull the objects around and the RenderingSystem doesn’t care.

Moreover, the RenderingSystem can make optimizations that won’t interfere with the other systems. For instance, rebuilding the instance buffer every frame is a bit excessive, and we could change ModelInstanceSet from a typedef to a struct containing the Set and a dirty flag, and the instance buffer. If it’s not dirty, we don’t rebuild it. The dirty flag would need to check for some additional things, like when transforms are created or destroyed, if there is a Model with a matching ComponentId, but that’s all done here, inside this one file.

The last few things I’m going to bring up about how much I like this take on Object Oriented Programming, are the following:

1. If for any reason this particular rendering system needed to be gutted and replaced with something else. Maybe you’re changing graphics APIs, or the guy who originally put it together was an absolute goof and wrote it horribly, you can safely extract and replace it with whatever you need.
2. If for any reason you don’t want the rendering system at all (ie, on a server, or a command-line client) then you just don’t instantiate it. The client can still instantiate one, and then all the client and server have to do is keep their component data in sync.

So back to the data you don’t care about – that’s exactly what the ModelInstanceSet is all about. You care about it for bookkeeping that can make it the game perform faster or smarter, but it’s not the actual data (the actual data you care about are the components). It provides modularity that it can be dropped in or taken out easily.

This all gets to the point from the first blog post and the video that spurred me to write it. Object Oriented Programming, as it is currently utilized in all too much of the professional world, really is bad. But I don’t think that it means all OOP is bad, and I hope these two posts provide sufficient example of how OOP can be used well.

The Data You Care About

I recently watched a video about why Object Oriented Programming is Bad and later tweeted a bit about it and quickly realize twitter wasn't the right platform to adequately describing my thoughts about a particular part of the video.

So here's my thoughts better laid out. Keep in mind, this is only in reference to what he says at 33:30 into the video -- not the entire video.

Basically the point he's making (and that I want to expand on) is that methods and the idea of encapsulation that they support are not always bad. He says that when the method is tightly related to the data of the class, it's appropriate. A common example are ADTs -- Arrays, Lists, HashLists and other generic containers and constructs.

The question I want to elaborate on is "Why do methods work out okay for ADTs but not other classes?" and "How can we use that to inform how we write other stuff?"

Here's the answer up front: Bookkeeping.

If you think about data (literally, the variables you declare) always keep in mind which ones are Data You Care About and which ones are data that do bookkeeping for the Data You Care About. Let's open up an array to see what I mean.

template<typename T>
class Array
{
   T* m_pArray;     // The actual array of data.
   int m_Count;     // How many elements are in the array.
   int m_Space;     // How much space has been allocated for the array.
public:
    // Constructors, accessors, etc.
}

If it's not obviously, only one of the members of this sample Array class are the actual data we care about -- the other two are just bookkeeping. The key thing here is that within the class, the various methods are manipulating m_Space and m_Count in order to keep track of how much memory has been allocated and how much memory has been initialized. If these were publicly exposed, anybody could write to these methods and screw up the classes accounting of data. In reality, if you know the internal structure of the array class, you could do some casting and pointer arithmetic to manipulate these values anyway. But that's not a big deal because something like that obviously looks like a very unsafe thing to do and you have to go out of your way to do so. Whereas array.m_Count = 10; looks like a perfectly normal line of code and you'd have to evaluate the surrounding code before realizing it was bad.

Like I mentioned in my tweets about this, this is more common than just ADTs, and in fact when you start separating data in your head into "real data" and "bookkeeping" you'll design your classes with much more clarity. Take a typical 3D transform class.

class Transform
{
   Vector3 m_Position;                            // Local Position
   Quaternion m_Orientation;                      // Local Orientation
   Vector3 m_Scale;                               // Local Scale
   mutable Matrix4x4 m_WorldMatrix;
   mutable bool m_WorldMatrixDirty = false;
public:
    // Constructors, accessors, etc.
}

Let's assume that m_Position is initialized as a (0,0,0), m_Orientation is an unrotated quaternion, and m_Scale is (1,1,1). The world matrix is initialized as an identity matrix. Maybe Vector3 is padded to 4 floats instead of 3 or any number of better decisions than how this class is laid out. The point is, there is Data You Care About and bookkeeping (AKA overhead).

This example is a bit deceiving because in the end, we probably only care about m_WorldMatrix. The local Position Orientation and Scale (POS) is likely just used so that when this transform's parent changed, we still have our data relative to the parent and can easily reconstruct our world matrix, which is used for rendering, physics, and many other systems. Note that this class isn't currently describing who the parent is -- could be bound by pointer or ID or something. It doesn't matter for the example being shown.

The obvious bookkeeper is m_WorldMatrixDirty. It's especially notable because it's got the mutable keyword. That means I can modify it within a const method. It makes this possible:

const Matrix4x4& Transform::GetWorldMatrix() const
{
    if(m_WorldMatrixDirty)
    {
        //recalculate world matrix.
        m_WorldMatrixDirty = false;
    }
    return m_WorldMatrix;
}

Now, we are only calculating the world matrix when it actually needs to be calculated. But to the outside world, they have no idea we're doing this trick. However, just as importantly, we don't want people directly writing to our local POS, because when the local POS changes it invalidates our world matrix. So we write something like this:

void Transform::SetLocalPosition(const Vector3& newPosition)
{
    m_Position = newPosition;
    m_WorldMatrixDirty = true;
}

This is almost like Event-Driven Programming¹. We'd guarded the access to our data member because we want to make sure we do something when that value changes. You can even imagine delegates and events used to notify other parts of the code when data has changed and they want to react to those changes. Here's some easy examples:

• In a game, when something is added or removed from your inventory:
  
  • The UI wants to know so it can update your inventory window.
  • The chat/info box wants to know so they can show a message (ie, "Removed Steel Sword").
  • If it is a networked or online game, a system that replicates data may want to notify your client that the item was added or removed.
• In a game, when your health changes:
  
  • Enemy AI may want to prioritize their targets. If you have low enough HP, maybe they just want to finish you off.
  • Friendly AI may want to prioritize their healing or protective abilities.
  • The UI will want to show the health change.
  • The game may want to make your character grunt from the hit if it was large enough.
  • In a networked game, a replication system needs to notify nearby clients of the change.
• In a level editor, when you make a change to the heightfield:
  
  • The terrain mesh will need to be rebaked for rendering, collision, pathfinding, etc.
  • Placed objects may want to move with the terrain as it is being deformed.
  • A terrain texturing system may want to change the texture based on height, slope, or any other number of properties of the new mesh.
  • Flora may want to regenerate -- maybe the grass only grows on flat terrain and not hills. It wants to know if you just made a steep hill.

Or the UI reacts to a change in stats.

I could go on and on with examples.

The big takeaway is that none of this automatic bookkeeping could be done without methods (or at least some form of indicating which functions were allowed access to data members). Methods certainly are useful and maybe even more commonly useful than the author of the video is letting on. I'm not saying he's wrong -- just that it's slightly more nuanced than the video describes. And maybe that's just a result of only having so much time in a video to explain things. Only he'd really be able to comment on that.

Next post I'll talk about who might want to be listening to these events and what type of data those objects are likely to have (hint, it's not Data You Care About, and that's okay).




¹ Full disclaimer -- event driven programming has it's faults too -- it certainly shouldn't be used everywhere.

"Me Too" MMOs

I was reading through an excerpt of a speech from Jeff Strain. I've read the speech many times before throughout my career -- it was given in 2007 -- but reading it nearly a decade later I found myself unsure of the words being said.

Here's the excerpt:

"Before you start building the ultimate MMO, you should accept that “MMO” is a technology, not a game design. It still feels like many MMOs are trying to build on the fundamental designs established by UO and EQ in the late ’90s. In the heyday of Doom and Quake we all eventually realized that “3D” was a technology, distinct from the “FPS,” which was a game design. It’s time we accepted that for MMOs as well. We are finding ways to overcome many of the limitations of the technology that dictated the early MMO design, such as Internet latency and limited global scalability. These improvements can enable a new class of online games that break out of the traditional MMO mold and explore new territory. It can be a daunting proposition to willfully walk away from what seems to be a “sure thing” in game design, but lack of differentiation is probably the number one reason that MMOs fail, so we all need to leave the comfort zone and start innovating, or risk creating yet another “me too” MMO."

The speech is somewhat prophetic at the end, saying "me too" mmos are likely to fail.

What's interesting is that 9 years later we've seen a lot of new types of MMOs. Survival MMOs, the MMORTS, social oriented online games. Even strictly non-combat MMOs like Ever Jane. The list goes on. But at the same time, we've still seen a lot of "Me Too" MMOS. Many have failed, but a fair number of them have succeeded. Perhaps most strangely is the fact that Guild Wars 2, the successor to Guild Wars and made by the company co-founded by Jeff Strain is very much a "Me Too" MMO that is succeeding. When Guild Wars 2 was first presented to the Guild Wars community, it was even pitched as "an MMO more like what you think a typical MMO is like" (paraphrasing here). The most notable difference is the persistent explorable zones. And while the dynamic events are an attempt at innovation, it's more of an evolution (Quests -> Group Quest -> Warhammer Online's Public Quests -> Guild Wars 2's Dynamic Events). Hearts are especially quest-like in their lack of real impact on the world your character lives in.

Now, by my second-hand hearing, Guild Wars 2 has been much more successful than Guild Wars 1 was from a monetary standpoint. I don't know if that's because of the more traditional design (granted, with plenty of non-traditional mechanics thrown in the mix) or a result of something else. Either way, I'm reading these words differently today than I was the last time I set eyes on them.

Blending Pixels

A task at work has recently required me to do some graphics stuff. I'll be the first to admit that as a learned discipline I'm not a graphics programmer. I enjoy almost any kind of programming and in my hobby work I find graphics programming especially fun. But simple things in that realm of the programming world I am embarrassingly ignorant of. Even something like... blending two pixels.

But! That wasn't going to stop me from researching and validating the right way to alpha blend two pixels together.

Now in reality, the task isn't so much for pixels, but rather for heightfield data. Now often heightfield data is just a single-channel pixel anyway, but in our engine heights are represented as floats. To expand the feature set of our terrain engine, our heightfield data needed to be modified to include layers and an alpha channel. So each heightfield sample is now two channels -- height and alpha.

Of course, googling and grabbing an algorithm isn't all there was to it. I wasn't really going to be satisfied with the answers I found unless I could test it myself. Sure, I could plug the code in and see what results I get, but it was much faster to throw up my favorite web app -- Desmos Graphing Calculator.



Compared to my last documented use of Desmos, this is absurdly straightforward. I'm visualizing the alpha channel along the x axis and the height channel along the y axis. I'll admit, It's a bit disorienting until you get used to it. Regardless, a/h₃ is the resulting value. a/h₁ and a/h₂ are the inputs. Alpha values are normalized, so we're working with ranges between 0 and 1.

The formula for the output ends up looking like this in code. As usual this code is for illustrating the formula -- not for being performant code.

struct HeightSample
{
    float height, alpha;
}

void Blend(HeightSample& out, const HeightSample& a, const HeightSample& b)
{
    out.height = a.alpha * a.height + b.alpha * (1.0f - a.alpha) * b.height;
    out.alpha = a.alpha + ((1.0f - a.alpha) * b.alpha);
}

It's interesting to note that while the alpha blending is a commutative operation (that is, if you swap the input values, the output is the same), the same it not true of the height channel. This is because sample const HeightSample& a is considered the "top" pixel. They are not even commutative if both alpha values are 0.5. This isn't particularly intuitive, so I thought it was worth mentioning.

Waste of Length in Vector Libraries

I've recently been on a bit of a vector math hook lately which naturally comes with coding up things, testing, toying, and experimenting. Not just vectors, but basically everything commonly used in game development -- boxes, spheres, intersections of shapes, rays, matrices, etc.

I wanted to better understand Sphere-Line collision test, so I made this up a few nights ago.

Thinking Out Loud

I tweeted this out last night:

What would my @vanguardsoh peeps say about the diplomacy sphere being turned into a mobile game? Obvs have no green light. Just wondering.

— Timothy Lochner (@tloch14) April 7, 2015

I did so because I was sitting in bed, searching for good puzzle games to play on my phone. I enjoy simple puzzle games when I have down-time. It's something that I can do at my own pace and leisure. If there are any time-constraints to the game, they're often in short bursts like "solve the puzzle as fast as you can" which only takes about a minute anyway.

After not really finding anything in the app store I was particularly interested in, my mind drifted to games that would fill this need I have to play a quality puzzle game that I can do in very short sessions, or chain them together for an engaging longer session.

I thought of Vanguard's diplomacy sphere. Don't know why, but I did. I also like wondering and thinking about how a game design would play out and discussing it with others, so I tweeted to see what other people thought.

What I didn't expect was to wake up to this:

#Daybreak dev muses about mobile #Vanguard diplomacy game: http://t.co/EVyC5Z1sop @DaybreakGames

— MassivelyOverpowered (@MassivelyOP) April 7, 2015

My first thought after reading this was that a better question is, "What kind of loser uses the word 'obvs'? Did I really use that?" *facepalm*.

The next things was that the tweet was probably misleading because I mentioned a "green light". As if it was even remotely possible that it could happen.

My intent for mentioning "no green light" was to attempt to be clear that this is just thinking out loud. After reading it this morning, it sounds like "I have no green light now, but maybe I could if it was a good enough idea" or something like that.

Sorry to say, nothing is brewing. It would be a neat challenge to design diplomacy as a stand-alone card game (holy crap, a lot of context would have to be filled to replace the actual game of Vanguard) but it ultimately is just not a thing right now.


That being said, if you know of any good mind-bender or puzzle games for the iPhone that aren't a thinly veiled attempt to nickel and dime the user, let me know. Here are two that I have enjoyed so far, plus some more action-y game too.

• Hexy - The Hexagon Game by Valcour Games - Although I wish it had more content. The picture puzzle thing seems neat, but I don't really want to solve pictures from my own phone.
• Flow Free by Big Duck Games LLC - A decent amount of content you can play for free. More purchasable if you want.
• Solomon's Keep and Solomon's Boneyard by Raptisoft Games - Very entertaining games to play. Really dug into Solomon's Keep. Only just started Solomon's Boneyard. And the in-app purchases aren't very in-your-face. The games are quite enjoyable without them.

Order of Construction in C++ for Polymorphic Classes

I came across a bit of a bug (or at least I thought it was) recently while programming. I thought I'd share the experience because it's a bit of a nuance of the C++ language and doesn't seem to fit what we normally expect C++ to do.

The issue was with polymorphism. I was creating a new class that derived from a base class. Part of the construction of the base class is to give it a pointer to it's owner. Upon construction, the base class would then call into the owner class, passing the this keyword to it. What I expected was to have all the vtable information of the derived class available to me. This is a key element to polymorphism that makes it such an incredible feature. However, when Owner began using the Derived object I had created (as a Base*), I found that it was calling only Base functions, not overloaded Derived functions.

Surely, I thought, I've discovered a bug in the compiler or something.

And then I decided to dig a bit deeper and try it out in a very controlled environment. This is the test I came up with.

#include <iostream>
using namespace std;

class Base
{
public:
    Base()
    {
        bool isDerived = GetIsDerived();
        if (isDerived)
        {
            cout << "Class is derived.";
        }
        else
        {
            cout << "Class is base.";
        }
    }
    virtual bool GetIsDerived() const { return false; }
};

class Derived : public Base
{
public:
    Derived() : Base() 
    {
        bool isDerived = GetIsDerived();
        if (isDerived)
        {
            cout << "Class is derived.";
        }
        else
        {
            cout << "Class is base.";
        }
    }
    virtual bool GetIsDerived() const { return true; }
};

int main(int argc, char** argV)
{
    Base base;

    Derived derived;
}

I have a Base class and a Derived class that extends Base. I then have a virtual function in Base called GetIsDerived(). This function always returns false, because in Base, that's true. In the Derived class, however, I overload it to always return true. In my entry point function, I create a new instance of Base on the stack. Sure enough, as you would expect, the first line printed is "Class is base." When I create the new Derived object on that stack, you'd think that the overloaded GetIsDerived() would run, but when within the Base constructor itself no vtables have been created yet, and as such, no overloaded functions will get callled. The total output is then this:

Class is base.
Class is base.
Class is derived.

So you see, when putting functionality in the constructor, rather than mere initialization, be careful what your functions are doing because until the object is fully constructed whatever is using it will treat it like the base and not like the derived class. The problem is even more difficult to see when you're giving someone else your this keyword and they begin using your pointer as the base, not the derived.

Programming as a communication to future programmers (including yourself)

I was recently in a discussion with one of my colleagues about some of the finer points of developing in C++. To be frank, we talk about this nearly every day, but this conversation in particular stuck out to me.

The particular thing we were talking about was how the code you write can clue in future developers into how something ought to be used or how something works. In C++, this is pretty important because C++ allows developers to accomplish tasks in a variety of ways. The particular example we were discussing was when to pass by reference and when to pass by pointer.

Surely, there have been thousands of discussions on whether to pass by reference or pointer. Just google it and you'll see the evidence of that. However, instead, we took the approach of "When should I accept by reference or by pointer?" Moreover, what does this say about how I want to use the references or pointers you are giving me?

I phrase the question this way because the user of a function doesn't get to choose how the function's signature is created -- the used function chooses that. By creating your function in a particular way, you are communicating how it will be used by user code. As an example, when thinking about passing by reference or by pointer, the two have rules in the language that permit certain things and restrict others. Therefore, depending on how you accept an object, you're communicating to the user how you expect to be able to use it.

If you are accepting by pointer, you are saying that

1. It is okay for the object to not exist, ie, it's optional. Pointers can be null, so only accept a pointer if you have a handle-case for the object to not exist. In fact, it's probably best to put all pointer arguments at the end of the function signature with default " = nullptr" values in each one, making the function more convenient to use.
2. The object, if not null, will at least live as long as the function's scope. Once you leave the function's scope, the object could at any time be deleted. This means that the function shouldn't store off the pointer somewhere else for later use. Of course, this much isn't even guaranteed because...
3. The function can delete the pointed-to object. This is often my biggest fear when using other people's code and passing objects to them by pointer. Does the function expect to take over ownership? Will the function delete my object? Of course, some functions explicitely are intended to do that and even say so in their name.

As opposed to accepting a reference where...

1. The object is guaranteed to exist.¹ This is great because then there's no null-checking, the user knows that the object must exist, and if they attempt to dereference a pointer in order to pass it by reference, the dereferencing null exception happens on their turf, not mine -- it's their mistake, not a bug in my API. However, like a pointer, there is no guarantee that the object will exist longer than the scope of the function, so don't store it off or even the object's address off anywhere.
2. The object will live for the entire scope of the function and you are guaranteed to have access to it for the entire duration of the function. Whereas with a pointer, I could re-assign it to point to a different object, with a reference I can't reassign it. Moreover, this means that...
3. A reference cannot be deleted (with exceptions). Try calling delete on a reference. It doesn't work. Of course, you could call "delete &reference;", but let's be honest, if you're doing that, you have no business being a developer at all.

And there's more about communicating to your user how you will use objects passed to them. Using the const keyword is a great way to promise to your user code that you won't modify the object passed to them (unless you cast it to a non-cost, at which point somebody needs to cut you... deep... and in a main artery).

Part of me feels dumb writing this. Above, I said that this was a finer point of developing in C++, but honestly it's a pretty blunt topic. This isn't an obscure practice. C++ developers have known these points since the dawn of the language. Heck, compilers even auto-generate copy constructors that take a const reference. Why? Because they never want to copy null and they want to guarantee that the copy constructor won't modify the original object.

Yet, I see time after time after time, code written that doesn't follow these simple rules, and it's often by developers who've been at it for well over a decade. Instead of guaranteeing the existence of an object by asking for it by reference, they'll ask for it by pointer and put an assert at the very top of the function. That will prevent shit from hitting the fan in debug, but when the shit hits the fan in release, you're shit outa luck and will likely have a harder time finding the bug because release dumps never give you enough information (optimizations that make the callstack not match your code, only getting stack memory, etc).

In my mind, it all comes down to subtle communication and usability. I'm a tools programmer, so I think a lot about usability. What many programmers don't think about is that the first tool is the code itself. The usability of the code also needs to be considered in detail and that includes what it communicates to users of the code.

A comparison might explain it best. If you have a property of an object in a tool you're writing and that property can be one of a list of values that do not relate to each other in scale, the UI representation you'd likely create for that is a combobox. Why? Because there are three discrete options and you can only pick one. But what if you create a slider? Well a slider can snap to 0, 33, 66, and 100% to represent the four values and only one can be selected. But a slider communicates a relationship between the possible values. A slider is, therefore, confusing.

Good uses of sliders: Graphic quality (scaling from low to high), view distance (scaling from near to far), field of view (scaling from narrow to wide).

Good uses of comboboxes: Physics Interpolation (none, interpolate, extrapolate), a character's profession (warrior, mage, ranger, priest), light type (point, spot, direction, area).

If you were to use a slider for the fields that lend themselves to comboboxes, the user could get confused. Wait, is a priest the best profession because it's highest on the slider? Is a point light not as good as a directional light because it's lower on the slider? Of course not, but when you present a slider to something that fits a combobox, the user will get confused and be unsure of how to use the tool.

This is what it's like when seeing a function call that is asking for an object in the wrong way. Possibly worst of all, it slows down future development time as confused programmers stumble their way through learning your API.

Write so as to communicate. When you write, think, "what am I telling future developers about my code?" and use what is most appropriate.


¹ While a reference is not absolutely guaranteed to exist, it is at least guaranteed to never be assigned to null statically. Because we're talking about programmer's static typing here, for all intents and purposes, a reference says "I am expecting this object to exist".

Code Dump: C++ delegate

When I started to learn to program, a lot of stuff seemed like magic. If you're a programmer, you probably know the feeling. It's just like when you are told how to do something, rather than getting an explanation of how it works under the hood.

For me, that happened all the time using C# delegates. See, I really liked C# delegates. I thought they were the shit (and what all the pros used, don't ya know). Turns out they aren't good in every situation (most situations call for a more simple and sufficient event pattern) but regardless, they can be very useful at certain times.

Dumb name is dumb

I've done some researching about how to start blogs. One thing that comes up a lot is to make sure you nail the blog name.

So I sat in front of my the "Create a blog" page for a few minutes, realizing that I feel like I'm naming a character in an MMO (you MMO gamers know what I'm talking about).

Then I realized that I can change the name at any time. So here's my blog, with a dumb (yet accurate, which the programmer in me is a fan of) name.

It's not much now, but hopefully that will change. You can expect to see posts about stuff I'm interested in (like the choreography of 1's and 0's) and from time to time, even my own original thoughts (coming from an American, this is pretty impressive), so come back again and follow me and all that stuff. You never know, I may actually entertain some of you.

Note: While I am a programmer for Sony Online Entertainment, you won't find any information regarding their games here. My thoughts and everything written on this blog are my own.