A good logging mechanism

Nostalgia:

Sometimes I tend to feel nostalgic thinking about the phase of development for Nintendo Wii, 3DS, GameBoy and J2ME. Things are so different now. Mobile is the mantra. Every damn game has to be on the device. iOS, Google play, Amazon, Windows and what not. After all, it is the bread and butter for most gaming companies.

Realization:

What is scary is the competition and the need to develop and roll out something quick. The speed of development has increased, thanks to amazing game engines like Unity. So, we had rolled out so many games for different platforms very quick; the scale of the games became bigger and bigger and we realized we were missing one crucial element in the framework. A good logging mechanism.

Situation :

QA reports a crash issue.The log uploaded is clean. Development team concludes that its not the game and most probably a crash due to low memory. Issue is marked as good to go and a release is done. Users playing the game start complaining and the percentage of users reporting the same issue increases. It now becomes a P1 and has to be fixed in the next release. Dev team scrambles making e builds after builds to find the cause. The damage is done. Rolling out a new release is not easy either. We need to go through the approval process and wait for it to be ready before we can roll out other platforms.

Conclusion:
  • Identify areas of possible crashes and use a try - catch with the exception  logged to narrow down on what is causing it. As we all know, try-catch is expensive but it can always be disabled when a final build is made. 
  • Enable a console or a remote logger that dumps all logs to help you out with all the events that had happened before the crash. Dump memory values too.
  • Mask logs so you know that you care only about certain levels of errors. i.e warnings, errors, log levels specific to purchase, login, missions etc.

 




Comments

Popular posts from this blog

Authoritative Server - MMO

Code dependencies