Design 101: GUI Design
Hello everyone and welcome to the final Design 101 blog post!
Today I will be talking about GUI design. I will point out now that this is purely about design and I will not being going into anything about programming. I can not help you there. However, some of these tutorials may be helpful to get you started: one two three
When I first started looking into GUI I was totally confused. Professionally I am a print designer so the world of screen graphics was pretty foreign. How was I meant to set things up? What were the rules? How the hell do those slidey bar things work??? What helped me a lot to get started was to actually look through some PSDs of GUI. It gave me an idea of how to lay things out and what would and would not work. So in that field of thought I’m providing some of my own PSDs to give people an idea of how I personally lay things out. This isn’t the one and only way, just the way I happened to do it this particular time. If something works better for you then that is the way you should go. Please note that these are for reference only and you may not use any of the elements in your own work.
In this blog I will be covering specific aspects of design including why you should do custom GUI, different aspects of GUI, design process and actually mocking up the GUI that can then be taken and used to program the GUI. To be clear, I can’t give you a walkthrough on how to design. It’s not one of those things that can be done through paint by numbers. Design is often about following your instincts on what is and isn’t good design. To hone your instincts you need to have good taste. Taste, like skill, is something you can gain through observation. The more you look at good designs and acquaint yourself with how things work, the better your taste will get and the better you will be at being able to make judgement calls.
The best I can do is give you some pointers and examples of what to look out for and to pay attention to. Hopefully these things can set you on the path to designing your own GUI!
The importance of GUI
Ren’Py comes with a number of basic default GUI that can be used to create your Visual Novels, so why should you go to the effort of creating a custom one? The defaults do the job right?
Functionally speaking, yes they do. But that isn’t the whole story. GUI are the way players will interact with your game and they care about more than just how functional it is. Having a tailor made GUI can do wonders for the theme and tone of your story, allowing the player to be further immersed in your story. It also lets you meet the individual requirements of your game that might not be easily meet with the default GUI, especially if you are doing something different, like a VN hybrid or a Sim. Functionality all comes from meeting the needs of the player as best you can. What buttons you have, how they access the menus, the size of the text, all of these need to be thought about in relation to how the player will use them and how they work with your story and game.
And let’s face it, it’s an indication of effort that goes a long way in convincing people that your game is worth downloading and playing.
Visual Novel GUI
If you have every played a VN or made a GUI you would probably be aware of what the most common type of GUI looks like. Text box at the bottom, buttons, choices that pop up in boxes. There is nothing wrong with this format. However I would like to point out it doesn’t /have/ to be this way and you should very much feel free to do something different. I think to really benefit it would work best when combined with a concept for the art overall, such as different screen sizes or a different way to use the sprites and background, but even that is not necessary. I advocate for experimentation in design especially if you are after something a little bit different.
That said, the common type of GUI is a great place to start since it works really well and there is still plenty of room to customise. I recommend starting with this especially if you are still trying to wrap your head around what you are doing.
I’ve talked about process before in the previous blog posts so I think I should have drummed it into your heads by now. Like any piece of design you can follow the design process to create your GUI. Instead of reiterating I will go over specific pieces I think are important.
Research: I think research for GUI is especially important because it can be hard to grasp different possibilities that are available to you. Beyond just researching aspects to do with tone of voice and style, I think it’s also important to look at GUI design as a whole. It can be particularly useful to see working examples as well, so games, websites and apps can be great places to explore what actually functions in the real world. I have a folder where I save GUI/UI examples and I usually go through it while I’m brainstorming.
There are various places to look for GUI examples. You can find plenty of GUI at places like LSF, Tumblr has a collection going, and places that do Let’s Plays can also be good to grab screenshots. It can also be useful to play games and keep your favourites saved so you can look at menu interaction and button states.
Beyond that there are plenty of examples in the design world as well. While not VNs, there are a great deal of images from professional UI/UX designers and since the principles are much the same you can gain a great deal of perspective from them. I like to look at Behance and Dribble as first stops.
Thumbnails: Thumbnails can be a great way to quickly ideate layouts for your GUI. They take like 2 seconds to scribble down and it’s usually enough information for you to decide basic components. I usually do this when I’m a bit confused about where I will put what. You can usually group chunks of information that belong together and shift them around into different arrangements based on your theme ideas. Seriously, they do not have to look great to be functional for what you are trying to do.
Requirement list: Before you start mocking up, you probably want to get a list going of what screens you actually have to do. Doing this first can save you some hassle down the road since a lot of your elements are going to reused and having an idea of what you will be creating for will help you understand how you can best use your time and resources and create a nice consistent design.
I’ll list the screens I usually work with and how I group them. Yours might be different based on the type of game you are making. If you are making a RPG hybrid or a Sim then there are going to be a number of extra screens you will have to do like inventories and stats.
- Main Menu: I usually do this one last. It’s by far the easiest and usually benefits from being done when both designs and artwork are more finalised. It’s usually a fairly simple screen that contains buttons such as Start, Load, Settings/Preferences and Quit.
- In game: These I usually do first since they tend to be the most complex and you will benefit from it by having your design stretched to the hardest places first. What I call ‘in game’ is actually a series of different elements with the defining trait they will actually be used by the player while ‘in’ the game, as opposed to the settings menu that is more separate. The elements I include here are:
– The textbox
– Buttons for save, load, settings etc
– Choice boxes
– Quit screen
– History (optional)
– Menu (optional)
– Click to Continue/Skipping marker (optional)
– Custom Cursor (optional)
- Settings/Preferences: This screen is where the players can set the different settings that happen in game. They are generally made up of the Ren’Py defaults of Display, Transitions, Skip, After Choices, Auto Forward Speed, Text Speed and Volume, but there are a number of other things that can be displayed here.
- Save and Load: Are functionally very similar so you can pretty much group them together. Usually contains a number of slots to host screenshots when the player saves since it makes them more identifiable, though you don’t really have to do that and instead could just have the information. Usually also has a page mechanic so you can have more slots available, a good idea for games that focus on branching.
- Extras: As the name suggests these are the more optional aspects of the game. Usually included here are the CG gallery, Music Box, Credits and other bits and pieces you may choose to include.
So we are at the point of actually creating the designs. The following are less like steps, and more like a collection of tips and hints to keep in mind when designing your GUI.
- Software: To build your GUI mock up you are going to most typically need graphic software that is capable of type and layers. I have only ever used Photoshop, but whatever works for you should be fine.
- Build to scale: Unlike other types of artwork where it is a good idea to do everything large and then scale down, it’s a much better idea building your GUI to the scale that it will actually be seen. That way you can make sure everything is readable and useable as the player will see it. If you are using hand drawn elements, do those separately at a large scale then copy and paste them in to rescale. You will probably want that element saved at a larger scale for use later as well.
- Always place a background and sprites in the before you start building. You need to know in what environment your viewer will actually see the GUI and that will mean on a busy background. It can also be good to test light and dark backgrounds. If you don’t have your own backgrounds and sprites ready yet, use placeholders.
- Layers and Folders: You will benefit greatly from making sure your layers are organised and in neatly labelled folders. Even if you are the one who will be actually programming the GUI and you aren’t handing the file to someone else, you are still going to want to find your way around easily and be able to switch things on and off. You are also likely going to reuse elements so knowing where they are will help. For a better idea of how I organise my layers, check out the GUI PSD I packaged above.
- Picking typeface: Use a MAXIMUM of 2 typefaces. While there are exceptions to every rule, this is a good one to stick to unless you have a really good reason not to. You will probably want more than one since it’s useful in terms of communicating different things. These two can be categorised by:
– Display font: This is the one that is used for headings, name tags and small amounts of text. Since you aren’t asking the player to read a lot you can afford to pick something a little fancier or characteristic.
– Body copy font: Will be what you display everything else in, primarily the bulk of your visual novel. Being visual novels there is a lot of text involved and you are asking the reader to consume it in small chunks. Don’t make that painful, pick something that is very easy to read for long periods of time. A simple san serif or serif is great. If you are looking to vary it up a little, try to pick one that has a number of weights so you can take advantage of italics and bold when you need to.
- Typefaces have different tones of voices and represent different things, so I recommend reading up a bit on it and thinking about what your novel is about before you pick ones out. You will have a large amount of choices for the Display font, so it can be good to look up similar things of a genre to find out what sort of style will suit you. You have just as much choice with the body copy fonts, but you can narrow down your choices by considering that san-serif=modern and serif=traditional.
- Matching typefaces can be a tricky task. The main concept is to find a nice contrast between the fonts. Not total chaos, but finding the harmony in the differences. There is a lot written up on the matter so I would recommend looking around. This should get you started one two
- Designers in general are pretty vocal and passionate about typefaces, so there is actually a lot out there about them including what fonts /not/ to use. It can all be a matter of opinion but it can be good to make yourself aware of those opinions and why they exist.
- Make sure that both your choice of typeface and the size is very easy to read on your text box. A good site to check for contrast and standard readability is Contrast A. I need to stop before I talk about typefaces all day.
- Try not to go overboard with your colours, patterns and elements. Your primary goal is useability and readability so if you have too much going on you are just making that harder for the player. One of the reasons I recommend starting with the in game content and making sure you place a background and sprites is because this will be your busiest section and it will allow you to have a better grasp of the functionality of your GUI. Less is more the majority of the time.
- Keep your screens consistent. Reuse fonts, sizes, elements and colours. Everything should look like it belongs together. Different screens will meet different functions, but by maintaining the different elements you can make clear design choices that unite the whole look of the game. If you have this one thing you only use once, rethink it. Is there something else in the design you could reuse instead? There is no need to reinvent the wheel with every screen, so make it easier on yourself and better for the player and your game.
- With design styles there are two prominent ways to go, which I will call modern and traditional, though they may also be referred to as flat and realism. Neither of these are right or wrong, and you can definitely mix them together, but they tend to be to different ways of designing. Modern tends to be clean, flat and simply. The style of gradient text boxes and clean typography (eg Athena). The other side is traditional, which relies more on elements being rendered realistically and tend to use opaque styles more, such as mimicking photos, paper clips and lined paper in a digital setting (eg Taaraadhin). This site explains it quite well.
- When creating your GUI make sure to consider how it is actually going to work. What will happen when something is clicked on? How are you going to visually indicate that the player has something selected? These issues such as button states and indicators are an important part of the functionality of your UI. Buttons for instance usually have 2 to 3 states. Non-Active, Hover and Selected. Sometimes hovered and selected can be the same depending on what you need them to say.
And that’s about all I can think of to say on the issue. I’m not a professional or a teacher so I tend to just dump everything I think is important. As such, if you have any questions let me know and I will do my best to answer, I might even update this blog post.
Thank you for reading!