BecomeAPatron

How to supply art ready for programmers

I’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.

3 Responses to “How to supply art ready for programmers”

  1. jc Says:

    Good points.

    There is something that could help you a lot too:
    Allow the artists to test their stuff in your game, so they could find problems before they send them to you.
    This might need a little bit of work on your side but you will gain a huge amount of time later. For example, in my engine, you can update a sound or an image and reload them in the game with just a key press. The artist really aprreciate this because it is fast for them and allow to see their stuff in action. They will see that their new stuff doesn’t work in the game and fix it (after they learn why it doesn’t work, but once you told them, they can solve it on their own). You will have less comunication time and better result (everybody feel more involve in the project).

    JC

  2. Grey Alien Games Says:

    Yes an extremely good point. Certainly on my last few games the artists have been able to try their art in my game but often they have to exit and reload. I’ve just added the ability to reload the game particles (and parameters) at the touch of a button so I can tweak the text file that controls them and see an instant result in-game.

  3. Grey Alien Games » Blog Archive » My best articles of 2008 Says:

    […] was some practical advice on getting your resume looking good and working as a contractor and how to supply art for programmers as well as tips on improving conversion […]