NimbleBit

“How long a minute is, depends on which side of the bathroom door you’re on.”
-Zall’s Second Law

You know the feeling of spending way too much time on a task and you just know the problem is the result of something really, really, really dumb? I do. I know that feeling well.

The past few weeks (ok, maybe it has been a couple/three months on and off all said) I have been trying to track down some jitter in the network system. Whenever a major event happened (like a new player connecting or sometimes when a weapon was spawned) the game would sorta lock up for about a half second. I spent a lot of time trying to understand this problem. I created many graphs plotting every network event, how long it took, when it happened, what type of event, etc. I created a test program to make sure the problem wasn’t in the networking library we are using. I queued up data on the sending and receiving end and tried to prevent too much data from being processed at once. I even did a code dance (Yes, this is like a rain dance but for code, duh. It looks like this).

So you can certainly imagine my shock to notice this line of code yesterday night at 6:10pm:

if (GetNetEvent())

Yeah, exactly. What was I thinking?!?!?!?!???!?!?!? This should OBVIOUSLY be:

while (GetNetEvent())

Anyone can see that just walking down the street (well, I couldn’t until last night, but anyone else could). In a nutshell (do all nuts have a shell?), network events were only being checked once a tick. So my code to queue up certain events was never really working. In a different nutshell, sometimes it takes a lot of time and a lot of effort to realize you made a really, really, really dumb mistake. That’s the way she goes.

Last week I spent the majority of the time re-working some of our race maps. After fine tuning our boost-giving mechanisms I had to add and move around some of the checkpoints in the map, as well as adding / moving some of the item boxes. We have been play testing every day which really helps highlight little things in the tracks that need to be tweaked. I also worked on a bunch of miscellaneous little art and gui tasks, creating a few new GUIs and item and gameplay graphics.

This week will hopefully be more playtesting and more little tweaks and additions.

Lots of progress with the NimbleCrew bunched together in our San Diego office last week! One cool feature I was able to implement in Zero Gear last week was the ability to add guiding forces to certain weapons to increase their effectiveness. You will no longer need extreme pin-point accuracy to ice or blow up other players. I also added a spectator mode which lets you watch others race when waiting for a new round to start.

Yesterday I labored to create a new weapon - the Repulsor Shield, which pushes all physical objects away from the player while active. The Repulsor can work as both an offensive and defensive weapon if used correctly! Also added was a new GUI element in Tag mode showing how close to winning the IT player is. This week I’ll be adding a graphical draft effect, fixing some race mode bugs, and whatever else comes up.

“Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you.” - Carl Sandburg

The start of last week was spent mostly on networking. I probably sound like a broken record but when networking is central to a game, it takes a lot of time to smooth out under all the different machine types and network conditions. I am currently working on some test code to make sure the middleware we use isn’t the cause of a specific issue we are seeing. I then worked with Ian on getting more GUIs working. After I binded the C++ GUI code to Lua script, Ian has been able to actually create the GUIs without needing to touch C++ code at all.

This week I am working more on my networking test code while taking breaks here and there to fix long standing bugs in our tracker.

P.S. A friend has recently launched the website for his new game dev company. Check out Final Form Games!

Last week I helped playtest ZG’s race mode a bunch. It is a probably a good sign when you go to test one thing and end up playing “just one more race” about 3 times before you get back to work. I also did a little bit of work helping to hook up some of the new GUIs in the game and refining them once I saw them working. I also started thinking about what kinds of changes I want to make to some of the race maps now that we have the race rules more nailed down, and I am starting to see what works well and what doesn’t in terms of course layouts.

This week I hope to mostly be helping hook up more GUIs in between tweaking maps.

Last week was a pretty productive one! Brian and I tracked down the bug that was creating Race Mode position anomalies which was giving me headaches most of last week. I also improved our race bot AI a bit, and even added a drafting boost award mechanism to liven things up. The end of the week saw me converting more of our GUIs to MyGUI which is where I’ll be picking up today.

“The only reason for time is so that everything doesn’t happen at once.” - Albert Einstein

