Building a Logger for a Custom Particle System Generator

In my previous Debugging class, my professor posed a rather interesting question: how would you build a logger? What constitutes a good logger? What should a logger display? As with most things in life, it depends. However it still is something to think about. The question really got me thinking, more so because I have been working on my own special effects program that creates and updates particle systems. If I were to create a debugging logger for a program designed for said program, how would I do it and what would it include?

My experience with debugging loggers

During my first and second year of making games at UOIT, the only logger I became familiar with was the Visual Studios error log and console. The error log allowed me to see blatant errors and warnings, while helpful, can only go so far. The console was useful for using cout to display fail/success of loading, if something couldn't be found, and more. The console proved used but was still very limited.

During third year, we used an engine which utilized a logger, but lacked a console. It would print relevant information to a text file and not overwrite information from previous program executions. The logger had some useful functions, as I would print out relevant game information. While useful, I felt it lacking, and I knew there could be more to it to help speed the development process.

How I would build my own

When I would make a logger, it would have two primary components: a printed element and a visual element. The printed element would print information to either a text file, console, or both. This could range from whether or not a third part library initialized, if an asset loaded, if some arbitrary class initialized, or other wise. The possibilities are really limitless.

When creating a custom particle system generator, I need to consider what my program would be doing. For example:

• Number of different particle systems being updated
• If they successfully initialized or not and related information such as:
• Number of particles
• If assets for those particles loaded or not
• The name of each particle system
• If I push a button on the GUI
• If something goes wrong, how long in the simulation was it?
• A generic error function that prints as much who/what/where/why/when info as possible

Printing to a file for debugging

The reason why I'd want to know all of these things is so, if there ever is some kind of problem right away, I can open up my log and have all of the relevant facts to analyze. When a problem occurs, I can save a copy of that text file, repeat the problem, then analyze my logger to try and determine the issue. Here is a mock class I wrote to visualize my logger class.

Obviously this would not be the final product but it might use a lot of the functionality provided. What is important to note is the inclusion of the function error. Error's purpose would be to trigger upon something failing utterly, and subsequently print the who, what, where, why, and when, if possible. It can get the who, where, and what by knowing what part of the program it failed (for example, when loading an asset), when, simply being the time. Knowing why could be as simple as, "it failed to load a file" to something not being properly defined. However, the program may now always know exactly why, so sometimes we may have to take that part with a grain of salt, depending.

Printing to the screen for debugging

The visual element would display live data on the screen or to a console. This data could range from player position, CPU usage, FPS, number of entities within a vicinity of the player, game time, and more. This way, the debugging has the most critical data on screen.

A good example of a visual debugger in a game

Unfortunately a console is limited to pretty much just text. While useful, it overlaps the duty of a text file. I would still use it to print initialize data, but I wouldn't invest to much time in it. When making a visual element for my particle system generator logger, I would want this information displayed live:

• Number of particle systems, and how many are active
• Number of particles. 
• Total 
• How many are being updated all at once?
• How many are being updated by a particular system?
• Inactive particles
• CPU usage
• Simulation time
• Display the information of a singled out particle system.

Here is an updated class:

While it is not much of a change, the display function is going to have a huge amount of responsibilities. It will take in two pointers, particle manager and the active particle system. Using that, it would print relevant information to the foreground, so that it doesn't get blocked by anything on screen. Also, a simple key should be used to turn it on and off. I like to use the '5' key for debugging purposes. 

I would make it so that it prints any encompassing information, such as total particle systems, number of active, etc, to the top left. Below it, would be the singled out particle system data, and to the right, system data such as RAM and FPS.

Example mock-up live display debugging screen

Conclusion

One of the more important things I've learned from my game dev experience is that knowing how to debug is absolutely critical. I also know it can be a painful experience. When making a logger, I would try to make it in such a way that it would make fact analysis and information gathering easier. While what I've displayed is only a mock up, it gives across the right idea of what to think about when making a logger.

Thank you for reading! Hope you learned something.