This section covers the basic mechanics of the game like UI, controls, etc..

The Server Hub is the first real UI the user will experience. It comes before the Server Lobby and its sub-menus, which comes before the Game and its sub-menus.

The server hub is a 3 page menu with the primary purpose of displaying a list of servers for a user to browse and join through.

Header

The window title bar is pretty self explanatory; there's an icon and title of the left, and a minimize, maximize, and exit button on the right.

Then below that, we have 3 buttons on the left and 3 on the right. The 3 on the left are for the 3 pages as mentioned above; Home, Servers, Settings (the Servers button is highlighted in the above image because that page is the active one). The 3 buttons on the right are SS3D links; Website, Discord, & GitHub.

Home Page

The Home page is the first page and mostly provides information.

(There should also be scroll bars on this page but did not get included in the image.)

Changelog

The changelog provides a feed of recent changes in the game.

This will be connected to either our GitHub releases or the devblogs from our website.

Information

A description of the game. Maybe a brief history, or witting quote, or welcome message.

Some links to our official platforms.

Maybe an official game trailer.

Events

A small bulletin of current/upcoming events on official ss3d servers.

Social Feed

A feed connected to our various social media accounts; like YouTube and Twitter.

Servers Page

The Servers page is the primary page users will spend time on, as they browse and read about servers.

Server List

The server list is the large window on the left. Not only server name, but the list provides server info on; crew count, map, round time, roleplay level, language, ping, and favorite star. The list can be sorted by any of these sections.

In the image above the server list is currently sorted by server name (hence the little arrow beneath "Space Station"), so the list has the names sorted alphabetically top-to-bottom... but the Favorite Star has higher priority over the sorting arrow so both favored servers are forced to the top. Though both sections (favored & unfavored) are still being sorted alphabetically, just separately.

When hovering over or selecting a server it will turn color.

(There should also be scroll bars on this page but did not get included in the image.)

Server Name

Server names may get long, if so they will be cut off after a certain point with "..." and will begin to scroll from right-to-left when hovering over it.

Crew Count

One thing to note is that if the server's population (crew count) is 0, the number will turn another color (grey). Also, if a server has set a max population in their server settings, and that max has been reached, the color of the number will change (black maybe?).

Map

Was thinking these could be color-coded in some way.... or not...

Round Time

When the round is not started (00:00) the time turns grey.

Roleplay Level

Self explanatory.

Language

Self explanatory. (Yes, I realize "BR" - Brazilian is really a language but it was late when I was making this.)

Ping

Color-coded.

<100 = green, 100-199 = yellow, 200-299 = orange, >299 = red

Favorite

Overrides the Server List sorting arrow (forces favored servers to the top). Favored servers basically become a second list that abides by the sorting arrow as well, but simply exists the non-favored server list.

Server List Extended

At the bottom of the Server List, exists some additional buttons and tools.

Search Bar

The search bar works like any other. The grey text vanishes when you start typing in the box. The magnifying glass is the send button. The revolving arrows on the far right refresh the Server List above. Next to it is the Server List Filter (see below). And on the far left is the Advanced Server Options (see below).

Server List Filter

The Server List Filter pops up a tab of options by which the user can filter the Server List by. The options stack together.

Advanced Server Options

The Advanced Server Options button also pops up a tab. This one has 2 sub-tabs; on the left (top image) is the Host tab, on the right (bottom image) is the Join tab.

The Host tab is used for hosting your own game. You can give your game (server) a name and a password. You then can select from 1 of 3 options: Local; keeps your game local and does not connect it to the web in any way. Public; connects your game to the web & hosts your game publicly on the SS3D Server Hub. Private; connects your game to the web but does NOT get shown on the Server Hub. Only way to connect to a private server is to join manually by inputting their IP (see below).

The Join tab is used for manually joining a server. This is used for joining to servers that are private (not listed in the Server List). You must know their IP and if they have one, their password.

Server Info

The Server Info section will be filled with content/info provided from the servers themselves. First their server name., then an image, and finally some information about the server.

