So, this is the first blog entry that I’m writing after switching from Wordpress to Jekyll - less clunky, easier to maintain, static. Besides this little blog update, let’s take a look at what’s been cooking in the Duality game engine over the past months.

This is something from the “it kind of make sense that it exists, but it never crossed my mind to actually Google it” category.

Say you’ve been away from a GitHub project for a while and just returned to see what happened in the meantime. You’re a bit out of the loop and don’t feel like reading all 500+ semi-descriptive commit headings to get a rough idea, and there is no official changelog in sight.

One thing you can do to still get a picture is browse through closed issues on GitHub and as it turns out, you can easily filter them by the date range they have been updated last. When you then sort them by the number of comments as an indicator of scope and importance, you end up with a query like this.

There you go. Makeshift changelog for a time range of your choice.

Just a quick shout-out that Duality is going to be in a talk by Ondrej Balas at the Kansas City Developer Conference:

Won’t be able to attend the conference myself, but I’m super honored to see Duality on the list.

It’s about time to put another Duality development writeup out there, and with this one I want to try a slightly different form. Getting away from “the giant forum thread”, we’re back to the blog.

With the recently started Duality v3.0 dev branch and continuous updates to the stable v2.x versions, there’s a lot of progress both visible and invisible to people following the binary release chain. The purpose of this split in two different versions is to reconcile the two conflicting goals of backwards compatibility and forward progress: Updating the Duality version behind a game or plugin project shouldn’t break it, so while fixing and adding features is fine, removing or changing them is not. However, as the project evolves, the requirement to maintain the same facade and feature set adds up to a constant maintenance cost that makes some things harder and pushes others beyond the threshold of viability. Old code just needs to be cleaned up once in a while, polished and streamlined – and that is exactly what v3.0 is for.

Don’t expect tons of big new features, but an improved API and the groundwork for future improvements on a more fundamental scale. That said, I’m (on a nerdy programmer-think basis) pretty excited about the things to come. You can find the full list of v3.0 issues here, and an overview on what has already been done below.

An interesting C# feature that I just stumbled across by accident: You can provide a custom collection initializer for any IEnumerable<T> using an extension method. It allows you to turn something like this:

List<Vector3> myList = new List<Vector3>
{
    new Vector3(1.0f, 2.0f, 3.0f),
    new Vector3(4.0f, 5.0f, 6.0f)
};

into this:

List<Vector3> myList = new List<Vector3>
{
    { 1.0f, 2.0f, 3.0f },
    { 4.0f, 5.0f, 6.0f }
};

by simply providing the Add method that is required for collection initializers as an extension method:

public static class Vector3Extensions
{
    public static void Add(this IList<Vector3> list, float x, float y, float z)
    {
        list.Add(new Vector3(x, y, z));
    }
}

Definitely not something for everyday use, but I can imagine it could clean up some data-heavy bits of code a lot. It appears that this was introduced in C# 6.0, along with indexer initializers.