A Mini Map With Maximum Enjoyment

After getting Hikari working, we wanted to test it.

We wanted to create something we could use in game. Something that would be difficult or time consuming to create manually. We also wanted to see how well it held up. What better test than a Mini Map?

First, here is the Mini Map in action:


It was created by Dave's brother Ian and supports rotating, zooming, and any number of icons on the map. It was written in ActionScript 3 and is a Flash element that is being rendering in our game using Hikari.

It performs quite well. There is barely a FPS drop and it is pretty smooth.

You can see the full source here and the data file here.

Here is a quick summery of what I needed to do to get it working in game.

I call the ActionScript
loadMap(imageUrl:String, mapWidth:Number, mapHeight:Number):void
function from Lua, passing in the name of the mini map image, the width of the map in game units (1 unit is a meter), and the height (or depth in 3D).

I can then call the ActionScript
setPlayerPosition(x:Number, y:Number, rot:Number, zoom:Number):void
function, passing in the x position, y position (or z in 3D), the degrees rotated around the y axis, and a zoom amount (based on speed of the player).

There is a similar function for setting data related to other players called setObjectPosition().

From there Ian takes care of the rest and that means I have time to watch an episode of Dexter instead of writing a Mini Map in C++. Yay!

Hikari - In Game Flash GUI

It seems lately the Holy Grail of game GUIs has been Flash. Scaleform is an example of a commercial GUI based on Flash. This does not work for indies because of the cost.

Hikari is a great option for Ogre users. It was just released yesterday and I already have it integrated into Zero Gear. It is still new and needs a little work but thanks to it being open source (LGPL), we should start seeing a lot of support from the community.

P.S. One thing to mention is Hikari only works on Windows.

You can't do it alone...

...unless you have some help.

Zero Gear is being created by two people. One artist and one programmer.

That is not entirely true however. We are making use of many, many tools to help us create this game. These tools have large communities of people creating them. I wanted to give some credit to these people and also just show how we are doing this so others might see how they can speed up their development with free tools.

Programming Language:
C++
C++ is a very popular programming language and we use it. Most of these tools (not all!) apply to C++.

3D Rendering:
Ogre3D
Every game needs to draw stuff on the screen. For 3D graphics Ogre is a great library. It has been in development for 6 years and been used in a lot of projects. Check it out, it will make your life easier.

GUI:
Navi
Navi is fairly new but a great solution if you want to get complex GUIs in game very fast. It uses the Gecko renderer (Firefox uses this renderer too) to render webpages to a texture. This allows you to create a GUI in something like Dreamweaver or any standard HTML, CSS, JavaScript tools. The only catch is that it is a bit slow for any real time displays. Note: This only works with Ogre.

Particles:
Particle Universe
The very FIRST thing that any game should have is PARTICLES. This is a great system to create awesome looking effects quickly. I am told that an editor is in the works. Note: This also only works with Ogre.

Texture Maps:
xNormal
xNormal is a great little tool that is kind of the swiss army knife of baking and displaying maps on 3D models. We use it to bake Ambient Occlusion into the textures of many of our models.

Physics:
Bullet
A game where nothing moves isn't very fun. Bullet will make things move. You can see it in action in our last video.

Networking:
ENet
ENet is a simple UDP networking library. It is a layer on top of UDP that adds reliability and ordered packets when needed and basic connection management. It is great if you want something easy to use but plan to implement most networking features yourself.

Network Prediction:
EPIC
EPIC is a class to extrapolate the players on the client past the most current physics update from the server. See this great article for some tips on how Valve does this.

Scripting:
Lua
Lua is a scripting language we have embedded in our game. We plan to have all gameplay coded in Lua. This will mean that it will be very easy to add new game modes, items, GUIs, animations, etc during development and perhaps even allow the community to create these too. It also helps speed up development as we don't have to recompile the game every time we want to change a single value or algorithm.

Script Binding:
luabind
luabind helps us connect Lua to our game. It uses C++ templates to generate binding code for your classes (Really good use of TMP!!). There are a few options for doing this. We decided luabind was best for us.

Script Debugger:
Decoda
This is a great tool to debug code written in Lua. It allows the standard debugging operations such as call stack, breakpoints, watch, etc. It is great if you have a lot of code written in Lua and you aren't a perfect human. This is not free however (but it is cheap and useful!).

