Greetings 😀

The following document is intended for use by the team’s artists

when preparing artworks and designs for importation into the Unity
Engine. If you have any extra questions after getting through this, please
feel free to reach out to Tanha, Rakshaan, or me (Dylan/Astronaut) about
them – we’ll do our best to help you however you need.

Table of Contents
Image Formats & Quality
Image Resolution & Scaling
Environments & Tiling
Characters, Props, & Animations
User Interface
VFX & Shaders
3D

Image Formats & Quality

When working on assets for the project, try to export files from your
image editing software of choice as either a .PNG, a .TIFF, or a .BMP. This
goes for all assets (animation frames, character portraits, UI elements,
environment art/tiles, etc). We prefer these file types over others such as
.JPG or .GIF because they are uncompressed (or they use lossless
compression, which is just as good for our purposes), which means that
they retain exactly the level of image quality at which they were designed,
and because they support pixel transparency (often referred to in
computer graphics terms as “alpha”), which is useful for making negative
space in the image files containing our sprite designs invisible in-game.
Image Resolution & Scaling
​ When working on assets for the project, try to think of them not as
designs in a vacuum, but as physical objects with dimensions in meters
that are supposed to share a space with other objects. Consider the
following graphic depicting sprite sizes in classic Metroid:

The individual sprites each have their own dimensions, but are
displayed with the same pixel density (pixels per inch) on screen – ergo, the
difference in pixel count/resolution between the sprites conveys their sizes
relative to one another, instead of their level of detail. So, as you’re
designing things, please try to have a scale for each of your sprites in mind
at which you want one meter to be represented in pixels, so that we on the
programming side can accurately represent the relative sizes of the game’s
art assets.
Importantly, you need not all use the same scale in your designs (for
example, the environment art could be designed at a higher level of detail
and have a pixels-to-meters scale of 100:1, while a small prop such as a
bullet could be designed at a lower level of detail and have a scale of 10:1)
as Unity scales sprites automatically according to a per-sprite
user-specified value – you need only to make us aware of the scale at which
you made the design, so that we can ensure that all objects are properly
scaled relative to one another in game.
 (That said, I would encourage you guys to coordinate with one
another and try to make your designs at similar, if not identical scales, for
the sake of visual consistency >_<)

Environments & Tiling

When creating tiles based on environment concepts, remember that
your goal is to create not levels, but building blocks out of which visually
cohesive levels can be constructed. All of the guidelines described in the
previous section apply to environment tiles as well, with the caveat that you
should aim to design them with dimensions which are a multiple of the
dimensions of your smallest tile, as this makes it easier to fit them into
Unity’s tile-map grid. To clarify – this means that if your smallest
environment tile is, for example, 20x20 pixels large, then all other tiles
should have dimensions 20a pixels by 20b pixels, where a and b are whole
numbers greater than or equal to 1. You may ignore this rule if you wish,
but please let us on the programming side know when and why you’ve
chosen to do so, so that we can make sure that the tile fits into the rest of
the level the way you originally intended.
Moreover, you should aim to design your tiles so that they fit into one
of the following two categories:
1.​ Repeatable/Filler Tiles: Tiles which can flow into one another an
arbitrary number of times without breaking visual cohesion. You can
further subdivide this category into filler tiles of different types,
which contain patterns that cannot be extended on sides of the tile
(think corner/external surface tiles vs. interior tiles). Consider
creating variants of each class of tile with different patterns, to help
avoid visual monotony in the game’s levels. Finally, an example of the
sort of design we would want in a filler tile might be Minecraft’s
grassless dirt texture:

2.​ Ornamental Tiles: Special tiles which contain more complicated

designs but which cannot be duplicated ad infinitum like filler tiles.
 These will usually end up being the center of attention in a given
room or area, and as the name suggests, serve as decorations to
give the game’s environments a bit more visual appeal. Additionally,
it may be beneficial in some circumstances to implement props as
this sort of tile, so that’s something to consider for our prop artist. An
example of the sort of design we might want to implement as an
ornamental tile might be paintings, like those in Minecraft:

​ The following image is a very, very rough example of how one might
tile the foreground elements in one of Nile’s environment concepts:
 (Purple blocks denote filler tiles; yellow blocks denote ornamental tiles;
yellow dots denote duplicate instances of one filler tile)

Characters, Props, & Animations

