{"id":548,"date":"2011-08-29T12:28:00","date_gmt":"2011-08-29T11:28:00","guid":{"rendered":"http:\/\/shadowcovenant.com\/blog\/2011\/08\/29\/gui-stuff\/"},"modified":"2011-08-29T12:28:00","modified_gmt":"2011-08-29T11:28:00","slug":"gui-stuff","status":"publish","type":"post","link":"http:\/\/shadowcovenant.com\/blog\/2011\/08\/29\/gui-stuff\/","title":{"rendered":"GUI stuff…"},"content":{"rendered":"

I\u2019ve been working on and off on \u201cAmoeba\u201d, mainly focusing on the GUI work (area selection, level selection, etc), and it has been a struggle:<\/p>\n

\"gui_work\"<\/a><\/p>\n

First, the \u201csimple\u201d problems: font aliasing was hard to get rid of (and its not completely solved, but on my Android phone you can\u2019t see any major artifacts, specially if you aren\u2019t looking for them).<\/p>\n

Then the complex problems: different screen resolutions\/orientations. I want \u201cAmoeba\u201d to work on all devices I can possibly put it on, and that means different resolutions and orientations. We got 480×800, 1024×768, 640×960 and many more\u2026 And these means different aspect ratios, which just add more confusion to the problem.<\/p>\n

The game itself is easy to adjust to the resolution (I have a virtual resolution system coupled with some \u201cmargins\u201d disguised with some GUI elements), but if I do the same on the GUI, it looks amateurish, and that\u2019s a definitely no-no on indy game development\u2026 <\/p>\n

I could program a kind of interchangeable file with the positions of the elements (or use structures in C++, whatever), but even that is hard to tweak, because of dynamic scaling, and I have to consider ALL the possible resolutions. But this might be a solution in the future; I\u2019ve already decided that all my next mobile games will only support one orientation anyway, since it\u2019s too much work supporting multiple ones\u2026<\/p>\n

So, getting the GUI working on different resolutions\/orientations\/aspect ratios has been a though fight\u2026 and it\u2019s only half the battle\u2026<\/p>\n

Then we have the code problem, where we hook behaviors\u2026 what happens when I left click and drag the mouse (equivalent to taping the screen and dragging my finger on it)? What\u2019s the reaction\u2026<\/p>\n

On this project, I initially had all the code in C++ in the animation loop of the screen, but it was becoming unmanageable. Every change implied going through loads of conditions to get to the right place, and half the time I\u2019d just get it wrong anyway\u2026 \"Confused I decided to scrap that and go for scripted GUI. While it\u2019s not much better, it\u2019s easier to control a GUI with LUA co-routines, specially transitions between \u201cpages\u201d of GUI. It\u2019s still not optimal, but a bit better\u2026<\/p>\n

Working on this (and on my previous experiences with GUI elements), I got thinking\u2026 I hate GUI work, but mainly because it seems to be much less organic than the rest of my code (at least the end result). Why is that?<\/p>\n

One reason I can think of is that \u201cI HATE GUI WORK\u201d, so I do sloppier code to try to get it over with\u2026 the other possible reason is lack of planning of the GUI and its elements. Finally, the lack of a really defined GUI framework on Spellbook might hinder me aswell\u2026<\/p>\n

Basically, I see 7 different ways of creating a GUI\/GUI logic:<\/p>\n

    \n
  1. \n
    All GUI elements on a particular game are a separate C++ object that can handle itself. This was the approach I used on \u201cBlitz and Massive\u201d and it worked very well, from a code organization point of view. This was further facilitated due to the fact that most of the \u201cend result\u201d of the GUI actions were script calls.<\/div>\n<\/li>\n
  2. \n
    We have a generalized object system (with sprites, text, aggregate objects, etc) and we instance it in C++. Control is done by using the animation pump that reacts to specific events. This results in long, hard-to-manage code, and loads of \u201ctemporary\u201d variables to handle the state of the system.<\/div>\n<\/li>\n
  3. \n
    Same as last, but using scripting to instance the objects and registering events. Events trigger script calls that change the system. The \u201ctemporary\u201d variables are more contained and can be handled locally by the scripting. Problem is that a language like Lua has great facilities for co-routines (superior to all languages I\u2019ve ever seen!), but it\u2019s terrible for flow control (because of syntax\u2026 seriously, on the 21st century, someone still requires the \u201cTHEN\u201d keywork for an \u201cIF\u201d clause!?!?)<\/div>\n<\/li>\n
  4. \n
    Same as 2), but use a more sophisticated event system for the event handling, instead of the animation pump.<\/div>\n<\/li>\n
  5. \n
    Use a GUI middleware (from native stuff like Win32 or iOS stuff (not cross-platform), to more \u201cgame-like\u201d alternatives like Scaleform<\/a> (expensive) or \u201cweb-like\u201d like Webkit<\/a>\/Awesomium<\/a> (I hate web-technologies and don\u2019t want to have 2 scripting languages involved in a single project)).<\/div>\n<\/li>\n
  6. \n
    Roll your own GUI middleware (a giant enterprise by itself!)<\/div>\n<\/li>\n
  7. \n
    Hire a gnome to do it!<\/div>\n<\/li>\n<\/ol>\n

     <\/p>\n

    I see pros and cons in all of these, but I think that most of my problems can be addressed with taking the time to think about the GUI, to plan it appropriately, like I do with the rest of the game components\u2026In the meantime\u2026. I REALLY HATE GUI WORK! <\/p>\n

    Tweet<\/a><\/div>","protected":false},"excerpt":{"rendered":"

    I\u2019ve been working on and off on \u201cAmoeba\u201d, mainly focusing on the GUI work (area selection, level selection, etc), and it has been a struggle: First, the \u201csimple\u201d problems: font aliasing was hard to get rid of (and its not completely solved, but on my Android phone you can\u2019t see any major artifacts, specially if […]<\/p>\n