Even though I'm not racist I hate the diversity of compilers and OS so I decided to use Boost for all the timing relevant functions. Within boost you have two types of clock:

1. boost::posix::second_clock
2. boost::posix::microsec_clock

Thinking which one I wanted I decided not to go for the high-performance clock. I only want to know if a message had timed out and if I should send another one.

A basic example of the code would be this:

class SendTask : public IClientTask
{
public:
    SendTask()
        : m_SendTimestamp(boost::posix::second_clock::universal_time())
        , m_SendInterval(boost::posix::seconds(1))
    {

    }
    void Tick()
    {
        auto currentTime = boost::poxix::second_clock::universal_time();

        bool sendAgain = m_SendTimestamp < currentTime;
        if(sendAgain)
        {
            // ...
            // Send message again
            // ...

            // Increase the next timestamp.
            m_SendTimestamp = currentTime + m_SendInterval;
        }
    }

private:
    boost::posix::ptime m_SendTimestamp;

    // The default delay is one second (decided by constructor)
    boost::posix::time_duration m_SendInterval;
};

Timing the above code I was surprised to see that sending a message using UDP over the loopback took about 0.5 seconds, which was at least ten times more than what I had expected. After checking my code multiple times and not finding anything I could only come to the conclusion that somewhere in my code I made a wrong assumption. So I wrote a little test to at least ensure it had nothing to do with boost and to ensure it was my code.

int main()
{
    while(true)
    {
        std::cout << boost::posix::second_clock::universal_time() << std::endl;
    }

    return 0;
}

Removing all the duplicate entries that were printed I found out that the time difference between each timestamp was around 0.5 seconds. This would explain why it would take so long before it would send again. I told its resend delay is 100 milliseconds it would take at least 0.5 seconds because of the problem with the resolution/precision.

But I was using the loopback (sending to 127.0.0.1) and although messages can get lost there it should not happen that often. Sure I could replace everything with a faster clock but I wanted to know why this delay occurred. Taking another look at the send code I noticed that the following line:

bool sendAgain = m_SendTimestamp < currentTime;

If the send time is in the past it would send and this is also true for the very first time. Changing the code so that it checks if the next send time is less or equal than the current time fixed it and the performance increased to 0.005 milliseconds since it no longer had to wait for the first time out.

Sure I could have saved myself a lot of trouble by replacing the clock with the higher resolution variant (after striking concurrency of my list this was my next guess) but I rather spend a few hours on figuring out what exactly is going on. It takes time now but in the end it should save me time when I come before the decision which clock to choose.

So I have been looking at alternatives like NoSQL database. NoSQL is not a formal term but in general it means "Not Only SQL". It's a new development inside the database world and one I think that is certainly worth looking at. The first SQL was created in 1974 which in our line of work is really old. I also want to point out that it can only be so old because it has proven it's value. NoSQL on the other hand is from 1998 and the most common flavors are Key-value and Document store and graph.

Document store is in my opinion the coolest one as you can often just dump the data in any table. You don't need to look at the format. This would mean that we can still freely define types but at the same time we can also have different values and parameters.

There is only one downside: Eventual Consistency.

I understand the reason behind it (delaying writes while allowing reads) but there are plenty of situations where it is not acceptable. Sure you can catch it in your application layer but again that is not what you want.

Currently I think the best method is using MSSQL where a row also contains an XML document.

The major advantages of working with Mercurial over SVN are:

• No unexpected merge (or merge conflicts)
• Developers can work independent of each other. They don't have to worry about commiting broken code, only syncing broken code.

There are two types of branching:

• Unnamed branches
• Named branches

Named branches are comparible to what we know from SVN. Unnamed branches are done when you have reverted to an old changeset and then make a change, they are like an automatic branch that occur where normally (in SVN) you would have conflict.

An example can easily be created by making a few commits, then revert to and old one because you want to try an alternative approach for a problem you were having and start commiting then. Once your done with the alternative you can decide which branch should be closed and which one should be continued.

When syncing your changesets with someone else, you make it possible to look at what the other has done without having to worry that your own code gets broken by the changes. For example you encounter a problem and notify another developer of it who tries to fix it while you continue work on your own problem. Once both of you are done, you can review each other code without having to merge. Then one is tasked with merging it while another continues with his tasks. Once done you simply merge again and you are done.

