on the menu:

• intro
• 3D realms and Duke Nukem shut their doors
• World of Warcraft jumping the shark?
• NCSoft’s Guild Wars and Dungeon Runners
• Stargate Worlds

Download audio file (wazoo-babbling-mashup-05-08-2009.mp3)

#include <boost/shared_ptr.hpp>

//create a base object for whatever..
class IBaseObject
{
  public:
    IBaseObject(){}
   virtual ~IBaseObject(){}
  //snip!
};

int main(int argc, char* argv[])
{
  // create a new IBaseObject instance with one reference
  boost::shared_ptr objA(new IBaseObject);

  printf("Ding! %i reference!\n", objA.use_count()); // 1

  // assign a second pointer to it:
  boost::shared_ptr objB = objA; // should be 2 refs by now

  printf("Ding! %i references\n", objB.use_count()); // 2

  objA.reset(); //set the first pointer to NULL
  printf("Ding! %i references\n", objB.use_count());  // 1

  // the reference count will drop to zero
  // when objB goes out of scope

}

The (real) secret of making games is finishing them.

Perhaps that’s a fairly trite “revelation” at this point, but nonetheless it’s worth mentioning once in a while. I think too many hobbyist and beginner game developers are lured into tackling a project that is much too large for either their skill level or even just their time commitment. Because on the surface every commercial engine is sold as making game development “easy as pie”, they aren’t capable of properly making a plan or project timeline for how long things may actually take to do.

The best way of avoiding this trap is to develop and grow your own project intuition on game development. While it is always suggested ad-nauseum by the professionals in the industry, it really is worth your time to sit down and write an Asteroids, Breakout or Space Invaders type of game. Starting and finishing one (or more) of these projects will not only open your eyes to how things are working “under the hood” of your game, but also to give you a better understanding for planning out a schedule or timeline for the real game you want to create.

By tackling a smaller project, you are also better able to discover your true skillset in the overall creation of your game, which can help you decide what (if any) aspects of the project you would hire someone to do for you. Do you find you had the most fun creating the art / sprites for your game? Did you find the art and programming side of things “tedius” compared to designing the actual game “play”? Did you have a richer experience just coding away into the wee hours, not really caring how good or bad the actual artwork or final game play was?

To repeat…the real secret of making games, is finishing them. Don’t just finish the engine, or the artwork, or the design or the audio; finish the GAME.

If you were using STL, then typically you would create something like the following:

#include <iostream>
#include <list>

using namespace std;

class IRenderObj
{
public:
float x;
float y;
float z;
};

main()
{
list<IRenderObj*> drawList;
list<IRenderObj*>::iterator drawListIter;

IRenderObj *a= new IRenderObj;
IRenderObj *b= new IRenderObj;
IRenderObj *c= new IRenderObj;

a->x = 0.0f; a->y = 0.0f; a->z = 0.0f;
b->x = 0.0f; b->y = 1.0f; b->z = 0.0f;
c->x = 1.0f; c->y = 0.0f; c->z = -10.0f;

drawList.push_back(a);
drawList.push_back(b);
drawList.push_back(c);

for (drawListIter = drawList.begin();
drawListIter != drawList.end();
drawListIter++)
{
//draw, translate each vector
glTranslatef( (*drawListIter)->x, (*drawListIter)->y, (*drawListIter)->z );

}

// Now Free pointers
for (drawListIter = drawList.begin();
drawListIter != drawList.end();
drawListIter++)
{
delete *drawListIter;
}

drawList.clear(); // List is deleted.

}

Not bad, not bad. It’s just a bit of a pain to remember to manually go through the list to delete each object. It’s manageable if you only have a few of these such lists, but even then you have to be supremely careful that you remember to do it. In short, there’s a chance of creating a memory leak.

Using Boost::ptr_list

Another approach is to use a component of the Boost C++ libraries, boost::ptr_list to manage your list of objects for you. With this object as your dynamic container, it will automatically clean things up for you.

#include <boost/ptr_container/ptr_list.hpp>
#include <iostream>

using namespace std;

class IRenderObj
{
public:
float x;
float y;
float z;
};

main()
{
//notice the declaration doesn’t require you to use a pointer to IRenderObj
boost::ptr_list<IRenderObj> drawList;
boost::ptr_list<IRenderObj>::iterator drawListIter;

IRenderObj *a= new IRenderObj;
IRenderObj *b= new IRenderObj;
IRenderObj *c= new IRenderObj;

a->x = 0.0f; a->y = 0.0f; a->z = 0.0f;
b->x = 0.0f; b->y = 1.0f; b->z = 0.0f;
c->x = 1.0f; c->y = 0.0f; c->z = -10.0f;

drawList.push_back(a);
drawList.push_back(b);
drawList.push_back(c);

for (drawListIter = drawList.begin();
drawListIter != drawList.end();
drawListIter++)
{
//draw, translate each vector
glTranslatef( (*drawListIter)->x, (*drawListIter)->y, (*drawListIter)->z );

}

//so far so good, the same as our STL code

//except the kicker…the clear method will clean up for us!
drawList.clear(); // All pointers held in list are deleted.

}

The choice is yours, but in this case I pretty much stick with Boost as it’s one less potential memory leak I have to worry about.

