Logs serve a purpose, which is to help the developers detect, diagnose, isolate, and fix problems. When everything is running perfectly, you're probably not even reading the log.
So the question of what to log reduces to the question of what helps you solve problems.
Stuff that definitely isn't right: Errors
As you code a system, you'll naturally encounter possibilities that should never arise at runtime - like calling the
Attack() function with no target, or popping a game/UI/behaviour state off the stack and leaving it empty, or encountering an unknown/invalid message in an asset file or network packet. These are natural places to log an error to alert the developer to the problem (or, to halt on an assertion / throw an uncaught exception and crash the game on the spot).
Stuff that looks suspicious, but might be OK for now: Warnings
Other scenarios might be more ambiguous. You're missing an important parameter, but you can carry on with a semi-reasonable default. Or you're over-budget for a particular asset class or performance metric, but it might be tolerable if it's just happening in a limited part of the game or while work is in progress.
These are good places to log a warning to highlight the presence of an issue that merits a closer look, especially if it might not otherwise be visible (because of sensible defaults or because it's just one of many cumulative issues that are only game-breaking if they pile up).
You might, however, want to add a flag that lets you check if you've already warned about this and skip repeating it, so that you don't spam the log with warnings about situations that are actually OK.
(As an aside: it's also important to be disciplined about fixing warnings that turn out to be real problems, and exempting the situations that are permissible, so that you don't get in the habit of ignoring warnings in your console/logs. Seeing the project go from 0 warnings to 3 will catch your attention and you'll find what changed. Seeing it go from 103 warnings to 106 might not be so alarming, letting bad code/content creep in unnoticed.)
Stuff that helps you isolate a current or recurring class of problem: Logs
If it's not an error and not suspicious, then your default position should be: don't log it.
Logging has a cost, both in performance, and in attention. You might be surprised how easy it is to bog down a game by doing string processing and file IO in the middle of a reasonably hot loop somewhere. But also, excessive logging can actually make it harder to spot what's going on, because every system in the game is spamming the chat with conversations unrelated to the thread you're trying to follow.
So, if a current problem you're having would benefit from some logs to help you trace how the game state evolves into/through the problem case, add logs tactically to the places that inform that search. Once you're sure you've solved that problem, go back and remove / disable those logs.
If you find you have to come back to a system to re-add/enable logging repeatedly, that's a good sign those logs are useful for tracking down a class of recurring problems, and are worth keeping around more permanently.
For complex games, you might want to introduce a logging flag system, where via a launch argument or console command you can enable or disable specific subsets of log messages. So an AI programmer can launch with
-ai_log_enable for their routine debugging, and the graphics programmer with
-gfx_log_enable, and neither one is distracted by spam from systems they're not working on. Or even further, the AI programmer might want to enable
-ai_log_verbose to get super granular logs of individual actions/transitions when tracking down a thorny issue, that are otherwise too spammy to keep on by default. You can filter as specifically as you want, like
EnableLog(Sound_Played_Events), if that helps solve the kinds of problems your game projects tend to have.