Portraits

2 years ago by stales

Share this post:

Portraits

The portraits was an unexpectedly difficult part of game development. The vast majority of code in the game is actually handling quirks with the portrait and character customisation screen.

To give an idea, here's the rough outline of how a character's sprites are assembled:

-------

The character has an property, e.g. head 0-7. This is what the user selects on-screen, it's then translated into an image name for the portrait, usually this is something like: head_0.png

but some of them are different,

e.g. wings have 2 images, front and back
capes are named 0 and 3 for some reason, no 1 or 2

So depending on the option a player picks, the game needs to generate the correct file name and apply these quirks.

But that's just the portrait. The character sprite also needs to be generated. Given each portrait, there's a corresponding set of sprites

e.g. a portrait might be called "torso_2" we need a set of torso sprites for the directions left, up, down (right is assumed to be a mirror image of left). That might look like:

 ['chest_back_2','pelvis_back_2']

But these numbers don't necessarily match the portrait.

e.g. the arms have names:
back_arm3x_0
back_arm1_0x

so more special cases are needed depending on what the destination file name is. Additionally, the folders are inconsistent,

e.g. for the torso, both the torso and the pelvis are in the same folder, but for the cape, they are in different folders:

cape_side/cape_back0_0
cape_back/cape_back_0_1

Then, since the original portrait only has arms, head, etc, you need to match the arms to the legs.

Then you get an array of sprite names. But each of them can have different sizes. For example, side view of arms are bigger than front-view. So you end up with lookups like:

 'torso':{x:-353.941834,y:683.037442},//portrait position

for the portrait, and

 'torso' :{abs_x:-18 ,abs_y:80 ,z_index:5},//sprite position

These are essentially hard-coded values that need to be applied on a case-by-case basis.

But we're still not done yet! Just knowing the image name and the offsets would be enough to show the sprite, but would require having

Each image as its own file. Multiply 2 genders, 3 directions, 8 options and 3 animations frames is over 100 files per item this quickly would fill up the limited number of files allowed on itch.io (1000), so the sprites are packed into a sprite atlas.

But this means the atlas needs to be translated from the source image->another lookup

 {"name":"chest_back_0","x":212,"y":65,"width":36,"height":56}

Finally, the image from this atlas can be extracted and drawn on the screen.

That's 5 different layers needed just to go from the user clicking a button to showing the image on the screen. Each layer needs a bunch of distinct patches to fix quirks found with the source image names, sizes, folders, or offsets.

The game would have to look through all this data every frame, for every character. Thankfully, I can cache the images before they are drawn, so that it can be quickly redrawn without redoing all these lookups.

Forever spent squashing bugs. To find and fix these issues, it was necessary to click through every combination of every option. Often looking for a single frame that might not work.

Composing these sprites is by far the largest amount of code in the game.