Inspired by millions of tiny lights

News, updates, and general rambling from the crew at Pixelscopic

Delver’s Drop Process — Part 2: Art

The sec­ond install­ment in this series is com­ing a bit late; I blame PAX and its indie mad­ness. This arti­cle deals with how all of the in-game art is cre­at­ed. At a basic lev­el, the process can be summed up as “Draw things in Pho­to­shop; Save; Ani­mate where need­ed” but the meth­ods of doing so are much more detailed and there are quite a few steps in the process to make it more effi­cient. I won’t go into the extreme details here, but hope­ful­ly you’ll get the gist of what is involved.

As any of you who have watched Ryan Baker’s draw­ing streams have prob­a­bly gath­ered, art is orig­i­nal­ly cre­at­ed at a *very* high res­o­lu­tion — nor­mal­ly at least twice the size of the HD in-game assets. Part of the style of the art itself is a byprod­uct of the down­scal­ing from the orig­i­nal art into the sizes we use for pro­duc­tion. It’s also eas­i­er to draw and paint at high­er res­o­lu­tions, and has the added ben­e­fit of mak­ing the orig­i­nal assets print-ready. For exam­ple, take this dia­gram of the size com­par­i­son of the Rogue char­ac­ter art as it was orig­i­nal­ly made in Pho­to­shop — at around 8x nor­mal size — ver­sus in-game usage:

size_comparison

All art pro­duc­tion hap­pens in 2–4 stages. First, the orig­i­nal sketch­es for the assets are drawn at the afore­men­tioned mas­sive size; this helps keep the line work style con­sis­tent and ends with a draw­ing that can be eas­i­ly passed off to any­one for paint­ing. Depend­ing on the item being cre­at­ed, sketch­es may be made for one, three, four, or eight direc­tions and/or for var­i­ous visu­al states (whole, dam­aged, destroyed, etc).

Sec­ond­ly, the line draw­ings are paint­ed and this can often be a mini two-step process where a rough set of col­or swatch­es are paint­ed in and then the item is passed off to anoth­er mem­ber of the team to add the final detail. If the item in ques­tion needs to be ani­mat­ed via sep­a­rate pieces — as is the case with any­thing using a skele­tal struc­ture — the draw­ing must be dis­sect­ed and paint­ed as indi­vid­ual parts.

Next, the art asset(s) are scaled down to the appro­pri­ate res­o­lu­tion. This is typ­i­cal­ly done via a com­bi­na­tion of basic Pho­to­shop resiz­ing, actions, and batch scripts. The Export Lay­ers to Files fea­ture is par­tic­u­lar­ly use­ful for sav­ing mul­ti­ple files — par­tic­u­lar­ly because our last step uses a tool that trims all emp­ty space in an image by default. All images are saved out as 24-bit PNGs. Our pipeline allows us to save all assets at HD sizes which are then auto-mag­i­cal­ly down­scaled fur­ther once they pass through the final step: Tex­ture Packer.

tp_ss1

Tex­ture Pack­er is a lynch­pin piece in our process. All art up to this point — includ­ing items that are used in ani­ma­tions (which will be detailed in a sep­a­rate post) — are placed into Tex­ture Pack­er. This pro­gram takes all image files pro­vid­ed to it and con­dens­es them into the most effi­cient space pos­si­ble. It does have some quirks, name­ly its use of a “smart fold­er” sys­tem that auto­mat­i­cal­ly adds all images inside the ref­er­enced direc­to­ry to the tex­ture sheet… but will not allow you to exclude spe­cif­ic images with­in said direc­to­ry if you need to. This forces us to keep only com­plete­ly final in-game assets in our pro­duc­tion fold­ers lest tem­po­rary or test­ing assets be includ­ed — prob­a­bly for the best.

Upon pub­lish­ing, Tex­ture Pack­er com­bines these images into a sin­gle giant PNG and cre­ates an XML file that servers as a ref­er­ence index. Our engine then uses this index to attach images to their prop­er objects when they are called in-game — more on how we define this in the ani­ma­tion and data posts that will be forth­com­ing. Tex­ture Pack­er also auto­mat­i­cal­ly down­scales the result­ing tex­ture sheet to half size for SD qual­i­ty and cre­ates a sec­ond XML ref­er­ence file for this sheet as well. These XML files are then includ­ed in a mas­ter assets list and they are now avail­able to be used in-game.

As a side note, export­ing the tile­sets that are used to cre­ate the floors and dec­o­ra­tions with­in each room is a some­what unique process. The pro­gram we use for paint­ing the envi­ron­ments — apt­ly named Tiled — depends on the ref­er­ence image hav­ing uni­form spac­ing each tile; because of this we can­not use Tex­ture Pack­er to export each tile image sep­a­rate­ly as it would com­pact them into the most effi­cient arrange­ment, destroy­ing any uni­form spac­ing. To com­pen­sate for this the tile­set tiles are com­bined into a sin­gle, large PNG which is then added into Tex­ture Pack­er, thus pre­serv­ing the spacing.

tp_ss2

Because the images used to build the walls and doors are ref­er­enced direct­ly like the major­i­ty of the oth­er game assets, these can use the default TP pack­ing behavior.

Well, that’s it for now! Next time we’ll dis­cuss our ani­ma­tion process, the won­ders of Spine, and how it saved our game from being 1000gigs in size.

Comments are closed.