Brief Introduction of the Dwarf Fortress
The
Dwarf Fortress is a well-established, closed-source, free game that has been continuously developed since 2006. It has inspired some of the most famous games, such as Minecraft. It is considered a rouge-like game, and it chiefly relies on ASCII characters to represent various parts of the game, although there had been many successful efforts to add more advanced graphics to make the game look more attractive. Despite the modest-looking graphics, the game is packed with many features including highly complex physics emulation (liquid and solid), path-finding of multiple characters based on various personal needs, and comprehensive mechanical construct emulation.
Curiosity that is about the kill the Cat
The game is closed source, so how it is designed and scaled is unknown to the public. That said, it seems to be a public understanding that the game, despite having many moving parts, is created to be a single-threaded program as was the popular paradigm back when Pentium 4 was around. Many believe, therefore, that introducing multi-threading to the code would make the game easier to scale against the current trend of multi-core systems. How much of this is true is unknown. I wanted to find out.
Behind the Locked Doors
It isn't possible to know directly if multi-threading would help the game. The source code is closed to us. Thankfully, there is an attempt at creating an open-sourced equivalent of the project, called
Goblin Camp. It seems to have laid some foundation to the effort. I am going to use this code to explore various modern techniques, including multi-threading, to improve performance and scalability. To that end, I forked the source code from its original bitbucket repository to the familiar github repository. That is also when I realized that the last commit was made 7 years ago for unknown reason.
Crazy Ideas
I do not know the exact methods of going through with this. At first, I thought of just brute-force the entire issue by finding every iterative loops in the code and try to apply OpenMP. Thankfully, professor Humphrey stopped me doing something so inefficient. Instead, he suggested that I look into data-driven analysis of the problem using a profiler. This is like a debugging process that keeps a record of the running process to provide the programmer a snapshot of how things work. This also requires that the code, left unmaintained for 7 years, to be compilable. Already,
one of the
laundry list of issues in its original repository is that one of its included dependency library, boost, is too outdated to be compiled by recent versions of g++.
Short-term Goals
Well, for better or worse, I ended up with a repository. I forked it thinking I would contribute commits back to the original repository, but shortly after forking, it dawned on me that such was not going to work out what with the project being abandoned. Therefore, it is highly likely that the exploration of the code will remain with my forked repository. Our forked repository. So my first step was to create issues of every tasks that I could think of to properly migrate and update the project, whether it be documentation or implementation. There are so many to do, even before we can start performing exploration or analysis of data. This is going to be one big yak. No, a mountain full of treasure, I am sure.
The Embark
This is a call-to-action. If anyone would like to join me in exploring various ideas to improve and get the open-sourced Dwarf Fortress, err I mean Goblin Camp running, come by the
repository. We will
embark on a journey. Sit, and be marry. If you would like, pick up a pick-axe or maybe a shovel and
let's go digging through the mountain of code. I swear I could smell
Adamantine nearby.
Comments
Post a Comment