°SS1src

I believe it is time to consider what to actually do with the source release - regardless of whether we'll base any work on the Mac-release, or, more likely, on the source port that NDS promised. We've been waiting a long time for this and we should be prepared for when it actually happens. By this I mean to have a plan and strategy on how to work on the source to make it do whatever people dream of. Like, lens-flares, selfie-stick-screenshots, and automatic Instagram-status-updates on plot events. You get the idea. Because to get there, much needs to be done.

I have never worked on a large-scale open-source project with several people so far, which even has the added property of being legacy code by both of my known definitions. So, for my ideas I will rely on my day-job experience from working on safety-critical software, influenced & supported by agile processes and XP practices. I like to plan a little bit ahead, and also have an eye on quality. While this doesn't always apply to my private hobby projects, an undertaking such as working on a product with a legacy on its own like this one requires more care. You will hopefully agree on that.

While it is fun to dream about all the big features that a future engine would support, the base needs to support that - and here's where I have the most ideas for now. With my sketch I'm inviting you, all current and future devs alike, to chip in and work with this vision, both by contribution, criticism, and support.
For now this should be a high-level perspective and we want to avoid bike-shed discussions. At this point I'd rather like to form a cohesive community focusing on one engine, rather than seed the thoughts of early forks already.

Phase 0: Get a grip on the material: documentation

This is all about making the code itself accessible, which is already happening right now - the mac source can be a basis for this already. So I guess this phase is a parallel one to all others. It can also influence other phases.

Including:

• Filling out the cracks of ss-specs about all the resource files: This allows tool makers to work against a spec, rather than wading through sources. This also helps future engines for compatibility reference.
• A separate document, describing the engine itself. This is a two-parter: One about component diagrams and data flows from a high-level. From these you can learn the current code, and plan ahead for feature extensions. The second part is the (public) function-level documentation. Both can be based on Doxygen, with a PlantUML plugin for the diagrams, so that it is always close to the source.

If this Doxygen document is even integrated into the build chain (see below), then you'd have a current documentation each build.

Phase 1: A reproducible, common chain: from writing code to binaries

This is all about making the contribution-chain accessible to anyone interested, with as little friction as possible.
With this I mean things like

• A reproducible build chain. Ideally this would be a docker-based build that people can use to generate the binaries (at least for Windows).
• A "common" build system. Assuming we'll stay in the C or C++ world, CMake would be my first pick. This also allows people to work in their IDEs as it supports creating project files for most common ones - including Visual Studio on Windows.
• A defined set of styleguide and naming guidelines (rules). This includes a configuration file for an auto-source-format that is required to be adhered to. I'd rather have the fight once for the rules in the beginning rather than regularly at each pull-request. Shared code-ownership requires to give a little in order to enjoy many benefits. (As they say about the language-defined formatting rules of Go: "Everybody hates them, and everybody loves that they exist.")
• A unit-test system prepared, and hooked up into the build chain. I'm voting for google-test .
• Possibly a decision on compiler and version. I'd like to avoid chasing fancy new STL features, hardly supported by all compilers. My vote goes for C++14.
• Documentation (!) on all of these elements. Even if this is all automated, it should be documented how it works, and why.
• Some sort of task tracker. Could be Trello, or the new features of GitHub.

With all of that, people can come in, clone the repo, set up their IDE, code whatever they like, and then cross-check with the automated build-system before making the pull-request. Any everyone's contribution will look & work the same.

This phase shouldn't require any drastic code-changes of the base material (I'm not counting the one happy-day commit of the reformatting) - and not even thinking about any "quick fixes" or "fun features".
Even if we can't agree on all the later things, at least these fictional forks will have it easier.

Phase 2: Cleanup & Compatibility

This is about driving the code into a direction that supports new feature ideas (where it doesn't already).

This can include:

• Multiple platform support (if the NDS release doesn't already)
• Defining a compatibility mode that lets the new engine load old resources, and activate new features on new ones
• Separating game-logic from engine-logic: there are many object-specific hacks in the source. See if these can be extracted into data-driven behaviour for mods. The first mod is the original game.
• Finding component seams for adding first tests
• Removing any unused stuff, such as leftovers from other (unknown) uses of the engine.
• centralize constants and/or make them data-driven

This again might be something that runs parallel. Yet, the more that is completed before the big features, the better.

Phase 3: Big ideas

Now we can start to think big. Which features should it support? How to modularize the system for best efficiency? and so forth.
This is where my ideas become sketchy, because for one this is months away and depends heavily on public demand.

At least I'd see it relevant to modularize the engine through interfaces. Perhaps it is this phase where the bigger refactorings will happen. In my ideal world, we'd be able to have automated tests for the various components via their interfaces and a good understanding of the various dependencies.