In most cases for a software codebase there is the need to usually ensure that there
is one single instantiation of an object. In other words, usually a fairly important object
which would wreck havoc on the application if there were more than one.

In the days of C, this was accomplished with the use of a global variable. While
not pretty, it does do the job it is meant for. One problem with using a global variable
this way, is that the object is always consuming resources. For example, what
if we have a class design in which the Singleton object need only be created when
certain circumstances / conditions are met?

In the C++ language, we can create a small Singleton object that we can
then use for future objects in our system. In other words we can create a base
object to generalize any common handling of Singletons.

Da Code!

/**
* Template class for creating single-instance global classes.
* The code in this file is taken from article 1.3 in the the book:
* Game Programming Gems from Charles River Media with the
* copyright notice going to Scott Bilas.
*/
template  class ISingleton
{
protected:

	/** The static member object */
	static T* ms_Singleton;

public:
/**
* Constructor
*/
ISingleton( void )
{
    assert( !ms_Singleton );
    ms_Singleton = static_cast< T* >( this );
}

/**
* Destructor
*/
~ISingleton( void )
    {  assert( ms_Singleton );  ms_Singleton = 0;  }

	/**
	* This method just returns the internal member by
	* reference
	* @return T& - reference to internal abstract Type
	*/
	static T& getSingleton( void )
	{	assert( ms_Singleton );  return ( *ms_Singleton ); }

	/**
	* This method just returns the internal member by
	* a pointer
	* @return T* - pointer to the internal abstract Type
	*/
	static T* getSingletonPtr( void )
	{ return ms_Singleton; }
};

That’s pretty much all we need defined for our lowest-level base class.
To see this object in use, be sure to check out the other tutorials
on this site. Most of them employ this Singleton object to
work with objects such as a FileLogger.

Although my Windows Vista machine is stable, I do admit that it is a rather “luke-warm” of an operating system. It does move some things in the right direction, while others it just takes to an extreme. In terms of both game development and gaming experience…again I’d say it was “luke warm”. Of the games that would run for me, none really seemed to benefit at all from the re-architected DirectX pipeline. Even when I did find some DirectX10 specific demos, they were fairly bland and unexciting.

My Windows7 experience thus far with the beta releases have only underscored how far in a short period of time the Windows OS has come. Vista is now more of a “bump” in the OS evolution cycle, with the Windows brand trying to focus a lot more intensely on what customers want.

There was a lot of “grumbling” around Windows Vista, along with the predictions that it would drive unhappy customers straight to MacOSX. Although I never subscribed to that prediction, I’m sure more than a few people began to take a step back and self-analyze what it is they actually wanted from an OS…which is always a good thing.

I’ll download the RC as soon as I can and share my thoughts.

So, I’ll start with a few of my lessons from 2008:

Developing a “site identity” - For most of 2008, I merely flipped between several WordPress themes for my website then called it a day when it came to “site design”. As a result, I had no real site identity / branding that I was happy with. In December, that changed when I seperated the content of the site from this blog engine. It’s still rough around the edges, but overall I’m more pleased with how it looks - it feels more like a “game company” and less like a “blog aggregator”.

Still no released products - One of the frustrating lessons from 2008, is that although I chipped in on several projects, nothing substantial materialized from the efforts. I had some irons in the fire, but the disease that swept through my family during the xmas holidays, really gave me a chance to re-focus and think about what I want to accomplish. A harsh lesson, but important if I’m ever to make headway in 2009.

WoW subscription ends Jan. 2, 2009 - My “projecttime” vs. “wow game time” was competing for the overall time I have available…which is not much overall. I enjoyed the game, got my paladin tank to 80, and will see what I can accomplish while she’s parked. Now one could make a correlation between my number of released game products vs. wow time, but it would only highlight the symptoms behind my product progress….not the disease.

Regular Site Updates - My workstyle is more suited to some regular updates vs. one-long-update-per-month. I’m still going to keep posting at a frequent pace, which hopefully maintains a consistent communication with my friends and customers.

Multi-focus kills progress - I have several great ideas for products and services to release, but I tried to flip between them on such a rapid rate, that I ended up making little progress.

Predictions for 2009

Finishing the RPG - It’s in the early stages at this point, but my team and I are excited about a small RPG idea that’s working through the pipeline. I’ll be bringing it up as often as I can for the benefit of everyone in the community.

Focus and finish one thing at a time - I’m aiming to do one thing at one time in order to make any headway on what I want to accomplish. Once I (hopefully) get some more money rolling in, I can take a look at making some hires for my other ideas.

So what are your lessons from 2008? Any concrete plans for 2009 yet?

However, there’s only so many units I could ever control at once, and this is a problem I generally have with large-scope RTS games. After I hit a “critical mass” of units, my armies quickly become under-utilized as there’s always a percentage of units that are “idle” until I’m able to process the information / data and find something for them to do.

I noticed a video on Kotaku today of a Starcraft II trailer showing off a Zerg rush strategy in the new game.

http://kotaku.com/365716/first-look-at-starcraft-ii-zerg

INSANE. Trailers vs. actual in-game footage aside, I’m excited to see how the efficient management of a large number of units are handled!