Let’s start with a little history: Development on ExEn started when I tried to use XnaTouch and SilverSprite to port an XNA game to iOS and Silverlight.

Up until that point I had been singing the praises of XNA, not only because it is a really fantastic library, but because it had this cross-platform support.

Of course, once I actually tried to use XnaTouch and SilverSprite I quickly changed my tune. Quite frankly the libraries were atrocious. Unusable. Poorly coded, ugly, buggy and slow.

Appalled, I started work on ExEn. It started from an amalgamation of XnaTouch and SilverSprite, but ended up being a near-complete rewrite. ExEn was created to live up to my very high standards. It’s performant, it’s has very few bugs – and none as blatant as its forebears, and it has a design philosophy that puts usability for real game developers first.

Of course, there is a wide chasm between a library for my internal use, and a library that anyone can use. So last year I experimented with crowd-funding. Thanks to contributions from the community, I raised enough money to take the time to work on a public release of ExEn, plus adding support for the Android platform.

The development of ExEn did not go perfectly smoothly – no software development project does. Adding support for the amazingly obtuse Android platform was especially challenging. But I think I did a pretty good job, and for the most part I enjoyed working on it. And the people who have been using ExEn for their projects have sent me nothing but praise.

ExEn is currently the best platform for porting SpriteBatch XNA games to iOS and Android.

As an added side benefit, since first announcing ExEn online, I have had many offers of contract work developing and porting mobile games using ExEn as the platform. (Incidentally, if you’re looking for a skilled C# and iOS developer…)

Sadly, all good things must come to an end.

ExEn itself is not a financially viable project for me. Not even remotely. Even with the contracting work it brings in, time spent working on it is essentially a loss for me.

This comes particularly in the face of competition from MonoGame. What once started out as XnaTouch, buggy and ugly, was endorsed by the Mono folks, renamed to “MonoGame”, and has seen its development accelerate at a tremendous pace in the last year.

My understanding is that MonoGame is still significantly buggy. Even as recently as this month I’ve had developers tell me they are switching to ExEn because they found MonoGame unreasonably buggy. And in spite of ExEn being a higher quality platform, MonoGame continues to acquire features, users and support at a tremendous rate. Not to mention: bug fixes. The simple fact of the matter is that they have way more resources than I do. Time is eventually going to make their library better.

(And on the Silverlight front, Silverlight 5 brought with it an XNA-based API for hardware-accelerated immediate-mode rendering, rendering some of the cleverest bits of ExEn obsolete.)

But this has been going on for some time now. What has prompted this blog post is that the iPad 3 (sorry, “the new iPad”) came out and I got a bug report. ExEn apparently has a problem with its automagic retina-display fonts on the new iPad. I suspect the fix is simple. But I can’t check it myself – I don’t have an iPad 3. (I figure that my iPad 2 is still good. I’m actually using it to write this post while I clone my failing HDD – another story.)

[UPDATE: This bug is now fixed in ExEn 1.0.1, Details]

Here is a screenshot (iPad 2 and iPad 3)

[UPDATE: This bug is now fixed in ExEn 1.0.1, Details]

Now – I could buy a new iPad – a significant expense for me and basically a loss when I consider that I have an otherwise perfectly functional iPad 2.

I also strongly considered crowd-funding the purchase of a new iPad – and perhaps even (in a fairly literal sense) buying some time to improve ExEn. In crowd-funding terms it’s a fairly small amount of money. I considered this so strongly that I actually shot the video for it. This option would still be a loss – this time of time. I would have had to put a large amount of work into the funding rewards and the funding drive itself – more than it would have earned back.

I decided, after a lot of reflection, to do neither. While those plans would have worked this time around, they are not sustainable. I don’t have the spare time or money to pour into ExEn development on a long-term basis (I wish I did). Even with the contract work that ExEn brings in it isn’t worthwhile. And I expect ExEn contract work will gradually dry up as MonoGame gains ground.

So rather than heading down this dead-end path, I have decided that it’s time to wind things up.

(I’ll still do what I can to fix this particular bug. I just won’t be spending money or an excess of time to do so. If anyone has a patch, I’d be very grateful.)

~

I don’t want to leave ExEn developers completely in the lurch. First of all, feel free to email me if you have any questions or concerns.

If someone out there wants to simply buy me an iPad 3, I would be thrilled to get ExEn to work as seamlessly there as it does on every other iOS device. Send me an email if you’re keen. (I know this isn’t as trendy as a sexy video and a crowd-funding project, but it’s a heck of a lot easier.)

Finally – and this is by far the most important - if you are a MonoGame developer: Please steal my code!

I would love to be able to tell all the ExEn users that MonoGame is a worthy replacement. So if you work with MonoGame email me and maybe I can help you integrate the best bits of ExEn into your library. You don’t even need my permission – ExEn is open source. (I haven’t looked at your code base for a while – but I’d love to be presently surprised to find ExEn code already in there.)

(Update: read my next post about nice ExEn features you can have.)

(Alternately, if someone out there is interested in taking over the ExEn project – and you have the time and skill to devote to it – I’d be happy to hand it over.)

~

Thank you to everyone who has supported ExEn. Together we made some fantastic software.

See you in the next project…

Comments

Mads Laumann

9:27 pm, Monday 26 March 2012

Hi Andrew

Sad to hear, but I totally understand you. You did great.
My suggestion would be to hand over ExEn to the community (by putting it on GitHub for instance) and have the community run it from there. It would be much easier for you to take in patches from people via Pull requests.

So make GitHub ExEn’s new home :)