This section isn't concrete in design, and possibly the layout of this section could simply be in the hands of the servers themselves.

Server Info Extended

Server Info Extended refers to the dark bar at the bottom of the the Server Info section. The left side displays the current gamemode set by the server. The middle is the obvious connect button. And the right side has 3 weblink buttons, similar to those in the Head of the Station Hub, but these are for the server's links rather than SS3D links. They are for website, discord, & github.

Settings Page

The Settings page is the final page on the Server Hub. It's pretty self explanatory and the above image is filled with example settings. Though one of those examples is the idea of color themes for the hub...

Color Themes

As seen in the example above, blue and grey options seem like they would fit well...

And maybe it would be nice to have something for the dark theme addicts... (ignore the poor photoshop color change on this one... though one thing about the below example that is really nice is the additional shadow/border on the header text).

Imo, it would be cool to have red, blue, & grey themes AND dark red, dark blue, & dark grey themes in the end.

This is the menu to change the setting in the middle of the round.

It has the regular settings one would expect form the 3D game, such as graphical tweaks:

Sound volume levels and sound-related settings:

Another, slightly more styled design:

And another but for the controls page:

The player hud is dependent on a few factors, with differences in the UI elements based on those factors.

• Admin: has special UI elements for special functions.

• Player: the most common user.

• Species: refers to what kind of character the player is controlling which determines the UI appearance and layout (e.g. a ghost wont have clothing, hands, etc. but a human will).

• Role: some roles may have unique abilities or inventories thus having some UI differences (e.g. a changeling scientist will have more abilities and UI options than a regular scientist).

Human HUD example below:

The player’s interface will likely be the most important part of the average game. The following is a breakdown of what is seen above, starting in the bottom center of the screen:

• Hands: These icons represent what is currently in the player’s hand. The active hand is lit up, while the inactive hand is dimmed. When a player picks up an item in the active hand, an icon should appear in the players’ hand representing said item.

• Pockets: To the right of the players’ hands are their pockets, which are concealable storage for small items that can fit in the players’ clothes. If the player doesn’t have clothes with pockets, these slots wont appear.

• Storage: To the left of the players’ hands is storage. This is where the player will be keeping their ID, tool belt, and backpack. Items of the respective types can be put into these slots for easy access. The player’s ID determines their level of access across the station, whereas tool belts and bags can store objects within them.

• Clothes: On the bottom left of the screen, the player can see what they are currently equipped with. Here, there are slots for shoes, jumpsuits, gloves, overcoats, ear-wear, masks, glasses, helmets, and one slot of suit storage for larger objects like rifles or oxygen tanks. A toggle also exists at the bottom left, for collapsing this menu.

• Intent: Near the bottom right of the screen, the intent indicator is a toggleable button which shows the player how they will be using their active hand. For example, if the player has a screwdriver in their hand in “help” intent, clicking a vending machine may open a maintenance panel. But, if the player has the screwdriver in “harm” intent, the player may do damage to it.

• Targeting Doll: To the direct northeast of the intent indicator is the targeting doll. The player can click various parts of the doll to indicate what part of a humanoid the active hand will be targeting. For instance: should the player find themselves in a fight, stabbing a player in the eyes would be strategically different than stabbing their feet.

• Chat: The chat is at the top left, and is arguably one of the key points of the game. In-game, this window can be dragged around the screen to suit the players’ needs. The chat contains all manner of information about the world around them, including player dialog and emotes, a log of actions, and even what your character may be thinking. On the station, different methods of communication exist between different departments. A medical officer probably doesn’t want to hear about the delayed shipments in the cargo bay, so different communication channels exist. For this reason, the player may create custom tabs that isolate specific communications for easy readability.

  The text in this game is rich. For example, text outputted by a robot is highly likely to be different than text outputted by a clown. Or, text by someone who is g-g-gg-ett-t-in-ng el-e-ect-tro-c-cute-ed may read differently than someone who is ssslightly more ssscaly than others.

  A person may have “said'' something, but a spider may have “chittered” something, and so on.

