ExEn is not brand-new code. It is effectively a fork of both SilverSprite and XnaTouch. So the question that a few people have asked me (particularly those involved in those projects) is why have I forked those projects, and not simply submitted patches?

It is a fair question, and a good question. To me it seems kind of rude to unilaterally go forking somebody’s project – and then to ask for community-funding for the fork! It involves being both effectively and actually critical of somebody else’s work, which is not something I normally like to do. So I better have a very good reason. I think I do.

~

First let me get my personal reasons out of the way: I think it would be fun bring an open-source project into existence and then manage it; especially one based around technology that I really love (XNA).

And I’m fascinated by the possibility of being paid to work on ExEn through crowd-funding. Companies like IBM pay people to work on open-source projects that benefit the company. So why couldn’t an entire community of developers pay someone to work on an open-source project that benefits that community?

~

Now for the more technical reasons for the fork:

The number one, primary reason is the sheer substantiality of these changes. I’ve submitted individual fixes to open-source projects before, but these have been patches of a few lines each. The changes that ExEn makes to its parent libraries are huge!

To give you an example, about 65% of the files in the “ExEnSilver” library (Silverlight-specific code for ExEn) are either brand-new or have been rewritten from scratch. The remaining 35% have also had fairly substantial changes as well.

The “ExEnEmTouch” library (specific to MonoTouch/iPhone) is harder to put an actual figure on, as I haven’t cleaned out all the dead code yet (I’ll explain in a moment). But most of the functionality that was rewritten for Silverlight was rewritten here as well (includes: rendering, audio, input, timing, game components).

The “ExEnCore” library, common to all platforms, is about 35% new code files. But most of the code that isn’t new in ExEnCore consists of maths classes that XnaTouch and SilverSprite got from Mono.Xna.

So because ExEn is so significantly different from its parent projects, it really ought to be treated as such. All the reasons that follow also double as explanations for why the changes that ExEn makes to SilverSprite and XnaTouch are so significant.

So the next major reason is differing project goals.

I couldn’t find any explicit statement of the goals for either SilverSprite or XnaTouch, but the feeling that I got from looking at their code was “completeness”. They try to implement every class and every function, but the upshot is that there are many things that are poorly implemented (buggy, slow). Worse still are entire classes that do nothing but throw NotImplementedException.

On the other hand the highest priority goal of ExEn is to be usable in production, which means it must be performant and bug-free. So, unlike its parent libraries, anything that cannot be (or has not been) implemented sensibly is simply removed from the API. By removing it, it allows the compiler to alert you when your game is depending on functionality that does not exist in ExEn.

So the creation of ExEn has involved the deletion of a lot of dead and buggy and slow code. This would be a pretty drastic thing to submit as a patch. (As I mentioned, I haven’t finished going through the XnaTouch code yet to determine which code is good and which is not.)

In the opposite direction, I’ve also added a few things, valuing performance over strict adherence to the XNA API. For example the “Hint” functions, that I describe in this article about ExEn on Silverlight.

The other important goal of ExEn is cross-platform compatibility. One important part of this involves the merging of the various platforms under the umbrella of a single project, which allows them to easily share code – not something easily done by submitting patches.

This also makes it easier to ensure that the APIs remain reasonably in-sync between ExEn platforms. You can see an example of this in my Marblets porting demonstration video: To make the XNA game run on Silverlight required removing a few XNA API calls that don’t exist in ExEn (which, as I mentioned earlier, were all flagged by the compiler). But after that, making the game run on the iPhone simply involved putting all the source files into a MonoTouch project and running it!

I think that, eventually, the ExEn platforms may have to go somewhat out-of-sync, as the iPhone is more graphically capable than Silverlight. But for now the highest priority features are those which can be implemented everywhere.

Finally, when I originally stated porting my games with SilverSprite and XnaTouch, I did not intend to fork them at all. I fully expected that I would make a few changes, which I could then submit as patches. But I quickly found that I had to make very substantial changes to make my games actually run – so I eventually ended up forking them internally for my own games.

After spending a lot of time working on it, it became apparent that ExEn was something that other people would also find really useful. I originally considered selling licenses for ExEn, but there are a whole lot of reasons why that is difficult to do. But then I stumbled upon crowd-funding and decided that this would be an excellent way to get ExEn ready for release and add substantial features like an Android port to it as well, while also allowing me to give something back to the community.

Of course, once ExEn is open-source, there is nothing stopping SilverSprite or XnaTouch from taking whatever code they like from ExEn. In fact – I welcome and encourage it! For such substantial changes, this seems like a far better way of doing things for everybody.