Last week I discussed tools that were used by a Cloud Imperium Games
Corporation to help debug code for their game. Cloud Imperium's YouTube series, Around the Verse, gives people an inside look
into the company, and even a look at how the debug their code in a segment
called Bug Smashers, hosted by Mark Abent, a gameplay programmer at Cloud
Imperium. This week, I'd like to discuss debugging techniques used from two
episodes and juxtapose them with techniques learned in class. I will be
focusing more on the techniques and thought processes used to solve the bugs
instead of the tools used.
Bug #1: Lens Flare methodology
In Around the Verse, episode 15, the focus of Bug Smashers was on a bug
with the flare for engines not appearing. Before hoping in the code, he at
first begins replicates the problem both in the game and the engine test scene.
Stating the problem, lens flare archetype does not work in the game or engine,
and understanding how it happens, he begins to do some fact gathering by
understanding it only happens with the ship engines. Double checking the
database tool Mark has available, he checks to see if the flare works as an
archetype, and sees that it doesn't work. Next he checks it with a normal light
entity and sees that it does in fact work.
He enumerates and narrows down the possibilities by looking at the entity initialization,
and because Lua deals with the lighting logic, he was able to determine a
likely spot where the problem may exist. After narrowing it down to a likely spot, he sets
breakpoints to help determine the problem and discovered the properties for the
newly created archetype does not set the property tables at all. Writing two
lines of code to make sure it initialized correctly, he tested to see if that
fixed the problem. The test was a success and the lens flare works in the
engine test scene, but it failed to spawn in the game.
Fixing the lens flare in the game test mode was dealt with in a
similar manner. Knowing the problem, Mark checked the database to see if there
were any anomalies. Seeing right away that a material was not being set for the
lens flare, he set the right path and gave it a test in game and found it
worked. With the lens flare working both in the game and the engine, the bug
was fixed.
Bug #2: Texture error methodology
Video games cannot display high resolution textures all the time and
will instead draw out low resolution textures when higher quality is not
needed. In Around the Verse episode 5, a bug was causing the high and low
resolution textures of one of their space ship models to constantly flip,
causing frame rate drops and very noticeable texture flickering.
Initially, this bug was looked at by one of the graphics engineers who
discovered that the level of detail (LOD) calculations were being done twice.
The program would calculate the LOD once, then use the same values to calculate
them again, causing the switching. The changes incurred by the calculations
were causing a floating point error where the affected variables would change
so minutely, between 1 and 0.
Trying to replicate the problem, Mark noticed that the bug was only
present on static models. So if you have a flying ship, it would flip between
high and low textures properly. A static ship statue however, would flip
textures. Next, he enumerated the possibilities by looking at all of the
related segments of the LOD code and then began to use breakpoints to see where
discrepancy happened and eliminate sections where it could not have happened.
After finding a segment where the LOD's rapidly change, he checks the call
stack to see where the LOD is calculated. Working with the graphics engineer,
they were both able to determine the location of the problem and ensure the LOD
calculations were using the correct calculations. Once the LOD's were changed
to calculate correctly, a test was done in the engine test scene and the game
to determine if it was fixed. The test was successful.
Comparison to methods taught in class and key takeaways.
In both bugs, Mark follows a clear method for uncovering and solving
bugs that follows a similar methodology of the Sherlock Holmes method in the
class textbook, Debugging By Thinking. Here is a list of methods that I picked
up from the Bug Smashers portion of Around the Verse:
- Define the problem clearly.
- Gather facts about the bug.
- State a hypothesis
- Enumerate and eliminate
possible bug locations.
- Make a change somewhere.
- Run and test all cases.
- If failed, go back to step
2.
- Remain calm during all of
the above.
When debugging problems, it boils down to your tools and technique. It
is important to remember that it is not what you think, but how you think. What
I find awesome about the Bug Smashers series is the clear methodology used to
identify and solve problems. Reminiscent of the Sherlock Holmes method of
thinking, the way of thinking presented follows a clear logical path that can
used to test any bug. Software defects are not solved by shotgunning code,
guessing, or trying to hack in some cheap fix, but by a set methodology that
makes it easier and less stressful.
In class, we are taught about how different debugging tools are used to
maximum effect. Bug Smashers also demonstrates the importance and effectiveness
of tools when combined with a methodology for identifying and squashing bugs.
Tools should be easy to navigate, visually simple, and provide ample
information about what you are currently working on without being to invasive
into your program.
I took away three key concepts from Bug Smashers. One, you should have a
logical methodology that helps you break down a problem, identify it, and not
only solve it but understand why it was broken and why what you did fixed it.
Two, your methodology should complement the tool you are using, which for me is
the key take away from that portion of Bug Smashers. Three, don't panic. Not
once did I see a sing of panic, stress, pull hair, yell, curse, or anything
negative, during Bug Smashers. It is best to be in a calm and comfortable state
of mind when debugging big problems.
Conclusion
Bug Smashers is a very fun an interesting segment of Cloud Imperium's
YouTube series as it gives you an inside look of what it is like to debug for a
game in development. There is a lot to learn from the series as it provides the
viewer with some real case scenarios of what can go wrong during game
development, how bugs can affect the game, and how to go about fixing them.
Thank you for reading, I hope you enjoyed it!
No comments:
Post a Comment