Using Monkey for an XNA project

Update: The following article is now obsolete and an updated version is here : Using Monkey For an XNA Xbox Project : Revisit.

When developing Ninjah I had to do some last minute changes in C# because Monkey wasn’t registering the controls properly (that is, if the player was to use controller #2, the game wouldn’t work) and I have to say, working with Monkey became quite difficult in the end. Not only is Monkey new, it also supports 6 different programming environments (C#, Javascript, Flash, Xcode, GLFW and Java) which has lead to a lot more bugs than you’d expect from a single programming language. I know Monkey will improve and I’ve no doubt the points I am about to raise below will become redundant sooner rather than later. For now though, I will focus on the difficulties caused by Monkey with regards to a XNA project.

Text files unnecessarily converted to strings

Monkey converts all file based text (e.g. a level file) into a string and stores it within a source function. Monkey does this for certain languages because they do not support file reading, however, XNA does support it so I think the trans process should really use the proper tools that are available IF they are available. The 50 levels in Ninjah generate about 1.2mb worth of text, this text gets stored within source and you then find yourself browsing through screens and screens of “0,0,0,1,1,1,3,3,3,1,1,0,0,0…”.

All source gets stored in one file

Ninjah has around 30 (I think it’s 30) different source files (I tend to store each class in its own source file). The trans process lumps all of this content, along with the underlying Monkey functions and any text files you are using to store data into a single C# source file, a huge great file. This wouldn’t be a problem if there was never a need to edit any of this code, but there is, and I will come to that in another point. This is a ridiculous way of storing the code. XNA/C# is obviously able to read from multiple source files, so why doesn’t Monkey do this? It makes looking through the generated code not only a pain for me but also it completely cripples my poor lil laptop. Every time I add/remove/edit a line of code my PC halts for a couple of seconds. It’s hardly practical.

You need to make changes to the generated code

To start with you have to edit some resolution / screen mode settings in the generated code. This is a minor thing that involves changing 3-5 lines of code (3 for windows, 2 for xbox), but it really should be something that gets set from within the monkey code.I had to make various changes to prepare Ninjah for the Xbox peer review. One of the main requirements is for the player to be able to start playing the game, regardless of which controller they are using (so 1 of a possible 4 controllers). Monkey claims to support 4 controllers, but from what I could tell it doesn’t and I had to edit the joypad code myself to look at additional controllers.

The trans process repeatedly processes all media every time you build

Let’s say you have some wav (sound) files. Each time you build your Monkey project as XNA, each of these files get processed in to XNB files. Each and every time, even if they haven’t changed. This seems unnecessary and once the media files start building up, build times can take a long time. Small sound effects are not too bad, but music files (for example WMA files), can take ages…

Music tracks are converted into XNB files

Monkey has a set of functions relating to playing music, however this is basically just a sound channel reserved for music playback. Monkey treats music tracks as long sound effects even when there is a dedicated system in XNA for proper music play back. This wouldn’t be too bad if Monkey didn’t reprocess the files into XNB (which I assume is like a wav file based on the compression). This turns my 40 or so mb of WMA files into 400mb of audio files. Not only is this an unnecessary use of storage (though I am assuming they probably compress well for distribution) but the process of converting these files takes ages. Builds were taking up to an hour and a half once I added audio tracks, and as stated before, it would take this long for every single build.

I had to scrap the Monkey system for playing music and go in to the generated code and add a music play back system myself using the XNA based Song class. As mentioned before, the process of editing the generated code is a right pain.

Conclusion

I believe all of the issues are purely because Monkey is trying to support a lot of new things at the same time. I’ve no doubt this will all be fixed/improved one day because already Mark (Monkey developer) has fixed an array of XNA issues which were causing lots of garbage collection (which is a real issue on the Xbox). So, would I use Monkey in it’s current state to make another XNA game? No. Would I use Monkey again if the above mentioned items are fixed?┬áDefinitely!