Bilgin Esme

9:29 pm, Monday 26 March 2012

It’s very sad to hear that ExEn is dying. It was such a neat tidy piece of code and it was working as a well crafted clock. Andrew, I know that you’re quite exhausted with the work overload; but isn’t there a possibility of continuing the project if it’ll be crowdfunded satisfactorily? I’m sure that there are lots of satisfied ExEn users around here to be willingly contribute the project. After all, MonoGame is totally a new road to experience. There will be totally new performance issues, optimization tricks and bottlenecks.

Andrew Russell

11:07 pm, Monday 26 March 2012

Thanks for the kind comments, guys :) I’m particularly fond of the comparison of ExEn with a “well crafted clock”.

Mads: I could look into it. It is on CodePlex under SVN at the moment. Would GitHub make it easier to manage? (I’ve never used Git). Still, I don’t believe that maintaining ExEn separate from MonoGame can be a long-term solution.

Bilgin: I put a lot of thought into crowd-funding. But I do not believe it will work again. To be honest it didn’t really work the first time. The only reason I didn’t go broke working on ExEn is that it brought in enough related contract work.

If I were able to make a reasonable income from working on ExEn, I would love to do so. But unfortunately I cannot think of any way to make that work.

Mads Laumann

11:57 pm, Monday 26 March 2012

Well, GitHub ain’t doing the work for you of cause, but on Github everybody can Fork the code, do changes and then submit af Pull Request, which is MUCH easier for all parties to work with, than the “patch” stuff on a regular CodePlex.com project.

I’m new to Git (GitHub) myself, but I already see the potential.

Lately Codeplex have made it possible to use Mercurial (which is similar to Git as far as I know – I don’t have experince with Mercurial): http://codeplex.codeplex.com/Wikipage?title=Source%20Control%20Clients

This enables this Fork/PullRequest work-flow.

Again, this ain’t doing the work from you, but it’s mucher for contributers to submit changes and much easier for you to review and apply/merge into the trunk.

I follow these Code52 projects, if you heard of them, if you look at one of the projects you can see this work-flow a little better.
https://github.com/Code52

Well, I see I’m not good at selling this :P

Hernan

6:23 am, Wednesday 28 March 2012

Great job Andy! i’m already using ExEn. I totally undestarnd you, system mantaince is expensive.
I think ExEn is performant and It have very few bugs compared to MonoGame. I wish too MonoGame community take the best of ExEn… it’s open source’s spirit!

Mads Laumann

8:27 pm, Thursday 29 March 2012

Just discovered that CodePlex actually also supports Git now :)
http://blogs.msdn.com/b/bharry/archive/2012/03/22/the-future-of-codeplex-is-bright.aspx

Just a little FYI.

Jeff

12:54 am, Friday 30 March 2012

Hey Andrew, I’m very sorry to hear about the shutdown of ExEn… I didn’t get a chance to use it in any of my projects but I’ve been looking forward to the opportunity to do so.

Thanks for taking on such a large task. Too bad it didn’t work out but hopefully your next big project will do even better.

Victor

1:36 am, Thursday 20 September 2012

Even knowing that Exen is being shut down. I tried MonoGame and it still not worth using it. I’m going to use Exen.

Facto.

Linked from

  1. A year of being published – but what now? « Paul Harman's Weblog — 7:57 am, Friday 15 June 2012