Game Design, Programming and running a one-man games business…

GUI Coding is slow and dull…

cliffski

I still hand code my GUI stuff. TBH, although I know people talk about using GUI libraries, I can’t see how it can save them that much time. I have a library of stuff like button, and window classes. This isn’t the issue. The issue is coding all the stuff that says “this window has a button here, and when you click it, that scrolls through this list there”

GUI stuff takes ages. it’s also really boring to code, and there is a huge long list of features which are automatically assumed by gamers which you must have. All buttons need mouseover states and tooltips, and you need the idea of modal windows, draggable windows, windows that go to to the top when clicked, etc.

Add to all that, the nightmare of making a GUI that runs nicely in different resolutions. I know that stardock have some clever system for doing this, but they employ dozens of people and run their own GUI software business, so they can spend a lot more time on it than me.

This is why I’m not blogging about exciting enw stuff in ‘the game that has no name yet but will have a code-name soon’. I’m doing GUI stuff for one of the three big ‘management’ parts of the game, and it’s nothing exciting to talk about. Not compared to the lasers and explosions anyway.

5 thoughts on GUI Coding is slow and dull…

  1. “I still hand code my GUI stuff. TBH, although I know people talk about using GUI libraries, I can’t see how it can save them that much time.”
    Why do you not write a gui design tool, this takes the pain out of hand writing code and instead generates a file such as xml which is parsed and constructs the gui. A good gui library would provide you with such a tool, this is how it saves so much time.

  3. I hear ya. I think when people say GUI they don’t consider the wide variety of interactions people want to have with a game. Instead they think of boring and simple business application GUIs. A good game has to have lots of hand written GUI code because each game is a unique interaction set and how you interact with it, is a primary part of the game’s experience.

  4. I wrote my GUI (FryGUI for BlitzMax) to parse XML files in addition to accepting hand-coded statements. I also ensured that it was as easy as possible to throw working screens together by automating whatever I could.

    Coding purpose-built GUI stuff bores the crap out of me. I still have to do it from time to time because of some legacy code lying around that would be far more effort to update properly, and it bugs the hell out of me, so I share in your frustrations. :)

  5. hey cliffski! nice blog dude – well done on what you’ve done – impressive and encouraging!

    GUI coding became a whole lot easier for me when I started coding using what the kids call “Immediate Mode” GUI : http://mollyrocket.com/861. I rate the guy who wrote the article, more pragmatic and also a nutbag maths whizz.

    Its just “a way” of doing things obviously, but for rapid UI coding for most of the simple things it really does the trick. I think (as in the link) it says you miss out on “global knowledge” of the state of the system, but that can be worked around.

    Anyway, I use it and it bloody well works and is a lot less faffing then using the message pump way. Have a look if you like!

    tkaktatk

Comments are currently closed.