Last week my copy of Anno 1701 for the Nintendo DS dropped in and I instantly remembered the happy days when I played the original version for the PC, Anno 1602. While the gameplay is pretty much the same, graphics have been improved a bit and the product circuits got less complex. While you may have needed two or three buildings to produce a certain good, now one or two are enough.
All in all its a worthwile game, which made me looking into alternatives and/or ports for the Mac OS. Sunflowers, the company behind the Anno series, never considered such a step (“market share too less significant”) and I don’t know of any other publisher, such as Aspyr Media, ever considered that either way. This is kind of sad, especially if you look at the gorgeous PC version of 1701 which was released last fall. Intel Macs now certainly have enough power to play those games, but even Steve itself doesn’t put the “almost no mainstream games for the Mac”-problem on a high agenda – which you may imagine if you look at the half-hearted try of Electronic Arts to support the Mac OS with games, which was, of course, vastly announced by Steve on the last MacWorld.
Now, one very interesting project which recently took my attention in this regard is OpenAnno. It seems that a couple of Anno-enthusiasts try to create a clone of the original 1602 version. The game is in very early stage, there is an editor written in Qt, and the game itself seems to be build upon SDL, making it suitable for cross platform gaming. However, like every Open Source game, the developer’s biggest problem is to find people who create kick-ass graphics and animations, and in general, get more attention by the community. I decided to give it a try and create some native mac binaries for the most recent version. This is not done in five minutes, given the fact that the SDL libs (they use SDL_image, SDL_mixer, SDL_gfx and SDL_ttf) aren’t installed on most user Macs and most of those libs are known to have other horrible dependencies. So instead of messing around with frameworks I’ll probably try and link all of them statically to the main application. PhysFS is another dependency, but this shouldn’t be too hard to integrate. Lets see how this goes, I’ll of course post news here if I get it done =)
Beside OpenAnno there are of course other projects which have my attention. At first guitone, where the development slowed down a bit recently, because I’m in the process of rebuilding the monotone wrapper in use again. Having the mtn process run in the main GUI thread seems to cause a lot of problems, sometimes it just doesn’t signal that output is available, so the GUI is stucked (this happens on my beloved win32 port). But I’m not saying that it works better on other platforms… OSX has similar problems. My current solution involves putting the QProcess in a separate thread which has a local task queue and which signals when a certain task has been finished. Thanks to the Trolls that signals and slots work across threads (they are enqueue in this case and are not executed directly), still, my new solution includes some ugly code parts, f.e. when I try to match the finished task to any of the signalled slots. Given a general signal like this
void taskFinished(MonotoneTask & task);
and any amount of consumer classes which have a slot for this of course makes the need for code like this
void Consumer::taskFinished(MonotoneTask & task)
{
// this is not our task...
if (task.getTaskNumber() != rememberedTaskNumber) return;
}
if one uses a thread-global task number to identify each of them. I’ve looked into various other solutions for this; what I basically need is of course a callback or something which only functional languages provide: lambda notations. But this is Qt, this is C++, so without getting your hands very very dirty (or throwing in big dependencies like boost) there is no way of doing safe, reliable, non-intrusive, cross-thread callbacks. But hey, if you know something I don’t know, I’d be happy to hear from you!
There are two other projects which have my interest, but I guess I’ll tell you of those in my next post – this one got already far too long =)