Memory Leaks

Eressea has a pretty simple memory usage pattern. It allocates a bunch of memory during startup, when it loads the current game data file and creates all the regions, factions, units, etc. and the new orders, then stays pretty much flat while it executes the turn, only allocating more memory for messages and auxiliary structures. Then, after the report is written, it exits and the death of the process cleans everything up nicely.

There shouldn’t be a lot of memory leaks in a situation like that, but the code is written with the intention of being able to load and unload data files from the console, for operations like building statistics over time, repairing one file based on data in another, etc. A recent example was “link every familiar in turn X to the same mage they were familiars of in turn X-1″. So while programmatic cleanup is usually not required, it is in a situation like this (after analyzing turn X-1, we should free it before reading turn X to apply the fix).

Another reason for working cleanup code is testing. Unit tests work best when running from clean state, so anything that gets created in one test should be destroyed at the end of it, so it won’t interfere with the next test. My favorite tool for finding leaks like this is valgrind, and recently it was reporting almost 1,000 leaks when run on the full unit test suite. I started a new feature branch to eliminate them, and after a couple of evenings of hard work, I have pared them down to one final leak in the parser that is really hard to track, and a bunch of static variables that are the bane of this code base. As can be expected when doing work like this, I found a number of small errors that were more than just leaks, and added a lot more test coverage, so this should cause overall code stability to go up. The work ended up in one giant pull request, and will be part of the 3.7 version of the code.

Plans Change

Last time I regularly updated this site,  my plans were to use my copious free time to create a mobile version of Eressea, or at least a game based on the same principles. That’s no longer the plan.

Eressea is less a game than it is a world simulation. In this, the original designers were correct. There isn’t very much good strategy game-play at its core, and many of the game’s elements are not in support of a war game, but for world-building and to give players other, self-defined, goals to strive for.

With that said, I don’t have a lot of existing game to build on. Building a mobile client was fun as long as I did it, but the total time required to build what I had in mind was going to be enormous. I was also having more fun just working on successive new releases of Eressea itself.

So the mobile project is dead. Long live the original game!

Some former players have started new factions this years, eking out a living in the ruins of fallen empires, trying to hold their own against the zombie hordes and finding some resources that they can mine, or older factions they can cooperate with. It’s a different way to play, but it seems to be working for some, and for the original game, it’s a better way to maintain the active player base than new recruits and growing the map.

That means my development work is now defined by bug fixing, new features, and occasionally tools for creating new worlds. When I’m asked, I try to support anybody who wants to run a game of their own. And those are the topics that this site is likely going to cover in the future.