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.