What is an asset pipeline?

Asset (or art) pipelines are the bane of many game developers' existence. The idea is simple: get some asset, likely an image, 3d model, audio file, etc., into the game!

This is usually done with an intermediate export step that converts from the art program's specific file format (.fla, .psd, .blend) to a more convenient one (.swf, .png, .obj). This export step isn't necessarily a problem, as normalizing your assets makes working with them much easier and allows artists to use different programs to create them. However, this step destroys most, if not all, metadata from the original asset, meaning you need a workaround to preserve it (depending on the format). Some formats account for this by allowing you to store arbitrary data when exporting, but they also require you to jump through extra hoops to access/correlate it how you'd like (see; .gltf). Additionally, you now have the problem of where/how to store these exported assets. Do you store them alongside the originals, keeping two files in source control for every asset (hope you like Git LFS). Do you only store the originals and automate the process of exporting, adding considerable startup time to your workflow? The simple idea of exporting assets creates many questions that are completely unrelated to the game you're working on. It sucks when you have to bikeshed on an asset pipeline instead of working on your project.

What if we could make this process much simpler and more powerful?

Just put the assets in the game, bro!

For simplicity, we'll only be talking about visual assets; specifically images. This covers a lot of cases for small-scale indie game development, and the principals can be applied to any type of asset.

Most of the time sprite sheets, texture atlases, etc. are created with a single program for the duration of the project (Photoshop, Aseprite, Flash, whatever). This usually doesn't change. If, late in a project, you suddenly swap from Photoshop to Aseprite after creating a large number of assets, you have other problems to worry about. Because of this, we can essentially gear that portion of our asset pipeline around that specific program. Why convert files to .png texture atlases when the original contains everything we want/need? Well, there's a few answers to that question:

1. The file format is undocumented (Blender, Flash, Photoshop)
2. My engine already supports the export format
3. I just want to make the game

These are all valid answers, and I'd recommend ignoring the rest of this series unless you're starting a project/only in the early stages. However, you'd also be surprised how easy it is to reverse engineer a file format using just a hex editor and some patience. If you're lucky, you won't have to do this because the art program's developers documented the file format for this specific purpose (try searching: "<file extension> specification").

The next installment of this series will cover the former, showing you how to reverse engineer an asset format. If you have any specific questions you'd like me to cover, let me know!

Thanks, and see you next time!