• Toggle UI: Should a player wish to have a little less clutter on the screen, at the bottom right there are toggles for displaying the chat and targeting doll windows.

• Announcements: Announcements are located to the right edge of the screen, and are messages that the station commanders feel are necessary to deliver to the entire station. They will remain on-screen, unless the player clicks the megaphone button, which should hide the message.

• Warnings: The station is a dangerous place. At the top right of the screen, a list of warnings may be present for the player, that may influence how they choose to play. For instance, pictured in the image above: the air pressure in here is way too high, and it’s way too cold! While most warnings exist to indicate hazardous conditions, it may also indicate other features regarding the status of the player character, such as whether or not they’re buckled into their shuttle seat, whether they are hungry, or whether they’re unconscious.

This page is for the design of the User Interface overall. For info on designing art assets for UI elements, see . For info on the implementation of the UI, see .

User Interface is broken up into 3 sections; the , the , and the itself.

Style

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 art GitHub repo.

The follow pages use concept images and ideas; please ignore wrong backgrounds, fonts, and/or icons...

Work In Progress.

Also see Containers

The game itself has many different UI components and systems that interact with it. This section will be broken up into these different components.

This menu is for customizing the 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, height, 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:

Radial Menu: Sometimes, just clicking is not enough to specify how you wish to react with a particular object; if a player wants to change the radio station on a boombox, how does the game know not to pick it up instead? This is the purpose of the radial menu. When holding right click on an item, the radial menu appears with a list of possible interactions.

In the case of a boombox, the player may see the option to pick it up, turn it on/off, or change the song. From this point, all the player needs to do is move their mouse in the direction of the desired option to interact accordingly.

Ideas:

Fill the inner circle with a generic/common interaction like Point or Pick Up. Alternatively and inner ring could be added that has a different type of interaction, like emotes.

Other interfaces may also exist for more specific use cases, like using station consoles, changing settings on a pressure valve, or interacting with a player’s PDA. These exist in the form of windows that can be dragged around the screen for convenience, and often share similar design elements with each other.

Most of those might be achieved by implementing proper windows. 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.

For a set of design guidelines one should take a look at .

Composite Elements

Element Swapping

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.

Element Layering

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.

Window Composition

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 with model & texture alone.

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 active elements/buttons highlighted. 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.

Interactable Elements

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).

This is the page for interactions design in terms of how a non-programmer can understand. Interaction in that sense is a way for player to use the objects around them.

The station is filled with objects that are complicated and have several functions, and yet we aim for a fluid and streamlined gameplay process. In other words, doing stuff should not be hard for players and they still should be able to do everything developed for an object.

Overall, interactions should be simple: click on thing - use the thing IF character has an empty hand.

Empty Hand

So. How do we do it?

In essence, all objects should have a Primary interaction. Something that should be done with that object by default: light switch should be clicked to be switched, a tool should be picked up on click, a fridge should be opened or closed on click.

And not only that can be different things for each object, some objects might (and will) have multiple functions. That raises the question "how do we deal with things that have several possible actions"? For example, a blender can be opened/closed, turned on/off and picked up/placed down.

For that we have an interaction wheel.

Still, some things have few interactions in them, their main one and a secondary one or two. For example, most people wouldn't want to open a wheel every time they'd like to pick up something. So, that also needs a faster way of doing.

So far, a LOT of stuff can be just picked up, a LOT of stuff can be opened (as a container) and a LOT of stuff have some sort of main singular function. So, it boils down to 3 most common interaction types:

1. CTRL + LMB = Move

2. Shift + LMB = Activate

3. ALT + LMB = Access

A simple LMB click on something still would do the interaction that is considered Primary, while the rest would still be available in the interaction wheel, but if someone wants to access those interactions immediately, they can do it right away.

Object In Hand

If the character is holding something in a hand, then if player clicks on any object, the character should try applying the item in hand to the object in a way that would make sense.

