Twitter  YouTube  E-Mail  RSS
The One Man MMO Project
The story of a lone developer's quest to build an online world :: MMO programming, design, and industry commentary
Biggest, Baddest Bugs
By Robert Basler on 2015-11-23 02:19:06
Homepage: email:one at onemanmmo dot com

A couple of my biggest, baddest bugs fell this week. There are three different types of bugs programmers face: there are bugs where you can easily reproduce the bug and know right away what the problem is, those are pretty easy to fix. There are bugs where you know what the problem is but fixing it is a huge effort (usually because it is in a system made of dozens of massively complicated components.) Lastly there are the really bad bugs, the ones that aren't obvious and can't easily be reproduced. Those ones can take days.

I once worked on a crash bug in a Need for Speed game that took about an hour to set up, and it took 59 attempts to get the bug to reproduce one time. It turned out that the bug depended on the WiFi dropping a UDP packet. When that happened, two packets arrived in the reverse order they normally arrived in, generating a crash.

I had avoided looking into this first bug for quite a while because it was firmly in the last category (and also in one of the most complex sections of the game's code.) Every once in a while while moving from place to place, tanks would turn suddenly, go at a right angle to the path to the destination for a while, and then either continue on in the expected direction or drive right back to where they originally turned and then continue. This turned out to be two bugs with similar symptoms.

When doing long-distance pathfinding it isn't possible to calculate the entire path before the tank starts to move, so the tank tells the pathfinder in real-time how much of the path it has already completed. It turns out the pathfinder was revising the part of the path that the tank had already started to execute. This resulted in abrupt changes of direction as the tank's destination moved around the map. Even with the problem in sight, it took a number of tries over two days to get a working fix.

While I was testing that fix, the tank happened to be going downhill and to my surprise, the game stopped. The tank had tried to go through the bottom of the world. If the pathfinder generates a path segment that is very long, it splits the long path segment into multiple shorter segments. It turns out I messed up the math for this. If I split a given length segment into 4 parts they would be 1/4 the length, 3/4 the length, 1-1/2 thes the length and then 2-1/2 times the length. This would result in the tank driving in one direction a long way, then quickly driving back to where it started and then continuing on its original path. This particular time I lucked out because the unit was going downhill near the bottom of the world. When it went too far, instead of just driving back, it went through the bottom of the world and stopped the game.

Another bug that I thought would be tough to track down was one where after building a new building, it would take a random, unacceptably long amount of time before the building would appear on the client. The process of building a new unit involves scheduling, databases, multiple threads, serialization, replication, networking and more, all complicated systems I knew it would take a long time to debug. But I had a hunch, and it turned out to be correct. The client who created the unit wasn't actually very interested in the new unit because of where new buildings are placed off-map prior to positioning by the player. A one line change to tell the client to be interested fixed that right up!

I've also been looking into my last longstanding bug. Every once in a while Chrome drops all the parameters when submitting a form. There are a bunch of forms in Miranda's UI (including the Log In screen) so this can come up pretty much any time and usually results in a hang of the game. Up to this point I've worked around this using AJAX to submit the forms that exhibit this bug, but the better solution to this (and some other minor issues) is to replace Berkelium (which is limited to Chrome 9) with Chrome Embedded Framework (Chrome 48.) If I can get this to work, Berkelium was also the last thing preventing a future move to a 64-bit client.

New Comment

Cookie Warning

We were unable to retrieve our cookie from your web browser. If pressing F5 once to reload this page does not get rid of this message, please read this to learn more.

You will not be able to post until you resolve this problem.

Comment (You can use HTML, but please double-check web link URLs and HTML tags!)
Your Name
Homepage (optional, don't include http://)
Email (optional, but automatically spam protected so please do)
What color is the ocean? (What's this?)

  Admin Log In

[Home] [Blog] [Video] [Shop] [Press Kit] [About]
Terms Of Use & Privacy Policy