Fourth month of development and fourth status update on Shade, a cross-platform framework for 2D games which will be the core technology of all my future mobile and desktop games.
In case you missed the previous updates or wanted to read more about Shade before reading this post, you can check out all the previous posts of the series.
This month most of the work went into a new module for creating Graphical User Interfaces for games, which basically means it’s something probably not flexible enough to be an UI framework for generic applications, but it should have everything a game developer normally needs for a 2D game.
I’ve also spent a lot of time working on an test application which hopefully in the future will be the base for my first games. Technically this test is not part of Shade, but it’s been of much help to spot problems and identify features needed for a real game.
I’d also like to mention that early this month I’ve stated using Trello for organizing my work on Shade and I’m loving it. Before that I tried to use several task/bug trackers, but they were too complex for my needs, so I ended up using a simple, old school, TODO file (which I was always forgetting to update). A tool like Trello gave me the simplicity I was looking for and the flexibility I needed to take my task/bug tracking to the next level. I’m probably going to write a dedicated post about it, but in the meanwhile check it out, it’s pretty awesome.
A simple GUI for games: DisplayGUI
At the beginning of the month I started to work on a GUI module which was supposed to use elements of the Display module (the module which abstracts the screen resolution and manages nested graphical objects I introduced 2 months ago) underneath, but which had to be totally independent from the Display module for an user (i.e.: you should be able to use the DisplayGUI module without even knowing of the Display module).
Unfortunately after spending few days trying to design the perfect GUI module I realized this approach had more cons than pros: it required to rewrite a lot of code I already wrote for the Display module and trying to integrate objects of the 2 modules in a single application wasn’t easy at all.
With those problems in mind I went back to the drawing board (literally, as this month I got my old whiteboard back and now I’m using it for any design/thinking task) and decided to create something simpler and more integrated with the Display module, something which extended the Display module adding widgets to it: the DisplayGUI module.
Basically the core concept is that the Widgets of the DisplayGUI module are also DisplayObjects of the Display module, so you can add them to the Stage (screen) and to other DisplayContainers using them the same way you use other DisplayObjects. This basically means I can add a DisplayGUI::Pushbutton to a Display::Sprite the same way I add any other DisplayObject to it.
The DisplayGUI module so far
At the time of writing I’ve implemented only three widgets in the DisplayGUI module:
- Pushbuttons – classic button with optional text and icon.
- Togglebuttons – button which keeps its down/up state.
- Slidingmenu – vertical scrollable menu containing sub-menus and buttons.
but the most important and useful feature I implemented this month is the styling of widgets or widget themes.
The current implementation allows you to have a default theme to “decorate” all the widgets and then apply custom styles to any particular widget you want.
Creating a new Style is extremely simple as the whole logic is managed by the framework, so a new style requires only to specify the graphical elements it needs (for example the background images for a button) and some parameters (for example the margin of the elements inside a button).
Such approach allows to have default buttons at the early stage of development of a game and to add custom styles as long as the development proceeds without changing a single line of the game code.
A preview of DisplayGUI in action
Today I’ve recorded a video of a simple test screen I created for the Widgets to give you a quick preview of some of the features of the new DisplayGUI module.
Unfortunately the video doesn’t show all the features I implemented, especially the Styles, and that there are no on-video notes, but unfortunately I didn’t have more time for it, so for now this will do it until I finish the work on the DisplayGUI module and record and edit a better video to show you all the features in a proper way.
Bug of the month
This month I stumbled upon a bug which was almost hilarious (in a nerdy way of course)… it’s in the next two lines, can you spot it?
It’s not so easy at first, especially when you see these two lines in the middle of hundreds of lines of code, but the bug is there.
The right parenthesis after the constant BUTTON_H was not supposed to be there, but at the end of the line, just before the semicolon which terminates the statement. Unfortunately the PushButton constructor has default values for its parameters and the C++ uses the comma as operator, making the whole line a perfectly correct statement for the compiler.
Obviously that’s not what I wanted and that’s the reason why that PushButton was using the default style instead of the one specified by the constant STYLE_GAMEMENU_BUTTON.
I’m going to define in detail the roadmap for next month tonight or tomorrow, so nothing is sure yet, but I’m planning to do more work on the DisplayGUI module and maybe I will start to work on the advanced (rich) text management which I was planning to start 3 months ago, but I wouldn’t be too sure about it as I already know August is going to be a busy month.
I should also create a separated test application for the DisplayGUI module, as at the moment I’m using the one I made for the Display module and things could start to get messy pretty soon.