Try to make sure that your character and prop sprites are consistent
in scale (remember, ‘pixels-per-meter’) across all variants. In general, it is
also a good idea to create all sprites for a given entity with the same
image file dimensions, even if this results in an abundance of unused
space in some subset of all files, and to make sure that the content of the
sprite is centered in the image and touches (leaves no blank space at) its
bottom edge – this helps us to ensure that the character sprite lines up
properly with its collider’s coordinates in Unity and doesn’t appear to
levitate or shift around randomly during sprite transitions.
The above are especially important for files containing animation
frames – all of them should be large enough in dimension to accommodate
the frame that takes up the largest amount of space in the sequence, but
ideally, no larger. Think of the image dimensions of a given animation as
defining the size of an enclosed room that the sprite is allowed to move
around in freely. Though, do remember to consider the context in which a
given animation will be playing before determining how the sprite will move
within the frame itself – if a given animation will only ever be playing while a
character is jumping, then the character’s center of mass should not move
at all within any of the animation’s frames (it should effectively be
grounded) unless there is a reason to do otherwise. However, if a given
animation will only ever be on screen while the player character is in, for
example, an idle state, then it is permissible to move it around more freely
(perhaps it does a little hop, or lies down on the ground, or does stretches,
etc). The important thing to remember is that the sprite’s movements
should not appear to be jittery, to be inconsistent, or to be interfering with
the way that the player character is physically moving in game. The
following are examples of the former and latter cases, respectively:
(The animation that plays while Sonic is midair after jumping – center
of mass does not move)

(An idle animation in which Sonic transitions from a standing pose to

one in which he lies down on the ground looking bored – lots of movement)
 Additionally, all negative/blank space in the frame should be made
transparent so that the sprite is not surrounded by a solid square which
isolates it from its surrounding environment – make sure to store your
sprites in an image format which contains an alpha/transparency channel
(PNG, BMP, TIFF, etc).
You may implement your animations either as a sprite sheet –
example follows:

… – or as a collection of individual image files, as Unity supports

either storage method. I would suggest trying to work in sprite sheets if at
all possible, as that is the industry standard practice, and it also helps to
save a bit of storage space, but for our purposes, either way is fine. If you
have not worked with alpha/transparency in images before, please note
that most image editing softwares represents transparent pixels with the
‘checkerboard’ pattern seen in the background of the above image.
Additionally, the suggested file formats PNG, TIFF, and BMP, also allow for
partial transparency (which enables pixels to act like colored glass), so
make sure to utilize that feature should it be useful to you (I imagine this
will be especially useful for our UI designer :D).

User Interface
Not as many special guidelines for UI – just be aware that Unity has
two different systems for UI design, one of which is almost identical to CSS
(“Cascading Style Sheets” in web pages), so if you have any experience with
web page design, that will definitely come in handy here. “UI” in game dev
often includes both the in-game HUD and the game’s menus, so keep that
in mind. To add onto everything that’s been said so far, consider whether
or not your UI elements will need to be composited and/or animated
in-game (for example, an ability icon glows when activated, or a health bar
turns red once the player drops below a certain amount of health, etc) and
notify the programming team of this, as we may have to set up some
graphical shaders to support it, depending on the effect and its
particulars. If you want any sound effects to play on a given UI event, then
let both the programming team and the audio team know so we can get
that up and running (it’s very straightforward for us to implement, so don’t
be afraid to ask ^_^).
If you will need to do any compositing, make sure that the
dimensions of the image files that you want to composite are all identical,
as the way that it will most likely work in Unity is that we will be stacking
images and using pixel transparency to make them fit together without
occluding one another. Importantly, composited elements do not
necessarily need to be of the same resolution, as Unity is capable of
dynamically scaling image files on its own (bear in mind that this may
cause visible artifacting) – they need only have the same ratio of length to
width in pixels, so that they will overlap properly when scaled (though they
should probably still be designed at the same resolution for the sake of
consistency). Also, make sure to consider whether or not your designs
should contain regions that are partially or fully transparent for aesthetic
purposes. Consider as well whether or not you will want any or all of your
UI elements to be rendered as part of the game world, as Unity supports
this (this would be most useful if we ever end up wanting to apply any
visual effects to the entire game frame, or if we want things like in-game
lighting to affect the appearance of the UI as well).

VFX & Shaders

You can think of graphics shaders as a means of applying visual
effects, filters, color correction, and other image-processing stuff to the
game in real time. Consider whether or not you will want to do anything
fancy in terms of real-time VFX for any of the assets you’re working on (for
example, a dynamically changing glow around a laser, wind effects, moving
water, many particle effects, etc), and let the programming team know
about it, as that’s something that we will need to handle via shaders until
you guys become more accustomed to using Unity yourselves. In the
interim, Unity has a GUI-based system for designing shaders called
ShaderGraph, so if you’re interested in learning more about this part of the
engine, that’s a great place to start. The following image is an example of a
shader effect designed in ShaderGraph:

3D
The Unity renderer is always working in 3D even if the game being
worked on only uses 2D assets, so if for whatever reason you decide that
you want to use a particular 3D asset in an otherwise 2D project, let the
programming team know, because this should very much be possible, and
we will help you figure out the nitty-gritty implementation details.

To End…
That’s everything I can think of that would be useful to you guys for
the moment – I’ll edit the doc and notify all of you if I come up with
anything else. Additionally, if you have any questions, want further
clarification about a given suggestion, or find that the document does not
address something important that you need help with, please let me
(Astronaut/Dylan), Tanha, or Rakshaan know, and we will see what we can
do.

Thank you for reading – hope this helped ^_^