Game development is an entirely different beast to other industries. Marketing, development, and release are more tightly interwoven than in other sectors, with a lot of pressure to meet community-anticipated milestones and launch. As such, it’s important to have game engine logging and monitoring pipelines set up for your projects.
In other platforms, version upgrades and roll-outs tend to be sudden, with no definitive date set. That’s done for many reasons, but mostly to give engineers time to work as many kinks as possible. But the hype cycle complicates that with games. So game devs have to have visibility, perhaps more than most other sub-industries, into backend data like logs when building out and monitoring their platforms.
There are plenty of game engines to choose from. While future articles will compare the benefits and drawbacks of those platforms, this post is more neutral. It’s just about one thing: tracking down the logs. Logs aren’t always stored in the most obvious place, and it’s not (yet) standardized where they live. Additionally, there might be several different collections of logs, stored in kind in several different locations.
This post is about tracking those logs down quickly, with some helpful tips on configuration and essential data that complement those logs.
Unity might be the most popular game engine right now. As such, there are a few Unity log categories to know. Outside of logs from a specific device, the three main ones are package manager logs, editor logs, and player logs. While the three most common kinds of log will by default display in the Console.app utility, they are also recorded in specific files. Each one has specific locations depending on if you’re using Windows, Mac, or Linux. Instead of a chart that truncates the local address of the log files, I’ve decided to go with an easy outline so you can see them more easily.
- Package Manager Logs
- Editor Logs
- Player Logs
~/Library/Logs/Company Name/Product Name/Player.log
On a Mac, you can use the Console.app utility to access the above logs. This option isn’t available for Windows and Linux, though.
You can also write additional game engine logging messages using Unity’s debug class of code,
Debug.Log. For example:
Debug.Log("Message log:"); Debug.LogError("Tere has been an error."); Debug.LogWarning("This is a warning.");
Blender also deploys log files in different locations depending on the OS.
You can set a lot of logging options straight from the command line according to the docs. This includes logging categories, levels, and output. From the command line, you can actually enable multiple logging categories with the argument –log. For example, you can query window-manager logs (wm) and “undo” actions with the following:
--log “wm.*, *undo*”
You can mark an exception, logging everything except a specific categories with ^:
–log “*,^*undo*” #log everything except *undo* actions
Other options include:
--log-level <level>(set the level of log detail)
--log-show-basename– Only show filename in output and not the file path
--log-show-backtrace– show back traces for debug logs (and only debug logs)
--log-show-timestamp– Make sure logs include timestamps
--log-file <filename>– Set up a file to record log outputs
GameMaker doesn’t have the extensive list of log files that some other engines have. Despite that, they do ask users to be familiar with the location of the sole log file, ui.log, in case they need to report bugs (Help Menu > Report a Bug) to the GameMaker team. You can find this file in two locations:
If there is a crash, the software will provide an error report with the exact logs. There is a link at the bottom of this error window with that report:
First, you have to check
Enable File Loggingin the project’s Project Settings.
Source: Godot Github repository
The way Godot is configured, there is a setting called Max Log Files that you can reconfigure. Once that max is hit, the previous logs are wiped to save space.
Depending on how you install Godot, the default log path is either
user://logs/log.txt. If you’re not exactly sure or for some reason you can’t locate the file in either of those spots, you can go to Project > Open Project Data Folder to find it.
Finally, you should check the flag Export With Debug when you export your project or app.
You can also natively monitor your logs live. The command is simple, by entering the directory where the /logs file exists, then use the tail command.
cd projectdirectory/.../logs tail -f logs.txt #or godot.logs
With Unreal Engine, there is a process for instrumenting, then setting up logging for your game. Focusing on the game engine’s logging for now, Unreal uses a file logging analytics provider and the Visual Logger. It records visuals of the gameplay state that can then be reviewed as debugging output, during live play, in the game Editor. Of course, you can also review it later after a gameplay session.
You can also gather user retention data by instrumenting Unreal There are other analytics providers or provider plugins: Blueprint Analytics, Multicast Analytics, and Flurry Analytics.
Most code in Unreal will be in C++ or Python. You also have to accustom yourself to the Blueprint Visual Scripting system, which also defines object-oriented classes in the system. Unreal does include a translation layer to move code from Blueprints to C++. Depending on which code you’re using, you will find a number of engine logging-relevant classes/parameters in Unreal:
Not the Endgame: Game Engine Monitoring
This was only a brief introduction to the locations and some particulars about logging work in popular game engines. There are many more engines, and this post doesn’t cover applying metrics or traces to your development, testing, and production environments.
Thankfully, Logz.io is extremely durable for taking in logs and data from a plethora of services, both open source and proprietary. Subscribe for more posts on game monitoring that are on the way.