NibleBit New Site! Update your bookmarks and RSS feeds!

We have finally got the new site up and running, and we have moved everything over to it! You can track all of NimbleBit's activities on http://NimbleBit.com

Our new RSS feed can also be accessed at http://feeds2.feedburner.com/Nimblebit

New Blog!
New Forums!
New Chat!
New GAMES!

So head on over!

This blog will no longer be updated. You will be re-directed in 5.. 4.. 3.. 2.. 1...

NimbleBit prepping for a big move . . .

... to a brand new NimbleBit world headquarters on the web! Brian has been smashing the heads together of technical kinks in Zero Gear, destroying bugs like a human RoboCop whose prime directive is to destroy all bugs. I have been prepping our new nimble nest to make room for all the extra content we are going to have as a result of a very special addition to the NimbleBit crew. More games! More games! More games!

here is a sneak peek:

Global Game Jam Postmortem

It has now been 2 weeks since the jam. I am finally making the time to write about it. As a side note, I posted to twitter while at the jam (I had very little sleep during the later parts of the jam so forgive any nonsense). Check our twitter feed starting from Jan 30th for those.

The Global Game Jam in brief was like a Lan Party but at the end you made a game instead of just played them. It was noncompetitive, the goal being to pump out as many cool games as possible. I went to the San Francisco-Silicon Valley jam and met a bunch of awesome people. I had an amazing time and definitely plan to do it again next year!

My teams room (no, that isn't a real person playing the guitar in the back, he is made out of cardboard (yes, it is a real person sleeping in the back, I don't know who that is))

LOCATION:

My jam was located at Cogswell College just south of San Francisco. They did an incredible job of running the event and supporting all the participants. There was always plenty of food/drink to consume and we never had any power or networking problems. They made it easy to concentrate on making games.

TEAMS:

There were about 35 participants at this location (hundreds of others around the globe) and we split into 7 teams of 5 people each. I think there were mostly programmers followed by artists and then a few producers and audio people.

Teams were initially (for the most part) chosen at random. You were free to move around and change up teams of course, however, it seemed like most people ended up staying with their random team which surprised me.

My team included:

Rob Jagnow: Programmer

James Hudson: Programmer

Jerome Bolusan: Artist

Dakota Hurst: Technical Artist/Programmer/Audio

and Me, Brian Cronin: Programmer

THEME:

The theme set for all games was: "Whenever we are together, we will never run out of problems".

The contraints were:

1. A complete play session must always last 5 minutes or less.
   
2. Have ONE of the following adjectives to incorporate in your game: thin, evolved, or rotating.

SCHEDULE:

