This started out as a reply to a comment by indie game developer Kevin Gadd on my last blog post about ExEn. But it has quickly become as long as an entire article, and I can see a lot of people being interested in its content. So here it is as a full-blown entry:
I’d love to support this project, but I find myself with significant concerns:
Thanks for writing, Kevin. I understand your concerns. I know myself that ExEn is solid on a technical level, and so my main dilemma is how to convince other people in the community. So I’d really like to alleviate your concerns.
I’m in favor of an XNA port (since I’ll probably need one down the road myself) but investing in this project would be a waste of my money unless I knew I could count on seeing something good come out of it down the road. The claim that you ‘had to fork’ the two open source libraries your implementation is based on makes me immediately think of [“Open Source Contribution Etiquette” by Miguel de Icaza] and highly suspicious of your coding skills.
(In case readers don’t know, Miguel is “the Mono guy” and also “the Gnome guy”.)
Regarding Miguel de Icaza’s article, I was half way through writing my previous blog entry when he posted it. And certainly if you read them back-to-back it makes my project sound bad! Even I got that impression!
My main response to the idea that Miguel’s article might apply to ExEn is that I haven’t actually “refactored” anything. I am a bit limited in that regard anyway, because I am writing to an existing API. I certainly haven’t made the noob mistake of rewriting-for-comprehension.
The major sections (rendering, audio) that I rewrote were entirely due to changes in technique in order to improve performance (with appropriate profiling).
Admittedly I am not perfect: rewriting the game-component system was more self-indulgent (two different code bases, two different bug sets, let’s chuck it and rewrite it once from scratch). But remember that this was before I planned to release ExEn, and the result is still an improvement.
Miguel’s article applies to blindly submitting massive patches. He points out that forking is a valid, albeit rarely successful alternative. I believe ExEn is good enough to supersede the existing libraries as the go-to library for doing cross-platform XNA.
But don’t take my word for it. He’s what Miguel has to say:
It is also worth noting that Miguel is one of the contributors to ExEn.
Why would I fund your project without seeing the code first? I don’t even know what I’m paying for; your example is so trivially simple that even a completely busted XNA port could probably run it.
Regarding the simplicity of my example projects (I assume you mean Marblets and Light Blocks): Yes, they are simple. Marblets is very simple, and SilverSprite even uses it as a sample. I was intrigued enough by your comment that I tried running Light Blocks through SilverSprite. I did have to comment out a lot of things (mostly NotImplementedExceptions) but here is the result:
It’s playable, and it even runs at 60FPS, but as you can see there is a lot of graphical glitching (audio too). So the existing libraries of course “work”. But ExEn does exactly what I claim it does: implements XNA with fewer bugs and better performance than the existing alternatives.
And remember that ExEn came about due to my efforts to port Captain Stretchy-Arms, a significantly more complicated game. I plan to finish it well before the ExEn funding period is up, to act as a non-trivial example.
The “see the code first” argument you make is compelling, and I will address that towards the end.
Worse still, the 3 months of development before you even open anything means that my money would basically vanish into a pit for 3 months. I could get better customer service than that from RentACoder.
Regarding the 3 month delay: That exists to allow me time to improve the library to a standard where I believe it is suitable for production use by the wider developer community. By holding back the source it gives me a simple way to add early-access as a funding incentive (incentives like this are normal in crowd-funding).
By giving immediate access to people who make a significant financial investment in ExEn ($100 or more), I am ensuring that their money doesn’t “vanish into a pit for 3 months”. Additionally if the project fails to launch, everyone’s money is returned. So I do not see your line of reasoning here as valid.
You’d be much better off open sourcing whatever you have now and requesting donations/sponsorship for continued development. Then people could honestly evaluate what you’ve done so far, make suggestions, and contribute (either with money OR code).
Regarding the decision to crowd-fund it and not simply release it as-is: First of all, there is nothing stopping me doing exactly what you suggest, after the project launches. This crowd-funding is for setting up the project. Afterwards it will run just like any other open-source project.
(The open-source release of the 3D modelling software Blender is an example of software that has successfully used the same approach to go open source.)
As I have mentioned before, releasing ExEn this way is obviously not a pure act of charity. ExEn represents a significant investment of my time so far, and more still to get it up to a release-quality standard and do an Android port. Unfortunately I cannot justify simply giving that away for free (I wish I could). But I believe that a price of $10000 is not only reasonable, but a bargain for the quality engineering work that it represents, especially when the cost is spread out over the community.
To look at it from the other direction: the XNA development community is going to make a lot more than $10000 through the use of ExEn. ExEn will add significant value to the system.
By combining this funding mechanism with open-source, I am exposing myself to a certain clash of philosophy. Personally I believe that this mixing of philosophies has the potential for producing better software than either method could on its own.
Basically it comes down to a question of whether or not you think I can deliver.
I can point to my 15-minute ExEn port example video, my existing released game, and video and preview releases of my next game (plus the game itself, when it’s done). I can point to my previous major game, which demonstrates that I am no dummy when it comes to graphics programming and performance. I can point to my honours degree in software engineering, or my top ranking on Stack Overflow or Game Dev Stack Exchange specifically for XNA.
So far 23 people have been sufficiently convinced to provide $2515 of funding to the ExEn project (thank you, by the way).
Kevin, you seem like a “show me the code” kind of guy – you pretty much said so yourself. You’re obviously a talented developer – I’ve been subscribed to your blog since around DBP09. I respect your opinions, and clearly a lot of other people do as well. So I would really like to see you endorsing ExEn.
Obviously posting the source code to ExEn before funding is complete would defeat the purpose of the funding (and devalue the investments of those who have paid for earlier access). This does make it difficult to satisfy the “show me the code” crowd. I have sent you an email, and I’m hoping that we can find a way to meet both of those goals. (I hope this reply alone convinces you, but going further can’t hurt.)
(Update: I should also mention that there are my technical articles on ExEn, if you want to get a glimpse under the hood right away: Silverlight performance in general, ExEn on Silverlight and ExEn on iOS/OpenGL.)
(Update Again: I have posted some source code samples and a feature list online.)
To anybody else who is also keen to have a high-quality cross-platform XNA implementation, but who still has reservations about contributing to ExEn, please get in contact with me (my email address is at the very bottom of the page). I can’t promise that I’ll dedicate an entire article to you, but I will do my best to answer your concerns. And hopefully I’ll be able to use your input to address those concerns to a wider audience as well.