The solution to last week’s console print slowness ended up being to thread the printing as Fabio suggested in the first comment. This resulted in about a 100% speed up. After solving that, I spent time on getting more of MyGUI binded to Lua so we can quickly make new GUIs for the game. I am pretty happy with the results so far. I also had a lot of fun generating graphs to help visualize problems in the networking code. Because network events happen so often and so quickly, it is hard to understand problems with simple printouts or through normal debugging. Below is an example of one of the graphs I am generating using PyChart:

This shows 1 second of time on the x axis and how long each event took to process on the y axis. The big streak of red dots (reliable data) from 34.218 to 34.718 represent a problem. The green dots (unreliable data) should still continue at a nice 50 MS interval throughout the red dot zone.

This week I am heading down to San Diego again to work with Dave and Ian. I am sure there will be plenty to do.

Last week I split my time between helping Ian test race mode and figure out some bugs in the placement system, and replicating / building GUIs in MyGUI’s layout editor. Once you get to know how the editor works it is actually very quick to create new GUIs which is a big plus for us. Here is a screenshot of all the GUI’s I made last week.

This week I will probably continue tweaking some GUIs as we try to hook them up, as well as continue helping test race mode.

With David’s help I spent most of last week going through Zero Gear’s race mode with a fine toothed comb and found some logic and game balance problems.

This week I’ll continue to work on some of the bugs present in race mode and then work to make it more balanced and enjoyable for all players.

Here is the low down on what we have been up to:

I think we can all agree that time is pretty important. Many parts of a game require time to constantly and consistently move forward. Time should not move backwards or take a break to tie its shoe. Turns out it is stupidly difficult to get reliable time readings on Windows. I have been dealing with this issue for a long time and I (hopefully) found the solution last week. The common methods did not work as we run a client and a server (so setting affinity wasn’t an option, bye bye QPF/QPC). I did other things too but have run out of time to write them down.

This week one of my top priorities is to speed up the build time. I have already started to get precompiled headers working which should help out. I also want to spend time on network optimizations and then there are always more bugs that need fixing.

Last week I created some new GUI elements for use in some of our game modes, as well as some new particle effects to spice things up as well. I also spent a day tracking down a really bizarre physics bug in our game or bullet which we were able to work around. I spent some time tweaking old maps we haven’t visited in awhile as well as re-scripting a few maps that needed some of the new things we have been adding to the game.

This week I am going to do more level work as well as any other polishing I can take care of.

Last week I reworked the “Tag” mode in Zero Gear to flip between “keep away” and “hot potato”. This should keep the tag mode more interesting and less boring. I also worked with Brian to try and improve the camera system. This week I have to do some writing but will be helping out on Zero Gear whenever I get the time.

Last week continued to be pretty constructive having everyone working from the San Diego office. Heres what went down:

Last week I finally got around to displaying an image when the game is loading. You will not be seeing this graphic for too long as currently Zero Gear loads super fast. Some code was added to make debugging easier. The server’s framerate is now displayed on the client’s network display GUI. It is now easy to see if the server slows down for any reason. I also added some very simple spike detection code to display when a game system (networking, rendering, sound, etc) slows down for some reason. So far the results have been… interesting.

This week I will continue optimizing, smoothing, and polishing. I also hope to spend some time on making the game build faster.

Last week was split between nursing a really bad cough and head cold and working on Zero Gear. I spent the majority of the week tweaking suspension and other physics values on the physical kart model. After days of tweaking the mass, wheel friction, suspension stiffness, compression and dampening, I finally arrived at a physical model that is much more stable than it was previously. You can never totally control what happens in a fully physical simulation, but we can try and help it in the right direction.

This week I will be working with Ian to continue putting polish on our existing game modes and general player experience.

Last week I got my feet wet in the Zero Gear Lua script code by implementing “air steering” so the player can control the rotation of their karts when in the air. After that I spent the majority of my time reworking the camera system to look a little nicer with plenty of help from Brian. This week I’ll be trying to fix even more Zero Gear odds and ends.