When to Move On

Posted on Sep 27, 2020

TLDR; unless you are genuinely interested in a project, if getting it to run requires a fair amount of inspiration and head scratching move on to something else.


For bug number 3 I decided that it would be a good idea to look at another codebase, lest I become complacent. So I started hunting around and one candidate project I came across was Civ One. This describes itself as

An open source implementation of Sid Meier’s Civilization 1 using C# and .NET.

Many years ago I was a huge Civ fan1 and this project seemed to be alive with a number of commits over the past month, so any PR I submitted would probably be looked at.

The ideal situation with a C# based project is that you get the repo, open the main solution in Visual Studio, hit F5 whereupon it:

  • Builds;
  • There are no warnings, and;
  • The main application launches and runs correctly.

For extra marks:

  • It has a test suite;
  • All the tests pass;
  • When you start looking at the code you begin to get this warm fuzzy feeling;

The application built, although there were some warnings and it took me a little while to work out which project I should actually run, as the root level project was not in fact the executable.

Once the application started to run I got a bunch of log messages indicating errors. Luckily there was a Contributing.md document, so I took a look. It contained a link to build and run instructions, however this was contained in the original repo from which this was forked. This matters because it seems as though the original repo is dead and this new repo is now the de facto tip. The build instructions state that the solution should be maintained in VS Code, although instructions are given for Visual Studio. Personally I like VS Code, but for a C# only project it seems an odd choice, especially considering the project’s age as Visual Studio is arguably significantly better for C# development.

These instructions contained no reference to the errors I was seeing (which would be the first thing anyone would see if they tried to run the project). The first errors referred to a bunch of missing game files. The Contributing.md doc said that I would need the original game files and that I would need to put them in a specific directory. I managed to find these here and put them in the folder. The errors remained. The debugger however was reporting a missing DLL. Naively I had assumed that the DLL was one of the original game files, but perhaps I had been mistaken. No mention was made anywhere of where the missing DLL named SDL2 could be found. A little DuckDucking indicated that this is a game library something like glfw. My first impression was that it had been abandoned, but it seems as though it has not.

I put the SDL2 DLL I’d found into the binary directory and to my delight the exception went away and the application started to run. The application now prompted me for the location of the game files and then copied them into %LOCALAPPDATA%. Having done this it got to the main game menu. I clicked on the item to start a new game and after showing some pictures of a planet in a dust cloud the screen went blank and remained that way. I took a look at what was going on, but games are particularly hard to debug as they run off events in a loop, so you can’t just step through the code to work out what is going wrong, you need to try to find the specific bit of the code that is not working and then try to figure out what’s going on with it.

In this case I guessed that after I clicked on the new game menu item a new instance of game should be created, so began looking for where this might be happening. I found a few lines in a file called Intro.cs that seemed relevant.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
protected override bool HasUpdate(uint gameTick)
{
    bool update = HandleScreenFade();
    if (!update && gameTick % 2 == 0)
    {
        _introTicks++;
        if (_introTicks % 30 == 0)
        {
            _introLine++;
            if (_introLine >= _introText.Length)
            {
                Destroy();
                Common.AddScreen(new NewGame()); // <-- here
                return true;
            }
            if (_introText[_introLine] == "_")
            {
                IntroPicture++;
                _introLine++;
            }
        }

        // chopped

Now I was able to set a breakpoint and on doing so discovered that the line marked <-- here was not getting hit. For some reason, that I didn’t bother to investigate, the _introLine variable stopped being incremented when it reached 4, however the _introText array contained 57 elements.

Rather than trying to resolve this issue I attempted to circumvent it by not showing the intro and going straight into the game, so the method became:

1
2
3
4
5
6
protected override bool HasUpdate(uint gameTick)
{
    Destroy();
    Common.AddScreen(new NewGame());
    return true;
}

Once I did this the game sprung into life and after messing around for a few minutes it looked like I would probably be able to play a game.

New Game

I should probably raise a bug on this, because there is definitely something going wrong here, but I’ve already spent longer than I was planning on just getting it running.

The conclusion that I came to is that this is someone’s pet project. They like tinkering with the code and are not particularly interested in anyone actually using it, the commit history bears this out.

I’m personally not overly interested in the project itself and the coding style is rather old fashioned. I’m glad I took a look, but I think that this is a particular rabbit hole I’m not going to go down.


  1. Despite having bought the most recent version I’ve never had the will to get beyond the early game, which in itself lasts hours. ↩︎