[Solved] Theming Custom Game GUI Components

Game Play & Game Design
#1

After quite a bit of tinkering around, I’ve finally gotten my 2D scene graph/controls to satisfactory point in regards to functionality. Now I’m trying to come up with a way to theme everything in a consistent way. For the moment I have to set individual properties on each control such as background color, foreground color, borders, etc. Ideally I’d like to set a basic theme and have that style applied to my controls when they’re created similar to what Swing does with the L&F/componentui framework.

The controls have been developed to work with Slick2D and all of them inherit from a base control class that contains a majority of the appearance based variables. I’ve thought about using something like the builder or factory pattern, but I really don’t want to have to write a new builder/factory for each type of control. I’ve also considered making a “themer” class that I can pass a component to after it’s created, but that seems a bit cumbersome as well.

Has anybody had experience with this issue who can offer some suggestions for the best way to approach this? While it’s not critical, it would certainly save me a lot of time when putting together an interface as well as cut down on the LOC I have to look through when developing other parts of my project. Any help would be greatly appreciated. :slight_smile:

#2

I’m not quite sure what exactly you’re looking for but to get a consistent look throughout the UI, start by defining a font, colors/texture, a basic shape etc for your controls. Then arrange controls on different places the same way if you can, so that users will have to learn only one parttern.

Usually I first think about a style like “brushed metal”, “rock”, “wood”, “rusted/blood stained/magic glow/dragon teeth/whatever” then I make some prototype elements, usually starting with a button, and then tinker with those and some screen mockups till I’m pleased with the result. From those prototyle elements I derive all other elements, thus achieving a consistent look and feel.

#3

I probably didn’t explain what I was looking for clearly. It’s less to do with how to develop a consistent style, and more to do with how to propagate the style through code with the least amount of work needed.

Essentially what I am looking for is a way to override the default properties for all instances of a control in my library without the need to modify the the library itself when a new look is needed. Pretty much the same concept as how CSS applies styles to a web page without changing the actual structure of the page, or more precisely how Swing can take a look and feel and have all controls inherit the theme.

I’ve managed to cobble together a solution that involved adding a few static methods and a static ArrayList to my base class. Basically the methods allow me to assign (a) “styler” class(es) to the base class that gets invoked whenever an instance of the base control is created. I’m then able to set basic properties from there. I’m sure there’s some sort of “bad practice” involved in my approach, but it seems to be working for the most part with the exception of a minor bug that I’m looking into. :persecutioncomplex:

I’m still open to alternatives other than the implementation I have at the moment. I figure there must be something out there a bit more elegant than the one I brainstormed. :point:

#4

I would say whatever works for You, should be good enough. With time and experience comes also the knowledge what should change, if anything at all.

I don’t think I can give You any straight suggestions, but I’ll describe a approach that my own GUI has.
Basically, it has 3 layers/abstractions/components:

  • The object model - This is the button that reacts to the button presses and calls out the actions, the input, that accepts texts etc.
  • The renderers - This is the layer, that actually paints/renders the objects to the world.
  • The themer/styler - This is the “layer”, that has the style info: the colors, the fonts, the images, borders etc

Having separated the model from the renderer gives me the ability to change the renderer pretty easy. I myself, during my learning, have rewritten one of my games/tech demos, 2 different times: from java2D -> slick -> libgdx. As far as my UI was concerned, this meant only replacing my renderers.

Now having separated the styler from the renderer means, that I can define different styles, either between different games, or why not, have one or more alternative looks for my given one game.

Basically, if You look at it, this seems very familiar:

  • The object model = HTML
  • The renderer = browser
  • The styler = CSS

Depending on Your needs, You can merge one or the other layer and have a little less complexity for a little less flexibility: for example, model + renderer (the button itself knows how to draw it) or renderer + styler (every object is custom-drawn).

I do think, most of the GUI’s have similar ideas and as I red, You yourself were also moving along the same pathway.

Now, how this all should look in code, is an implementation detail.

#5

For further reference, that’s called MVC (or one of it’s derivations like MVP, depending on how you slice it).

#6

yes it is :slight_smile:

#7

MVC/MVP pattern is indeed sound advice. I’ve kept the controller separate from the other two aspects; however, I muxed the view and model together. I may consider breaking them apart at some point, but since I don’t foresee the scope of the projects I currently have in mind going beyond the functionality of Slick, it will probably be a while before I get motivated enough to do it.

Since I’ve managed to work out the last of the current, apparent bugs in the approach I threw together, I think I’ll go with the “if it works use it” philosophy. I appreciate the input. Cheers! ;D