• Discover STK
• Download
• FAQ
• Get involved
• Community
• Blog

Graphical user interface

This is the current status of the design of GUI for STK 0.7 (with irrLicht). These are mainly based on ideas coing from the Previous design by Coz, incorporating new ideas by Auria and feedback from Conso and other comments from the mailing list.

Please note that these mockups are only meant to show the layout and navigation, not the actual look it will have.

• All screens should have an empty space border of 5%, to make up for screens, for TVs or configurations that don't show the whole screen.
• There should be as much in a screen as possible without feeling cluttered in order to reduce the number of screens (and clicks) required before starting a game.
• Settings within a screen should be group in subcategories when relevant
• Reference to GUIs user in other games

The banckground image should not stretch in high resolutions. Instead of supporting many background images, I was thinking of "dynamically" generating the bg image, like in add an abstract background, then add STK logo and other stuff over this. This way it could adapt to any resolution.

Main menu

Note that icons used below are mostly taken from google-images, so we can't use them :( see them as placeholders

Icons make it more user-friendly, and eases seeing the different possible options. Note that here is no multiplayer mode; networked multiplayer obviosuly happens through the 'network' item, while split-screen multiplayer will happen naturally at the kart-selection screen.

Messages can cycle in the lower-half area, saying that STK is free and open-source, etc... it can also contain messages if config file was reset

Only this screen shall show the 'SuperTuxKart' logo (and Tux or whatever the artist who makes our next background image puts). All other menus shall use a pretty neutral background image.

General navigation concept

In order to remain friendly with GamePads, the new GUI should be easy to use with a minimum amount of buttons and no mouse (though mouse use will still be allowed of course).

• Up/down axis or buttons
• Left/right axis or buttons
• Fire
• Enter

To keep the menus easy to navigate and setup with a gamepad, I came up with the following concept :

• Different settings are laid out vertically, so you can choose which setting you wish to edit by moving up/down
• Possible values are laid out horizontally, so you can pick a value by moving left/right
• It will not be necessary to press enter or fire to select an option when moving horizontally, simply moving the cursor over the icon will select it.
  • An exception must however be made for choices which have an immediate impact, like e.g. screen resolution. For these, using enter or fire will of course be necessary since you don't want to change the resolution 4 times if the one you want is the fourth in the list, etc...
• To save space and be more user-friendly, we can use icons with text under it when relevant. If there's not enough space on a single line to display all options, we can display their icon only, and show the text under the selected one only.
• For number choices, hitting left or right will reduce/increase the number.
• For buttons or checkboxes, left/right navigation cannot be used. For these, pressing enter or fire will activate them.

Here's a small animation to make the basic navigation idea clearer :

This concept also does not hinder mouse navigation, where user can simply hover mouse over items to select then. Whether they will be selected on hover or on click is unclear the the moment; this can be decided by testing both and seeing which one feels more comfortable. While select-on-hover might be quicker, in combined screens it might get too easy to select things you don't want to.

Kart selection

The original idea

FIXME : add support for add-on categories

At this point, all human players can easily and quickly join by pressing 'fire' on their input device. As players join, the screen further divides smoothly to show more karts.

The up/down keys can be used to select the name of the player. Choices will have been specified in a list in Options (except the first one which can be the System's name by default, like it's done now in 0.6). This is necessary in order to give highscores to the right person in a multiplayer game (without requiring to go in preferences, changing the name, and making sure to give the right pad to the right person like in 0.6) For single player games, odds are that the right name will be there without action necessary, so single-players can just ignore this (i.e. it doesn't add unnecessary clicks when not necessary)

When a user presses enter or fire again, their current kart is selected and is removed from others' list. When everyone selected their kart, the setup can continue.

Hiker : In the character selection screen it should be possible to remove a player (e.g. someone uses a wrong (e.g. broken) joystick and wants to use a different one, or accidentally presses a key
Auria : I'm not sure how to do that without cluttering the interface :( I think on mistake (which wouldn't happen often) it's easy enough to go back and start again. Do you have a better idea? Pressing escape might be an option, though if you activate a joystick by mistake you may not know where escape is on it.

a new proposal

The previous was nice, but didn't allow good support for add-on groups, was quite cluttered with many players and could require lots of scrolling to get the kart you want. After much discussion and many mockups, Conso and I agreed on this :

If more karts are added, more lines can appear. Kart models can reduce and even disappear if player installs lots of add-ons. Users can go up above the karts area to focus their name and change it (depicted for Player 3 here) Add-ons, standard, etc. groups are selected with tab-like widgets; in a multiplayer game, only Player 1 could access this to avoid conflicts.

The idea of joining with fire and leaving with rescue is still kept. Users can confirm their set-up by pressing fire/enter. When everyone confirmed, the game goes on.

Race Setup

The initial proposition

Discussion with hiker

Hiker adds : After thinking about it, I noticed a certain non-symmetry: In GP: you can select the GP on the same screen. But in single race you have to go to a different screen. What about making the entries on the left side collapsable: You start with only "GP Single Tracks Battle tracks" When you click on one, you get a (scrollable) list of all entries of that theme. you would have to make this scrollable. A cool idea was posted here  : Display the tracks as 3x4 rectangle, and make this scrollable. I.e. you can go to the left, and all columns move the the right. (like a scrolling grid) It would have to be a separate screen I'd guess

Auria (to herself) : maybe we could come back to Coz's idea, which I liked very much : each track would have a unique icon, then we can scroll these icons

Auria (to hiker) : is symmetry more important than saving a screen?. I would tend to consider saving an additional screen is more important than having symmetry. What do you think? We might need to get more ideas on this.

Hiker:: 1) saving key strokes. So this approach has no real advantage - it might actually add a key: you press the game mode (single), then you have to select single track (or random), and then you select the track. So it's one more key stroke. 2) If we change the lower part depending on the selection of the upper part, we might as well have a separate screen (and more space).

