NimbleBit

Just a quick update. Here is the change list:

• Changed from using std::string to using const char * to improve overall speed
• Changed SuperRoot::PopProfile() and SuperStack::Pop() to accept a name parameter, this helps SuperProfiler to find any mismatches in pushes and pops
• Added SuperException which is thrown if an unmatched pop is detected (really useful actually)
• Added SUPER_PROFILE_PUSH and SUPER_PROFILE_POP macros which are useful if you want to access SuperProfile from a scripting langauge that doesn’t support RAII (cough, Lua, cough), Still use SUPER_PROFILE whenever you can however
• Fixed a bug when there was no SUPER_PROFILE in a root parent function call (such as a main function). I would suggest not profiling a main type function, anything that only returns at exit

SuperProfiler is a library I wrote to help us track down performance issues in Zero Gear. It is open source so anyone can use it (and hopefully help make it better!).

You simply place a piece of code at the start of any function you want to profile and SuperProfiler takes care of the rest.

An example…


void SomeFunction2(int var1)
{
    SUPER_PROFILE(”void SomeFunction2(int var1)”);
    var1++;
}

void main(void)
{
    SomeFunction1();
    SuperProfiler::TextOutput textOutput(”SuperProfilerResults.txt”);
    SuperProfiler::Root::OutputResults(textOutput));
}


and in SuperProfilerResults.txt is…


Function List | Total Run Time=0 | Total Profiled Function Calls=2
—————————————–
void SomeFunction1(void) | Total Time=0.00 | 50.00% of time | Total Calls=1 | 50.00% of calls
void SomeFunction2(int var1) | Total Time=0.00 | 50.00% of time | Total Calls=1 | 50.00% of calls

Call Tree
—————————————–
ROOT
    void SomeFunction1(void) | Avg Time=0.0000 | Times called=1
        void SomeFunction2(int var1) | Avg Time=0.0000 | Times called=1


Simple and easy. Check out the Google code site for all the juicy details.

Let me know if you find it useful!

This weekend I (Brian) participated in the Global Game Jam in San Francisco.It was 35 people spending 48 hours (most of them awake) creating games. It was an amazing event and we all had a blast. All of the games were very impressive.

I plan to write more about the actual event but first I wanted to post the game that my team finished.
Coopetition
The goal of the game is to work with/against another player to collect the most coins. The 2 players are connected by a sort of electric spring. This means that each player has some influence over the movement of the other player.
Collect as many coins in your “wallet” without hitting an obstacle. If you do hit an obstacle, you lose the coins in your wallet. To deposit the coins from your wallet to your bank (the coins are safe in the bank and cannot be lost), go through a hoop that is the same color as your character. Going through the other player’s hoop will cause your wallet money to be deposited in thei

r bank. Each coin you pick up actually doubles the amount of money in your wallet. So play it safe and deposit as often as possible or walk on the wild side and try to save up for massive profits!

Read the rest of this entry »

now you can keep track of Zero Gear’s progress if you are part of the growing ModDB community.

You can check out Zero Gear’s ModDB game profile here.

Maybe there is a better term. A fake player is just like a real player as far as the server and other players can tell. It has no AI. It is just for testing. It exists only on the server. A lot of games have this feature (not claiming to have invented it or anything!).

I want to express my love for fake players. I just recently (yesterday) got this feature working in Zero Gear.

Here are some of the advantages to adding fake players to your multiplayer game:

• Makes testing bandwidth and other networking issues much easier. Even some gameplay code might only have a bug when there are X number of players on the server.
• Obviously a MMO would benefit from having fake players to test server load and whatever else those crazy MMO devs need to test.
• Profiling. Your game might work great with 6 people playing. What happens when there is a full server with 16? Physics might slow down, clients may not be able to render all those models, maybe too much data is being sent over the net. It is better to find these sort of issues before getting 16 real people together to test.
• Possible to translate the fake players into bots later. No promise of this for ZG! Since the fake player acts just like a real player, all it needs to do is send input to the server and the fake player is moving around.

The implementation was pretty easy after some code restructuring. I simply moved the client networking code (networking only, no graphics, input, sound, etc) into the server. Each fake player executes the same client networking code a real client executes and just like magic (Illusion, Michael), it works! This is because the server only really interacts with the real players through the network.

Overall I wish I would have gotten this feature in ZG a lot sooner! If you are developing a networked game, do it now!!!