You can always sync your code with a central repositorie. It's not uncommon that you are working on a large issue which might take a day or two. With Mercurial you can still commit as you normally do and if only a central repository is backed up you can still push your changes to that location without interfering in someone else his work.

Another great feature is shelving. Simply put it puts your changes on a shelve. Imagine you are working on a feature and suddenly you have to put that on hold as your boss wants you to work on a bug. You can either complete what you were working on or revert all changes. With shelving you put those changes on the shelve and when you are done with whatever had a higher priority you can take the changes from the shelve and continue as if nothing had happend.

There are, as always, a few bad things about moving from Subversion to Mercurial. First of all, Subversion is linear which gives you a linear method of developing. Secondly because Mercurial automatically creates branches and you would have to actively control this by doing merges often.

Mercurial has a lot of nice features like being able to import from SVN (nice if you want to do a complete switch) as being able to rebase (similar to Git). Also Mercurial could easily be intergrate in our toolchain.

Since I mentioned Git, I would like to say that I have thought about it but decided against using Git. Git has no native version for Windows. Git was also hard to start with, heck, the installer alone requires several extra steps. As a developer I don't want to worry about the tools or how it should be used. Mercurial was ready with just a few steps and working with it is quite easy compared to Git which I was messing around with for a few days. So basically the choice was made on personal preference

Because of all those distractions I have decided that I will take some extra time, relax, smell the roses and stuff and then start again this month. The result is that I will be behind, but that is OK and knowning myself I will most likely catch up at one point.

Image from: http://www.studiohajo.nl/ (license unknown)

For my current project I was conflicted about what to do with the terrain editor. I had two choices, either create a seperate tool or integrate the editor in the game. The first choice always has my preference as a tool and a game have different usage requirements which is reflected in the way they are programmed. The second choice is also a risk in my opinion as you might couple part of your codes that should not be coupled. Decoupling them afterwards is, as many programmers can tastify, a pain.

However the advantage of combining the code is that I don't need to duplicate code or functionality. This is also the reason why I have decided to create the editor in the game. The cool thing however will be I can review the results of my work in realtime.

However before I can start working on terrain editing, I need to write the terrain code, which means that I need to start thinking about the culling acceleration structure and refresh the knowledge about terrains.

However I recall that at one time I was writing a fantasy story which was a bit heavy with spells and frankly I needed that to have that information to be written down as well. Now let's say you are working on a story that involves all kind of politics and parties. You can shove those under items, characters or locations. In fact you want to have the rightwing party to be seen as a completly different group.

So this night I was thinking about how to address this issue and finally I figured out that I will drop all support for items, characters and locations. The tabs with those really nice looking icons will thus be dropped.

Wait? What? You drop something because you need more of it?

Yes, because I don't know what you (or me in the far future) wants or expects from the project and a smart programmer is a lazy programmer.
However that doesn't mean that those features are lost. No, they don't exist yet but if you want them you can create them yourself.

It's going to be part of my CustomData system which I originally only wanted to use to give extra properties to characters. Now I'm going to give the user the control to fully create their own templates.

I look at the above idea what quite a bit of reservation, but I think that users, once they understand the system, are really going to like it. And for those who have difficulty understanding, I can always generate a few basic templates like characters, items and locations so that they can start working with the program to begin with it.

For now however I'm finishing the outline of the story and making certain that it works so that hopefully I can release the very first demo this week.

The reason I abandon Brick3 is because the system has become too hard to maintain and there are too many pieces of legacy code around for me to quickly improve it. On top of that Brick3 was the first incarnation of the Brick project series in 3D with some advanced features, the new way of memory management (a 37 MB instead of 2 GB). So I had expected I would need to rewrite it, even though I wanted to avoid it.

Brick4 will have unlike its predecessor cleaner code a new way to some things (XML instead of custom file formats) and it will make heavy use of the command and strategy patterns. This will allow me to developer faster and safer in the long run, although I fear that rewriting the application will have an heavy cost and that any advantage I gain will be lost to that.

The good is that this will allow me to revisit some off the old features and make some notes and see if I can improve it.

If I’m lucky everything should be rewritten at the end of this week and with even some more luck I will also have implemented a new feature. Guess time will tell.