After a long bout of writers blog and researching some new debugging techniques, I finally decided what to write my next blog on. Rather than discussing a debugging technique, or a particular tool, today I thought it would be more useful and interesting to dive right into how industry professionals go about debugging their games and how we can learn from it. So this blog will be split into segments, the first will be a tool analysis, the second a technique analysis, of the debugging methods used by Cloud Imperium Games Corporation, the developers of Star Citizen.
Star Citizen and Around the Verse
Star Citizen is an upcoming space trading and combat game developed using the CryEngine. The game is truly massive in scope, featuring first person space combat, first person shooting, trading, building of ships, on top of that a persistent multiplayer universe with a galactic economy, NPC's, and more. The game is huge and debugging is an even bigger task. Every week, the developers give players an inside look into the game with a YouTube series called 'Around the Verse'. An interesting segment of the 40 minute YouTube series is called 'Bug Smashers', where one of the gameplay programmers, Mark Abent, will answer fan questions or debug actual problems in the game. What makes the segment so awesome is the combination of tools, techniques, and experience, that are used to, well, smash bugs.
Bug Smashing in Bug Smashers
What makes Bug Smashers such a fun segment is how well it connects to not only in class lectures, but the class textbook, Debugging By Thinking. In episode 15 of Around the Verse, a bug with the engine flare not occurring during ship engine boost is the focus of this weeks Bug Smashers. Upon a quick test in the games debug mode, we get a visual representation of the problem. It's quite simple, no lens flair from an archetype entity. Note: an archetype entity is based off a regular entity that specifies individual parameter values for that Entity. Very quickly, we get a peak at some of the cool tools necessary to debug problems like this.
The tools
First thing to note was the ability to hop from a test mode to an editor that feels a lot like a Maya scene quickly. Very easily was he able to test flying the ship, to a debug test scene. Next was that we get a look at a menu that displays a database that allows the programmers to easily keep track of 'archtypes'. This data base keeps track of all kinds of data, whether it be light information, entities to use, etc. So if some particular light gets set up in a certain way, the database will hold onto that for easy use to grab later on.
Next, was that this database was used to grab a lens flare entity that should glow orange. It was as simple as a few clicks to grab it and place it in a test scene. What is important to note is that because this is a database, any other programmer focusing on this problem can simply open up the scene and grab that same lens flare entity and begin testing. While that is awesome, there is more to it.
Thirdly, was when he was attempting to solve the bug, the game uses Lua scripting for lights and Visual Studios for compiling code. Every time the code would compile, he would reset the editor, hop back in the level, and go right back to testing.
Exploring the bug
Over the course of the video, Mark discovers a series of problems which he is able to quickly and efficiently narrow down because of the tools at his disposal. After discovering the Archetype was not receiving the proper information, he double checked the code and made sure that the Archetype was getting the proper initialization that it needed, and reran the scene. After recompiling the code, he discovered that the lens flare was working in the editor! Next, after testing it in a debug test scene of the game, he discovered it didn't work. Using the database editor, he was able to identify that the correct material wasn't being set correctly, which was a simple as inputting the proper file path for that material.
Why the tools are so critical
After watching the video, it was abundantly clear why these tools were so useful to the development of the game. The database was easy to use and visually appealing, with ample features. Essentially a list of all kinds of information, programmers would be able to easily create new entities or archetypes that are saved in the database, view critical information, change values on the fly (for example, brightness, color, direction), spawn copies, see material paths, and more.
From a debugging point of view, when running into problems, it is easier, faster, and less stressful, to narrow down and test problems that would otherwise take forever to debug. This can be used to quickly replicate and analysis potential bugs without a steep learning curve of the tools. The ability to quickly change entities and test them right away in a test scene is a very powerful feature. It cuts down a lot of waiting time and gives programmers the power to debug their code on the spot. When waiting time and stress is reduced, everyone wins.
What is so important about these tools is that they are organized, visually appealing, easy to use, and informative. When a tool has these properties, they can help in so many different ways that it will really help the team solve problems much quicker. When tools are lacking in some way, they can be stress inducing, cost the company more time and money, and possibly even prevent some bugs from being exposed, which is never good.
What I take back from this
When developing my own tools for games in the future, a database is something I would love to create. For my Capstone project, I want to create a database to view and edit story instances of the game, so that it is easy to not only set data for them, but to connect them all together. While the test scene might be a bit to much beyond my scope and not fully necessary, a database of all my information in an easy to access and visual way would be exactly what I could use to speed up my production. While it may take a lot of time to make a database editor for the project, the amount of time, and stress, it would save over the long run would surely make up for it.
Next week I'll be discussing the thought process and methodology used to narrow down the bug, as well as its in class application, how it relates to portions of the textbook, and how the tools made all of that possible. Thank you for reading, hope you enjoyed it.
No comments:
Post a Comment