Here’s a screenshot from my the new improved Hailstorm engine! A big thanks to Christine who got me a DirectX programming book for Christmas. Right now the program only starts up a window and DirectX, but more is coming.

I know its just a blank window

Check out https://github.com/smacdo/Hailstorm for the code and wiki!

#include <sstream>

template<typename T>
std::string dumpContainer( const T& container, std::string sep )
{
    typename T::const_iterator itr;
    std::stringstream sstream;

    for ( itr = container.begin(); itr != container.end(); ++itr )
    {
        // insert a seperator char for all but the first element
        if ( itr != container.begin() )
        {
            sstream << sep;
        }

        sstream << *itr;
    }

    return sstream.str();
}

#include <vector>
#include <iostream>

int main( int argc, char* argv[] )
{
    std::vector<int> values = { 1, 2, 3, 5 };
    std::cout << dumpContainer( values, ", " ) << std::endl;
}

1. Download and install the Qt for Visual Studio plugin.
2. Download the source code for Qt 4.7
3. Start the Visual Studio 2010 Command Prompt ( Microsoft Visual Studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt)
4. Navigate to the directory with your downloaded Qt SDK
5. Run the configure program like so: “configure -platform win32-msvc2010 -debug-and-release -static -no-gif -no-qt3support -no-dbus -no-phonon-backend”
6. Wait ten or so minutes for configure to finish
7. Now run nmake. And make dinner, because this will take a very long time
8. You have Qt ready to go! Yay!

The configure parameters I provide will configure Visual Studio to build the vast majority of Qt. There’s a lot of extra options you can explore if you desire more control – for instance, you can enable exception support.

Have fun!

The interesting thing about this though is the idea of luck, or more specifically runs of bad luck (aka incurring the wrath RNG God) where you consistently do not realize the outcome you wish. Ask your average RPG player – what’s more frustrating then attacking a low level spider and missing the next five attacks only to have the spider slay you? Impossible? Not at all. Improbable? Of course. Another infuriating example of this comes in with loot drops. Many bosses drop unique or rare types of loot that people want to collect, and expecting to collect these items can be an exercise in frustration. A 25% drop in no way means that you will have the item within four kills, rather you will need to kill the boss 14 times before you have a 98% chance of collecting said item.

So basically, pure random rolls stink. Over time, the bad runs average out with the good runs, so its not like these situations happen all the time. However it’s human nature to remember the bad runs, and sometimes enough improbable bad strings of luck is enough to make the player quit your game entirely. Sure, it might be _fair_… but who plays a game to die to a lowly spider just because of bad luck? People play games because they want GOOD luck.

So how do we fix this? Well this is what I’ve been thinking about for the past few days. Instead of a pure random number generator, I want a “nice” random number generator that somehow ensures you will get a desired outcome sooner rather than later. Essentially, we want to break up runs of “bad results” with good results in between. The best answer I’ve found so far is the concept of a “grab bag”, which is array of pick results that is shuffled.

I’ll go over this concept more in my next post, and some of interesting properties it brings up. The results are more “balanced”, but does it ruin the concept of a game? Stick around!

(I’m going to try writing more entries to practice my writing abilities, and also to share my thoughts with everyone else on game programming and design. Please share criticism or suggestions with me!)

void myFunction( int* i )
{
	std::cout << *i << std::endl;
}

std::vector myVector;

myFunction( &myVector[0] );

Pretend you have an awesome templated square matrix class, parameterized on the value type and its size. It would probably look something like this:

// the template class

Once you have the matrix, you’d want to specialize it for specific sizes (say N=4). Its also a good idea to do this so you can add more constructors (doubt you want to keep creating arrays to pass in!). Anyhow, your implementation might end up looking something like

// derieved TMatrix4<T>

Guess what? It won’t work! But before we can get to that, the compiler is going to try to confuse us into thinking the problem is somewhere else! Take the following code. It should work, right?

TMatrix4<float> a = b + c;

Ha! The compiler throws a really nasty error, which I’ll paraphrase here:

“No match for operator= in ‘n=TMatrix<T,N>::operator + ( const TMatrixT,N>& ) const [with T= float, int N=4]“

“What black magic is this?”, I hear you say. Without going into details, the compiler is lying to you – while the compiler is erroring out on the assignment operator it is actually trying to find the constructor. (Return Value Optimization). So, implementing the copy constructor in the derieved TMatrix4 class should solve the problem, right?

Wrong!

// i need to recreate the error for you guys

When you created TMatrix4, you created a templated class that depended TMatrix<T,N>. When you call operator +, it is using TMatrix<T,N>::+ which has a return type of TMatrix<T,N>. Open returning from operator +, it needs to construct a new object – but the compiler cannot tell that the returned object is TMatrix4<T>. So the solution:

TMatrix4( const TMatrix<T,4>& mat )