Eressea

Turn-based strategy game development

[eresseapbem]

Things that happen when I'm suffering Insomnia: I squeeze 5% out of the storage space required to store Eressea's data.

[eresseapbem]

Cloud Backup

I have kept meticulous backups of every turn from the three games I run. Before and after each turn, the data file, orders file and summary are zipped up into a .tar.bz2 file. This is essential for fixing bugs weeks later, because it lets me re-run a turn with the old data and watch what went wrong in my debugger “as it happens”.

The problem with these backups is that they sit on the machine in Germany that hosts the game, and I tend to do my debugging at home. Also, storing the current game data and the backups on the same hard disk is hardly redundancy. A weekly rsync between my home machine and the server would solve this, but my home machine runs Windows for a number of reasons, and so that’s not really an option. I could rsync to another machine in the house (I have a few Raspberry Pi for similar purposes) but then I still have to move the files from there to my desktop PC when I actually want to debug something.

Today I finally solved that problem, with a free Box (previously box.net) account. Box supports webdav, so it’s as easy a single curl request to upload my file to a shared folder, and the Box app on Windows will sync it to my desktop. Backup and local debug copies solved!

For future reference: to store the eressea.db sqlite database in a Box folder named Eressea, this is the curl command to do the HTTP PUT request:

    curl -n -T eressea.db https://app.box.com/app/Eressea/eressea.db 

Authentication with Box is done through a .netrc file on the host, because I don’t want to check the account password into github along with my backup script. cat ~/.netrc:

    machine dav.box.com login [email protected] password swordfish

Standards are great, and WebDAV support really makes the decision for which cloud storage service I want to use an easy one. The free account gives me 10 GB storage, enough for approximately 460 turns at today’s size of the game, so if I move them to CD backup frequently enough, I should never have to pay for storage. Nice!

[eresseapbem]

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.

[eresseapbem]

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.

[eresseapbem]

Maps and Coordinates

The classic Eressea game has an unusual coordinate system for hex maps. For the future, I’m going to go with the system that Tiled uses, and all my work on the hexmap already uses it. Speaking of the map, I owe an image of the work I did on the selection:

Now with new tileset, ripped from Magellan.

The map you see here is from Eressea, because while I was not updating this Tumblr, I worked on a new report format for the old game that would write JSON maps for Tiled. It’s incomplete, but my game can read it, and I already learned something important: There are several ways to draw the same data, and it is important to know whether the first or second line of hexes is staggered (indented half a hex to the right). My game now reads this information and displays the map accordingly.

So even though that export is not on my roadmap to an MVP, it was still useful because it showed me a bug in my thinking before fixing it became too expensive (in this case, only rendering the tiles and the selection needed to change, as well as mouse-picking).

[eresseapbem]

Map selection

I made a simple selection marker, controlled by keyboard or mouse clicks. It is visually a square, the mouse click boxes are not hexagonal, but it works. Good enough for today. Starting to get a bit antsy about making things other than UI. Watched two episodes of B5 today, and have Kingsman with Colin Firth lined up for an evening movie. Easter soon.

[eresseapbem]

Menus

I mentioned menus in my last post. Here’s how the main menu looks right now. It does not mark disabled entries in a different color yet (that’s on my TODO list), but it works.

What does not seem to work, however, are inline images in tumblr. Maybe it is a combination of privacy addons in my chrome going wild, but the images I insert into my posts do not seem to get uploaded. I had to link them from imgur in my last post. Trying this one more time...

Works when I’m posting from an incognito window (all addons disabled), so I guess that’s my own fault in some way. This is the kind of shit that keeps me from getting work done, because I just cannot let it rest...

Update: That’s it! Looks like HTTPS Everywhere doesn’t play nice with tumblr.com - I guess I can selectively disable it on this site? Mystery solved!

[eresseapbem]

Building UI Elements

I’m a day late with this update, even though I worked through the weekend. A week into this project, and I have already got problems with focus, but I have been able to get some UI elements to work.

The game is going to have a large map view with hex tiles, so the first thing I built was that. I will be using a modified version of the Tiles JSON format as my report format, and step one was loading that map from disk. I also prototyped that I could load it from a web server, but it’s a ways before that protoype will make it into my actual code. Here’s what the map looks like:

The map can be scrolled with the mouse, but needs an active selection and detail view before I can call it done.

I am going to need a menu that opens up when pressing escape from the main view, so I prototypes that as well, with a bitmap font that my friend Andy posted a while ago. So I can count the bitmap font class among the things I built, too. Then I prototypes a login screen. My current rough idea is that I will give players a hexadecimal code to connect to their position in the game, and combine that with a code generated by the app. Since I’m still a bit sketchy on the details and not quite there yet, I didn’t finish the dialog until I’m actually going to need it. For now, it is the first UI element I have that supports all the interesting inputs: keyboard, mouse and game controllers.