Auria : well the thing is, I want to remove the current approach of showing twice every game mode, once under GP and once under single track. do you agree? If so then we will need one more click, since mode and GP/single will be selected apart from each other while to used to be combined

Hiker : What about one combined screen for track and GP selection?

Auria : okay let's try!

Notice that game mode descriptions fit in this screen; no need for a separate help menu or a "help" button

Auria's version (in which GPs are always visible) : I also think GPs are important; while we devs always do quick races to test things, i would think players prefer GPs, since you set-up the race once then race for a while.

-->Auria's layout has Consop's support =) (as long at the GP list is scrollable too, to allow GP add-ons)

The number of visible tracks could depend on resolution. All mock-ups are 800-600, so quite low. On high resolutions, there would be more space to display tracks

Hiker's version (in which GPs scroll along everything else) : once you have scrolled to your preferred 'type', this would be saved, and allow you to see more tracks/GP at the same time (e.g. my design would allow you too see about 20 tracks (15 in your design), plus it has more space to display additional information. Similarly for GP: my design would allow you to see 6 or 8 GPs

Auria : Another very simple reason to prefer mine though : the grid would be much easier to implement if all elements are of the same size and nature ;) In yours, some are small, some are big, some have text, some dont, etc. which significantly complicates implementation.

Hiker : What about a 'half-new-screen': when you select a track, the current picture will become semi-transparent in the background, the track icon will be enlarged, track details (name, estimated lap times or so) and #laps icons will be displayed. You can then either select the #laps and press GO, or press back to select another track

Hiker: One other comment: it might be useful to display additional information for each track. Not only name and designer, but also current highscore (or length or so) - this way people can estimate how low a race on that track (or GP) will be. Perhaps we could have a scrolling text line: 'Designer: Wonderful Auria Fastest lap time: 33 seconds.
Auria : This can go in the 'half-new-screen' you just described; this way we have more space for tracks, and it spares the player with scrolling text that's annoying to follow

Other Ideas

sj04736's version (Settings + tracks on one screen, track groups scroll separately from tracks):

Some comments by Auria :

• many people reported disliking tracks presented in a list since you need to scroll to get the one you want. Your mockup would require lots of scrolling since it can display few tracks at the same time, this may get annoying.
• The idea of something like "tabs" to switch to add-ons may be a good idea however.

Options

The options screen too makes full use of the vertical-horizontal concept described above.

SFX and Music can be turned on/off by pressing fire/enter, and volume can be modified with left/right axis.

Resolutions are organized by screen ratio, since this makes it easier to find one suited for your monitor. A resolution is only applied when fire/enter is pressed.

Comments from MiniBjorn on IRC:

• it would be better to say 16:10 than 8:5 since this is the widespread name
• maybe sizes should be in 2-3 lines (800\n600, or maybe 800\nx\n600. that way more would fit ;]
• add 1400 in 4:3

Networking

TODO

Player list

For highscores, we need to know who's playing. In STK 0.6, we had only 4 slots, so if you invited friends, then invited other friends, you constantly needed to go in the Options menu and edit the names. Using a name list makes this more flexible and easier to maintain. It furthermore allows to set per-player speficic preferences - see more below about output.

By default, we could add one default player, retrieving the name from the System, like it's currently done in STK 0.6.

It might also be a good idea to allow reordering names with drag-and-drop, so people who play often will get at the top (or automatically calculate who plays the most and put him/her at the top. quite minor at this point IMO)

FIXME : it's unclear as of now how enabling a special config for one player will be done, especially from gamepad. It might also be cleaner to do this at the input configuration menu?

Input configuration