The whole event went from 5pm, Friday, Jan 30th to 3pm, Sunday, Feb 1st (I was told there was some important sporting event on this day involving a pig's skin that is tossed around a field with the goal of avoiding large agressive men who wish to tickle you).

Friday night was mostly about meeting everyone and forming teams. It was also when we learned of our theme and constraints. This was so people couldn't start working on anything before the event (it was a 48 hour jam after all) but also to force us to be creative.

We had about half an hour to talk to our team members and come up with a game idea(s). Our team worked really well together during this process and came to an agreement on a game concept very quickly. We decided that the theme called for a 2 player game. The theme also implied working together while also competing against each other. We decided that the players should be tied together with a sort of electric rubber band while trying to collect more coins than the other player. We chose the rotating adjective by having the players make turns around the level, thus causing the camera to rotate with them (turned out to be cooler than it sounds now that I type it). Our final game idea was modified very little throughout the development process as you can see:

Here's one of the game's many wild TURNS!!!

After this short design meeting, the teams presented their ideas to the entire group and some feedback was given. After this, we all rushed to find the best room to begin work.

The rest of the night was about setup and preparation for the next very full day of work. We decided to use XNA for the project. Only 1 of us had more than a day or two experience of with it. We decided to use it anyway as part of the point of the jam was to use and learn new technology and methods. My experience with XNA was generally good.

Our team (except for Dakota who I suspect to be a vampire, warewolf, or something) went to bed around 2am that night so we could get some rest to finish the game.

Saturday was when we got most of the game done (It is mostly a blur at this point). We worked on physics, input, rendering (per pixel lighting and shadows = awesome), level design, modeling, menu flow, and probably a bunch of other stuff. There was a ton of energy and always a lot of work to do. It was a blast!

Sunday, some of us got some sleep and some continued to polish up parts of the game. It was all coming together and we were really excited. The most surprising part of Sunday morning was finally playing the game with somebody else and realizing it was a lot of fun!

After putting in some final polish and fixing one last bug, we all ran down to the auditorium to see all the team's games and show ours off.

We were very late to this final event. All my fault. It worked out though...

All the games were very impressive considering they were made in less than 48 hours by teams of people who had never worked together before. Each game had at least 1 unique and interesting aspect to it.

Considering I plan to do this again next year, here is a right/wrong list...

5 things that went right:

1. Very little team conflict, everyone was on the same page.
2. Game design and scope, we didn't attempt to compete with Halo 4.
3. Iteration, we used XNA and SVN which allowed us to quickly iterate game ideas.
4. Communication, everyone was in the same room and was able to work together when they needed as well as, for the most part, leave somebody alone when they were working on a vital aspect of the game.
5. Fun, we weren't struggling to make the game so we were able to have fun and enjoy the experience.

5 things that went wrong:

1. Level format + pipeline: some more thought up front in our level pipeline would have saved a lot of time later on.
2. XNA: it was great overall and I do not regret using it, but I did end up spending a large amount of time doing a few things that should not have taken so long (I speak only for myself on XNA).
3. Sound code: the actual audio was great but we had some issues later in the project related to stopping and starting a music track. It wasn't the end of the world, but it was annoying.
4. More time, the event was only 48 hours but because of the previously mentioned sports event, we had more like 36 hours, that meant we had less time to sleep.
5. More art help, we had only 1 dedicated artist and he definitely had too much to do, one more dedicated artist would have been nice.

In closing, it was a great Jam. I fully encourage you to look out for and take part in any future events like this. If nothing else, it was great to take a break from the big project and work on a smaller game for a very small amount of time.

SuperProfiler Speed Improvement and Bug Fix

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

If you find any issues, please post them to the bug tracker here: http://code.google.com/p/superprofiler/issues/list

SuperProfiler Update and Screenshots

I just updated SuperProfiler with support for comma separated value and XML output as noted here. There were a few other small changes as well.


This is an example of what you can do with the CSV output if you load it into a spreadsheet program:




And here is an example of what you can do with the XML output if you load it into an awesome program like the free XML Marker:




You can imagine how useful this can be I am sure.

Some things I plan to add in the near(ish) future are:

1. Real time data (view the performance of your code while running it!)
2. Per frame recording
3. SPIKE detection (just a way to mark a recorded frame specially if it took more processing time than the average)

SuperProfiler to the rescue!

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 SomeFunction1(void)
{
    SUPER_PROFILE("void SomeFunction1(void)");
    int lala = 2;
    SomeFunction2(1);
}

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!

Progress on Space Jump

Did a little more work on the obstacle-type course in between other things. Here is a little stitched together panorama of it (click for big)

Global Game Jam result: Coopetiton

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 their 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!

It is best played with 2 people (1 keyboard or 2 controllers) but can be played alone as well.

Our team had a great time making this game and would love to hear any feedback so please comment after playing!

Some screens:

Space Jump WIP video

This is a 4x speed run through of a map I am working on to test out a "gauntlet" type game mode where the goal is to be the first to get to the finish against the clock. We are planning on having checkpoints throughout the map so that if you fall off you can respawn. Brian is also anxious to add physical obstacles along the blank straight lengths that will move around which you will have to dodge.

In other news, I have found a new place to work on Zero Gear - a real actual office space shared with my brother, exciting!

Zero Gear now on ModDB.com

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.

Zero Gear on the webs

I have been on a little mini PR blitz lately, trying to increase awareness of our game. So far it has netted these little Zero Gear outposts on the tubes:

Zero Gear page on Gametrailers.com

A news story on N4G

A shoutout from Steve Streeting

A floundering Digg submission (DIGG IT!)

A post on independently-speaking.com

A link on The Awesomer

I <3 fake players

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!!!

New Character: Cacti

From the barren and windswept mesas of the desert comes our newest character Cacti. Say hello, but I wouldn't touch!