Particles

All the other guidelines apply to particles as well, with a few differences.

As seen above, the particles need to be even more cartoonish, simple and recognizable, since they are not only small overall, but also move and rotate in space a lot. They also must be in PNG format, 64x64 and named in PascalCase.

Posters

Poster templates can be found on the project’s google disk. Agreed resolution for a poster is 600x900 pixels (or 900x600 pixels for horizontal ones).

In case of posters, the guideline on the amount of details is somewhat lighter, but it’s still encouraged to not create too much visual noise.

Pictured below: Standard NT posters, in pallet’s colors and with sleek vector shapes.

Pictured below: Various posters in cartoonish vector styles.

Pictured below: Various posters, utilizing actual rendered models from the game.

Pictured below: Poster art in a variety of styles.

(add some examples of horizontal posters)

Decals

Decal is a texture/image overlaid on top of models. It’s mostly used to simulate bullet holes, cracks, spills or footprints.

It is advised that the decals are made of one or several images overlaid on top of each other, in order to be colored separately to simulate the material of the damaged object or material of the substance on top of the object. The colorable image layers must be white in order for Unity to add color procedurally.

When it comes to transport or robots or any other object that uses tracks, the trail left by those tracks is supposed to be composed of a single fragment, meant to be repeatedly placed on the floor with every track movement.

That is supposed to function similarly as a photoshop brush to “paint” continuous tracks on the floor along an object’s path.

Other uses for decals are overlays - decals applied to structures, for example, overlaid over the floor or walls.

One texture might be used for several different items, if it is convenient. Take a look at the floor tile above as an example. Note: Floor tile textures will be rendered from 3d models so we can also render normal maps.

This document is a set of rules and guidelines for designing and contributing 2D assets for SS3D. It covers the UI elements, textures, decals, particles and so on. Nothing is set in stone, but for reasons of “consistency of style” these things should be kept in mind.

General Info:

• In most cases, .png file format is to be used as it is easy to edit and supports transparency.

• For consistency it’s best to use the colors from the 3D pallet when possible.

• In case the image or it’s fragment needs to change color, an image should be made white, as Unity programmed coloring works by adding color to the image.

Software:

Tasks:

• 2D tasks can be found here: https://trello.com/b/XVZ95Hjq/ss3d-2d

Screens

SS3D has a number of computers and terminals equipped with screens. By general consensus, their contents should be made in the similar style: flat-colored vector graphics.

In order to be animated, a texture animation should be converted into .mp4 in a resolution enough to fit the model’s screen. For regular consoles (pictured above) it’s 640px X 640px. But do note that the console’s screen is somewhat rectangular so the very top and bottom of the texture will be cut off. AI cores also have a place for textures, allowing some creative freedom (640px X 640px for these as well).

If the image is made after (or based on) a humanoid person, it should resemble the style of the humanoid model. The same principle is used for ID cards in their menus (see UI elements above).

SS3D models mostly use a color palette in place of actual textures, as it negates the need to learn texturing and UV unwrapping, helps with cohesion and supports a unique style of SS3D.

For simpler stuff it might be best to use colored polygons, as pictured on a few examples below:

Do not worry, the render settings make those look seamless, unless the seam is needed. For more info on that, consult the 3D Modeling Guidelines document.

Though do remember that items will be seen from pretty far away, so zoom out early and often, and always look at your work from all angles.

Actual Textures

However, textures may be used for some specific cases. For example, repeating patterns, complex shapes or where cutting up the model to add colors may cause problems.

One of such examples: HumanSeveredLimb.png (256x256) used as a texture for flesh cross section with a bone in the middle.

Another example: a cowhide texture Cow.png (256x256)

Same principle can be applied to models that have too fine details to be modeled yet not enough to create visual noise. Such as clothes.

Complex text or symbols can use a transparent texture and placed on a model like tattoos or floor decals.

Some models can use several texture variants, like cows from the example above. To make the creation of such variants easier, one might create a template to guide others, who might take interest in creating more in the future.

Yet another way the textures are utilized are skyboxes. It is a cube with textures (4000x3000) on its inner faces, used to simulate the sky or similar backdrop around a three-dimensional space. Ours mostly used just for that: space backdrop. But there’s some creativity in creating a skybox for a holodeck (Those are in PNG, 4096x3072):

This is a page for menu concepts in terms of info and element allocation, please ignore wrong backgrounds, fonts and/or icons.

Connection Menu

Connection menu is where the player pastes the server name or adress or hosts their own server:

Starting Menu

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.

Edit Character

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:

In-game Settings

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.

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.

Fonts

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.

Unique Fonts

Digital Fonts

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

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

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

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

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

Custom Icons

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.

Rendered Icons

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:

Composite Elements

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.

!