PlanetX, multiplatform: iPhone development (Part:3) – MonoGame–what a mess… – #iPhone #WP7 #Xbox #XNA #Monotouch #XnaTouch

Here I’m publishing a discussion I had via email with Andrew Russell ( about his forking of XnaTouch project (now called Monogame) and the creation of ExEn.

The guy is a smart .net developer and XNA passionate, he had developed some games for Xbox and WP7 as an Independent Indy Game developer, and I invite you to go and download his games Dark: and Light Blocks

As many other .net developers, he’s trying to find a way to recreate the XNA framework for the iPhone and Android phone.
That would mean 90% code share between Xbox, WP7, Windows, iPhone, and Android, covering a huge percentage of the market.

Unfortunately (IMHO) he decided that XnaTouch (now called monogame) wasn’t good enough, and instead of improving it, he decided to fork it and create a total new product called ExEn (

His Idea is that “combining the work of a dedicated, paid engineer (me) with the work of open source contributors“ will produce a better final result.

While I do not disagree with that, and I think he’s doing a great job trying to finance himself to work full time on the project, I also think that forking the project, and spending time back porting bug fixes (1) from Monogame on his on personal implementation, instead of working WITH the open source contributors is a waste of brain power.

Have a read at hour conversation and let me know what you think.


Sent: Thursday, February 24/02/2011 12:28 AM
To: Andrew Russell
Subject: Re: ExEn vs monogame

Hi Andrew, a friend of mine just sent me a link to a link that talks
about you
The idea is uber cool, and as you might know you’re not the one working
on it, has in mind exactly your same target.
I heard Miguel de Icaza will be helping to port monogame to OSX App
Store too…
Is there any reason why you’re not joining forces with them?
I’ve been working with/on monogame for a few weeks now, and it’ seems
that most of the porting has been done,
but it’s like a mix of XNA 3.1 and 4 apis…
And they’ve now started to implement the android version
Have you already started with your development?
Is there any chance the 2 teams can work on the same codebase/project?
Hope the project will be very successful

From: Andrew Russell
Sent: Thursday, February 24, 2011 6:16 AM
To: simone basso
Subject: Re: ExEn vs monogame

Hi Simone,

It looks like MonoGame is, in fact, the same project as XnaTouch and
that they have very recently renamed themselves.

So, in fact, ExEn *is* MonoGame with a lot of patches to improve
performance and stability. (And a Silverlight port on the side!)

(Admittedly, in the time since opening the ExEn funding project, they’ve
fixed some of the worst bugs themselves. That’s competition for you!)

I am not aware of any current plans by Miguel de Icaza to help port
MonoGame/XnaTouch to any platform. I am under the impression that the
idea was suggested for iOS/MonoTouch at one point – but that no further
action was taken.

For the detailed reasoning why I forked ExEn from XnaTouch and
SilverSprite, read my blog post here:

If you have any other questions, I’d be happy to answer them 🙂


Sent: Thursday, February 24/02/2011 7:08 PM
To: Andrew Russell
Subject: Re: ExEn vs monogame

Sorry for not reading your blog before 🙂

I do not entirely agree with your choice (forking instead of submitting patches) because it seems to me a waste of brain power to create 2 frameworks with the same target (you said you want a fast and reliable framework while the monoxna guys wants completeness). You could have achieved the compile time errors on xnatouch by adding attributes to the unstable methods (something like the Onsolete attribute), helping them at the same time to improve performances.

What the community needs is a fast AND complete framework, without both those characteristics, the framework would be useless…

We developers are strange beasts..
We prefer to fork instead of communicating our ideas 😀

I was starting to work on a porting of a game from xna to monoxna, but at this point I’ll wait and see who wins between you 2 🙂

Keep up the great work


From: Andrew Russell
Sent: Thursday, February 24, 2011 10:52 AM
To: simone basso
Subject: Re: ExEn vs monogame


I wouldn’t worry too much about seeing who "wins". I fully expect ExEn
and MonoGame to end up sharing the best bits of code between each other.
Indeed, I will be looking to incorporate patches from MonoGame into ExEn
during development.

In theory you should be able to write a game for any of the three
platforms (XNA, ExEn, MonoGame) and have a fairly easy job porting
between them.

Regarding completeness vs performance: When I was developing ExEn, I
don’t think I removed anything in XnaTouch simply for being slow,
without replacing it with something better. The stuff that was outright
deleted was either NotImplementedException, or buggy – which, in my
mind, is even worse. So I’ve not really reduced the completeness level,
in terms of practical usage – just API coverage.


Sent: Thursday, February 24, 2011 11:04 AM
To: Andrew Russell
Subject: Re: ExEn vs monogame

Anyway, the stuff you deleted could have been marked as
[Obsolete("This method is totally bogus", true)]
So the compiler can rise an error if referenced by any 3rd party project
(like your game).

So it would have brought to the attention of the community that some more
work was required.

We could have had a more mature product instead, and a bigger team working
on the project…
I really do not understand why, if the frameworks are interchangeable you
wanted to fork the project and rename it…

Open Source is meant to bring people with the same targets together, not to
divide them creating fragmentation…
It just require a bit of effort from both sides, but it can be achieved.

Do you mind if I publish this email conversation on my blog?
I think it’s an interesting conversation for the people using both the


From: Andrew Russell
Sent: Thursday, February 24, 2011 3:42 PM
To: simone basso
Subject: Re: ExEn vs monogame

Regarding bogus code:

Really I think that there isn’t that much of a difference between
deleting the "bogus" code and marking it with an attribute. Remember
that deleted code can be brought back from version control if need be.

I personally think deletion is nicer from stylistic and maintenance
standpoints. Maintenance In particular, for ExEn – with such sweeping
changes, reducing the surface area helped significantly.

(Also removing all that code saved many kilobytes on my Silverlight
download size.)

As you say, attributes could act as documentation of unfinished APIs.
But that documentation could also be handled externally.

We could explore these tradeoffs in detail, but really I don’t think it
merits further discussion (tabs vs spaces, anyone?). In either case, no
one would want to actually call these functions.


Regarding forking:

You must remember that when I originally forked ExEn (for my own,
internal use), that SilverSprite was a stalled project and XnaTouch was
unuseably buggy and moving extremely slowly. (It seems that SilverSprite
remains stalled, while XnaTouch, now MonoGame, has picked up its pace.)

If I had submitted my changes as a patch, it would have touched the
majority of files in the project. Replacing a large percentage them, and
deleting a few more. As well as a fairly substantial restructure to
merge in a separate project. Not to mention philosophical changes – like
my decision to delete "bogus" code. In light of all this, a fork seemed
highly appropriate.

When I suggested that the projects are interchangeable, I meant
externally. After all – they both attempt to replicate Microsoft’s XNA
API. Internally they are mostly very different.

When I say I will be incorporating patches from MonoGame/XnaTouch, here
is what I mean:

(1) When I start working on ExEn (as a dedicated project, hence the
funding), I will be going through the MonoGame/XnaTouch patch list,
one-by-one, from the point where I was last in-sync. In areas where the
code is identical (eg: GamerServices), I can simply adopt their code.

For the code that is different (did I mention there is a lot?), I will
very carefully have to go through and compare it with the changes I have
made: Did I fix this bug? Is my code better? If not, how can I improve
my code based on their improvements?

So, yes, on the one hand I can see that this has resulted in some
duplicated effort (eg: they’ve fixed bugs that I fixed independently).

But I believe that, for the users of the finished product, the end
result – of combining the work of a dedicated, paid engineer (me) with
the work of open source contributors – will be better than what could be
achieved by pursuing either approach independently.

Please feel free to publish this email exchange on your blog. And I
welcome any more questions you or your readers may have 🙂



[PS: If you do publish these, let me know when you do. I will gladly
post links.]


4 thoughts on “PlanetX, multiplatform: iPhone development (Part:3) – MonoGame–what a mess… – #iPhone #WP7 #Xbox #XNA #Monotouch #XnaTouch

  1. Well, it’s not a competition between projects tbh in the end. Lately there have been alot of developers attaching themselves to MonoGame so I think it’ll end up best in the end anyways.

    And to be fair, if you don’t want a framework that replicated XNA, why not go with DeltaEngine? =)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s