I haven’t worked a lot on libgdx in the past few weeks due to various things i won’t get into here. The last big thing was implementing the JNI wrapper for Box2D which Richard from StickCoding is now actively using in his Rokon engine.
The last couple of weeks went into discussing some potential games to be implemented in the neat future as well as looking into creating a GUI library on top of libgdx specifically tailored towards game development. An informal overview of what functionality would be needed looks as follows:
- Support for different standard widgets and containers like labels, buttons, scrollable lists, dialog boxes and so on
- Auto-Layouting and support for multiple screen sizes
- Animations/Transformations, e.g. translations, rotations, scaling, fade in and out
- Data driven (e.g. XML) and programmatical ways to define the GUI
- Easy integration with the input classes of libgdx, e.g. ease of determining wheter user input should go to the GUI or the game world
Now, i’ve written my share of game GUIs in the past years and have a pretty good crasp of how to design something like that. What’s new is the need for animations/transformations which i’ve always handled via small hacks up until now. All my previous GUIs have been using the standard event-driven OOP style you see with a lot of other GUI toolkits like Swing, or Nifty GUI.
It seems that in recent years a lot of people started hating this style of creating GUIs, saying it would be to tedious to work with. I can understand this notion to some degree. So a lot of fuzz was generated when so called immediate mode GUIs started to come out. What’s an immediate mode GUI? Instead of instanciating widgets from a class hierarchy and adding them into a tree like structure like a scene graph one simply calls methods that will immediatly draw e.g. a button with certain features and simultaniously checks whether the current input device state triggers an event for that button. This also means that state normally held by the widgets like the current value of a slider and so on becomes application data and has to be managed outside the GUI library. You can find a (rather confused at times) talk about this kind of GUI at https://mollyrocket.com/forums/viewtopic.php?t=134. Also, some of the bigger names out their have adopted this GUI paradigmn as well, like Unity 3D or even NVIDIA.
At first i really wanted to try out this “new” paradigmn and implement a GUI lib based on these principles in libgdx. Upon further investigation i found some problems with the approach though. Many common GUI operations seem to be awkward to implement with this approach, some seem to be solveable only with a multi-pass approach. In the end i find it more confusing to work with this approach then going the old way. I might just be getting old myself though for not seeing the brilliance in all this :).
Anyways, after discarding the IMGUI paradigmn for libgdx i was searching around for some GUI libraries which i could adopt. And i think Nifty GUI will be the winner. I’m tired of coding my own GUI library and Nifty GUI seems to be good enough for my purposes. All that is needed is implementing a few interfaces for rendering, input processing and sound output. I will try to do that tomorrow and see how it works out. At least the rendering interface should be a piece of cake really. The only thing that i’m a bit worried about is that it is not all that well documented yet, and i somehow have the impression that the developer is a bit sloppy at times. Also, it might do too many temporary object allocations but we’ll see about that. In any case Nifty GUI can fullfill all my needs listed above so i give it a try.