XML Parsing:
TinyXML
XML is a really great way to store data in a human readable format. Just use it...

General Code Support:
Boost
Boost is actually a large collection of different libraries for C++.
We use:
shared_ptr
bind
function
signal
I will have to do another post about these as they are a bit more complicated...

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.

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.

I wanna pick the color

In taking the kart color concept a bit further, we spent some time last night working on a color picker GUI. You can see the results of our work in this video.


ZeroGear color picker from marshmonkey on Vimeo

Now here is why this is cool. We did this using Navi + Lua. The C++ framework only needed slight modifications. I feel this was done extremely quick and has a nice, clean result. Here is how we did it.

We got the color picker html + javascript code from here.

And here is the part that I added to the color picker javascript:

function HSVupdate(v)
{
  var tempColor = HSV=v?v:slideHSV;
  v = hsv2hex(tempColor);

  $('plugHEX').innerHTML=v;
  $S('plugCUR').background='#'+v;
  $S('plugID').background='#'+v;

  $ND('HandleEvent', {LUAFUNC: 'SetKartColor', Color: v}).send();

  return(v);
}


This function is called whenever the user changes the color in the GUI. The line that starts with "$ND" is the message from the Navi GUI to Lua. "$ND" is the javascript code included with Navi that sends the message. "HandleEvent" is the function that Navi calls in C++ and LUAFUNC is the Lua function that "HandleEvent" will call when this event happens. "SetKartColor" is the name of the Lua function and it is passed the new color as a parameter.

Here is that Lua function:

function SetKartColor(guiArgs)

  local colorValue = GetNaviMultiValue(guiArgs, "Color")
  local color = colorValue:str()
  local colorNum = hex.to_dec("0x" .. color)

  local red = bit.brshift(colorNum, 16) / 255
  local green = bit.brshift(colorNum, 8)
  green = bit.band(green, 255) / 255
  local blue = bit.band(colorNum, 255) / 255
  local alpha = 1
  kart:SetColor(red, green, blue, alpha)

end


It is basically just a conversion function. The javascript code gives the color as a hex value in this format "4499FF". So I do some conversion with this lua bit library to get the color as red, green, and blue float values to pass to the C++ code.

And here is the SetColor C++ code that changes the color of the kart:


void OGREPlayerKart::SetColor(float red, float green, float blue, float alpha)
{
  Ogre::Entity * testEnt = kart->GetEntity();
  for (unsigned int i = 0; i <>getNumSubEntities(); i++)
  {
    Ogre::SubEntity * testSubEnt = testEnt->getSubEntity(i);
    Ogre::MaterialPtr testMatPtr = testSubEnt->getMaterial();
    Ogre::Technique * testTech = testMatPtr->getBestTechnique();
    Ogre::Pass * testPass = testTech->getPass("ColorTweak");
    Ogre::TextureUnitState * testTUS = testPass->getTextureUnitState("ColorTweak");
    testTUS->setColourOperationEx(Ogre::LBX_BLEND_TEXTURE_ALPHA, Ogre::LBS_MANUAL, Ogre::LBS_CURRENT,     Ogre::ColourValue(red, green, blue, alpha), Ogre::ColourValue(1, 1, 1, 1), 0);
  }
}


This C++ function is where I want to improve. I want to support changing colors on different parts of the player and karts (shirt, skin, paint, windshield, whatever). Also, different karts will have different parts that you can change the color of.

As you can see, this was all done in only a few lines of code. I bet you can see how easy something like a color picker is when you are using HTML/JS/CSS and Lua for your GUI.

Webify your GUI!

Alright, enough of this "art" nonsense. Time for some code updates!

I was looking for a good solution to creating a GUI system and found Navi. We have been using it for our GUI elements inside the in-game editor we are developing and I wanted to show my praise for the beauty that is a web-based GUI.

Navi is a GUI library for Ogre that allows somebody to create the look and feel of a GUI element entirely in HTML + CSS + JS and whatever else Gecko (Firefox's renderer) supports. Check out the Screenshots to see what this looks like.

Using Navi + Lua has allowed Dave to design GUI elements in Dreamweaver and me to code all the logic associated with it in Lua. This means that I only have to touch about 10% of the GUI related code which makes me a very happy programmer.