Templatize your factories

In Object Oriented Programming we create systems that manage objects. However, it is always a good idea to separate the implementation of the objects from the systems. This way, we can add or change objects and the system doesn’t need to change.

This post is related to object Factories. A factory is responsible for creating objects. Here is a very simple example of an object factory:


IObject * ObjectFactory::CreateObject(const string & objectType)
{
    if (objectType == “Model”)
        return new Model();
    else if (objectType == “Sound”)
        return new Sound();
    else if (objectType == “Light”)
        return new Light();

    return NULL;
}

Each of these 3 objects derive from the IObject interface. Based on the type of the object (”Model”, “Sound”, or “Light”) we create that object (new Model(), etc).

This is great. But we can improve…

What if we want to get a list of object types that the factory is able to create? This was my question and here is the way I solved the problem.

First we create an interface for our object factory. This would allow us to create multiple object factories for different parts of an application (one for the map editor, one for the driving level, etc) or for different applications all together.


class IObjectFactory
{
    public:
        IObject *(*Creator)(void);

        virtual ~IObjectFactory() = 0 { }

        /**
        * Returns a list of objects that this factory can create
        **/
        list<string> GetCreationTypes(void);

        /**
        * Create an object of the type passed in
        **/
        IObject * CreateObject(const string & objectType);

    protected:
        void RegisterCreator(const std::string & objectType, IObjectFactory::Creator creator);

        void UnregisterCreator(const std::string & objectType);

    private:
        IObjectFactory::Creator * GetCreator(const std::string & objectType);

        map<string, IObjectFactory::Creator> objectCreators;
};

The concept is that we can Register a Creator into the IObjectFactory and then the factory will handle everything for us. We can create an object or get a list of object types that the factory can create at runtime without any additional modifications from us. The implementation for this interface is trivial…

This line is important:

typedef IObject *(*Creator)(void);

This defines a function pointer to a “Creator” function. This is a function that will create a specific object for us.

Here is a templated “Creator” for you to use:


template <typename T>
IObject * ObjectCreateFunction(void)
{
    return new T();
}

Then simply inherit from IObjectFactory in your concrete object factory and define a constructor similar to this:


ConcreateObjectFactory::ConcreateObjectFactory()
{
    RegisterCreator(”Model”, &ObjectCreateFunction<Model>);
    RegisterCreator(”Sound”, &ObjectCreateFunction<Sound>);
    RegisterCreator(”Light”, &ObjectCreateFunction<Light>);
}

P.S. I know that the IObjectFactory isn’t a purely an interface but I am still going to call it an interface. Deal with it.

more pretty pictures for you to eat

first up, we have 3 screenshots I put together, click to enlarge.



I also assembled 3 wallpapers (people always want wallpapers) in a veritable cornucopia of different resolutions.


standard ratio: 1024×768,1280×960,1600×1200
widescreen ratio: 1280×800,1440×900,1680×1050,1920×1200,2560×1600


standard ratio: 1024×768,1280×960,1600×1200
widescreen ratio: 1280×800,1440×900,1680×1050,1920×1200,2560×1600


standard ratio: 1024×768,1280×960,1600×1200
widescreen ratio: 1280×800,1440×900,1680×1050,1920×1200,2560×1600

multi-player mayhem

Brian has been working a ton of hours getting the networking portion of our game far along enough to have our first Zero Gear play test, which we hosted at a LAN party this weekend. It seemed to be a great success and everyone seemed to have a great time driving around their characters even if we didn’t have any real race rules in place yet. I was able to grab a lot of footage and I pieced together a little video, click the image below:

Here are a few action photos of the Zero Gear party in progress, thanks to everyone who came and played!

New character poster, Robo Viking!

Here is another poster I whipped up after finishing the robot character. This little guy will pillage his way into your heart <3

new character, now with 100% more robot

here is a quick look at a new character I just finished up

Here are a few more peeks at him with some different color schemes, of course you will be able to choose whatever combination you would like!

Nine Paths To Indie Game Greatness

I wrote an article a few months ago about some methods independents are utilizing to develop games with a very limited amount of resources. Many of these ideas are things that we try to follow to develop Zero Gear in an efficient manner. The article just went up on Gamasutra, check it out!

re-vamped character model and animations


The last week or so I have been taking a shot at re-doing our first player model for Zero Gear, the original model didn’t sit right with a lot of people or me included. Luckily I stumbled into contact with Edwin Rhemrev, a concept artist in Rotterdam. We talked about how much we enjoyed kart racing games, and offered to do some concept pieces for us. He came up with a lot of differently styled and awesome looking characters. This is the one that I based my character model from. After a couple days of modeling I had the base model done that everything else would build upon.

Once this step is complete, I unwrapped and textured the body and head. This step involves some tricky and/or tedious work assigning how the flat 2d texture is wrapped around the 3d model. Luckily there are a lot of different tools to help you do this, just imagine trying to cut out a set of skin tight clothes out of a piece of paper for a doll, in a shape so that all the seams match up perfectly to fit the contours of the body. Sounds pretty tricky, doesn’t it! These are the flat textures I created to wrap around my character

Here is what he looks like with the textures applied.