Last but not least, I tested the Android version of LÖVE with the hex map, and made sure that I could get the game running on my phone. Overall, I’m still pleased with the technology choice, even though I seem to be building very much from scratch. I hope to finish the hex map for my next update, and then move on to communicating with a web server for map data by the end of the week.

[eresseapbem]

Client Technology

With the decision to start writing the client first came the question of client technology. The existing Eressea client, Magellan, is written in Java, and even if I wanted to use some code from it, I would not be able to run it on a mobile device. I also do not know the code base, since it is mostly written by player volunteers.

So unlike the server situation, there is no reason to stick to the language used in the past, and I am free to choose whatever I want. The real constraint here is mobile, and the options that I know of are Cordova/Phonegap (HTML5 and Javascript), Unity and LÖVE.

Cordova is the only one of these that I have practical experience with, and while it’s a great choice for an app with a lot of UI, it is not what I would choose for a game in which I want to render a lot of bitmaps. I am also not a huge fan of Javascript. Unity is hot with other indies, but it is a 3D engine first, and there is a learning curve that I do not feel like scaling right now. I would also have to brush up on my rusty 3D math, just to make 2D projections. That seems like a waste. On the other hand, Unity skills are very marketable in the game industry right now.

Finally, there is LÖVE. I had only briefly looked at it before, but it looks exactly like the engine that I had always wanted to write myself: Built on solid, industry-proven, portable C libraries (SDL, PhysicsFS, Box2D), with Lua as the programming language, and Android and iOS ports in addition to the desktop releases. There is an active developer community, and an IRC channel where people answer questions. I think it’s charming, so I wrote a few prototypes for key technology (networking, UI, controller input), got a simple map viewer for Tiled to run on my phone, and decided that my search for technology was over.

[eresseapbem]

Legacy Code

The first days on a new project are always exciting. I initially spent a lot of time thinking about how the rules of the game will have to change, and my instinct was to write the server code first, because that is what I already know and feel comfortable with.

The first obvious question is what language I want to write this in. I have gotten a lot of complaints from people that Eressea is written in C, but I am very happy with that choice, especially since I have gotten to a point where everything high-level is now written in Lua. I am very comfortable with that language mix (C plus Lua), it is very portable, and I already have great tools to work with it that I know inside out. In short, I see no good reason to throw 18 years of experience by the wayside, just to try another language. Especially since I’m not likely to collaborate on this project, but plan to write all of it myself.

I have two code bases that I can work from. On the one hand, there is Eressea, which is a super complex game with a lot of rules that I am not going to need. The code quality is really great, it has tests, but stripping away all the layers of rules that won’t make it into a “mobile” game is going to be a lot of work.

On the other hand, there is my incarnation of Atlantis 1.0, which is super simple, and free of cruft, but the code is not as great, does not have a lot of tests, and I would miss a lot of the conveniences I built into Eressea over the years, like the order structure that replaces the crazy string parsing in Atlantis. It has a slightly better build system, and the Lua code is in a shared library, while Eressea just embeds Lua in the main executable.

My conclusion at the end of the day was that I will probably start from scratch, and import the good bits that I need from either game. That means the Atlantis build system, new types for objects, regions, etc. that reflect the reduced complexity of the rules, and any useful utilities that I built into Eressea. I guess that also means that I will have a third code base to maintain, and I should be looking out for the second system effect.

Most of all though, my conclusion is that all of this server code needs to wait until I know the rules of the game. To find out what those are, I am looking at other games for inspiration, and have come up with a few basic traits that I want the game to have, but the real constraints will come from the client UI. I have never worked much on the client side of my games, so this time, I am going to start there. My next post is going to be about the technology decisions for that.

[eresseapbem]

Modernizing Eressea

Due to circumstances beyond my control, I’m finding myself “between jobs” again. This sucks, because I really liked the most recent product I was working on, and was finally enjoying work again. Job hunting sucks.

Instead of sitting on the couch, watching Ghibli films and feeling sorry for myself, I have decided to use my time off to finally put Eressea on some more solid feet, making it more accessible.

What that means for me is:

I want future games to fall more on the strategic end of the scale. There are already three active games that cater to the role players, and the hard-core strategy players are problematic, so I want to give them a separate game to play.

The game will have a friendlier client. No more textual orders, no more dependency on the JRE, no more email.

I am going to approach this with the goal of creating a commercial product.

There will be a mobile version as well as a desktop version of the client. 

To keep myself honest, and make sure I don’t get distracted along the way, I am going to try and update this development blog three times a week, whether I feel that there was progress or not.