Things that happen when I’m suffering Insomnia: I squeeze 5% out of the storage space required to store Eressea’s data.
Who needs databases?
eressea
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.
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).
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!
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.
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.
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.
Code Kata: Unrolled Linked List (in C)
The other day I needed a linked list for the umpteenth time, and instead of going with the old (data, next) pairs, I decided I wanted something a bit more efficient, like an unrolled linked list. This also provided a good opportunity to use the CuTest unit testing framework and do some test-first development.
The result is pretty nice, testing actually found a small bug, despite the fact that I was sure can do linked lists in my sleep, and I was so pleased with the performance characteristics (better cache efficiency and far fewer allocations) that I replaced all the lists in Eressea with it.
Code sample:
quicklist *q, *ql = 0;
int i;
// insert element at index:
ql_insert(ql, 0, foo);
ql_insert(ql, 0, bar);
assert(ql_get(ql, 1)==foo);
assert(ql_length(ql)==2);
// push element at end, get indexed element:
ql_push(ql, baz);
assert(ql_get(ql, 2)==baz);
// iterate over list:
for (q=ql,i=0;q;ql_advance(&ql, &i, 1)) {
printf("%p ", ql_get(q, i));
}
Code is on github. Use as you please.
Enno: Erklär mir das mit Deinen 7 Parteien mal, bitte.
Samurai: Ich verwalte lediglich ein paar Einheiten auf meiner eigenen Insel.
Enno: Erstens ist genau das Doppelspiel,
Enno: Zweitens sind die Adressen dieser Parteien alle nicht mehr existent,
Enno: Drittens bist Du der einzige, der für diese Parteien Befehle schickt.
Eressea Delays
Eressea reports will probably arrive later in the afternoon for some weeks to come. The turn deadline, however, is still 9:00 CET.
When the server is up and receiving emails, it will update this page which can serve as a crude check to tell you if your report (or that of your allies) has arrived.
To explain: After the recent outage, the Eressea Server is running on my home machine. this machine is not on all the time, especially not during the night from Saturday to Sunday. Since 85% of all turns get sent during this time, it means there is a lot of mail to process when I turn the machine on first thing Sunday morning. And it’s not always that I make it out of bed before 9:00 either, so expect to wait for your reports.