Now we have something that looks like a character, the next step is making him move like one.
To animate the character, I make a skeleton that fits the proportions of the body and has joints in all the proper places. Then I have to assign all the verticies to correct bones in the skeleton, and after that is done I can animate the bones in the skeleton to move in whatever way I wish and the body will follow. The entire animation process is something I have been learning as go, and it has filled me with a lot of respect for animators, as it is clearly a discipline to master in and of itself. Here is a screenshot of the program I use to animate the skeleton:

The animation is done using “key-frames” on a timeline. In a nutshell this involves moving something to a position and setting a “key” and then moving the same thing to a different position and setting another “key” farther down the timeline. Using this process, the animation between those two keys are filled in for you and the result is a smooth transition between the two positions. Here is a short video I created of some animations I created for this character.

There are still some additional steps to be taken to get the character into the game, but it is mostly complete at this stage. I will be following this same process to create multiple other new characters for the game. After finishing this guy, I posed him in a little scene and rendered out a poster-type image for fun. Click on the links to the right of the image for a number of different sizes.

MVC LUA GUI FTW!!!

This is a more technical post but don’t run away!

When designing a game (or any application) we tend to want to separate the graphical user interface (GUI) from the game logic. A way of doing this is called Model-View-Controller (or MVC). Here is a summery of what this means:

MODEL: This is the code and data that controls your game. An example could be setting the color of the player.
VIEW: This is your GUI. An example is a GUI widget to select a color and a button to apply that color to the player.
CONTROLLER: This is what ties the MODEL and the VIEW together. It is some logic that takes the color selected from the GUI and applies it to the Player in game.

The reason for doing this is that is separates the MODEL from the VIEW. This means we can easily change the VIEW without changing the MODEL and vice versa by only changing the CONTROLLER. And most the time we don’t even need to change the CONTROLLER.

Here is the way I am handling this:
MODEL: In C++ I have code that sets a player’s color Player::SetColor(colorVal)
VIEW: Using Navi, we have created a simple GUI to pick a color. This has some code in JavaScript that gets called when you change the color which sends an event telling us the color has changed and what color it changed to.
CONTROLLER: This is where Lua comes into play. Lua is the CONTROLLER that receives this event from the VIEW. The Lua code calls the C++ code Player::SetColor(colorVal) with the color from the event. This modifies the MODEL which changes the color of the player on screen.

It might seem complicated but it actually simplified things greatly and allows us to change one aspect of the game without affecting other things.

rim lighting extravabonanzathon


While Brian has been toiling away at the bolts and gears under the hood of our game to implement our networking system, I have been working on getting our environments polished up and in the game. While I was playing around with Ogre’s fixed-function environment mapping features, I noticed a method of environment mapping listed that I had never tried out before, cubic_normal mapping. According to the manual: ” Generates 3D texture coordinates containing the camera space normal vector from the normal information held in the vertex data.” While that is pretty self explanatory, let me explain to you how it is different from most of the environment mapping utilized by Zero Gear. The environment mapping I use a lot to make things look shiny, simulates a cube sitting around whatever it is applied to. I basically use a black cube with a few white highlights around the top panel of the cube, and when applied to an object, a white highlight appears reflected as from the top of the scene. In this method, the cube is static. However, using this cubic_normal method, the cube that objects are reflecting is locked to the camera, so wherever you move around in the scene, the cube moves with you. An easy way to look at it, is one method the cube is a room you stand in, and the other method the cube is a box you wear on your head that moves around with you. This is significant becuase I can easily use this second method to simulate rim lighting. Since the environment map is locked to your view, it will always be facing in one direction, and you would just need to build a cube map that simulates a halo of light on all sides. Here is the cubemap that I came up with:

To create this cubemap, I built a scene in maya of a hollow white sphere, with a black dot on the front face. Since you are always looking through the “front” of the cube, when this is applied to objects it will apply that light gradient around the top, bottom, left and right of it.

Here is a screenshot of what this environment map looks like applied to an object, with both the cubic_normal and cubic_reflection methods:

The environment map on the left remains relative to the model, and using the method on the right, remains relative to the camera.

This method has some advantages and some drawbacks.

The advantages:

  • It’s fixed-function which means it is fast and will work on low end hardware. Also it does not require another pass for cards that support multi-texturing (almost all of them).
  • It can be implemented using Ogre’s material script, which means I don’t have to mess with a shader language.
  • Artist control. I can change the cubemap face assets, and the resulting effect without touching a line of script or code.
  • It looks pretty good!

The disadvantages:

  • It’s not per-pixel. This means that the effect relies on the verticies of the model to figure out how to apply the map. This means that the effect will be less accurate on very low poly objects.
  • Cubemap asset takes up memory. If this were done using a shader there would be no memory hit, but using this method requires 6 textures - one for each face of the cubemap.

After getting this effect on a lot of things in the game and some tweaking and tuning, I made some screenshots / wallpapers of the rimlighting in action for everyone to enjoy. They come in 1280×720 and 1920×1080 flavors:


click -> 720 , 1080


click -> 720 , 1080

click -> 720 , 1080

Champion Circuit and first look at kart driving

Since getting back from our holiday hiatus, we have been working on our vehicle physics as well as a new track to test them on. Here is a look at another new track, Champion Circuit, as well as a preliminary glimpse at the basic implementation of our driving model using Bullet physics. Still lots of things to come! Click here to see the video in higher resolution on vimeo.


Zero Gear - Champion Circuit from marshmonkey on Vimeo.

« Previous1 ... 1516171819202122Next » (215 total posts)