Hi!

I managed to have a 2D pixel artist contact me to make some pixel sprite work for me. I am happy but also lost on how to go about setting up a work plan list for this artist.

Can anyone lend me some tips on how to complete a work plan list?

Thanks!

Speaking from personal experience (as a pixel artist) I can tell you what I like to see, which ultimately helps me produce results faster and with less reworking.

1. A Complete Game Concept in a Design Document
   • This lets me know the scope of the project, and get a pretty good idea on a production time frame based on the needs of the project combined with the speed I can produce the desired results.
   • Without this there is always the fear the developer will just keep adding to the game, or make changes to the design that forces reworking of 'completed' assets. This helps inspire me as well as keep me motivated to see a potential end in sight (regardless of how far in the future that might be).
2. Style Desired
   • What style is wanted is important too, if the developer likes a pixel art style they want to emulate, reference art from that game helps. That way I can create something similar in style, but with my own unique art style. This will also work along side dimensions to let me know if I should pack in as much detail as possible, or if they want something more simplistic looking.
   • Style is a pretty broad concept. It can range from how big the color palette can be, to what the actual sprites look like, to hard contrast sprites vs line art style sprites.
3. Concept or Reference Art
   • For me this is huge, as it helps me see into the mind of the developer and create an end result that is closer to what they envision. Without any type of concept drawn up or references, I have to use my own imagination. If what I imagine is different from what the developer imagines, then it creates a redundancy of work. I have to go back and recreate sprite work over and over until I basically luck out in creating what the developer imagines.
   • If the developer doesn't have a concept artist on the team, or can't draw concepts themselves, I encourage them to find real life photo examples of what they are thinking. Even crudely drawn examples help huge, no art skill is required, even stick figure drawing help for how they might imagine stances for character sprites, or animation frames.
4. Sprite Dimensions
   • Knowing what dimensions to work with for tiles, and character sprites, allows me to ensure that things like doors, buildings, signs, etc, all look like the appropriate size relative to everything else. This also allows me to immediately know how much detail I can add.
5. Frames for Animations
   • Knowing how simple or complex animations are needed to be will allow me to give them a more accurate production time frame.
   • Simple rpgs with tile based movement can use 4 frame animations for characters, with 1 frame repeating (so 3 unique sprites), like the early Final Fantasy games for SNES. Where as something like Legend of Zelda which uses pixel based movement has an 8 frame animation for the character sprite, each frame being unique.
   • I personally define the differences between styles as 'emulated/representative movement' versus 'realistic movement'. So if you think of a character swinging a hammer down from a side view, emulating that movement only requires two frames; 1 frame with the hammer up, 1 frame with the hammer down, then alternate between them. If you wanted more realistic movement you might have 4-8 frames, where not only do we see the hammer at a 45' angle, but also changes in the characters stance. 
   • Side Note: How many frames used for animations will also determine how quickly they are displayed (frame rate). With the above example of the hammer swinging; you'd want a slower frame rate with the 2 frame animation, and a faster frame rate with the 4-8 frame animation.
6. A Hard List of Required Assets 
   • This ideal and takes the work of me mentally realizing what sprites are needed by reading the design document. If the developer has already cataloged their needs, it's simple for me to use that as a check list.
   • The hard list would also include what sprites need animations. Some games don't animate drawers in a dresser, some do, so it's important to have that kind of stuff figured out in the design document, then added to the hard list of required assets.
7. Not Feeling Like Team is Waiting for Results from Me to Continue Other Project Aspects
   • One of the most frustrating things is feeling like I don't have enough time to properly execute the needs of the developer to the fullest of my abilities because they are waiting on a completed asset to progress development. This happens when developers aren't using place holder or 'programmer art' initially.
   • Something to consider is if the project is versatile enough to implement pixel art assets that might vary in size from the place holder art. If finished assets vary from place holder assets, this might cause extra work on the programmer's end. Which is why I always recommend that they use the same dimensions they want me to create with, in their place holder art. This way it's just a matter of replacing files.
   • For things like UI's and buttons and stuff, for me personally, I typically don't mind cranking out something to use as a placeholder, but it always runs the risk of not being the same dimensions as the final asset, and ultimately causing more work for the programmer.
8. Not Waiting For Concept/Reference Art in Order to Keep Working
   • Being able to keep working without waiting for the rest of the team to finish up concept art, or find references, is as important as not having the team wait for me to finish up work so they can continue. 
   • Some waiting is to be expected, but feeling creative and motivated, and wanting to put a solid days work in is easily killed when there is nothing I can get my hands on to put my creativity towards.