Finding the right way to do your user interface is always a sticky problem (I’m sorry, I couldn’t resist the pun)
But it’s true. I’ve now had the (dis?)pleasure of working with several GUI systems both through work and outside of it. There have been a great many people who have attempted to tackle “The GUI Problem” online. I believe I have the reason why there are so many different solutions, but they’re all awkward to use.
GUI is easy.
It’s just 2D. We work in 3D now, the 2D stuff is no problem.
Getting a nice GUI system is very difficult. The system itself should take just as much care, architecting and design as a physics solution. On top of that, usually, you don’t want programmers just tweaking values, so you have to spend a good deal more time on top of that making an artist/designer interface. These things seem to have been overlooked.
Let’s take a step back and look at the different types of GUI solution available at this point, in particular for games. I will attempt to not use names to protect the guilty (ha!)
Firstly we have the most basic of basic, an Immediate Mode system. This is very quick to develop, and pretty quick to prototype. It’s straight forward. It’s clean. You tell it to draw a button and it draws a button. So what’s the problem here? Well, unless you are one of the incredibly rare crossbread of programmer/designer/artist, you will find this incredibly cumbersome. Yes, you can throw together a layout pretty quickly, but you actually have to do the throwing together in code, and it usually ends up with the GUI code being spread throughout the project, as different things might need to display things at different times. If you plan this well, you can consolidate all the GUI code in one place, but even then it becomes unsightly and awkward.
I will skip the more standard code driven system as it has many of the same shortcomings as Immediate Mode, apart from, for the most part, you can init and forget, instead of manually drawing every image every frame. But that leads me nicely onto a data driven system. For the most part these work in a very similar init and forget way, but there can be little to no actual GUI code written. The GUI layout is loaded in as data files. The benefit here is that you can quickly change the GUI without recompiling. This is actually a very good system, as long as it doesn’t take 30,000,000 XML (yeuch!) files to be written before you can display anything.
Before I go on, I should say that at no point, yet, have we seen an editor. It’s even safe to say that for the code driven systems, it’s near impossible to make one (unless you want to make an editor which outputs code, which I guess is an option…) This displays one of the biggest issues with GUI systems. Editors are always an afterthought. GUI systems are written by programmers, so they have programmer interfaces first and foremost. Editors come after if/when there’s time and they seem even more of a tacked on addition to the tacked on feel of the GUI system itself.
Finally, the most favourable option right now, is to use an existing format for GUI. The “industry standard” is using Adobe Flash through Scaleform. I myself have used something similar. Artists love it. They can design the GUI in an environment that they are familiar with and they can have access almost straight away to a lot of shiny features and animations. Leaving any prejudice of Flash behind, the IDE is possibly the pinnacle of what could be considered GUI editor design.
Am I saying we should all be using several thousand dollar flash libraries for our GUI? Definitely not. This causes a lot of issues, if you take a moment to think about it, it becomes obvious. Flash is designed to be entirely standalone. True, you can send things across the net to have your flash application talk to other things, but in general, it doesn’t expect to be communicating with anything else.
Very usefully, flash actually is quite flexible. You can try to call a function in actionscript which doesn’t exist. Most languages, if you tried to do this, at best you get a message our assert saying it can’t find the function, after which behaviour may be a little unexpected. At worst the program crashes, that’s if it’s allowed to compile. Flash shrugs it’s shoulders and continues as if nothing happened.
This means that within your game, you can implement some new magic functions and when you do any testing add a standalone flash application, it will just ignore it. This works absolutely great for menus as they can be, for the most part, pretty self contained. When it comes to in game GUI, you usually require a much tighter link with game code to make it feasible.
Basically, what I’m getting at is that the best solution right now can only be a series of hacks.
I’m not denying that they are good hacks, but they are hacks. And hacks are almost always the weak point.
There is one more solution that’s come up more recently which is to use a 3D editor to lay out the GUI in 3D, then draw it using an orthographic camera. This is a great idea in principle, it makes the GUI part of the actual game world so it makes tying into game code almost trivial. It allows you to use whatever editor software you already have set up for game design. I still have issue with this. The best 2D artist/designers I know are just that, 2D designers. Sure, we can ask them to learn 3D tools, but it’s a workflow that they’re not necessarily most comfortable with.
There are a great many things to consider here. Am I just going to sit back and complain? Well, I’m tempted now. But I can make a couple of suggestions. Most of which I am attempting to address in the combination of Maratis and Löve2D. First of all, the system should be pretty easily integrated with any game code. This will come down to the API I expose on either side of the interface but as the interface can be entirely open (unlike the flash layer) then that shouldn’t be an issue at all. Secondly, the editor. I would absolutely love to be able to use an existing and proven editor, but that would probably end up as another series of hacks. The main thing is that, from the word go, the editor should be planned for. Finally. One incredibly important thing which I haven’t mentioned yet, and possibly should have, is flexibility. No GUI solution is ever complete. There are always bespoke things that the game you’re working on will need. Making the system flexible enough to extend is fairly easy, making the editor accept and respect the extended features is a little more complicated, but should be do-able.
Anyway, I think I’ve ranted enough about this topic. I would love to hear if someone has any experience with GUI systems, especially if they think they’ve found a good one. Also, with more user interfaces now moving into 3D, is this even relevant any more?