First, a late thanks to the staff at GDnet for featuring one of my entries. It was certainly not expected and I'm glad it was very insightful to a lot of people. Back to business on my game work, I am moving away from working on the voxel terrain engine so I can start adding relevant gameplay features. I needed a GUI to make certain things easier to test, especially user configuration for controls, voxel rendering and also debugging things that just make more sense to do in runtime than recompile the code many times.

With that said, I was browsing different open-source UI libraries that are made to work with XNA. Ones I have tried before or investigated are NeoForce, Squid, NuclearWinter and Ruminate. The NeoForce library looks too big for my needs and too dependent on external XML files. Squid looks nice and has enough documentation to get you started. Nuclear Winter has less documentation but the sample code makes a lot of sense to me, plus it has a nice default skin. Ruminate is actually made for MonoGame so a couple of extra dependencies are needed, and it doesn't support lists or tables. Out of these four, I chose NuclearWInter's UI.

While it lacks a lot of documentation, the samples are straightforward to see how they are put together. More significantly, it has been used by the same developers in an ambitious project of their own, CraftStudio, which is a GUI program that lets anyone build games without needing programming experience. I imagine that if it can be used for that it should certainly be robust and work well enough for my game. Within two days of downloading it, I managed to get a custom settings menu in my game, which is launched in a separate game screen.



The controls don't do anything yet, except for "Test" which closes the UI and returns control of the character. Also, since NuclearWinter is actually a collection of different libraries to handle other things like sound, game states and animation, I had to include all the code, for now at least. These systems compile into a single DLL. But my only interest is in the UI and the input library that it relies on.

Since I use my own Game Screen system, I modified the code to not create a Game State Manager class that was specific to that library, and not update it. It's not required for creating the screen area necessary for putting the UI into. The Audio code was easy to remove, as it relies on a separate DLL. I was also able to remove the custom Collections that it used. There's also a bunch of code files on the root that I haven't gotten around to checking yet.

When all modifications are done, I should just have the UI and Input code compiled into the library. Even then the input code is too Windows centric and I don't know how much work it will be making it platform independent. Maybe I should have forked this project and work on the changes from there. It would be easier to document the changes, plus I can provide people with the UI library as a standalone.