I feel like my last entry was a mess. So let’s refocus and talk about what everyone is most interested in - the UI. I like games with diegetic UI (where the UI is part of the game's narrative) or minimalist UI. When it comes to an action game the less time spent in menus the better. There is nothing like the boredom of managing inventories when you could be out slaying dragons. When you enter into the world of strategy games, especially the world of turn-based ones you need some way of deciding your strategy. A menu if you will. Rather than removing menus, it is a matter of making useful menus. You want as much information at your fingertips as possible, while also avoiding overloading the user. In Illic I put the most important information in a big font and use icons and tooltips, to provide additional information. To further enhance this I have controls for different actions visible as icons on screen. At Avcon I got first hand experience of how useful my tooltips are by comparing people who used mice and those that used controllers. As such I've been looking for a way to get tooltips for controllers but that is a topic for another time. 

There is an argument about how games like Into the Breach simplify some of the rpg mechanics and reduce the amount of UI needed to make the game more dynamic. It is food for thought for my next game - Illic and its inspiration Fire Emblem are very different games after all. Since I first started Illic I have been thinking about how best to use the UI. It is a bit of a shame that the glitches in my UI pushed me towards putting gates (i.e. confirmations to end turns) into Illic's UI to patch glitches in my code (I talked about this in a previous entry). What I realised recently was that I have managed to fix most of these UI glitches and issues. Which if you think about it isn’t a given. It is very easy to make nasty code so tightly coupled together it would not be possible to fix without a complete rewrite. My success is all thanks to having a solid foundation.

What was that foundation? The core is the IDisplayableObject interface. Anything with this interface can be displayed in the UI and have a tooltip. So everything interesting in Illic implements this interface. All the UI is built up out of SimpleImageTooltipUI (or a child) which displays Displayable Objects. For situations where implementing an interface doesn't work I have scriptable objects which lists of displayable objects. With these you can create an enum, cast it to an int and display the corresponding element in the holder. If the element doesn't exist it will display a default display which makes it easy to see when something is missing.

It is generic, encourages separation of display from behaviour and stops you having to write duplicated code to display objects. It is a bit tedious to implement it on everything but inheritance trees help there.

So what's in the interface?

ObjectName: 

The name of the object - separate from the game object's name since objects' names and how they appear in the hierarchy is different.

BaseDescription:

I split up tooltips between name and description. This is “base” because it is the text part assigned in the inspector.

LongDescription:

The full description to display in the inspector including any programmatically created parts. I am planning to turn this into a GetLongDescription(int type) to allow different descriptions for different types of UI. Auto implemented to return description.

Icon:

Sprite to be displayed in UI.

Display Icon:

An alternative to the icon for objects which have a larger image. I.e. characters have full sprites and icons which are displayed in different circumstances. Auto implemented to return Icon to reduce the amount of boilerplate code.

IconTint:

As I learnt from my tutor, designing icons for an rpg to be tintable allows icon reuse while still allowing them to be distinct from each other. You just have to be careful of colour blindness.

BackTint:

My UI has a back sprite which the icon displays over. Back tint is used to tint this back sprite. This is how abilities have their weapon triangle colours tinted.

Static int CompareTo(IDisplayableObject first, IDisplayableObject second):

Compare two displayables to figure out if their displays are the same.

SetDisplayable(IDisplayableObject toSet, IDisplayableObject template):

Sets the display of one displayable as another. Very useful if you want an object to represent another.

The interface has evolved over time - for instance I didn't know that you could give interfaces default definitions for years - but the core idea has been there since I started studying. It is useful enough that I use a similar interface to great effect at work.

I have been fortunate that I had a sense of design from the start. When I look back I see lots of the core parts of my game were actually chosen with a lot of thought. My problem has always been the boundaries between the different systems, overuse of inheritance and lack of testing. This doesn’t have to be the case. My student project Poppy in Paintland is highly coupled and despite a decent time investment on my part it is very difficult to extract or change the painting code from the rest of the game. All of which is a reminder of how far I've come and how even back then time, effort and planning paid off.

Until next time.