I draw in massive print resolution - 300 DPI at poster sizes for important artwork. I start smaller in resolution for the sketches, color and composition studies, then up-rez when I'm ready to do the final piece. That way if I want to print anything, I can.
Like the article mentioned, always go bigger than your final image display will be, then resize down. You can imagine the file sizes I run into when my final image display size is 1920x1080 at 72DPI, so my working file is even larger at 300DPI and twice that resolution. Of course, I've worked on IMAX resolution frames for movies before, and those are 10,000 x 7000 pixels. (It's fun when 10-20 seconds of footage at 24 frames per second - i.e. 240-480 massive resolution images being held in your RAM all at once makes a workstation scream itself to death.
)
Text boxes and interface interactions are important to check, but I do that with all my images by having an interface layer I can toggle on and off while working on the image. I also keep other images from the game open in Photoshop to match tonal values and color palettes, so sprites and backgrounds match and look like they belong in the same world and lighting conditions throughout the game.
As for version control, what I do in team projects (and personal projects) is name files like this:
YourName_AssetName_Today'sDate_VersionLetter.FileTypeSo for instance, if I where working on a happy expression sprite for a princess character in a game I would save the file like so:
LWRabbit_HappyPrincess_July2012_A.psdThe version letter would change every time I saved the file - which should be often, right? So it would go from A to B to C, and usually eventually loop over to start at AA to BB to CC. Each day the version letter would reset to A, so if my final version of the file today was named
LWRabbit_HappyPrincess_July2012_RR.psd, when I saved it for the first time tomorrow, the file name would be
LWRabbit_HappyPrincess_July2112_A.psd.
For a long project, eventually I start condensing backups. This means that I only bother saving the final version of each file for each day, not the numerous iterations that took place over a day. Eventually I'll even go in and start making judgement calls on which days to keep and which to delete, keeping only the versions with significant changes from each other. At the resolutions I work at, a file can quickly eat up gigabytes of memory with all of its backups.These are considered my raw files. The ones with layers intact and super high resolutions for printing. When I save out an image for a game, I name it
HappyPrincess_Final_July2112.png When working with a team, having the artist's name attached to the file is very important. Especially if multiple people are working on the sprite or character, it lets you know who did what and when. The date on file names is one of the best things with this naming system. You don't have to wonder what the latest version of a file is - it's right there in the name. And it can be weirdly cool to be browsing files and realize how long its been since you worked on something.
Of course, when I was working at a studio, we would log into our workstation and the latest versions of our files would be automatically downloaded from an server, then when we logged out, our changes and new saves would be automatically uploaded back to the server. This was done on a scene by scene basis - if you were assigned a scene, the server gave you the latest version of that scene when you logged in. Once a scene was finished and signed off on, the server denied you access to those files. Sometimes two or more people worked on a scene, so we used the naming conventions like above to make sure we didn't screw with THEIR version of the scene by mistake. But it was cool to be able to OPEN their version and check it against yours to make sure things were matching or lining up. (And stealing things from a related scene to make your job easier!
"Hey! Is that a tweaked version of my animation for the background of Scene A?! You lazy, efficient bastard!")
Login
Register
FAQ
Search
Members
