Joining the project

Oct 11, 2008 at 11:03 PM

I first would like to congratulate the job you've done with XEN. Great library with a great architecture and best practices.
I personnaly involved myself in a similar project that isn't hosted anymore on Codeplex called XXL which standed for eXperience Xna Libraries and main goal was to bring together a set of best practices to help XNA developers start their projects with the basic set of features expected by a Game (and not only a graphics) engine.

I'd like to know if you would be opened to other developers participation. Something that is missing from my point of view is a game state management and I thought I could contribute on that side of things. I already have a set of classes that could be plugged to XEN with some redesign.

Let me know if you would be interested ;)


Oct 14, 2008 at 4:19 AM
Edited Oct 14, 2008 at 4:22 AM
Hello. Firstly apologies for the slow reply, I'm quite busy right at the moment...

I appreciate the offer for help on the project.
Right now I'm not looking for help contributing to the core xen library. I will at some point in the future, but right now I'm waiting to see what the reaction to the API is, and most importantly I want to see where people struggle with it.

While expanding and updating it is the long term goal, at the moment I want to keep the updates as subtle as possible. I'm not looking to add major components or sections.
I don't plan to make any radical changes to xen - although xen.ex will see more frequent updates and additions.

If I keep things fairly lean to begin with, and see where/if people have trouble with the library, then it makes things much easier to fix in the long term. Xen is about building a really solid foundation - and testing the hell out of it. Xen.Ex is about building really useful tools and helpers using xen.
The implications of this are that I'll only be accepting code from other developers for Xen.Ex (at least initially) also this means the code is to be built using xen. I want to make everything in Xen.Ex as good as any alterative out there, just all that much better because it takes full advantage of what xen can do - not just in terms of features, but also ease of use and reliability.
By doing this, then problems with xen should become more obvious - and fixing them should be less drastic.

Does that make sense?
Anyway. I greatly appreciate your offer and your feedback. :-)

Graham Aldridge
aka StatusUnknown