Classic 2D pixel art is timeless, but modern games take the flourishes of dynamic lighting, shades, particle systems, and post-processing effects like a chromatic aberration in bloom. During the creation of Bite the Bullet, some of our senior developers had an immersive round table on how they achieved the layered lighting effect for teleporters used in-game.
I have to say that seeing them in action brings the process to a whole new level. For demonstration's sake, we’ll keep the reference images as single still capture, and share them as a single gif animation of one of my favorite teleporters to kick off.
In this example, the glow stems from an emissive material, with a ton of effervescence cranked upon it. It looks “ just okay,” but does provide a sweet sci-fi sense of luminescence that any neo-futuristic teleporter would have.
Yet, there is a way to make it look better.
The difference is that in the former image, highly saturated color caps out as a solid cyan color. In the latter, it starts turning white, how light naturally behaves in intensity. The former's restriction is fundamentally depending on how Unity's rendering pipeline handles color by default. Our focus here is about the 'color space' rendering output.
Introducing: Filmic Color Space
Filmic color space accurately represents the behavior of 'lightness.' If you use Blender 2.79 or later, you may be familiar with this as the default color space starting at that version is Filmic. In Unity, you can achieve the same look by using a tone mapper in the post-processing stack.
Filmic Blender was created by Troy Sobotka, an industry professional and camera enthusiast who saw the problem with the default color space in Blender and wanted to fix it. So he coded Filmic Blender - a similar color management configuration to ACES, which is the industry standard for VFX.
Please note, this affects the color of everything. For example, comparing the floor colors in the above two images, you’ll notice that one is slightly darker. With this adjustment to a new tone mapper, the effect on all colors is substantial. If you want your art to translate the game view to look as it was drawn, this requires making this adjustment early in the asset creation process, so all colors are selected and applied as planned.
In our game, all of the VFX have been made in the previous linear color space, To achieve filmic-looking effects, we added bright white layering, and the contrast between colors was chosen in the context of the linear color space. When viewed in filmic, they'd look extremely overblown.
Similarly, much of the environment would look too dark because it was made under the assumption it would be viewed under a linear color space - the same color space the artists used when producing the art. In the same way, if you were composing a scene in Blender using linear color space and changed it to filmic color space, you would have to redo all of your lightings to accommodate this. You could choose not to change anything to match. Still, the overall look you get would be very different than you possibly intended.
The Bottom Line
Filmic color space will accurately and dynamically represent light behavior in a way that looks like HDR, but the removal of linear color space means that the color you see for a PNG asset in Windows Photo Viewer is not what you get in-game. Filmic color space is more realistic due to its higher dynamic range and translates to a more cinematic look. Even if viewed on a non-HDR display, the effect is still conveyed.
If you compare linear to filmic, linear usually feels washed out in comparison. But it's not as simple as contrast or saturation. As you see with the light example above; the behavior of color itself changes, especially as you get into extremely bright and saturated colors.
Effective lighting can give a simple and unfinished space a sense of life and ambiance. Using light, you can provide a level of polish that elevates the entire scene in pixel art games; giving it a modern feel without losing the purity and details.
Lighting doesn’t necessarily mean using light source objects in your engine. We prefer to use options like overlays and shaders to achieve a dynamically lit look despite not having dynamic light sources present. One of the most interesting takeaways we had during our filmic roundtable; was that for us: a better understanding and command over lighting may be the best way to provide the most effective visual feedback to a player with everything else already standardized. This is likely one of the reasons why people think UE4 looks better than Unity by default: UE4 uses filmic, and Unity uses linear color space by default, aka sRGB.
Your Filmic Workflow
Applying Filmic color space effectively in your Unity project requires an adjustment to your workflow, and some planning for visuals on both the artist and development side, planning around a specific color space.
There is a particular workflow for creating art assets for use in a filmic color space context, such that what the artist sees on their canvas is what you get in the game, 1 to 1. If Unity's filmic tone mapper is accurate, then using a filmic LUT profile in an image editor that supports it would be able to achieve that. For example, the graphics editor Krita has a LUT management system through something called OpenColorIO, which takes an OCIO profile to determine your viewing colorspace.
Take this Film Emulsion-Like Camera too for Blender so awesomely shared by Sobotka on GitHub:
https://github.com/sobotka/filmic-blender/blob/master/config.ocio
Once configured, you will then be viewing your canvas in the filmic color space, so what you see is what you get in-game.
The cost/drawback being all involved artists would need to have a workflow set up in a way that's compatible with the using a different color space. E.g, if their editor of choice doesn't support it, that's a problem. You can simply choose to have all art made in standard linear color space, but none of it will look exactly as-drawn when rendered within the filmic color space.
Here's a tip when making VFX, assuming you are staying in linear/sRGB color space:
Make the first iteration in linear color space, switch to filmic, and take a snapshot of it. Switch back to linear and try to recreate the filmic look using layering and adjusting colors. You can never 100% recreate it, but you can get close in the 50-70% range.
As an example below:
Then, after:
Filmic for reference:
It’s close! It took a second iteration, around twice as much time in total, but it gets strikingly closet to our desired effect. You have to use a whole other layer of problem-solving and creative decisions to get to the same point that filmic gets by default, and that's only if you're faking lighting like we are with our emissive materials. Additionally, if you animate or tween VFX (which is often the case with our projects), you’ll have more layers than normal to animate, and there will be a performance hit of more VFX-related objects rendering. If you are using actual real-time lighting, your mileage may vary in achieving a filmic color space look and feel while remaining in linear color space.
Our 2d projects pretty much never use real-time lighting for performance reasons. There are some cost considerations to achieve this level of juicy lighting, but for many, it’s a toll happily paid.
If you have a lot of dev-side VFX, especially with high complexity like particle systems, adding the art cost of using filmic would be worth it. Otherwise, if flashy VFX are rare and/or simple, it would probably be better to just fake filmic look on dev side with tricks. The main time cost in our consideration above is on the art workflow and existing assets that were already created in a different color space.
Adjusting your art toolchain the first time, and then getting familiar with the adjusted workflow can take some time in and of itself. Most artists have a personal preference of one or two programs (Photoshop, GIMP, Aesprite, GrafX2, GraphicsGale, etc), but will adopt a specialist set of brushes, or programs for a given project due to a unique feature. For example, some of our pixel artists prefer animation of pixel art to be done in Aseprite simply because of features like onion-skinning (not to mention the simplicity of importing sprite sheets into Unity using .ase files).
In addition to turning reams of design documentation and gorgeous art assets into an actual playable game, one of the goals of a video game developer should be to ensure that their code is efficient and maintainable. With these end goals in mind, it is important to start the coding process with certain principles in mind.
This guide presents the strategies and ideas that underpin our approach to coding. While each game is unique, these tactics can be applied to many different situations to ensure that your project is manageable and won't become a nightmare if you need to refactor or debug your code (which is always).
Table of Contents
We, Mega Cat Studios, have recently wrapped up development on Coffee Crisis, a multiplatform 2D Beat'em Up game for Sega Genesis, PC, and Xbox One! One of the features exclusive to the PC port that we implemented into Coffee Crisis was Chroma support. Chroma is a unique, proprietary, next-generation technology that Razer implements into its product line of high-end gaming equipment, which allows dynamic lighting on its equipment. Products created by Razer which implement their top-of-the-line Chroma technology include their keyboards, mice, mousepads, computer cases, and much more. Using the Chroma SDK, developers can integrate Chroma support into their games and applications, and configure the lighting on Razer's Chroma-enabled products. Such examples of Chroma integration include making the products light up as a VU meter in multimedia applications, encoding gameplay information on products, and even attempting to show images on the device by approximately color mapping colors in images to certain buttons/keys on the device.
Coffee Crisis is a neo-rogue brawler that puts you in the shoes of the only baristas on Earth with enough heavy metal in their veins to fend off an alien assault. Play solo or join up with a friend to fight across eight unique locations ranging from your Coffee House HQ to the far reaches of outer space. Go up against an army of wild alien enemies, and the humans they have brainwashed with a variety of weapons, special moves, suplexes, and coffee!
The Smurglian race has come to Earth and they're not leaving until they steal our three most prized commodities: heavy metal, free WiFi, and our coffee. Crunch through fistfuls of alien meat as you stop their invasion, and enjoy random modifiers to the enemies and action on each playthrough. It's a unique cup of beat 'em up action every time you play!
As part of our feature set of Coffee Crisis, we implemented Chroma integration into our game. The game was created for PC/Xbox One using Unity3D, a closed-source but critically acclaimed video game engine created by Unity Technologies, applauded and used by Indie and professional game developers worldwide. To add Chroma integration into Coffee Crisis, we used the official Chroma and Chroma Native Unity3D SDKs. For our game, we utilized Chroma for showing colorific animations on the Blackwidow Chroma Keyboard in cutscenes and menus, and on encoding gameplay information. Specifically, we implemented the following:
This guide will show aspiring Indie video game developers how to set up and use the Unity3D Chroma plugins for game development, as well as show an exclusive behind-the-scenes look on how we implemented the Chroma functionality in Coffee Crisis!
Before you can even use a Blackwidow Chroma keyboard for development, you must plug it into your computer for the first time. It goes without saying, but Chroma development will only work for Chroma-enabled Blackwidow keyboards. Certain Blackwidow keyboards do not include Chroma support; please check your user's manual.
Plugging in your Chroma Blackwidow keyboard
Plug in your Chroma Blackwidow keyboard into your computer. Some Blackwidow keyboards have 2 USB cords; one as a piggyback cable, another for the keyboard. Make sure at a minimum to connect the USB cable labeled "Razer" and not "Port". After plugging in your Chroma Blackwidow keyboard, the keyboard's drivers should install from online, and it should light up. In order to control the lighting and handle it in code, you will next need to install Razer Synapse software.
Installing Razer Synapse for development
Razer Synapse is a piece of software created from Razer which will allow you to configure the Chroma lighting on your Chroma-enabled devices, as well as interface with the lighting with code (after we implement code and the Unity Chroma plugins).
To begin, download and install Razer Synapse. At the time of this writing, the latest version is Razer Synapse 3 Beta, while the previous is Razer Synapse 2. Download and install either version (for this guide, we'll use Razer Synapse 3 Beta). After launching the installer, select which features you want to be installed, and where to install it. At a minimum, you will want to install Razer Synapse software and Chroma.
Now that we have both Razer Synapse installed and the drivers installed with the Razer Chroma Keyboard (via plugging it in), it is time to set up our Unity project to interface with Chroma!
In order for a Unity project to interface with Chroma devices, you will need to install the Unity3D Native and non-native plugins for Chroma SDK. You can find the native plugins here, and the non-native here. The former plugins are required for usage in compiled games (they interface with the hardware), while the latter plugins are used in the Editor only for creating Chroma animations. The latter ones should be removed for compiled builds, to reduce filesize bloat in the compiled builds. Please read the instructions from each download page on how to use the plugins and install them.
With the keyboard's drivers installed, Razer Synapse installed, and the Unity3D Razer plugins installed into your project, you should be good to go for developing with Chroma! Below are a few conceptual notes on how Chroma works in Unity. Full-details on how to use Chroma with Unity can be found in the tutorials on the pages where you downloaded the Unity3D Chroma plugins.
Chroma color with the Unity3D plugins works in either one of 2 ways: via Chroma animations, or by manually updating the colors of keys on-the-fly. The former method will be discussed in this section, while the latter in the next section. Chroma animations should not be confused with Unity's animations. The latter is used for changing properties of a GameObject's components overtime via keyframes (especially sprites and image graphics), while the former is used for changing the colors of Chroma-enabled devices over time.
Chroma animations are simply .chroma filetypes, stored in the StreamingAssets folder within the Assets folder in the root folder of the project. Unfortunately, Chroma devices are only supported on Windows machines, so when compiling the game for other platforms (Mac and Linux), you should remove the ChromaSDK plugins, UnityNativeChromaSDK plugins, and the StreamingAssets folder with the Chroma animations, since they will bloat up the build's filesize and are unused for those platforms.
To create Chroma animation, go to GameObject>ChromaSDK>Create 1D/2D Animation. For Keyboard animations, we will want to use 2D Animations. The Chroma animations should be placed in your StreamingAssets folder.
In order to edit Chroma animations, right-click the animation, and click ChromaSDK>Edit Chroma Animation. This will bring up a custom Chroma Editor in the Inspector.
In the custom editor, you can select the device type ("Keyboard" for this tutorial), select key types from the keyboard, and assign colors to each key in each frame in the animation. You can also import an image to assign colors to each key (however, this feature seems to crash often). When modifying colors, the Chroma devices attached to the computer will update to display your color configuration.
Alternatively, to individually assigning colors to each key, you can use the Chroma capture tools to map an image onto the various keys. To use these tools, Goto Windows>ChromaSDK>Open Chroma Particle Window. To learn how to use these capture windows, check out the tutorials here.
Animation playback
Now that we have our animations defined for the game, we will need to add code to playback our animation. Any Unity3D script that utilizes the native Chroma plugins will need this namespace added to the top of the script:
#if UNITY_STANDALONE_WIN
using ChromaSDK;
#endif
Furthermore, Chroma support is only supported in the Windows platform, so make sure to add #if UNITY_STANDALONE_WIN code blocks around Chroma code. Below is a quote from the API documentation here for the most important API functions for playback:
Now that we have animations defined and code for playing the animations, you will want to test them on hardware. You can either test it as such on real hardware (by playing the game with the Chroma device connected) or with the Chroma Emulator. The Chroma emulator will simulate Chroma lighting for a variety of devices. At a bare minimum, you will need one real Chroma device setup first before it can be used. Usage should be straightforward.
A limitation of the Unity Chroma setup is that animations are static; it doesn't really allow for combing several animations to encode data. When designing the in-game Chroma animation, we wanted to encode most of the game's information on the keyboard. Luckily, we were able to exploit a few things in the Unity Chroma set up as a workaround and allow dynamic key lighting. Coffee Crisis' in-game Chroma animation is simply a dummy Keyboard animation with no keys lit.
We heavily utilize the SetKeysColorAllFramesName API function in order to manually update the keys in an Update() thread; however, there is a catch to this method. In order to edit an animation during runtime, you must do the following:
This sequence of code events was what allowed us to pull off dynamic animations in-game. A problem with using an update() thread to update dynamic Chroma animation in such a fashion is that it may lag other people's machines. Different models of Chroma keyboards have higher fresh rates, and running such an update thread at full speed will severely lag other people's machines. As a workaround to this issue, we added a cooldown timer, to update dynamic Chroma animations every 250ms. Please see our truncated, relevant code attached, for a sample of how we set up dynamic Chroma animations to work.
