The writings below cover a number of experiences and problems we've had in development, and changes we've made as a result. This doesn't cover concepts like game design, how to get a bazillion sales on Steam, or getting reviewers to like your game; instead, it focuses on the thing you probably spend most of your time doing - creating the game by writing code.

I've spent the last three years as the lead software developer on a freeware multiplayer game. "Lead" is a rather grandiose title for "myself, and another guy who has a little knowledge and chips in now and then". Unusually, I'm not the original developer; the game had been in existence for a bit over ten years before its creator decided to step back and hand the game over to some players with an interest in continuing development. I wasn't an active player at the time, but was invited to step in by a close friend who knew we had a similar background and thoughts about the game.

The game worked, but had numerous unfinished or buggy features, as well as issues with crashes, errors, and data corruption. The most important change we made here was to ensure that error messages were sufficiently informative to let us isolate bugs. In particular, getting code line numbers out means that almost any error can at least be instantly understood, even if recreating the circumstances around it needs a little more work. Our work has also included the removal of a lot of try/catch clauses in the code, which were either removing all helpful details of a bug and displaying a simple error popup, or simply ignoring it altogether, as an effort by the previous developer to make the game appear less buggy. Ensuring that unexpected errors do get raised (rather than ignored), and that any exception is logged to file, have really helped.

Having a good debugger to use, and more importantly the knowledge to use it, have been vital in then solving the bugs we find. Being developed in .Net, we can leverage Visual Studio's very well polished debugger (it really is better than any other language/IDE I've worked with), and follow through bugs in detail. For example, if we know a variable is being set incorrectly somewhere, but not where, we can simply watch every time that variable is changed until the issue occurs, and then see what's going on at the time.

Related to debugging, being able to recreate the game state is also a great help. For us, this simply translates to being able to drop in savegame files into a development environment and loading it to reproduce a problem. However, it took a little while to ensure that savegames do truly capture the game state, avoiding issues that go away on save and reload (this is a very common issue/"solution" I see mentioned all the way up to AAA games).

Together, these have allowed us to diagnose and fix almost every bug we come across. The rate of error reports from players has dropped significantly, from a few per week (and many more ignored by players) to only a couple a year from a playerbase of ~200.

The fact that we're able to debug so easily also hints at the fact that the game is always in a buildable state, and usually a near-releaseable state (although likely with some half-implemented features). As both developers and players, we're usually playing the game live on our multiplayer server with the latest cutting-edge development version. This probably isn't feasible for all games - an FPS game where weapons behave vastly differently between versions wouldn't be a good way to test this - but for ours, the game style and interaction between players is such that we can spot a bug, hop off to fix it, and get back into the game after a few minutes. For us, building the game is a single button click that takes only a few seconds - this really helps with iterative development! That build provides us not only with an executable we can run locally, but the installer we'd provide to players.

Another item that has helped with solving bugs, and making the game easier to extend, is the adoption of good, modern coding practices. The original codebase was littered with vast arrays of data, and a single in-game "thing" might have data scattered across 40 or 50 arrays, each of which had to be kept in step. Variable names were often incredibly difficult to decipher (we never deciphered some; we simply reverse engineered the behaviour). There was no separation of concerns or abstraction, meaning that everything had to be done in minute detail everywhere, placing a huge mental burden on a developer - one would often have to wonder "is this array by index, or by in-game ID, or by in-game ID minus 1000, and in any case, is it one of the ones that's off-by-one or not?". Furthermore, code was almost always duplicated if the same behaviour occurred in several places, often leading to a trail of code that had been copied, edited slightly, and then copied elsewhere; fixing a bug in those pieces of code was always very painful. To fix this, huge swathes of game logic have been completely rewritten such that an in-game "thing" is represented by a sensible object in code, removing many of the unwieldy arrays, hiding low-level logic away, and removing a lot of code duplication. This wholesale rewriting of certain areas also fixed a number of never-solved data corruption bugs, which must have been related to errors in the complex array manipulation.

Making use of external libraries and functionality has helped to reduce our development burden. The game originally had a custom-built chat server, which had lovely quirks like numbering messages from 0, and an annoying habit of dropping messages. This was simply replaced by a private IRC server, more than enough for our needs. A lot of low-level network code has also been replaced by external code, either from the standard library itself, or third party packages. Perhaps most criminal of all was that, through poor understanding of graphics programming, all coordinate transformations were done on the CPU, before sending the transformed coordinates to the GPU - anyone who's worked at this level will understand that simply providing transformation matrices to the graphics pipeline is both easier and faster.

Ensuring that new versions of the game are released smoothly for players is, unsurprisingly, important. Ensuring game data compatibility, or that old format data is updated to the new format automatically, is vital - for a long time, any update to a map within the game resulted in all player data for that map being wiped, which understandably wasn't very well liked! It's also been revealed to us many times that features we thought were rarely or never used were actually vital to some player's game experience, and equally, that features we thought were universally used are actually rarely used or poorly understood.

Unusually for game development (at least, based on what I've read elsewhere), we're slowly including automated testing into our development process. Unsurprisingly, this is difficult to do for a large, unwieldy codebase, but inevitably we've found that refactoring code and adding tests has both improved our understanding of features, and revealed longstanding bugs. In my day job as a professional software developer (not at all related to the games industry), I'd never dream of writing code with so few tests; I've got a way to go with this project yet!

That more or less concludes my stream of consciousness on things we've done to make our lives easier as developers. In several cases, these directly impact players too, and almost all have an indirect impact by virtue of providing a higher quality product.