# Partheo's Spriting Manual

## THIS GUIDE IS A WIP

## About this document
|About me| |
|-|-|
|Hello, I'm [Partheo](https://github.com/Partheo) and I've been spriting for [Space Station 13](https://spacestation13.com/) on and off for a few years now, mainly contributing to Yogstation's codebase, although you've probably seen a few of my projects in other servers as well. I'm by no means an expert, but I believe I have a good understanding of what's important to know as a beginner and byond.||

This document will cover everything from the basics (like what program to use and how to open the sprite files) to advanced topics (like color theory and writing graphical code). Whether you are a total beginner or an expert, you will likely find this manual useful to you in some way.

**This is not a guide on how to make good sprites**, although I will certainly cover that briefly. There are lots of pre-existing resources (which I will link to at the end) on how to make good sprites. **Instead, this manual aims to to make *you* a good *spriter***. The actual artistic part of spriting is a surprisingly small fraction of the whole process - this manual will focus on the rest, allowing you to master the technical aspects and become a productive contributor.

**This is a big document.** It's currently 60k characters long, and I plan to continue adding to it until I feel it covers every possible topic a spriter might want to know about. For that reason, reading it from top to bottom may be an information overload, especially if you are new. Instead, use this document as you would a manual, referring to sections as needed while working, and move onto new information once you are ready.

## Basics

### What is a spriter?
In the context of this manual, a spriter is someone who creates and improves the visual experience in SS13. Making sprites is just one of the tasks spriters do. Here are a few other things you as a spriter can do:

* Learn to use drawing/graphics software effectively
* Improve, fix, or revamp existing sprites
* Collaborate with coders who use your sprites for their features
* Participate in development and give feedback
* Fulfill bounties to make sprites for money
* Communicate with the playerbase for feedback
* Assist other spriters with advice and improvements
* Publish sprites to an SS13 codebase yourself using GitHub
* Use your skills to try some pixel art
* Learn enough code to create your own features


### What is a sprite?
A sprite is a piece of pixel art that represents something, for use in a game. In SS13, sprites are PNG images that are generally 32 by 32 pixels, although some can be much bigger. They are stored in the `.dmi` (Dream Maker Icon) file format. I will go into more detail on the intricacies of the file format later in the manual.

It's important to note that a sprite's main goal is to *represent* the thing it is drawing. It does *not* need to be realistic, accurate, or beautiful (although these are nice to have too!). More than anything, it should be immediately clear what your sprite is when in context. This is called **clarity** and it's very important for making good sprites.

:::info

*The apple sprite has unrealistic colors and texture, yet it is unmistakenly an apple because it imitates the important features of the apple: the rounded shape, red color, and stem.*
:::

Sprites should have a reasonably consistent art style. That means that your new sprites should fit harmoniously with the existing ones. Given SS13's chaotic development history, the currently existing "style" is mostly improvised and quite inconsistent at times, but it is still worth respecting, otherwise your sprite will stick out like a sore thumb and not do its job correctly.

Here are a few sprites that have different art styles:

:::info

*While they all clearly represent skulls, the sprites look wildly different. Note the different sizes, colors, shapes, quality, and level of detail.*
:::
Here are a few sprites that have the same consistent art style:

:::info

*These sprites look and feel cohesive, even though they all represent different objects.*
:::
Learning to respect SS13's art style, knowing when to break the rules, and reinventing things in creative ways will all be key to becoming a good spriter.

### Where can I find sprites?

One way would be to take a screenshot in-game:


However, there is a better way. Most SS13 codebases are open-source, which means that all the code and sprites used in the game are free for you to view and download. Most codebases are hosted on GitHub, so you'll be able to find the files you need there. First you'll need to the link to your server's GitHub repository. For Yogstation, that'll be https://github.com/yogstation13/Yogstation.

Here are a few other links:
* [/tg/station](https://github.com/tgstation/tgstation)
* [Goonstation](https://github.com/goonstation/goonstation)
* [Baystation 12](https://github.com/Baystation12/Baystation12)
* [/vg/station 13](https://github.com/vgstation-coders/vgstation13)
* [Paradise Station](https://github.com/ParadiseSS13/Paradise)
* [Colonial Marines](https://gitlab.com/cmdevs/colonial-warfare) (hosted on GitLab instead)

:::info
When starting out, it'll be fine to download individual icon files from the GitHub website. Later on though, it'll be quite useful for you to **clone** the repository to your computer so that you can have every file available on your device. We'll go over this later.
:::

Once on the main page of your repository, you'll want to go to the `icons` folder. All sprites are stored there.


Inside, there are a number of folders and a few `.dmi` files. The folders here separate the sprites into their main categories: `obj`, `turf`, `mob`, and `effects`. There are some sprites that don't fit into these categories, but nearly all of your work will be in these.

---

#### obj

Every single item in the game, as well as structures like tables, machines, and pipes. Airlocks are here too.

#### turf

Every wall and floor. These are the sprites used for the "map" of the game. Ground sprites, like you'd find on a planet, are here too.

#### mob

Every creature, living or artificial. You'll also find the sprites for clothing and objects when they're worn or held by a creature.

#### effects

Every sprite that isn't a tangible in-game object. You'll find UI elements here, as well as things like lasers, puffs of smoke, on-screen effects, ability icons, and a variety of other things.

---

Once in the appropriate folder, you'll probably find a disorganized mess of files, and more folders. Certain things are categorized, and some aren't. Some things are partially categorized. Some sprites get their own file for some reason. For example, tools are all predictably in `tools.dmi`, but abductor tools are in `abductor.dmi` instead. Clock cultist tools are still in `tools.dmi` though. Learning to find where certain sprites are can be frustrating, so feel free to ask other spriters, or use your codebase's search function for some clues.

Once you've found the appropriate file, click on it. Unfortunately, .dmi files are not viewable from GitHub in your browser, so you'll have to download it.


If you have [BYOND](https://www.byond.com/download/) installed, you'll be able to open the `.dmi` file in Dream Maker, which will let you view all the icons inside, as well as their names and animations:


You can also open it in a regular image editor, which will show you the raw image:


Now that you have the file we want, you can get to work. But first, which program should you use?

## Your tools

### Spriting programs

There are lots of different programs you can use to make and edit sprites. In most cases, it is a matter of preference, although there are some key differences from program to program. Below is a comprehensive list of software you can use, with their pros and cons compared. **If you already have experience with a particular program, I recommend you stick to it** while you learn the basics of spriting and switch to a more appropriate program later if you desire.

---

|  | [Dream Maker](https://www.byond.com/) |
| -------- | -------- |

The default editor for `.dmi` files. Lacks essential drawing features, which will hold you back for bigger projects. However, for single sprite edits it is just fine and will save you the hassle of having to convert file types. Start here, but move on as soon as you're comfortable.
| | |
| ---------------- | ---- |
| ➕ **Easy to use** | ➖ **Can only edit one sprite at a time** |
| ➕ **Included with BYOND** | ➖ **Very restrictive** |
| ➕ Directly edit icon states | ➖ No layers |
| ➕ Simple animation tools | ➖ No selection tools |
| ➕ Good for learning | ➖ Bad color tools |

---

|  | [Paint.NET](https://www.getpaint.net/) |
| -------- | -------- |

Simple and lightweight editing program that is like Dream Maker but better, with actual drawing tools. A great starting point.

| | |
| ---------------- | ---- |
| ➕ **Easy to use** | ➖ Not very powerful |
| ➕ Free | ➖ Not configurable |
| ➕ Versatile | |
| ➕ Lightweight | |

---

|  | [Pixelorama](https://orama-interactive.itch.io/pixelorama) |
| -------- | -------- |

Though it's not as versatile, it's as simple as Pa<span>int.NET</span> and even better for pixel work. Lightweight and convenient for spriting. Can also be used in browser. Open source.
| | |
| ---------------- | ---- |
| ➕ **Designed for spriting** | ➖ Not very powerful |
| ➕ **Easy to use** | ➖ Only slightly configurable |
| ➕ Free | |
| ➕ Decent animation tools | |
| ➕ Decent color tools | |
| ➕ Lightweight | |

---

|  | [Aseprite](https://www.aseprite.org/) |
| -------- | -------- |

Powerful and stylish program made specifically for spriting. Has the best animation and color tools, but has an odd interface and costs $20 (you can compile it for free, though). Used by many talented spriters. Open source - [a fork of Aseprite that you can download for free, called LibreSprite, is available here](https://libresprite.github.io/#!/#page-top).
| | |
| ---------------- | ---- |
| ➕ **Designed for spriting** | ➖ **Costs $20** |
| ➕ **Great animation tools** | ➖ Unorthodox interface |
| ➕ **Great color tools** | |
| ➕ **Very configurable** | |
| ➕ Powerful | |

---

|  | [GIMP](https://www.gimp.org/) |
| -------- | -------- |

All function, no form. Very powerful editing program, great for bulk spriting work. It's basically free Photoshop. While professional, the interface is frustrating and difficult to use properly. Open source.
| | |
| ---------------- | ---- |
| ➕ **Very powerful** | ➖ **Difficult interface** |
| ➕ **Great color tools** | ➖ **Huge learning curve** |
| ➕ **Very configurable** | ➖ Bulky |
| ➕ Free | |
| ➕ Versatile | |

---

|  | [Photoshop](https://www.adobe.com/ca/products/photoshop.html) |
| -------- | -------- |

The most powerful program, hands-down. Extensively configurable and can do anything, if you can learn how to use it and have the (expensive) license. Only use this if you use it already.
| | |
| ---------------- | ---- |
| ➕ **All-powerful** | ➖ **Prohibitive cost** |
| ➕ Configurable | ➖ **Huge learning curve** |
| ➕ Professional interface | ➖ Bulky |
| ➕ Versatile | |

---

|  | [Pixel FX Designer](https://codemanu.itch.io/particle-fx-designer) | OR | | [BlastFX](https://benhickling.itch.io/blastfx) |
| -------- | -------- | --- | --- | --- |

Specialized spriting software for animated particle effects. These programs can only do effects, but do them very well. They cost between $10 to $20, but you will make the coolest looking explosions and lasers. Both have free demos that let you try out the program fully.
| | |
| ---------------- | ---- |
| ➕ **Designed for spriting** | ➖ **Costs money** |
| ➕ **Great effects engine** | ➖ **Only does effects** |
| ➕ Lightweight | |

---

|  | [GraphicsGale](https://graphicsgale.com/us/) |
| -------- | -------- |

Old but specialized software for sprite animation. Like a predecessor to Aseprite. Requires some setup for hotkeys.
| | |
| ---------------- | ---- |
| ➕ **Designed for spriting** | ➖ **Outdated** |
| ➕ Free | |
| ➕ Decent animation tools | |
| ➕ Configurable | |

---

|  | Microsoft Paint |
| -------- | -------- |

Default drawing software on many computers. Does the absolute bare minimum, not recommended unless you are a ~~masochist~~ minimalist.
| | |
| ---------------- | ---- |
| ➕ Free | ➖ **Very restrictive** |
| ➕ Lightweight | ➖ Bad color tools |
| | ➖ No layers |

---

Other programs:
* [Krita](https://krita.org/en/), a great drawing program with a professional interface, but requires some configuration as it's not designed for spriting.
* [Piskel](https://www.piskelapp.com/), a simple and lightweight browser-based editor for spriting. Has simple animation tools. Very approachable.
* [Photopea](https://www.photopea.com/), a browser-based editor that emulates photoshop. Quite powerful for a browser program.
* [Marmoset Hexels 3](https://marmoset.co/hexels/), a premium and specialized program designed for hexel art, although it also supports pixel art. Only suggested if you also want to make use of the hexel tools, as the high cost ($50) doesn't justify its use as a spriting program. Has a free trial.

---

Ultimately, any program will work, as long as it has a pencil tool. Pick what you are comfortable with. If you're not sure, here are my personal recommendations:

* Complete beginners that want to practice editing individual sprites should use **Dream Maker**. It's very easy to learn and works fine for work on one sprite at a time. By using DM, you'll also be able to work directly on the `.dmi` to skip any complicated file conversions. It's a good program to use while you learn how sprites in SS13 function.
* Novice spriters looking to start working on projects with more than a few sprites should use **Pixelorama**. It's much more powerful than Dream Maker since it has layer support and selection tools, but it's still very easy to use. You'll be able to work on the entire sprite sheet at once, so it's great for when you want to add, for example, 5 new jumpsuit sprites in one project.
* Spriters that are comfortable with drawing software and want to go to the next level should invest in **Aseprite**. It's highly specialized for work on sprites and pixel art, and very powerful. You'll be able to use the multitude of convenient tools and smooth keyboard shortcuts to accelerate your workflow. It takes some time to learn it properly, but this is a solid "endgame" program for spriters.

I personally use **GIMP**. If you really like Pa<span>int.NET</span>, GIMP is basically the advanced version of it. It's extremely versatile, customizable, and has lots of powerful tools for working on big projects. It also has great colors tools and is the only program other than Dream Maker than can save to the `.dmi` format directly. However, I don't particularly recommend it, because of frustrating design decisions and the awful UI that will frequently break your flow. However, if you are willing to suffer through this, it's a great program and rewarding to learn.

Now that you've got your spriting program, how do you use it?

### Software basics

As we'll learn later, a `.dmi` file is just a `.png` image, but with a different file extension. Some programs will detect this and be able to open the file as if it was just a regular `.png`. Others won't be able to, so you'll need to rename the file to change the extension from `.dmi` to `.png`.

:::warning
It's important to note that **this process is not reversible**. You can change a `.dmi` file into a `.png` by renaming it, but **you cannot convert it back this way**. We'll go over how to convert images back into `.dmi` in the next section.
:::

:::info
Note: On Windows, you might not be able to change file extensions unless a certain setting in your file explorer is enabled.

Make sure this box is **unchecked**. Now you will be able to change file extensions by simply renaming the file.
:::

Now that you've got your file open in your editing software, we can get to work. The most important thing will always be the :pencil2: pencil tool. Using it, you can place single pixels at a time. If you use brushes, you'll get heavily smeared images and lose all control. Don't do this!

| Using the paintbrush tool :x: | Using the pencil tool :heavy_check_mark: |
|:-------------------------------------------------:|:------------------------------------:|
|  |  |

If you're using specialized spriting software, you likely won't need to worry about this, but there are some settings you should keep an eye out for when using editing tools. This varies from program to program, but generally they're referred to as **interpolation** or **anti-aliasing**. When using these tools, make sure interpolation is set to "none" or "nearest neighbor". For anti-aliasing, make sure it's off. Doing this will ensure your pixels stay crisp through your edits. Here are some examples:

| Incorrect settings :x: | Proper settings :heavy_check_mark: |
|:-:|:-:|
|||
|TODO resizing image | |

Key to spriting, and also pixel art in general, is consistent color use. When drawing in parts of your sprite, **always try to use a color that is already present in your sprite**, instead of creating a new color. To pick a color that's already in your drawing, use the color picker tool. If your spriting program has palette support, then you can pick colors off of the existing palette too. I highly recommend learning what hotkeys/shortcuts open the color picker (usually C) so that you become comfortable picking colors off your sprite quickly. Certain programs will let you bind this to right click, or ctrl+click. Very useful! You shouldn't need to use the color window unless you want to add a new color to your sprite. We'll go into more detail on color use and theory later.

| Don't pick a new color every time... | Instead pick a color already in your sprite! | Or pick from your palette |
|:-:|:-:|:-:|
|||  |

:::warning
Dream Maker has a built-in "colors in use" function. However, note that this contains the colors of **every single sprite in the file**. Since files often contain dozens of sprites, it is quite useless. If your file contains only the sprite you're working on, feel free to use it.
:::

After you've done your work, make sure to save it. Most programs will have their own file format that saves layer information, palettes, undo history, etc. Using these is fine, but once your sprites are finished and ready to be sent to BYOND, make sure you save/export them as `.png` images. We'll learn how to convert `.png` images back into `.dmi` files using a handy tool called TweakPNG.

### TweakPNG

You may wonder why we bother using a separate tool just to convert files. After all, you can use Dream Maker's import function or even copy sprites from whatever software you're using directly into Dream Maker to make your `.dmi` files. However, doing so only allows you to import **one sprite at a time**. This might be fine for you when you're starting, but if you want to be able to work on projects with multiple sprites, it starts to become a hassle. Most projects will have you editing many files, some of which can easily have 100+ sprites inside. Learning to use TweakPNG will make you productive and empower you to take on big projects!

[You can download TweakPNG here](http://entropymine.com/jason/tweakpng/). It's a very lightweight executable you can put anywhere with no installation required.

[I'll go into detail on how to use TweakPNG later in the guide, or you can click here to go there directly.](https://hackmd.io/@Partheo/spriting#Using-TweakPNG-to-convert-to-dmi)

Now that you have your `.dmi` file ready, you can add it to the game!

### Using git

**git** is a version control system which allows collaborators from all over to work on a project simultaneously. Lots and lots of people are involved in SS13's development, and by learning to use git you will be involved too!

First off, it's important to note that git is complicated to use. If you've never used it or other version control systems before, it can be a daunting step in contribution. Because of this, I highly suggest that you **avoid trying to use git yourself for your first few contributions**, and instead ask a coder(or other contributor) to publish your sprites for you. Attempting to figure out git right as you're trying to finish your first project will be very frustrating. Getting your contribution added onto your server will be an important dopamine hit for you to keep going, so get all the help you need.

:::success
I am personally available to help spriters who'd like to contribute their projects to a codebase. Feel free to contact me at any time- you'll find my coordinates at the bottom of this document.
:::

That being said, **I highly recommend learning git sooner rather than later in your spriting career**. Doing so will allow you to be independent and submit your projects whenever you want. Additionally, contributing to a codebase and making your own pull requests is super satisfying. How to do so is not in the scope of this manual, but here are some other guides that will teach you:

* [Making your first pull request with GitKraken](https://forums.yogstation.net/threads/release-the-gitkraken-how-to-make-your-first-pull-request.15099/), written by myself and aimed at complete beginners. The same exact guide in wiki format can be found [here](https://wiki.yogstation.net/wiki/Guide_to_GitKraken).
* [Goonstation Development Guide](https://hackmd.io/@goonstation/docs/%2F%40goonstation%2Fdev), a much more readable and concise adaptation of the above guide. This adaptation uses VSCode to publish your features instead of GitKraken. **This guide is the most modern, but has some Goonstation-specific steps in it that may not be necessary for your codebase.**
* [Guide to Contributing](https://www.paradisestation.org/wiki/index.php/Guide_to_Contributing#Setting_up_.26_Using_Github_Desktop), by Paradise Station.
* [Setting up git with TortoiseGit](https://tgstation13.org/wiki/Setting_up_git/TortoiseGit), a straightforward albeit outdated guide to git.
* [Setting up git with the command line](https://tgstation13.org/wiki/Setting_up_git), by /tg/station (for advanced users).

Once you've published your first sprite change, publishing new features in the future will be much easier.

### Repo tools

Servers often contain some tools in their repositories that can be useful to you as a spriter. This is not an exhaustive list as it depends on which server you contribute to, but here are a few that are worth knowing about. Ask your maintainers or senior spriters if there are any other tools worth checking out in your repo.

:::spoiler **Sprite coloration preview**

A little infographic that shows you how to preview what sprites look like once the `color` var has been applied to them, without having to load the sprites up in game. It refers to photoshop, but any image editor that has layer operations that support **multiply** will work. This works for any sprite that has `color` applied to it, not just mobs.

---
:::
---
:::spoiler **HitboxExpander**
A python script that extends the "hitbox" of a given sprite by placing 1/255 alpha pixels all around the sprite, which makes it invisibly larger in-game. This can be done manually, but the script exists if you'd like to use it.
https://github.com/yogstation13/Yogstation/tree/master/tools/HitboxExpander
:::
---
:::spoiler **Icon Smoothing Cutter**
A DM script that takes an image template and transforms it into a "smooth icon" file, which can be used by the game to make seamless tiles, like what's used for grilles, walls, and tables. This can be done manually, but it's very tedious. This is a very useful tool to use if you plan on making tiling sprites. I've added a section later in the document which will cover the smoothing system.
https://github.com/yogstation13/Yogstation/tree/master/tools/SS13SmoothingCutter

|Turns this input...|Into this output, for use by the game engine|
|:-:|:-:|
|||
:::
---
:::spoiler **Unused sprites repository**
This is an open-source repository that contains lots of sprites that were originally intended for SS13, but never ended up being used. If ever you make sprites for SS13 that don't end up in use, feel free to submit them here. That way, other servers may find use for them. Likewise, you're free to look here for sprites that you'd like to use on your server. Be sure to credit the creators.
https://github.com/tgstation/SS13-sprites
:::
---
:::spoiler **DMI2PNG**
This is a script that will unpack `.dmi` files into its constituent sprites in `.png` format, and can even export animations into gifs. Doing this could be useful to you, although keeping all sprites together in their file is usually easier for work.
https://github.com/Xkeeper0/DMI2PNG
:::

### ImageMagick

[ImageMagick](https://imagemagick.org/index.php) is a command-line based tool for bulk editing of images. It's highly specialized and most spriters will never need to use it, but if you ever find yourself stuck situations where you have to apply operations to hundreds of files at a time for example, then learning to use it will save you hours of tedious work. I've only ever had to use ImageMagick once in the many years I have sprited, but it was a lifesaver. Learning to use it is not necessary- simply knowing it exists in case you ever end up in a challenging situation is enough.

## Working with the BYOND engine

Understanding how BYOND (the engine that runs SS13) handles sprites is crucial to properly implementing them in the game. Processing your first sprites into a format that the game can read can be a bit of work, so you can save a lot of time if you make your assets while keeping in mind exactly how your sprites need to be organized for the game to use them correctly.

Lots of documentation exists on this topic already, but I'll cover the basics here. If you want to go further in-depth, you can view the [official BYOND documentation on icons](https://secure.byond.com/docs/ref/#/DM/icon).

### Icon states

`.dmi` files are arranged in what's called a **spritesheet**, which is a single image file that contains a large amount of sprites. In each file, the individual sprites are grouped into what are called **icon states**.

:::info

*A example of a **spritesheet**, which contains many different sprites.*
:::

In BYOND, an icon state can also represent an animation, and can even have multiple directions to it. This means that a single icon state can contain multiple sprites.

:::info

*These four bear sprites, each facing a different direction, are all part of the same **icon state**. The fallen bear beside them is a different icon state.*
:::

Icon states all have names, which is what the game's code uses to identify which icon to use. Making sure your icon states are properly named is important- we'll go over this in the "best practices" section later.

:::info

*These two **icon states** are named `brownbear` and `brownbear_dead` respectively. Icon states in the same file cannot have the same name.*
:::

The easiest way to view icon states is to open the `.dmi` file in Dream Maker. You'll get a complete view of all sprites in the file, organized into their **icon states**. From here, you can also view and edit the animations, directions, and names of the icon states.


#### Animation

Icon states can be animated, which means that they cycle through a series of sprites when they display in-game. Here's an icon state that has six frames of animation:

:::info


*Opening the icon state in Dream Maker allows us to see and edit all six frames of the animation.*
:::

There are a few controls here that are useful for animating. First is the **Delay** number. This represents how long a frame lasts in an animation. You can specify a different delay for each frame, although most animations will use the same value throughout. A delay of 10 represents a frame that lasts one second. You can use decimal values here, so a delay of 0.1 for example is one hundredth of a second.

:::info

*All the frames in this animation have a delay of 1, or 0.1 seconds.*

---

*All the frames in this animation have a delay of 10, or 1 second.*
:::

Another useful feature is the **Rewind** toggle. Animations with rewind turned on will play first-to-last, then last-to-first before playing again. This can be really useful in certain cases, like an oscillating animation.

:::info

*Rewind is enabled here, which makes the animation loop backwards before replaying.*
:::

Finally, there is the **Loop** number, which determines how many times the animation will play before the animation stops. After that, the sprite will remain still on the last frame of the animation. Most icons will loop indefinitely, but you can make an animation that just plays once before settling on the final frame. This can be useful for things like explosions, lightbulbs burning out, or airlocks opening and staying open thereafter.

:::info

*You can make animations play any number of times before settling on the final frame.*
:::

#### Directions

Things in SS13 can have multiple directions, which determines which direction the sprite faces. Most of the time, this applies to mob sprites, although there are a few odd cases with tiling turfs that use directions for their display. All icon states can have either just one direction, four directions (↓, ↑, →, ←), or eight directions(↓, ↑, →, ←, ↘, ↙, ↗, ↖). You can choose which to use for your sprite by pressing the buttons on the top-left of the frame diagram.

:::info

*A bear icon with a sprite for each of the four directions. Note the animation controls, which are present but unused because the icon state has just one frame.*
:::

Mob icons *should* be created with four directions, otherwise they'll look like they're sliding around when they move. This can be fine in some cases: an example is the medibot sprite. 

Icons with eight directions are rare, but those extra directions can be useful for mapping purposes. A good example is the conveyor belt object:

:::info

*The diagonal directions represent the curved sections.*
:::

#### Movement states

Certain states are what's called a **Movement state**, which is the icon that the thing uses when it is in movement in-game, for example a mob walking. Movement states have to have the same name as the icon state they're associated to. A movement state doesn't *need* to be animated, although that is usually the point of using them in the first place.


Movement states are the only case where two different icon states can have the same name. Note the **(M)**. No actual coding is necessary here- to create a movement state, you just have to check the "Movement state" box when renaming an icon state:


This particular spider icon is a great example of an icon state that has both multiple directions and multiple frames:

:::info

*Each direction is animated independently, having its own set of frames.*
:::

Movement states are used almost exclusively for mobs, so you likely won't use these unless you work on creature sprites.

### The .dmi file format

In this section, I'll go into the intricacies of the `.dmi` file format. This information is largely irrelevant to sprites themselves, so feel free to skip this part. However, it'll be quite useful for spriters who want to be able to do work in bulk, for rapid edits of icon states and quick file conversions.

As I mentioned earlier, a `.dmi` file is just `.png` file with a different file extension, and some specific metadata added in. This data isn't unique to BYOND- the PNG file format can actually support this metadata natively. Without this metadata though, your `.dmi` files will not be properly read by BYOND.

:::danger

*An incorrectly read `.dmi` file. Note how the entire spritesheet appears together in the same state.*
:::

:::success

*The same `.dmi` file, but with the proper metadata. All the states are correctly grouped and named.*
:::

Here is the same file, but displayed as a regular `.png` file instead:


#### Dimensions

Each `.dmi` file has a set width and height. This is set per-file so that the `.dmi` knows how to cut up your sprite sheet into individual sprites. That means **you can't put 64x64 sprites in the same file as 32x32 sprites.**


Most sprites in SS13 are 32x32 pixels- the majority of files you'll work on will have these dimensions. Since other sizes are so rare, most of them are all arranged into their own special files that contain all sprites of that size. These files are simply named by the size of the sprites they contain. The majority of oddly-shaped sprites can be found in the `effects` folder.


The singularity is an example of one such sprite. This one is 224x224.


Sprites don't have to be squares. An example is the basketball hoop, which is in its own file, alone at 32x64.

 

#### Metadata format

All the icon state information, animation timings, sprite dimensions, and so on are stored in the `.dmi` file in plaintext format. As we'll learn in the coming sections, you can edit this metadata directly if you'd like - doing so might be more convenient if you're working on a large amount of sprites.

Here's what the metadata looks like for the above `device.dmi` file:

# BEGIN DMI
version = 4.0
	width = 32
	height = 32
state = "beacon"
	dirs = 1
	frames = 2
	delay = 18,1
state = "signaller"
	dirs = 1
	frames = 1
state = "igniter"
	dirs = 1
	frames = 1
state = "motion0"
	dirs = 1
	frames = 1
state = "motion1"
	dirs = 1
	frames = 2
	delay = 1,1
state = "motion2"
	dirs = 1
	frames = 2
	delay = 5,1
state = "motion3"
	dirs = 1
	frames = 2
	delay = 2,2
state = "timer0"
	dirs = 1
	frames = 1
# END DMI

Every `.dmi` file has this metadata, which always starts and ends with `# BEGIN DMI` and `# END DMI` respectively. Right after the first line, there's a three-line header that contains the width and height of the sprites in the file. The version is unimportant.

After the header, each state is listed by name. By default, every state has 1 direction (`dirs = 1`) and isn't animated (`frames = 1`), but if not then the value will reflect this. If the state has multiple frames (i.e. it's animated), an extra line with the timings is added (`delay = 18,1`). If the animation uses the rewind feature, an extra line is added (`rewind = 1`). If the state is a movement state, an extra line is added (`movement = 1`). Finally, if the state animation loops a certain amount of times, an extra line is added (`loop = 1`) with the amount of loops as the value.

Here are a few icon states and their state metadata as examples:

| Icon preview | Animation window | State metadata |
|:------------------------------------:|:------------------------------------:|:---------------------------------------------------------------- |
| | | |
|  |  | <pre>state = "signaller"<br> dirs = 1<br> frames = 1</pre> |
|  |  | <pre>state = "honkbot"<br> dirs = 1<br> frames = 5<br> delay = 1,1,1,1,1<br> rewind = 1</pre> |
|  |  | <pre>state = "guard"<br> dirs = 4<br> frames = 3<br> delay = 2,2,2<br> movement = 1</pre> |

As per that last example, we see from the metadata that the state has 4 directions and 3 frames. That means it requires 4 x 3 = **12 total sprites**. In your sprite sheet, all these sprites will be bundled into that single icon state:


If you were to change the amount of frames or directions, you would also have to change the amount of sprites in the sprite sheet. The states in your `.dmi` file populate themselves from the sprites in your spritesheet from left to right, top to bottom, according to the metadata.

:::warning
Note that this metadata does not have any effect on the sprites themselves, only how they are organized into the `.dmi` file. It is important that the sprites in your spritesheet match up with the list of states in the metadata, or else you'll have mismatched states.
:::

### Using TweakPNG to convert to .dmi

Now that we know how the `.dmi` file format works, we can use [TweakPNG](http://entropymine.com/jason/tweakpng/) to edit and create them. This process may seem complicated at first, but once you get it down it'll only take a few seconds.

If you're just editing sprites from a `.dmi` file, then you don't need to change any of the metadata. That means you can just copy the metadata from the original, unedited file, and use it as the metadata of your new, edited file. If you don't have the original anymore, you can just redownload it from the Github repository again.

Here's how you copy the metadata from one file to another:

First, open the **original** `.dmi` in TweakPNG. You can do this by just dragging the file into the TweakPNG window. The file will look like this:


The only part of this you need to pay attention to is the zTXt chunk. Select it, and just press copy. Ctrl+C works too.


Next, open the **new** `.png` that you saved, with your edits. Again, you can just drag it into the window.


Note that it doesn't have any zTXt chunk. If it does, just delete it.

Now, select any of the chunks in the middle of the file and press paste, or Ctrl+V. You can put the zTXt chunk anywhere **after the header (IHDR)** and **before the image data (IDAT)**. Then, just press save - or Ctrl+S.


Now, all you have to do is change the file extension on your new file from `.png` to `.dmi`. You'll also want to make sure it has the same name as the original, so in this case it should be `device.dmi` instead of `device_new.dmi` That's it!

:::info
You can also **Save as** a `.dmi` straight from TweakPNG, once you've added the zTXt chunk. Keep the type as `.png` though.


:::

To recap, here are the steps visualized in a graph so you can see what you're doing:


### Advanced TweakPNG usage

The above technique works fine for making changes to existing sprites, but what if you want to add new sprites? Or create a new `.dmi` file from scratch?

If you add new sprites to the end of a spritesheet, they will be ignored unless you also define them in the metadata. To edit the metadata, open up your `.dmi` in TweakPNG, and double click on the zTXt chunk. It'll open up this window:


From here, you can make any changes you like. To add new sprites, simply copy another state into the list. If you added your sprites to the end of the spritesheet, then add your state to the end of the list. **Make sure to give it a unique name, and list the correct amount of directions and frames.** If you added your sprite to the middle of a spritesheet for some reason, or otherwise rearranged the sprites in the spritesheet, make you sure also rearrange the list of states to match what's in the spritesheet! Left to right, top to bottom.

**If you want to create a brand new .dmi file from scratch**, you'll need to create the zTXt chunk and write in the template yourself. First off, open your `.png` file. Go to **Insert**, and add a text chunk between the header (IHDR) and image data (IDAT):


Then, double-click on it to open it. Change the keyword to "Description" and make sure "Compressed" is checked:


Finally, write in the state information for your spritesheet. Here is a blank template that you can copy and expand yourself:

# BEGIN DMI
version = 4.0
	width = 32
	height = 32
state = "icon"
	dirs = 1
	frames = 1
# END DMI

This template creates a `.dmi` file with a single, non-animated sprite called "icon". Add as many states as you need, give them proper names, and define any animation or directions used. Make sure to save your file, then just change the file extension to `.dmi`. Voila!

:::info
If your drawing software can also edit text chunks (such as image descriptions), then you may be able to create and edit `.dmi` files without even using TweakPNG. To my knowledge only GIMP and Photoshop are able to do this.
:::

## Best practices

In this section, I'll cover some practices that you should follow when making and contributing sprites.

### Naming icon states

Give icon states **simple** names that are **clearly readable** and **distinct from the other states** in the file. These are used as keywords in the code, so keep them in **lowercase** and avoid using special characters.

If you have multiples states for an object, list their icons with the same name and a suffix (joined with a hyphen) that defines the state. For example, in `canister.dmi` you might have an icon state called `can` for the canister itself, and `can-open` for when it's opened.

When objects go through a series of icons depending on their states, you can use a numbered suffix such as `light-0`, `light-1`, `light-2`, `light-3`, and so on. Ideally though, use verbose descriptions such as `light-off`, `light-low`, `light-med`, `light-high` when possible.

### File organization

It is bad to put every single sprite into one file, but it is also unnecessary to have a separate file for every icon. Ideally, you should group your sprites by category. By cutting up your icon files into more specific groups, you make it easier to find sprites you need. Don't go too granular though, as having to open more files is bad for game performance.

:::info
For example: putting all atmospherics sprites into `atmospherics.dmi` is too vague, as you'll end up with canisters, uniforms, and tools in the same file. Instead, make a separate `canister.dmi`, `atmosuniform.dmi`, and `atmostool.dmi` file with their respective sprites, and put all those into an `atmospherics` folder. Making separate files for each type of canister would be bad.
:::

If you are working on sprites that have their appearance modified by code during run-time(such as a machine that can have a panel opened), include each sprite used by that object's code in the same file.

TODO image example

TODO List how icon categories are currently organized

### Error sprites

The icon state an object uses is defined in the game's code. If this icon state is incorrect for whatever reason, due to a typo or bug in the code, the object will become invisible, as it will have no icon.

However, if you define an icon state in a `.dmi` file that has a blank name, any objects with broken icon state names will use that icon instead. This means you can use these icons as a sort of "error" sprite that show up when something is broken. This is often more useful than having your object turn completely invisible, preferably during bug-fixing.

TODO Add example

### Hitboxes

Players interact with objects by clicking on their sprites. To determine the area of the object that can be clicked on - the **hitbox** - BYOND simply includes any pixel that isn't completely transparent.


If your sprite has holes in it, like a donut for example, then players trying to click on it might accidentally click the hole in the middle of the sprite and wonder why nothing is happening. Or worse, they'll interact with whatever is behind the object instead of their desired target. To prevent this, it's recommended to add some near-invisible pixels to cover the holes. To do this, **simply paint some pixels that have an alpha value of 1**. These are invisible to the eye, but let you click on "empty" space as if it were a part of the object.


:::info
Keep these holes in mind when working with objects like grilles and catwalks too. The numerous holes in the sprite could be better off being covered entirely.


:::

You should also add these invisible pixels to the sides of very thin or other inconveniently-shaped sprites, so that the objects are easier to pick-up. **Don't overdo this though**, otherwise the sprite could "block" any objects behind it. I used a two-pixel wide buffer in the example below, but a single pixel is usually enough.


### Working backgrounds

When working on your sprites, I highly recommend that you use an in-game screenshot or mockup as a backdrop in your spriting software. You'll need to place it on a background layer and do your spriting above it.


Doing this will help you see if your sprite fits in-context right away, without having to open up the game. It'll also let you spot problems that might not be immediately obvious if you're just working on a checkered background. For example, you might notice that your sprite blends in with the floor- in that case, increasing contrast and using a darker outline might help.

Work over something that makes contextual sense - your background should be where the object you're spriting will be found. If you're spriting a Lavaland creature, use a Lavaland screenshot as your background. If you're spriting drinks and bottles, use a bar or table as your background.

### Copying parts

When creating or editing a sprite, it can be useful to copy portions from other related sprites. This is especially useful as a beginner, where sprites you create may not be as good as existing assets. Instead of starting a sprite from scratch, use a similar pre-existing sprite and edit it to be what you need. By using good sprites and imitating them, you will learn what works much faster and be able to develop your own style once you've got the basics down. Be sure to credit any artists you work from.

This is also good practice if you are creating objects that are identical in nature or theme as other objects already in the game. For example, when creating a new Syndicate gun, it would make sense that the sprite has some parts or colors that are already in use by other Syndicate weapons in the game. This is especially true for clothing and armor, or machines and objects from the same department.

TODO ADD EXAMPLE

### Overlays

Overlays are a technique used by BYOND to layer sprites on top of each other. Often, it can be useful to design your project to use overlays instead of making a separate sprite for each possible combination that could occur in-game. This will require your project to use some code, (TODO ADD LINK) but it is usually quite simple and can save you a ton of time. It's also a much more elegant solution.

**Overlays are used liberally in SS13. Knowing how to work with them is important.** Complex objects that modify their appearance based on gameplay factors often use overlays to make it work. Panels being opened, food being eaten, objects being broken, clothes and worn items, and so on- all use overlays.

:::info
Consider player sprites: their appearance is made up of a base human (or other race) sprite, with eyes, hair, clothing, hats, accessories, injuries, and so on added on top. There is a virtually infinite amount of combinations of player sprites, so drawing each one separately would be impossible. Instead, the game constructs the sprites by overlaying the different parts together.

(TODO ADD DECONSTRUCTED IMAGE)
:::

TODO ADD IMAGES

### Palette use

A good technique to follow when working on a sprite is to have a palette somewhere directly on your canvas next to your sprite, so you can quickly pick colors from it. Not only does this speed up spriting, it'll help you stay consistent in your color use. If you arrange your colors into ramps, you'll be able to quickly see if two colors you're using are similar enough that you could just merge them into one.


### Crediting

Since most SS13 servers are open-sourced, sprites are usually permissively shared between codebases. Although you won't get in trouble for not doing so, it's polite to ask spriters for permission if you can use their sprites on your server. This being said, certain servers have special copyright requirements that apply to their assets. Make sure to verify the license used on the codebase's git page.

Whenever you use or adapt someone else's sprites, make sure to credit them in your PR. Likewise, make sure others credit you when they use your sprites!

### Pop culture references

SS13 contains many, many easter eggs and references to popular culture. For example, the fact that you can use the detective's hat to store candy corn is a [reference to Problem Sleuth](https://www.homestuck.com/problem-sleuth/80). These references are usually much-beloved, but try to be creative and show some restraint when adding your own:

* **Does the server you're contributing to have a serious or original theme?** If so, a reference might be out of place.
* **Is it subtle?** Overt and low-effort references are usually uninteresting or even annoying for players who aren't into what you are. A subtle reference can be tantalizing for those who care and inoffensive to those who don't.
* **Does it make sense for the object?** Don't try to fit a reference into something that doesn't work well with it. If fitting in your reference comes at the cost of the sprite's clarity, it's best to do without it.
* **Is it thematically relevant?** SS13 is a science fiction game, so references to sci-fi pop culture are a better bet than fantasy.
* **Is the reference novel?** Try to avoid referencing works that are already present in-game. For example, the Alien franchise is already extensively referenced by various objects in game.
* **Should your object have a serious sprite?** If what you're spriting is a core gameplay element, try to avoid making it a reference unless it would really make sense. References are best reserved for less important objects.

Some examples of **good** references:
* The **stunbaton** references the same batons from Half-Life 2. They fit the sci-fi, dystopian theme, and otherwise fit into the setting just fine. A user that doesn't recognize the reference wouldn't find them out of place.
* **Meatbread** is a reference to the meme from the /tg/ board. It's goofy but plausible enough for the setting, and makes a convenient recipe for the chef. It's also an unimportant object.
* The **AI core theme** has some garbled samples from the Space Jam song. They're just barely perceptible enough to arouse attention from someone who knows the theme, but seem like just random noise to others.

Some examples of **bad** references:

* The **SORD** is a reference to the same weapon from Homestuck. It's an eyesore, not even a useful object, and doesn't offer anything of value to the Chaplain besides an extra weapon among dozens. On top of this, the game already has numerous other references to Homestuck.
* The **engineering hardsuit** sprite is taken straight from Dead Space, without actually imitating features of the suit from the original work. It's also unlike any other suits the other departments wear (although hardsuits for other departments were added afterwards).
* The **marble bust** sprite is literally a resized image of the same bust omnipresent in Vaporwave imagery, with no adaptation to the art style at all. The genre itself also isn't relevant to the game or setting and isn't incoporated in other ways.

## Style guide

### Perspectives

While BYOND itself is a top-down game engine, sprites in SS13 are drawn in various different perspectives. While the rules vary from server to server, and some have no rules at all, it's best to follow these basic guidelines:

**Mobs** are drawn according to these rules:

* **Player** sprites, like humans, alien races, and the clothes they wear, are drawn from a **side** perspective. Since all the clothing sprites are drawn this way, anything that can wear clothes has to be in this perspective.
:::warning
The exception is Goonstation, which has player sprites and their accessories in **three-quarters**.
:::
* **Creature** sprites, like space creatures, monkeys, etc are usually drawn in a **side** perspective, but some (like spiders) are **three-quarters** instead.

**Objects** vary heavily. Usually, the perspective that best represents the object is chosen:

* **Small or handheld objects** like tools, syringes, pills and so on are usually drawn in a **side** perspective.
* **Inert and decorational objects** in the environment are drawn in **three-quarters**.
* **Guns** are always drawn from a **side** perspective.
* **Big, bulky, or boxy objects** like machines are always drawn in **three-quarters**.
* **Objects that are commonly found on tables** like food and drink are drawn in **three-quarters**, like the tables.

**Effects** are generally perspective-agnostic, since they look the same from any direction. Draw them according to their source.

**Turfs** depend on the server you play on:

* **Floors** are always drawn top-down, since they must be square.
* **Walls** vary from server to server:
* The most common walls are drawn **top-down**, like those found on /tg/station and most of its branches.
* Some servers, like Baystation and Colonial Marines, have **slanted** walls, which are a modified three-quarters view with the sides visible.
* A more recent and experimental project uses true **three-quarters** walls, also called "tall" walls.

TODO ADD IMAGES

### Sizing

While the size of your sprite may be 32x32 pixels, the true size of the object you are drawing is likely much smaller. Properly sizing your sprite is important to make sure it fits within the game world. Less important objects are generally smaller.

If you add a new burger sprite for example, make sure it's about the same size as the existing burger objects. You can't easily resize sprites, so make sure you're working at the right size before you finish your work and realize it doesn't fit! Working with a mockup background is a great way to avoid this problem. (TODO ADD LINK)

**The size of your sprite also has a direct impact on gameplay**- in order to interact with an object, you have to click on the sprite. If the sprite is very big, it's easy to click on, and if it's small, it's a lot harder to click on it. Keep these facts in mind when determining the size of your object.

:::warning
One such example is the energy sword sprite. When it's turned off, the sprite is very small and hard to click on. In the middle of a fight, being able to click on the sprite could be a life-or-death matter! If the object you're spriting for is of high importance, consider giving it a bigger sprite.

TODO esword sprite
:::

:::success
Inconveniently sized sprites can be good in certain cases though! The pocket pistol traitor item is cheap and easy to conceal, but one of its main drawbacks is that it leaves casings all over the floor when fired, which can be used as evidence. Picking up each individual casing, since they're so tiny, is tedious and time-consuming, but this is a good thing! This is a realistic effect. If cleaning up all the evidence were quick and easy, it wouldn't be as much of a drawback.

TODO casing sprites
:::

### Color use

A fundamental aspect of all pixel art is the concept of **color count**. This stems from the origins of pixel graphics, were colors were limited by the hardware of the time. However, even with modern systems, it is important to keep track of what colors you are using in order to produce sprites that look good and retain their crisp and clear appearance. This requires intention and control, and it is what separates pixel art from digital art. Here is a tiny section from a larger digital art piece, and the same section but recreated in pixel art:

| 481 different colors | 8 different colors |
|:-:|:-:|
|||

At the small scales required by SS13, keeping your color counts low is a good idea. Simple sprites may only need 4-5 colors. Some may require 8-9 or so. Complex constructions might even need up to 20 colors. If you end up regularly surpassing this number, then you are likely using too many colors. **Try to keep your color count low** by always using colors that are already in your canvas (use the color picker tool often).

**It's also good practice to use colors that are already in use in *other* sprites.** If you're spriting a new gun in use by the syndicate, try to refer to the existing syndicate gun sprites and copying the same colors. That way, the objects will look cohesive together. This goes for any object you're spriting - chances are, there exists a similar object that you could refer to for consistent coloration.

### Outlines

Sprites in SS13 generally have outlines. This is to help separate the objects from the background they are displayed on, which is important for clarity. Here are a few examples of different oulining techniques:

TODO ADD OUTLINES (HARD OUTLINE, COLORED OUTLINE, SHADED OUTLINE)

A hard outline is an outline that is the same color throughout (usually black or a dark color), and is identical to the outlines of other sprites in the same work. **Avoid using these in SS13** as they lead to a very arcade-y look.

A colored outline is an outline that is a dark color based on the overall color of the sprite. For example, a red apple could have a dark red or brown outline. A blueberry could have a dark blue or purple outline.

A shaded outline is like a colored outline, but its color is not the same throughout. It is brighter on the parts of the sprite that are exposed to light, and darker on the other parts. **This is the ideal type of outline to use in SS13.** Although an outline is always darker than the parts of the sprite it is outlining, the brightest part of a shaded outline could be brighter than the darkest parts of the sprite.

:::info
Outlines are still a part of your sprite. They can still carry form and visual detail, so use them as a part of your object rather than just something that you add at the end.
:::

Tiny sprites that are only a few pixels, such as pens or bullets, can become too big if they are outlined, so omit them in these cases. Effects generally aren't outlined either, as they aren't objects and are visually distinct enough from the background already.

TODO add example

### Lighting

### Inhands

## Spriting techniques

### Anti-aliasing

Preserving shapes

### Dithering

don't

### Color theory

Color theory is a vast field of knowledge, and even just the parts that apply to spriting could fill a guide to themselves, but I will attempt to cover the basics. **Understanding color is crucial to pixel art**.

#### Color spaces

You might remember the color wheel from grade school:


While popular, this way of conceptualizing colors is more applicable to print or traditional media and not quite useful for pixel art. Since we are using a digital medium, it is very helpful to know how computers work with color.


Above is a three-dimensional representation of all the possible colors that computers can use. Each axis describes the amount of **R**ed, **G**reen, and **B**lue that is present in a pixel. These values are mixed together to produce the final color: every pixel on any image has its color somewhere in this cube. This visualization of color is called the **RGB color space**. In most cases, these values are a number between 0 and 255.


This is a very convenient way for computers to compute color (for reasons I won't get into), but still not super useful for us as artists. An even better way to visualize things is with the **HSL** or **HSV** color spaces.


Instead of splitting colors into their red, green, and blue components, the HSV/HSL color spaces separate them into **H**ue, **S**aturation, and **L**ightness/**V**alue.
**Hue** is the *color* of your pixel, as humans understand it: whether it is red, or orange, or green, and so on. This is typically a number between 1 and 360 (representing the degrees around a circle of color, like was shown at the beginning of this section)
**Saturation** is how *colorful* your pixel is. If your hue is red, saturation determines whether that is an intense blood red or a faded dim pink. Having zero saturation means your pixel is in grayscale.
**Lightness** or **Value** describe the brightness of your pixel, basically how bright or dark it is. There are some key differences between the two, but they work similarly in practice.

These color spaces are arranged in a way that is much more intuitive for humans to work with. **Make sure your art software is in HSL or HSV mode when you are picking colors**- it will make color adjustments much easier, especially when it comes to hue shifting.


:::info
For example, when making a palette, if you already have an orange color and would like to add a new paler orange, you can simply raise the value/lightness and decrease saturation. In RGB, you would have to fiddle with all three values and would likely end up with a different hue.
:::

:::info
If you are a more advanced spriter and your software supports it, consider learning about the **[LCh color space](https://atmos.style/blog/lch-color-space)**. It is more complex to use as it has dead zones within it (combinations of values that don't correspond to any color), but comes with numerous advantages, notably that it corrects for the fact that different hues have different levels of brightness.
:::

A takeaway from this section should be that when pixel artists (or this document) refer to "color", they are referring to the exact combination of values here, not just a concept like *red* or *green*.

#### Palettes

A palette is the collection of each color that is in use in your sprite or piece. It should contain just enough colors to properly illustrate your sprite ([see the section on Color count above](https://hackmd.io/@Partheo/spriting#Color-use)).

Some projects will use a large, comprehensive palette that contains enough colors for every sprite within the project. Others will have smaller palettes on a per-sprite basis. If your SS13 server has a unified palette in use, make sure to use it. Otherwise, just try to stay consistent within your own work.

Palettes are often divided into what are called **ramps**, and within each ramp the steps in color are called **shades**. Each ramp represents a general color and is always arranged from darkest shade to lightest shade, although some get darker before going back to brighter colors(or vice-versa). This gradual change in brightness is why they are called ramps. Below are three different palettes: the first is only a single ramp, the second has four ramps, and the third has several.


Different ramps are connected together if they share a color as one of their shades. In large palettes, it's good to reuse colors to keep your color count low, so ramps will often overlap. Don't worry too much about how they are arranged, it's generally just a creative exercise for whoever made it.

:::success
Working from a palette is a great way to both improve your skills as a spriter and to create nicer-looking art. Always stick to your palette (if you have one, which you should), but don't be afraid to add colors to it if it's too limiting- just make sure to do this in moderation.
:::

### Contrast

Color choice

With background

### Clusters

Noise (and how to avoid it)

Level of detail (what details to try to include)

### Shading

General shading

Outline shading

### Hue shifting

Hue shifting is a very important technique because it makes your sprites look way better with very little work. Simply put, **the color ramps in your palette should have variations in hue between steps, not just brightness or saturation**. This is an excellent way to improve the colors of your sprite. Without it, colors will often look "flat". Notice how much more vibrant and dynamic the ramps on the right look:


This is an exagerated example and probably more suited to artistic pixel art rather than spriting, but *all sprites benefit from at least some hue shifting.* Just make sure not to overdo it. For a game like SS13, very light hue shifting is enough.

**Hue shifting works best for objects that are of an organic variety**. Think something like an apple, or a creature, or objects made from wood. It looks great on clothing and uniforms too. Inorganic objects like guns or metal should only use very light hue shifting. If you want something to look dull on purpose, like it's made of cheap plastic, then avoiding hue shifting altogether will work great.

TODO add example sprite

Consider which colors you are shifting *to* as well. A gray palette for metallic objects looks great with a bit of extra blue hue on the darker shades, but you might want to go for red instead if you want it to look like rusted iron instead of stainless steel.

## Where to contribute

So, now that you know how to sprite, what do you do? If you're reading this guide, there's likely a project you're already interested in working on - but if not, here are some suggestions.

### Improving existing sprites

The best place to start. Play the game for a bit, and see if any sprites stick out to you as needing some polish! **Editing existing sprites is quick, easy, and makes for great practice**. It's likely there's also a lot of placeholder icons from recent additions that could be given a real sprite.

:::warning
Be aware that you'll likely experience some pushback if you try to change iconic sprites. Players get very attached to certain icons, and changing them (even for the better) will attract some unwanted attention unless you've built up some reputation and trust in your community. Make sure you're confident in your ability to improve them.
:::

### Adding new objects

Ever wanted to add your own object to the game? Adding new features will generally require some code, but in a lot of cases it's quite easy. Adding clothing can be a fairly easy task, for example: just copy a clothing object's code, set its appearance to your new sprite, and give it a new name and description. You'll want to talk to a mapper to ensure it actually ends up in the game world somewhere.

Brand new features will definitely require some coding experience. You can do it yourself, or see if you can get any coders to help you. If you have a good and straightforward idea, you'll probably be able to find someone to help you. Ask nicely.

### Porting sprites

Are your server's sprites showing their age? Chances are another server already has an improved version of the sprites you'd like to change. Shop around on other servers and see if there are any sprites you can port over. This is a great way to improve the look of your server without actually having to do any spriting work yourself. Just make sure to ask for permission from and to credit the relevant people!

:::warning
Make sure the sprites you are porting actually fit the look and theme of your server. A low-quality sprite that is thematically consistent is often better than a high-quality sprite that doesn't fit in with the rest.
:::

### Helping coders

Coders generally aren't very good at spriting. If you look through the open PRs on your server's GitHub page, there's a good chance you'll find a new feature with some low quality codersprites. If you think you can do better, reach out to the creator! They'll be happy to replace their placeholders.

Certain coders will announce that they need some spriter help on Discord or GitHub, and sometimes even offer money for your time.

### Bounties

Certain servers offer **bounties, which are paid rewards**, for improving the codebase in some way. Usually this will be things like bug fixes or feature coding, but you may find some sprite work as well. Since this is paid work, a general standard of quality is expected. Being a bounty spriter can be fairly profitable. Look on the GitHub issues and project pages for a "bounty" label, or check the server's forums.

## Spritercode

Spriting is mostly an artistic endeavor, but **you will hold significantly more contributing power if you learn at least a little bit of code**. This section will cover basic sprite-related code that will allow you to work independently and on more complex projects. I **highly** recommend learning this material at some point in your spriting career, as it will open a lot of doors.

This section will assume that you at least understand how DM, Byond's programming language, functions at a basic level. If you don't, [here is a brief tutorial](https://tgstation13.org/wiki/Understanding_SS13_code) that explains DM's basic concepts to beginners. If you have programming experience already, but not with DM, [here is the page for you](https://tgstation13.org/wiki/SS13_for_experienced_programmers#Important_procs).

### Overlays

### Emissives

### Icon smoothing (tiling)

### Native icon code

## Creating your project

Inspired, informed, and with pencil tool in hand, you are finally ready. This part will go over the steps to complete your project, from beginning to end, with some tips for each section.

### Being independent

### Project ideas

### Making your sprites

### Testing your sprites

### Feedback

### Making a pull request

### Sprite icon conflicts

## Beyond the guide

Here are some external resources that are worth taking a look at.

### Spriter communities

Besides your server's forums and Discord server, there are a few other spots that are good to hang out in for questions and feedback:

**[SS13 Spriter Server](https://discord.gg/A35MP69qG8)**: A fairly active Discord server with channels for sprites, requests, pixel art, and guides. This is a good place to get in touch with spriters from all sorts of different servers, including Russian ones.

**[Spriter's Den](https://discord.com/invite/BxfUwAr)**: A smaller and significantly more edgy Discord server. Worth mentioning as there are still some very talented spriters here.

**[Coderbus](https://discord.com/invite/Vh8TJp9)**: Active Discord server for all manner of SS13 code-related discussion. Very helpful members.

### Other guides

### Pixel art

Pixel art is a great medium that has a ton of overlap with spriting. If you want to flex your artistic side or be inspired by some incredible artists, here are some places to visit:

**[Pixel Art Discord](https://discord.gg/pixelart)**: Very active and thriving Discord server with lots of artists. Come here to look at some great art, get advice and feedback, guides, and frequent events and collabs.

**[Lospec](https://lospec.com/)**: A new website for digitally restrictive art (such as pixel art). Has guides, a palette list, and an art browser. You can upload pieces here.

**[Pixelation](https://pixelation.org/index.php)**: A classic pixel art forum. An institution. Has some incredible threads and collabs.

**[Pixel Joint](https://pixeljoint.com/)**: The classic pixel art gallery. Hosts some of the best art in the medium.

There are also numerous ways to find pixel art on art websites like DeviantArt and ArtStation, or social network sites like Reddit and Instagram.

## Thanks for reading!

You've reached the end! I hope this guide was useful for you in some way. Please share it as much as possible, and feel free to reference it & use it in any way you see fit. If you have spotted any errors, inconsistencies, or have any other suggestions about improving the guide, reach out to me on Discord (**@par**). Due to spam, **I no longer accept friend requests from accounts I don't recognize. Please join the SS13 Spriter Server** (Linked just above) **and send me a DM directly so I don't delete your request.**

I am also available for any questions, help, or feedback. Feel free to reach out at any time.

<style>
.markdown-body table th,
.markdown-body table td,
.markdown-body table tr {
border: none !important;
}

.markdown table {
background: transparent;
}
</style>