see the lower half as a different screen, that will change depending on what is selected at the top

The main-menu will react on every keyboard configuration, so no need to choose a default. For gamepads, there will be one "main" configuration per model. Whoever actually pressed the button to get into kart-selection is the first player and the device will be connected this way (and assigned to this player; i.e. there is no need to go in preferences and tell if you are player 1, 2, 3 or 4. STK will use the right input profile depending on what you press, or what gamepad model you use)

New and/or alternative configurations can be added with the buttons at the top of this screen (of course we might need to add a delete button; or choose to have a fixed number of configs. that's not very importing at this point) We could also add auto-detection of gamepad models and automatically add new ones.

Special case

What's below sounds a bit more complicated (and it is, but mostly to describe; i believe in-game it would be quite straight-forward). Also keep in mind this is a use-case that less than 5% users will ever use, so i believe it's okay even if it doesn't jump in your face.

let's say there's a party with lots of friends playing with gamepads (all the same model, so normally they'd all use the same configuration). Unfortunately, MiniBjorn is left-handed and feels uncomfortable with the same config as others. Well here's what we can do for this :

• The input configuration would allow specifying additional configurations beyond the main/default/call-it-what-you-wish for the gamepad.
• STK already has ( and needs ) a list of players ( mainly used for highscores ). So we can just go in this list and say that MiniBjorn, as a special case, would like to use a special gamepad configuration for his gamepad. So when he enters a game and chooses MiniBjorn as his name (see kart selection screen above), his special configuration will be used. These configurations must not be seen as player-specific; it must rather be seen as different profiles being available, and if one player is unhappy with the default one he can choose another one that suits him better. The same profile could be used by several players.

• consop even suggested that we could ship a left-handed alternative configuration by default
• also, with clever naming of gamepad profiles players could get a nice effect : if MiniBjorn is set to "left-handed", then no matter what model of gamepad he uses, if it has a profile named "left-handed" then it shall be used.

Discussion:

--Conso 01:57, 13 January 2009 (UTC)About default configurations: We could set up default joypad-layouts for left-handed and right-handed. example:

No idea how a left-handed one should look like.

So, the community might send us their implementations of that layout for their special joypad and we will store it as a default-layout inside stk. So, if a new joypad is connected, one might directly start playing, unless the layout shall be changed.

--Hiker: I am not convinced that the 'special setting for lefties' is the right way to go. Doing it means more implementation work as well as potentially more typing work for the user - since we need a name for the configuration. (we should try to make STK keyboard-less friendly, e.g. joystick use only, so typing it annoying). I still like the way it is currently handled, and I think it can be made to work with the new interface, too: Save for each player the input device setting (for each input device he has ever used), and save the last setting as a default (so if you use a gamepad for the first time you get the default, but if you re-use it months later, you settings will still be around). I think that should cover for pretty much each possible situation, without using special names or configuration, no typing. We would only need one menu (for a player to define the input settings to be used, which would then become the default) - and not a specialised menu in which each configuration can be changed.

Highscores

A menu section with highest scores, fastest laps, won cups, etc.

Challenges

TODO. They should be displayed in a nicer way (with a story long-term), and it should be possible to have multiple sets of challenges (add-ons), it should also be possible to re-play beaten challenges. Perhaps there should be multiple difficulty settings.

Ideas posted by Phil (SIR_Taco) on the mailing list : This one is in the to-do already, but I'd like to throw some ideas out there. What I imagine the Challenges menu to be like is to have squares with screen-shots of the challenge in them. If they are locked, they have a little locked padlock in the corner and are grayed-out. If they are completed, the screen-shot is full colour and where the padlock was is a medal for the achievement (gold, silver, bronze.... the result should be determined in the challenge file). A mouse-over of each Challenge should display some text in a box (maybe at the bottom of the screen) detailing what was achieved (medal wise) and unlocked, or what needs to be achieved and what will be unlocked. As it stands now, you don't really have much of an idea as to how many Challenges there are and/or what the incentive for doing them are.

In-race GUI

TODO

• Currently when you use 7+ karts, kart names overlap the map. This should not happen in next implementation.
• Currently it's hard to know if it's safe to spend some of the nitro in 'collect nitro' challenges, because the red line disappears behind the energy bar texture when you got more than the required amount. -- Arthur
• It was suggested that the energy bar be replaced with a nitro tank model. Ideas :
  • It could progressively fill up as you get more nitro
  • It could also just grow bigger
  • There should be some animation when you get a tank, especially a big one

Global flow

TODO

Hiker: I think a global 'flow diagram' is kind of missing: e.g. what happens when you end a multiplayer GP? Will you get back to the main menu (if so, you would have either select the characters again (which might be annoying), or you should save the previous number of players etc.). It might be better to offer at least a setup different race option.

User Tools