How do you or your company require designers to deliver their assets to coders? Do they deliver a PSD? A series of 24-bit PNGs?

If you are a coder, what would you include in a best-practice guideline to designers? If you are a designer, what questions would you like to see answered in such a document?

Here are some ideas:

  • Generally:
    • include designs for mouse-over and mouse-down states for all buttons and other interactive elements, as well as the normal state.
    • for toggle buttons, this can also include different states for both selected and unselected modes, for 6 states total: normal, over, down.
    • in drop-downs, lists, etc, please design a selected and unselected state for each item, if appropriate, especially where the content varies.
    • Flash is strictly an sRGB colorspace. If creating assets for Flash, make sure that your deliverables look how you expect it in sRGB.
  • If delivering assets as a PSD, please:
    • label all layers clearly.
    • make sure that the dimensions of your document exactly match the dimensions of the application

What else would you include in a Visual Asset Delivery Best Practices document?

  • 4
    \$\begingroup\$ Don't ever, ever, ever use PSDs. Not even if all you use is Photoshop. To quote Jeff Schewe: TIFF = Good, PSD = Bad (read his whole rant if you want to know details) \$\endgroup\$ Commented Aug 26, 2011 at 19:37
  • 1
    \$\begingroup\$ @Martin Sojka: I don't understand why TIFF should be any better than PSD. The PSD specification is available as well and several third party developers have implemented it. Also I just tried to open a (layered) PSD and the same file as TIFF in GIMP. Opening the PSD preserved all layers, but lost some of the special PSD layers (effects) while the TIFF just opens as a flat file (no layers are parsed at all). \$\endgroup\$
    – bummzack
    Commented Aug 27, 2011 at 9:16
  • \$\begingroup\$ @bummzack Mostly because TIFF is open (and always was), extensible, free, widely used and normative (vs. Adobe's "The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Adobe Systems Incorporated."). Oh, and it's still being updated and developed further. \$\endgroup\$ Commented Aug 27, 2011 at 11:03
  • 5
    \$\begingroup\$ A PSD file is akin to source code or project files imo - ie the working format for the artists. Giving this to the coders makes as much sense as giving source code to the artists. Delivery of assets should be done in "final" formats in the variations needed, and the specifications of this would be completely dependent on the project. \$\endgroup\$ Commented Aug 27, 2011 at 16:30

4 Answers 4


The standards should be, "whatever the code department needs, within reason". This may involve the coders writing exporter plugins for artists. But there is no standard way of distributing art since there is no standard way of consuming or using art. It's just down to what the technology pipeline requires.

However, as some rough guidelines:

  • First, ask what they want. If they want a certain texture format, eg. DDS or whatever, ask and they'll say so. Check to see if you can export in this format, and if not, confer with the team to decide on how to proceed. Maybe they'll need you to install a converter, or maybe they'll let you supply the images in a different format.
  • Make sure you have a consistent storage system for your assets that corresponds to the game's data. At some point you will be asked to redo assets, and therefore you will need to quickly find individual assets when told about a problem in-game.
  • Use common sense. Use lossless formats when they won't be too large for little gain. Use lossy formats when they are much smaller and don't lose you significant image quality. Keep lossless versions around in your own control system so that if lossy versions are unusable, you can still generate a lossless one.
  • When producing GUI elements, again, ASK how the system works. Don't waste your time producing mouse off/over/down/focused images when the system probably does not support all those, and might well implement some of them directly via hue shifts or alpha or whatever. Don't produce a precisely-sized dialog when it turns out they use a nine-slice system to allow dynamic sizing. Ask exactly what format they use, then supply it.
  • Don't render text onto a background unless you have confirmed this is the right thing to do. eg. If asked to produce OK and Cancel buttons, that usually means you make ONE button and then the code will render the words 'OK' and 'Cancel' over the top. When that game is translated into French later, this means someone just has to change the 'Cancel' string to 'Annuler' and you don't have to go back and produce another set of buttons.
  • When producing any asset type for the first time, deliver one to the intended recipient and get them to verify the format and dimensions are correct. You don't want to crank out 20 buttons and find out that they are all wrong.
  • Establish texture sizes and overall budgets before delivering textures - coders hate it when you deliver 2048x2048 textures for something that only ever takes up 10 pixels on screen. Similarly, if the colour is uniform across the whole texture, you do not need 2048x2048, or even 128x128 - you need 1x1. More generally, deliver the smallest asset that delivers the visual quality you need.
  • Establish consistent and descriptive naming conventions. If you generate buttons in off/selected/on states, name them quit_button_on.png, quit_button_selected.png, quit_button_off.png, etc., and repeat this across all buttons you ever make. If you generate several asset types for one object (eg. mesh, anims, textures), name them similarly if appropriate. I've known several artists who don't understand why coders have such an OCD attitude towards file names - it's because arbitrary file names waste our time. It becomes harder to find the right assets in a directory of hundreds. It becomes hard to flick from one to the next and back again easily to verify size changes and labelling is correct. It's difficult to know whether it's the code or the art which is wrong when something looks incorrect on screen but the debugger lists the texture only as "aaa34_345b.dds".
  • Do what the programmer wants - but make him help you do it. If saving in the relevant format is a burden, or checking the texture budget is impractical for you, or they want all assets in a special archive format that only one obscure piece of software can use... get him or her to write tools and plugins to help. A week spent on appropriate art tools can save both the artist and the programmer much more than a week of effort later. Don't let your code team skimp on tools.

The artists were able to keep the raw assets in any format they wanted. They would then export the files to a specific format, either from a plugin to Max/Maya that we made that would dump the data out in our format or simply saving as a PNG for photoshop and the like with the quality settings varying from project to project (ie, from target platform to target platform).

The files would then be processed into their load-time format by an asset compilation tool for faster load times.

However, this was just the way we did it. I would imagine alot of examples would follow along this line and there may have been guidelines above and beyond what I was aware of that an art director might have placed on top of the technical limitations depending on styles of art, but in general I think you will find the basic 'Artists keep it in a raw format and export it to a game engine specific format that is then further processed' as fairly standard at most large and even mid level game companies.


as a coder I just ask them what assets are the going to create, and then create a sample asset of those properties. give them the code and let them play with my app until they think output is good enough.


As a student I can't give proper advice as to what is done in the industry, however, when working on a group project the programmers were "in charge" and told the artists exactly what they needed. In addition to the guidelines provided at the beginning of the project they were also expected to follow the requirements provided by the programmers.

There was a lot of going back and forth when an artist didn't understand that the color R:254, G:0 B:254 was COMPLETELY DIFFERENT from the required R:255 G:0 B:255, was therefore unusable, and they had to start over.

  • \$\begingroup\$ On the other hand, you, as a programmer, could've trivially made your data loader change 0xFE00FE to 0xFF00FF. Like Kylotan says, programmers get to be anal to artists about formats because programmers also have a responsibility to make the tools. \$\endgroup\$
    – user744
    Commented Aug 29, 2011 at 13:57
  • 1
    \$\begingroup\$ @Joe: he couldn't change it because likely he had some images 0xFF00FF and some others 0xFE00FE. Moreover, people have to get used to do stuff in a proper format if that has been requested: circumventing their errors creates a flawed workflow. \$\endgroup\$
    – o0'.
    Commented Aug 31, 2011 at 9:05

You must log in to answer this question.