ShadowRx
patreon
on Layers, Clothing, and Graphics...
🕑 Added 2019-02-25 20:57:12 +0000 UTCThe new clothing system should support manual layer ordering... the fact is automatic layering is a very complex algorithm, and there are many exceptions that might move layers around in some cases. The simplest way to handle this would just be to have layers placed over each-other by default, and allow you to move things up or down the list.
So, if you want to wear red underwear outside your blue costume... you would just put them on afterward. :superman:
Then outfits would be defined/saved in the layer-order desired, and it would make the layer-drawing process a lot simpler. (though I do need a way to detect if under-layers are covered before rendering them to the canvas)
Anyway, we're nowhere near having the graphics ready to show clothing yet, but this is a design consideration we should make now... while we're replanning the clothing system to be more flexible, allow size and color variations off the base item (the latter we can easily achieve through hue-shifting of graphical layers, the former will be the harder part- along with supporting all the possible character build/shape variations), and integrate with the description system.
In fact, we ultimately want clothing to also impact the reaction systems, so we're starting to add traits to clothing such as: Posh, Slutty, Professional, Ratty, Stained, Torn, etc.
Some of these traits are part of the base item, while others are formed/changed over time as the clothing is worn/damaged... and we might even throw something in down the road that accounts for changes in fashion/style... so something that's hip now might become passe after playing for awhile, then might eventually be retro-hip again.
Similar functionality could be added to other gear and wearables... including evolving standards for wearable-gadgets, Personal Protective Equipment, Weapons, etc. Such that things become obsolete/sub-standard over time. This and the damage traits could also be used in more disciplined environments such as military and business suit/uniform standards. (is your shirt ironed? are your boots scuffed or polished? how do others react to this?)
Again, we're not trying to do everything at once, but looking at building a solid core that we can expand on later... allowing new dimensions to gameplay, and even allow for different games altogether to reuse this engine design.
The reason we need to calculate which layers/items are hidden is the sheer number of layers that could become involved. A character might be wearing dozens of things, each one could be using multiple layers for the different materials/colors needed for color-customization on the items.
A Pinstriped Suit with a corsage is 2 layers each for the dinner jacket and pants, plus 2 layers for the corsage (flower and clip), at least 2 layers for the tie (one for each color), 2 layers for the vest (material and buttons), 2+ layers for the shirt (base-color[s] and buttons), 2+ layers for the belt (chord and buckle), 3+ layers for the dress shoes (top, sole, laces), a layer for the socks, 2+ layers for underwear (material color[s] and waistband), a layer for the undershirt, 3+ layers for a watch, 2+ layers for glasses, 2+ layers for a ring...
with possible additional variations such as using a skirt instead of pants, adding stockings, a bra, jewelry, etc.
And each of these layers has to be run through an HSL-shifting filter to get the desired colors... (we'll also need to define the filters for certain colors and materials, as well as render with a good universal base for that material)
Now, some of these things would be too small to notice in the base graphic, but might show up in other poses or closeups (such as the ring if we have a closeup on the hand), while others would be almost completely covered and could also be skipped.
We also need to consider some way to cache the multiple layers of items so we can minimize redraws... but we can wait on such optimizations for now, the only one we really need to focus on is image resolution and count and how it might affect game size and eventually stability. At some point we may have enough assets/media that we'll need an alternative way to store/access them outside the compiled game file.
For now, I'm strongly leaning toward splitting character and object graphics into 4 distinct sections:
* Damage/Status - color-shifts object/character-zones based on condition (already being tested in the new UI) - uses a universal base-figure for the object (such as a mannequin-like untextured unisex figure)
* Style/Variation - color-shifts layers based on color/material patterns and shows what the clothing/etc. would look like on the base figure (same as base above, except it uses a universal base skin-texture, then assembles color shifted layers atop it)
* Build/Shape - this goes back to a simple/minimally textured image that allows for different shapes/body types. This might mean separate layers for arms, legs, etc., to accommodate different physique combinations.
* Poses & Animations - this one isn't even on the board yet, but if/when it gets added, it will likely again use a simple base-figure.
Sections 1 & 2 are mutually exclusive most of the time, you'll want to see one or the other... though there could be scenarios where we want an x-ray like effect to show damage overlaid atop the normal graphic.
Sections 3 & 4 require additional dimensions to the array of graphics. Trying to accommodate every variation in these sections would exponentially increase the number of graphics needed.
In a perfect universe we could combine all these effects/representations. For now we need to hold off as long as the game remains 2D. If, down the road we can get a flexible enough 3D engine to allow morphable, poseable figures, and the appropriate content and licenses, we may be able to combine these design elements.
Anyway, many of these sections can benefit from using sprite-sheets to help compress the variations, and this topic came up because I was wanting to make the damage graphics more efficient (right now it uses 8 layers for the different damage-zones, which are all functionally identical to the base image, except they use different alpha channels). What I want is to apply an alpha-mask to the base image-- drawn from another image/sprite, instead of repeating the RGB data for each zone.
I've also been planning updates to the items and clothing systems, as mentioned above, in order to make defeated opponents and slaves/pets lootable/strippable. For this I need to be able to generate random outfits that make sense... and to allow variation I wanted to use weighed properties/traits to build the sets, rather than predefining rigid sets or classifying items as being able to be only in one set (question then, which set gets the underwear??? ;p).
So, we get to generate opponents with a clothing probability table like:
casual:0.40; athletic:0.20; work:0.20; posh:0.10; rags:0.03; beachwear:0.05; leather:0.02; underwear:0.01; fetish:0.01; nude:0.01; random:0.01
(which is from the actual entry for 'human' in the species table)
...and pick out an assortment of garments, with variations on each layer selection and colors.
Part of the idea is to allow it to chose potentially inappropriate undergarments (or skip them entirely), as well as selecting acceptable variations/mixes that might fit somewhere between black-tie and business-casual, yet still be work appropriate. (and might be hiding a red-thong, or going bra-less or commando) Perhaps they have a watch, perhaps not... etc.
I want each NPC/encounter to feel unique... even if you never see them again, without creating a ton of overhead for the game or the designer. :D
Plus, who doesn't want to be able to dress-up their pets? ;)
(attached is an image showing the current damage layers... the color is shifted, and the base is changed to grayscale, but the original images are rendered with a yellow hue since it shifts so well
the point here is that even for these limited damage zones, we are repeating the same exact image data 9x with different alpha channels... this could become a bottleneck for graphics if we don't find a better way to mask damage layers in
not only will we need these layers for characters, but later we'll use them for other species and objects, and we might even use them with different poses/regional zoom-ins... so the number of images could grow quite large)
