Jump to content
Sign in to follow this  
  • entries
    31
  • comments
    55
  • views
    46805

Testing UI

Sign in to follow this  
CC Ricers

2044 views

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.

20150216-ui-test2.png

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.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!