GUI stands for graphical user interface. Borders, icons, menu bars, mouse cursors, font(s), the title screen, the credit screen(s), the help/about screen(s), trading and shop interfaces, pop-up menus, tool tips, any backgrounds which are solid colors or gradients rather than artwork, etc. all make up a game's GUI. There are programming toolkits and libraries available to help implement standard GUI elements, but first they need to be designed. This is a tricky type of design because it's half usability and half art. As such, GUI design is a field related to web design and graphic design. Consult your statement of purpose to review what art style and theme/tone you wanted your game to have; the GUI must be consistent with these. For example, you probably don't want to use smiley-faces as indicators of high durability on armor in a horror game.
Controls are the way the player uses an input device to tell the game what they want to do. Each button/key or directional input is a control. The GUI and the control scheme are inevitably related, because if you are making a mouse-driven game then you need to have mouse-friendly controls. If you want the game to be dual mouse/keyboard then it's really helpful to label the mouse-click-able buttons with the keyboard shortcuts that will activate them, or if it's pure keyboard then you need to have a 'cheat sheet' of all the keyboard shortcuts or some other reference the player can consult to learn them. Gamepad controls also require a different GUI - they have fewer buttons than a keyboard, are awkward to use to drive a mouse pointer, but work really well with a cursor that slides or rotates through menu options, and that menu can be completely invisible when the player doesn't need it instead of taking up screen space with a clickable button. Some games even use microphones, cameras, gyroscopes, toys with gamepad buttons built in, and other gamepad-substitutes like dancepads and steering wheels.
Game modes are strongly related to both GUIs and controls. A game mode is situation within the game - account/character creation mode, exploration mode, battle mode, puzzle mode, inventory mode, and a particular minigame's mode(s) are examples of these kind of situations. Each game mode has unique GUI and control needs. Thus each game mode needs a version of the GUI tailored to it, and the controls need to be context sensitive, which means the same button or mouse click can do different things in different situations within the game. It is called remapping the controls when your game assigns different functions to each button/key/whatever when the player enters a different mode within the game.
I haven't really mentioned concept art design in this document yet, so here's a crash course of the steps involved:
1. Make a list of needed features - (Yo dawg, I heard you liked making features lists so I put a features-list-making step in your features list.
) Specifically you need to make a list of your different game modes, what information and actions need to be immediately visible to the player in each, what information and actions are necessary but less urgent and should be accessible by a menu, and what controls the player should be using in that mode, including how they access any menus and how they exit that mode.2. Get source images - Google Image Search is one of the most incredibly useful things on the internet. Make one or more folders on your computer and save copies of anything relevant. You do not own the rights to these images so you can't copy them directly, but looking at them for reference is fair game. That's what a source image is. What are you searching for source images of? GUIs of other games and random art related to your chosen theme and tone. If possible, identify 1-3 example games, animes/cartoons, or similar which have a very similar theme and tone to the one you want your game to have; google those as well as terms for your theme and tone.
3. Make mock-ups (concept art) - You can doodle on paper or use your graphics program of choice, but either way you need to make pictures of what your different game modes, including their GUIs, might look like. If possible, use the proportions you want your game to have on the player's screen. Don't just make one concept; after you make your first attempt try to clear your mind and do something different, then do that again.
4. Revise, Consult, Revise - Look at the different attempts side-by-side, see if there's any way to get something better still by combining part A of attempt 1 with part B of attempt 2. Now, it's almost inevitable that this kind of mock-up is missing something. Many, many, student architects have designed a house with no bathrooms, for example. So even if you are your game's main artist I don't recommend putting your GUI concepts right into development without getting some kind of second opinion. If you have to wait until a later point in your development process to have someone you can ask, then wait. When you make your final revision after getting some input, then your job here is done, unless the required features change or playtesting turns up a problem later. If your document format can include images, add your concept images to an appendix.
- [Input devices you want your game to use, such as mouse, keyboard, and/or gamepad]
[indent=1]- [List game mode(s) with the primary control scheme]
[indent=2]- [Describe the control scheme, both info displayed to the player and input giveable by the player.]
[indent=1]- [List each group of game modes with an additional control scheme]
[indent=2]- [Describe the control scheme, ditto.]
