My kind has long had a reputation for creating so-called ‘Coder Art’. This term describes all kinds of art, from 2D to 3D that has been created by coders themselves, instead of a real artist. And the result is art that can generally be placed within a spectrum ranging from small to high degrees of shittyness. This is just an observation of the average, of course. Some coders are capable of creating truly beautiful art for their games and music right along with it. So there are a few exceptions to this rule…
…unfortunately, I am not one of them.
With the Game Design Document nearly finished I have started adding little mockup graphics to it, showing what I think the UI (User Interface) should look like. A picture says more than a thousands words they say. I don’t know whether it really always says more, but it definitely says it faster. Why describe how an image on the screen should look like, when you can simply show a picture?
The UI is part of the GamePlay
I will not go as far as saying that creating mockup graphics of the UI is important for every type of game. In fact, I don’t remember seeing a single game design document for any of the AAA First Person Shooters I worked on that included any kind of mockup graphics for the UI. And that makes sense. These games had their gameplay tightly focussed within the 3D world (the 3D part is irrelevant, the same can apply to 2D). Instead of the UI there would need to be drawings of the in-game scenes and scenarios. And there were. These are called Concept Arts, and they were usually created by real artists that know what they are doing.
Mobile Game like this one however, are a different matter. In this game, essentially, the entire UI is the gameplay. All you really do is click buttons and scroll through menus and dialogs. So it would make sense to create little previews of it. Obviously these are not the final in-game graphics. A mockup graphic just conveys the general idea, content and layout. They work almost like a concept artwork.
Just much less pretty.
Personally, I wish I could skip this step. I really have to force myself to do this, because producing any kind of art – even the infamous bad ‘coder art’ my kind is known for – is a painful task for me. But there are two distinct benefits to doing it anyway:
Benefit #1 – Increase the odds in your favour
As painful as the creation process of these graphics may be – once I finally get started with the actual game, I won’t have to worry about layout and graphics, because I have mockups to guide me. This means less unpleasant tasks that interrupt the flow and need doing before being able to continue with the fun stuff (making the game). Every time you have to stop the fun to do something not fun, your game is at risk of being shelved forever. Because we are human and most of us like to procrastinate on things that we don’t like doing. Especially in our free time.
This is one more step that will help me not lose momentum during the game development and increase the odds that the game will actually get finished.
Benefit #2 – Actually design the UI
There is another benefit of going the extra step to create mockup graphics. Instead of making it up on the fly as you go along, you spend some time thinking about what your various dialog boxes, menus and buttons really should show.
For one this means considering how much screen space you really have available. You will notice this as you try arranging your little graphics in Photoshop and run out of space for button #36. And as a result, you will start throwing out or combining information that isn’t really needed. You will automatically streamline and de-clutter your UI without even noticing it.
Secondly, and this is more important than the de-cluttering, you will spend actual time thinking your UI through. There will actually be a design to your UI. Which button would open what menu? Would it be nice to have this in a separate dialog? How many clicks does it take to do XYZ? Hint: The answer to that last one better be low.
You don’t even have to be great at interface design (common sense is a very good place to start). It should be obvious that any UI that had any time and thought at all put into its design will automatically trump a bunch of random buttons that you throw in during the implementation to tie together your individual features.
I mentioned that for this type of game, the UI is part of the gameplay. So just like the rest of the gameplay, it deserves to be taken seriously and you should put some time and effort into designing it.
Example: A Game Tower Department
Here is a practical example of the above. I needed some way to distinguish different departments from one another. Coloring the background walls of the floors is one way, but I knew that wouldn’t be enough. I also want to avoid using text everywhere, which aside from being boring, incidentally also takes up more of my precious screen space. So each department will have it’s own icon, which is used in all the menus. And to streamline the UI, clicking on the icon will bring up the floor’s upgrade menu.
My Game Design Document is nearly done. I fleshed out a level system for the player, worked out all the different department floors, nailed down the details of the upgrade system, the build system, the menu structure and even made a list with some ideas for achievements.
Can’t wait until that day I get to open up Unity and finally get going.