And then some things have a Primary interaction they do regardless of where the player clicked. Horns always honk (activate), jukeboxes always blast music (activate), lighters always burn (activate), guns always shoot (activate).

However some of the items have a Secondary interaction in them as well. Guns need to be unloaded, jukeboxes need to change songs, etc. And those actions are guaranteed to be needed urgently.

Dropping an item will also have a hotkey (likely Q).

Placing Object

Now, in question of how to place the item in the world with precision and not just drop it, there are several suggestions:

1. Drag-and-drop from hand slot to the particular place in the world. It does not require an extra hotkey and is fast enough.

2. Hold+Click for those players that place a lot of things manually.

When the animation system is done, both options should allow for such things as "Procedural animation that plays where player starts placing object and blends their hand position to where the mouse is going until it eventually lets go, placing the object."

The Server Lobby is the menu for the individual server after you have chosen to connect to one via the Server Hub. From here you can join the round (if in progress) or spectate it.

It also serves several other purposes:

1. Provides server information/images custom to each server.

1. Includes a lobby chat to talk in OOC with the other people in the server. (needs image)

2. Provides a list of players and possibly occupied roles.

1. Allows editing/saving character presets at any point prior to embarking. (needs image)

2. Grants server settings to admins so they change aspects of the round and start/stop rounds. (needs image)

Players should be able to examine the things that are being visually displayed to them. This is vital due to simplistic of the game and the amount of unique qualities of many objects.

Basic Examine

AKA "Hover Examine", this basic form of examine happens continuously to display the name of the object your cursor is hovering over.

We can also add more detail to the description of an item the longer someone is examining it (while close). So if you examine someone running past you just get their skin, hair color, and some clothing yet miss their name for example.

Custom UI

The custom UIs on certain objects can provide more information than to the player than just a name and description. Below you can see a character's ID card with his name, age, occupation, and even a photo.

Custom examine UIs are distance-sensitive though. Meaning they only show up if you are within a certain distance, otherwise you will only see a basic name & description or even just a name.

Some objects may show their inventory contents even, like characters for example.

For technical documentation see Game Controls page linked below.

Implemented Controls

Almost all currently implemented controls can be seen and edited in Content/Input/Controls.InputAction.

Specific buttons are bolded. Tapping a button is colored green. Holding a button is colored blue.

Ideas and discussions for future game controls have been consolidated on our Trello page. See below.

Moving an object implies different things depending on the object you're trying to move.

1. Pick Up - the character takes the object with their hand, picking it up, and carries it with them.

2. Grab - the character grabs hold of the object with 1 or more hands, to pull/push or even strangle.

More accurately it depends on the size of the object you're trying to move.

So how do we decide when to pick up and when to drag? We check the number of available hands..

• small objects - always pick up

• medium objects + one free hand - drag

• medium objects + two free hands - pick up

• large objects - always drag

Rounds are a core mechanic in this game as most games you played. They simply represent a single "match". Matches will vary from individual to individual.

First a round needs to know what gamemode it will run. From here the round pulls some RNG parameter to run from the gamemode settings. This decides the RNG preset for all sorts of round attributes.

These attributes include things such as; map, player cap, role availability/rates, objectives, item spawn rates, etc. An admin can override the default settings for each of these for an given round prior to start.

Players should be able ready up for an unstarted game, so they will automatically join when the game starts and will go through the RNG process for their roles, or join a started game mid-round.

Activating an object implies different things depending on the object you're trying to activate.

(add more here)

(examples)

Accessing an object implies different things depending on the object you're trying to access.

Does it?

(add more here)

(examples)

Players should only see what their characters reasonable can see.

That means not being able to see through walls and some other large opaque objects, but being able to see through windows or other large objects with transparent materials.

Additionally, the color and transparency of the FOV itself can be adjusted. This could be used for a variety of things.

It could turn green and grainy when the character's eyes are exposed to radiation. It could turn 90% transparent to simulate x-ray vision. Etc...