Matthew Smith
On GUI Systems

So I have been working on this game for over a month now and the big thing I keep coming back to when thinking about how I will implement the game systems is the gui. Now, this game is a strategy game that is very board game inspired. The gameplay involves sifting through characters and items and challenges, and selecting options. Thus there will be a lot of ui, and the ui is very important to get right.

During and since my previous job, I had some time to think about Graphical User Interfaces. I think gui does not get talked about enough, at least in terms of what the actual problems are. I hear a lot of stuff about model-view-container and variations. However I do not hear a lot about what the core issues are what. I think that is because it is fundamentally and issue of state and complexity, and varies from project to project. There is no massive computer science problem that can solve gui. It is not one problem.

There are many requirements to consider:
Who will be using the program?
How much information does the program traffic in?
How many different kinds of information does it traffic in?
What is the platform it will be running on?
What does the user control the ui with?
Is the ui developed for personal use?
How fast does it need to be iterated on?
How is the ui layed out? Is it fluid?
What is the look and feel.
Will you need to tweak the look and feel.
Who tweaks the look and feel. The programmers?
How stateless can the ui be?
And probably many many more

Therefore, the first thing I have decided is:

Now sure there will probably be aspects of it that I can use in future projects but I am creating something. Though given this is the most ui heavy game I have in the backlog it is unlikely that I will need more than the basics for future games.

This game here, while it is focused on ui, will not be drowning in the number of situations it needs to handle. There will be a limited known set of screens. In these screens the UI will be known for the most part (at least on a high level). I am currently using an immediate mode gui system. If you don't know about that I recommend watching this:
Casey's Explanation of IMGUI
My main takeaway from the immediate mode way of doing things is:

I believe this will make things the simplest to handle. I have done some amount of coding with this and there is some more work involved with passing the required state around. But because I am being explicit, I no longer have to have widgets Now I may make concessions for common widgets, and even in the simplest imgui systems, there is the state of what the focus is and what the user is doing. For instance, you could imagine having a text box, the position of the typing cursor would be part of the global ui system state rather than having to be explicit about that.

I have not spent a lot of time thinking about animation, and animation is something that may make aspects of this harder. Animation introduces a whole lot of state that may be an issue when trying to be explicit. However my main guess is that the animation state would fall under its own seperate animation system, and thus the ui can use that state assuming it is static without causing issues.

The final thing I want to do, and this isn't a must but

I have never been happy with not being able to explicitly place ui elements where they need to go using code, but I always feel like it is a lot of work and a lot of clutter to have to programmatically place everything. Thus I would like to be able to do both. If the user is able to customise how the ui looks for them in any sort of non-trivial way then this may be harder, but I can't see that being a likely thing in this game. If only end up with code driven ui, at least in the initial versions of the game though, I won't be too unhappy.

It is really important to me that the ui is simple, and therefore fast to iterate on. A lot will change as I work on it and new art will replace old art will replace programmer art. For more of understanding of how simplicity affects everything I recommend watching this talk:
Simple made Easy

Until Next Time,
Matthew Smith

Questions or Comments: Email me at
Blog Index

2016 Matthew Smith