2D User Interface elements
User Interface Style used in the project at the moment can be described as simple and clear: white or brightly colored and outlined elements on a black, 60% semi-transparent, blurred background.
Text elements should be white as a general rule, and always be incased into a block of semi-transparent dark background with rounded edges. When colored (in chat or in case of warnings) text should be bright enough to be readable on the dark background, distinct enough from white text and slightly desaturated, Fonts used are available in the project’s google disk.
Windows are UI elements opened when interacting with certain environment items, like accessing the terminal or a piece of tech that is not detailed enough on the level of its model/texture.
Most windows should be interactable, movable and closable. I suggest the design that retains the dark and semi-transparent work area, but has a distinct header with a recognizable close button and a readable name. This header should be wide enough to click on to drag the whole window through the screen.
The text within should be bright and buttons or highlighted elements should have the frame in color of the header. Said color should be brighter then the work area of the window, yet overall diluted to not distract the player too much and spare their eyes. The exact hue can be chosen within unity and changed depending on the window type, window order or other parameters.
The window can also have interactable elements within. They should be bright and readable enough on the window's background and, preferably, should retain some vector style. See an airlock control panel from SS14, for example:
It’s planned to be made out of several individual interactive parts: light bulbs and wires, with several versions of each (uncut, cut or fixed wire, lit or unlit light bulb). For obvious reasons, those versions are better made in the same style.
Note that the photo is the rendered or captured character model with a filter to limit its color to the pallet.
Icons, used in the UI, should be consistent in the style of the rest of the UI: simple, descriptive and stylized. One of the examples of using the Icons in the UI is the interaction wheel pictured below:
Every Icon is white (we can change its color in Unity), smooth and readable on the dark background (or on a more transparent/light part of the wheel, if the option is selected) and descriptive, clearly indicating the action it represents. (White icons also have the benefit of easily changing their color in the editor.)
In case the action cannot be fully depicted by a simple icon, the priority should be simplicity and readability over descriptiveness.
Take the size of the icon into consideration: most of the icons would be placed into relatively small menus and still should be clearly seen. The “overcomplicated” icon above in that case might also create visual noise when scaled down, due to the distance between the wall and the tool parts of the icon.
Additional, extremely lazy, but hopefully useful mockups for the interface with icons below:
While the general composition of the mockup is not representative of what we aim for, do notice that most of these icons are readable even when zoomed out.
Do avoid pixelization and aliasing of the edges of icons. And generally, avoiding small details and unevenness is a good idea. The problem is, small icons don't scale up well, and large icons don't scale down well. There is a method called “Improved Alpha-Tested Magnification”, outlined here. But until it’s implemented, best to have the icons in a quality that would allow them to be vectorized automatically via any convenient program or service.
Stylization in these icons involves emphasizing certain parts of an object. Just like with modeling objects for the game, the goal is just to make a caricature of the real thing, not emulating an object itself, so feel free to take creative liberties, as long as the previous guidelines apply.
For slots (as seen in the loadout menu example) the icons located inside should be half-transparent to not clash with the items placed into that slot. Alternatively, the icon inside should turn transparent the moment that slot is occupied and return to the full opacity the moment it's vacant once again.
As for rendered icons, they should be recognizable, fit into the inventory square and visible on both light and dark background. One of the options to accomplish it is to give an outline to the rendered item via Unity instruments:
Both options have their advantages. However, as most of the inventory slots are also located in the block that is dark and semi-transparent, right next to the white UI icons, it would make sense to choose the bright outline. Not to mention that there are more colored and dark items then bright ones, and a dark outline on the dark object does not help it's readability:
Grizzly Bear 11 Shadow Fill is used for big UI buttons in menus, while Do Heyon is used for pretty much everything default, like menu text, user input, chat messages, etc.
Square Deal is used for window headers and secondary headings in documents.
Font Spessman Regular is generally used for titles or in places when WORDS ARE SUPPOSED TO BE BIG.
There is a Work In Progress idea for generation of unique fonts. It's not a priority, but the main idea sounds like this:
Digital fonts are the fonts used on digital devices like computers and tablets. They are also used for things like borgs or printing a note at the printer. These fonts resemble more of your typical computer fonts.
Handwritten fonts are used for writing on paper (and similar things) with pens/pencil/etc. The font for your character's handwriting would be randomized each round and could be used as evidence against you. (could work for spraypaint letters too) (if a borg did the writing it would be a normal computer font still).
In theory, if every player has unique handwriting which is randomized for each round, we would likely need close to 100 or even more hand written fonts. One way to achieve this would be to sample a bunch of the contributor's normal handwriting and convert these to fonts to use. Another way around this would be to generate the fonts themselves from a collection of letters based on style. Come up with several styles (blocky, bubble, thin, cursive, messy, etc), and then make 5-6 different letters for each style. Your hand writing will now be generated by first randomly selecting a style then randomly selecting each letter (according to the style). This way hand written fonts will truly be random and identifying them will be harder and more engaging, players also can't memorize or save them. Alternatively, we can use a font generator like analyzing 50k fonts using deep neural networks.
With unique handing writing, how would you get away with a threatening note while also hiding your identity?... Magazine scrap writing. Basically a font with randomized sizes, font colors, and background colors. The player would actually need to cut (using scissors, wire cutters, or a scalpel) up books or magazines to aquire letters for their message.
Language fonts are determined by, you guessed it, your language. They can be used both digitally and for handwriting (not sure yet if the same font will be used for both or if we make variants). [See images below for examples]
Transcribing languages can be another small part of the librarian’s job. Although there will be software available on PDAs and computers to translate messages, hand written messages will need to be transcribed through language dictionaries available in the library. Each book can give like 50 letters and each magazine gives 25.
Languages to consider:
Human
Clown
Grays - eldritch style?
Vox - eldritch style?
Reptilian
Moth
Plasmeme
Cult - Runic
Wizard
Syndicate - Maybe have specific codes to pick up on, and unless you're a syndicate, you gotta REALLY work to find out things (add incentives for this, maybe science or a tcomms agent can intercept messages from syndicate command or whatever and relay their info).
Some UI elements can have variants to be switched for one another in case of different circumstances. In that case the variant switch needs to be seamless, meaning that the images for those elements need to be of the same size and with the same base position.
Note the bar, it is missing from the variant files themselves, but can be added within unity and be programmably extended or shrunk from the bottom of the thermometer.
UI elements can also consist of several parts to be layered on top of each other and programmed to be moved, colored or otherwise changed separately.
As an example, the atmospheric pressure meter consists of 3 parts: the base with a dial, the arrow to rotate and indicate the overall pressure on the base’s dial and an exclamation mark, to be colored and/or flashing in case of dangerous atmospheric conditions. The text for the exact atm amounts is added within Unity, using accepted project fonts, so it can also be changed programmably.
Same principle applies to the target dummy, surgery dummy and other complex UI elements.
!
This is a page for menu concepts in terms of info and element allocation, please ignore wrong backgrounds, fonts and/or icons.
Connection menu is where the player pastes the server name or adress or hosts their own server:
Starting menu should be the one to follow the connection menu and the one that actually sends the player into the game as a set character or as a spectator. It also serves several other purposes:
Provides a list of servers or information about a selected server:
Provides a list of players and occupied roles:
Allows changing the game settings (video and audio settings the same as in the #in-game-settings):
And allows editing character at any point prior to embarking.
This menu is made to set up player's character. This requires several other systems, like shape keys, clothing and jobs.
The character appearance is the menu where the player decides the character's shape, mass, hair, skin color, special features and other things:
Character loadout is the menu where equipment like clothes, tools and cosmetics are assigned to the character:
Job selection screen is where the player sets their preferences for their role on the station:
This is the menu to change the setting in the middle of the round or to AFK in if needed.
It has the regular settings one would expect form the 3D game, such as graphical tweaks:
Sound volume levels and sound-related settings:
And the same controls menu page from the #starting-menu.
There are other types of menus that are actually taking part in the gameplay directly, such as crafting menus or console menus. Most of them are either a part of the player's initial interface or a specifically set up type of window with unique interactable elements.
