Skip to main content

Pick up where others left off

Digging through the dirt

My fascination with the Goblin Camp, and by extension Dwarf Fortress, continues. One of the first thing the team did was to implement the initial setup of Travis CI to the repository: I made the issue and linked the account for it, and Robert figured out the configuration file and got it to do something. Our plan is to use this to tell us when, in fact, the game compiles properly. It is spamming me now that the build isn't working, but one day, it is going to show me a green light. The next task was to dust off the 7-year old libraries and implement spanking new ones, starting from Boost. So first, I researched on how boost is included into the repository. There seems to be largely three ways to go about it: system-wide installation, copying over the full source code, and using modular source code. First, just to see if it would work, I replaced the old /vendor/boost folder with the most up-to-date version of full boost. It did not work. Well, it couldn't have been that easy, of course, so I decided to understand all of the boost functions used by issuing a command like the following: 
git grep boost:: | sed -E "s/^.*(boost::[^()<>& ;]*).*$/\1/" | sort | uniq
I also investigated all the boost libraries used by: 
git grep \#include.*boost | sed -E "s/^.*()/\1/" | sort | uniq
I was well on my way of getting started with the modular installation approach. Well...

Struck a £ vein

As soon as I had a list of modules to start looking at, Robert sent me an interesting link: a year after the original repository was abandoned, someone else tried to take up the torch and do what our repository is currently trying to do. In fact, he was taking the other approach; instead of taking the modular installation method, the project tried to use the system-wide installation for boost and libtcod. This method is attractive in that the repository is no long responsible for keeping the library up-to-date with necessary fixes, but burdens the user with the responsibility of taking care of more dependencies. The repository also moved the build system away from the complicated and less popular bjam to better documented CMake. With these favorable changes almost implemented, I was very excited to look over more of his conversation and find more clues to what steps our repository should take. That's when I found that ...

The mighty D puffs the mighty puff

Some other programmer, who seems also had an interest in the project in the past, had expressed his thoughts on the project.
I considered it at some point, but decided that the codebase is practically unsalvageable, and I don't have time or patience to rewrite it. The internal architecture is completely fucked, control/data flow is nigh impossible to follow sometimes, and I don't even want to think about the NPC class. Good luck, I guess. Consider starting over with a better tech stack.
This was met, to my dismay, a positive response by the repository maintainer.
I've taken a peek at the source code outside the build system and understand what you mean. After having compiled it and played it for some time, I came to peace with the thought that I actually like Dwarf Fortress. If I want an open-source alternative, it should be a clone, most probably with an unimaginative name, a-la FreeDwarf. A complete rewrite is not something I'm able to undertake these days.
So now we have a better idea as to why the follow-up repository, and possibly the original repository, was abandoned.

Going forward

As of this writing, the interest still is on reviving the project to our best abilities. Working with boost, or learning to at least deal with it, seems to be a strong skill set to have as many other projects had gone through the same issues in the past, and is currently dealing with the same problems. I made an issue and the subsequent PR to merge the goblin-camp-ng repository to our current repository. This way, we can maintain the hg-to-git conversion efforts, Travis CI configuration, and other issues/PR histories while also enjoying the progress made in the goblin-campe-ng. We still will have to make some significant changes to bring the code up-to-speed with 2018. We also have tried and failed the compilation of the goblin-camp-ng repository and have found few fixes to be made, so I will be creating those issues to be completed incrementally after the merge.

Links

Labels:

Comments

Post a Comment

Popular posts from this blog

Creating a patch for GNU GCC using Git

Overview and Target Audience The GNU GCC project followed a blend of a traditional method with contemporary git tools when it comes to contributing code, making the experience unique from some other, git-based projects. This blog post will explore different aspects of the process, helpful commands, and various scripts that would make the experience more pleasent for new contributors. While this blog aims to help new contributors get acustomed to the GNU GCC code culture and make contributing easier, it must be stressed that this is not in any way in-depth exploration of the process. This should help you put your first foot forward; the community will help you take the rest of the steps from that point on. This post also assumes the user is in a POSIX environment (e.g. Linux, FreeBSD). Git and GNU As stated in this phoronix post , GNU GCC made a full transition to git early 2020. As of this writing, the community seems to be adjusting to the new tools. GNU GCC hosts its own git serve...
Post a Comment
Read more

Debugging with GCC: GIMPLE

GCC and GIMPLE One of the very first thing GCC asks the GSoC applicants to do, even before writing the application, is to try various different debugging techniques using GCC. I was personally familiar with the basic, compile-with-g-flag-and-use-gdb method. Turns out, there's more: GIMPLE. A Simple but Non-trivial Program Problem Description The instruction asks to compile a simple but non-trivial program with some flags that generates debugging information: -O3 -S -fdump-tree-all -fdump-ipa-all -fdump-rtl-all . Because I was keep reading on ways to debug GCC just prior to the statement, I immediately thought "GCC" and tried make -j8 CXXFLAGS="-O3 -S -fdump-tree-all -fdump-ipa-all -fdump-rtl-all" . This was a mistake: turns out, GCC can't be compiled with those flags. Thankfully, GCC developers have a very active IRC channel for me to signal SOS. Resolution jakub and segher were quick to respond to my call for help. jakub: it isn't meant that y...
1 comment
Read more

Researching Awl Pike

Last time... In my previous commit, I had the pleasure of studying the guns and their ammo and how they are reflected in the world of Cataclysm-DDA. This time, the some members of the community were buzzing about a 3-meter-long pointy stick called awl pike. Awl Pike The awl pike is basically an extra-long spear designed specifically for use in a formation attack. A formation of 3+ ranks hold the longest possible stick at their disposal and poke the enemy that stands in front of them or charging at them. It is very powerful weapon against things that stands in front of them, but due to the need for formation and the shear unwieldiness of the weapon, it is not very versatile and adaptable to changing circumstances. In a one-on-one combat, the weapon would be very difficult to stay effective. How do I know all this? Well, there was the entire discussion about it in the issue page. Like I said, this kind of games brings out the geeks from their closets and provide the floor to sp...
Post a Comment
Read more