How to supply art ready for programmers
Monday, March 17th, 2008I’ve worked with quite a few artists now and I’ve realised that if game artwork can be delivered in a certain way it really speeds up my job as a programmer, and ultimately speeds up the artist because I don’t need to email them with unnecessary changes.
There’s nothing worse than spending hours laying out a screen only to have to spend hours repositioning it all again because new art has been delivered that has needlessly changed size or its position has changed within the image frame! Or how about having to figure out which image is which because the artist has changed all the file names? Or that the shadows and glows have been truncated and look bad on-screen. Or that the images look blurry because they don’t have even-sized dimensions?
The list of potential pitfalls is quite big and so I’ve made a list of requirements, which if the artists can comply with, will benefit the whole project as follows:
Files Names/Types
- Files to be named logically and the names shouldn’t change in future revisions so that I can plug replacement graphics directly into my game without having to rename them first.
- Instead of using spaces in filenames, please use the underscore character “_” OR capitalise each word e.g. GameScreenBackground.
- Always supply images as 32-bit pngs (24bit + 8 bit transparency) unless we can get away with a simple jpg because no transparency is required e.g. for static single layer backgrounds.
Image Sizes
- Try to reduce art dimensions to power of 2 numbers e.g. 8,16,32,64,128,256,512,1024 etc. Why? To save Video RAM (VRAM). Video cards only use textures with those dimensions so if you make a 129×257 texture the video card will round it up to 256×512! This is a huge waste of VRAM on lower spec machines. Ideally I try not to load in more that 32MB of textures to VRAM at any one time so that my games can run well on older PCs.
- The maximum size I can use safely is 1024×1024 because many video cards won’t handle textures bigger than that.
- Make sure that all dimensions are EVEN numbers. If I try to draw an image with an odd numbered dimension in my game, it will come out blurry because the centre of 31 is 15.5 for example (not a whole number).
Graphic Placement
- Centre all graphics/buttons/text as precisely as you can in each image based on the solid portion of the graphic i.e. ignoring shadows. This makes it easy for me to place the object in the game and if you send any replacement graphics later on, I won’t need to adjust the coordinates due to the centring being different (which is a pain).
- Always leave an empty 1 pixel border round each image. If any graphics are drawn right at the edge of an image and I later try to draw that image at sub-pixel coordinates, nasty anti-aliasing artefacts will appear.
- Try not to truncate any shadows or glows when cutting the image out. This is quite a common problem and can be easily tested by temporarily using a solid background like black to test glows and white to test shadows.
- Don’t leave too much blank space round buttons because the mouse over code treats the blank space as solid.
Layers
- If you are making a layered image of some kind, please let me know the Z order of the graphics so that I can draw them in the correct order (no thinking required on my part).
- Try to keep as many of the components of the artwork as possible in separate layers in case we need to adjust a small portion of one layer later on.
Replacement Graphics
- Where possible make sure that replacement graphics are a) the exact same dimensions, b) start at precisely the same x,y coords in the image, c) the same scale if applicable, unless there’s a good reason why a change has occurred (let me know of any changes to size/placement/scale that so I can alter my code). This enables me to plug them straight in without having to adjust them or my code first which is time consuming when we iterate a lot.
- When sending a batch of files, please zip them up. If you are sending updates with a date or number in the zip file name, please use the same format each time. I recommend using the date in reverse e.g. YY-MM-DD because when file names in that format are sorted alphabetically they also end up in date order which is very handy.
- Every time we make a revision it’s a good idea for you to leave the old file alone and save a copy with an incremented version number on your system in case we need to go back to a previous version.
Anything else?
Phew, quite a big list! It may be hard for the artists to remember everything at first but with gentle leading in the right direction the project will flow much more smoothly.
I hope that you found the list useful and I welcome additions/comments.