2
\$\begingroup\$

In a lot of the games I've (tried) making in the past, I often run into the problem of the code getting really heavy on ugly mathematical code. This happens especially frequently in setting up user-interfaces such as choosing the positions of things on screen. Just to get an idea of what I mean, here is some code from the setup for the level selection screen in a recent project:

enter image description here

It gets really verbose, as you can probably tell. I try to mitigate it with descriptive variable names and detailed explanations of the purposes of constants such as INITIAL_LEVEL_SELECT_Y_OFFSET, but then it becomes verbose just in a different way.

I considered making everything, rowNum, totalWidth, totalHeight, etc., constants, but to me it looked really weird to have 30+ constants attached to every class. I also tried using local variables with smaller names, such as xOffset and yOffset, but then it defeats the purpose of having descriptive variable names (as you can see I use INITIAL_LEVEL_SELECT_Y_OFFSET anyways 5 lines after declaring yOffset).

Another problem this causes is that some constants are used by multiple classes, but aren't really general enough to be included in some static "Constants" class. For example, the constructor for LevelSelectButton uses INITIAL_LEVEL_SELECT_X_OFFSET, and the class in the picture above does the reverse and uses a constant defined in LevelSelectButton.

I originally placed the constants according to "what they were most attached to" if that makes any sense. For example, BUTTON_WIDTH makes most sense in the LevelSelectButton class since it describes a level select button's width.

Another problem is that some of these constants refer to the width and height of images that haven't been loaded statically. For example, LevelSelectButton.BUTTON_WIDTH is supposed to be the same as the width of the button sprite that class uses, but my current setup requires that the sprite for LevelSelectButton be loaded in the constructor for that class (I can think of ways to remedy this based on my current system however).

Any tips on how to avoid these problems? More comments? More constants? Less constants? A static Constants class?

\$\endgroup\$
  • 1
    \$\begingroup\$ Have you considered storing the GUI constants in a file - something like xaml in wpf? I am not sure if that would not produce more problems than it would solve though. \$\endgroup\$ – wondra Aug 22 '15 at 23:46
  • \$\begingroup\$ @wondra I tried something similar, it was an xml file where you defined groups of similar constants that were loaded in the static constructor of a class and could be accessed as Constants.GetGroup("name").Constant("other_name") but that only made things more confusing. I'm sure there are simpler ways of doing it, but I shied away from a file-based solution after this. \$\endgroup\$ – user3002473 Aug 22 '15 at 23:57
  • 3
    \$\begingroup\$ This question might be a good candidate for code review codereview.stackexchange.com \$\endgroup\$ – craftworkgames Aug 23 '15 at 0:20
4
\$\begingroup\$

I'd move all those UI constants to a centralized file. It doesn't matter if they are only used in one class or not. The reason is that if you ever want to adjust that type of stuff, it is nice to have it all in one location. You don't want to have to muck with a dozen different classes just because you decided you wanted to change the overall look and feel of your UI.

Make a LookAndFeel static class (or some similarly descriptive name) to contain all those types of UI properties and constants. You might also want to have nested classes within your LookAndFeel class to namespace and categorize all your constants and properties, rather than having very verbose constant names.

Namespacing is particularly nice if you have code completion or intellisense like in Visual Studio. Then you don't have to remember all those long names and if you have documented your code, you can get descriptions for that stuff as you write.

Also, don't be afraid to use functions to self-document and contain your code bits. It doesn't matter if it's only used once. It won't really hurt performance at all and will make your code more organized.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.