Developer Letter #02
Back from holidays, and we are going straight into bug fixing phase…
This blog entry is going to get a bit more technical, showcasing some of the challenges when debugging multiplayer game errors that are not easy to recreate as they only happen under specific circumstances.
So here’s what’s going on for the next version 1.0.25: We are working hard on improving the current codebase, to fix bugs and crashes, and improve performance in general. A big focus lies on enhancing our bug logging systems. We already do log lots of stuff to our backend servers. Please don’t be concerned about data privacy, because it’s only statistical data about your game, your multiplayer sessions, errors, and stuff like that. No personal data is logged for this! Some of these cryptic messages from us code magicians can also be seen in your favorite browsers’ log console - some Catan Universe versions even had enhanced logging on, so you (and our QA testers) were able to “read the matrix” behind your Catan session.
Ok, but what do we do with all this data? At the moment we focus on our testers´ and uses´ error reports, find the correct multiplayer session by it´s Challenge ID (that’s the internal identification number of a specific game you played) and try to recreate what happened.
For instance, we got some reports of players joining an Auto Match game and, after some time, recognizing that they are not seeing the same map at all. They still can play somehow, but each client shows different tiles and value chips, so the entire session will come to a halt at some point… the game will reach a point where the wrong data is given, or data needed for some transaction is not there for one specific client.
From reading the logs, we could track down the issue relatively fast. The server logs of these specific sessions showed that game clients were really delivered three or four different game states on start. The bug was found relatively fast - an event listener not being removed in some certain situations… wait, what did he just say?
An event listener is a piece of code that waits for some specific event (be it “create the game state and send it to these three guys there… wait, four… it’s four!”). When that event happens, the code listening to it will be executed. To have it listen to something, you have to “add” it, or attach it to that same event. And at some point, you should of course “remove” that listener again. First, because listening to something forever is boring, and second, it can cause some serious errors later on.
Because what happens if you add a listener to an event, and then add it again, and then again? And maybe even a fourth time? - Yep, you guessed it… you hear some crazy echo sound driving you nuts. And your cool piece of code will be executed more often than you would expect… ê voila: here we have our four friends playing together, but not the same game. So we removed that listener for all cases that could cause the module to stop, and had clean multiplayer sessions again.
Ok, so we got this thing fixed… or do we? To be absolutely sure, I added some lines of code that will give us an alert in our error logs if maybe that event “go do your game state shizzle” will happen more than once per session again. Just to be sure. Sounds paranoid, you think? Yeah, but maybe at some point in the future... some not-so-skilled programmer than me could implement this super-cool new function... and by doing so will break something else... which re-invents this old bug from the ancient times that was already fixed by me? You know the story.
Ok, that’s it from the Denz and the dark side of software development. Have fun with CU!
P.S.: See the soon to be posted 1.0.25 changelog for more crazy bug fix adventure stories!