Layered animations for non-player entities

[dorkster]

See discussion: https://github.com/flareteam/flare-game/discussions/867

I think it would be best to start with "Option 2" as described in the above discussion. The TODO list will look something like this:

• [x] Create an equivalent of engine/hero_layers.txt as a new section in StatBlock files called render_layers.
  • Both the player and non-player entities will be able to use it, so this will be able to deprecate engine/hero_layers.txt
• [x] Create a new section in StatBlock files for defining the slot/animation pairs.
  • Example: slot_animation=head,animations/avatar/male/leather_hood.txt
• [x] Move the layer rendering code from Avatar to Entity

[dorkster]

Complete! Here's a shot of some zombies turned into human mages:

And this is what was added to the enemy definition to get that result:

# base animation that animation_slots will sync to
animations=animations/hero.txt

[render_layers]
INCLUDE engine/hero_layers.txt

[animation_slots]
slot=head,animations/avatar/male/mage_hood.txt
slot=chest,animations/avatar/male/mage_vest.txt
slot=hands,animations/avatar/male/mage_sleeves.txt
slot=legs,animations/avatar/male/mage_skirt.txt
slot=feet,animations/avatar/male/mage_boots.txt
slot=main,animations/avatar/male/staff.txt

Thanks to the Entity refactor in the last version, this also will work just as well with NPCs.

[WithinAmnesia]

This is amazing! That is a HUGE world of possibilities for making the world HUGE for the player to experience. Now every armour and weapon and player animation can be used for world building:-D! Man the skeletons will have a run for their money. I guess a grey skinned human can be made easy enough [throw the default human art assets in and tint them grey XD] now and that could represent an undead / zombie. We can have Death Knights / Shadow Knights / Reavers, Liches and Necromancers, Vampire Rogues and Ancient Ghost Vikings even. Wait, is there a transparent effect for making 'ghosts' for regular entities / sprites / creatures? I guess they could be manual done in image editing [transparent ~'tint'] if all else fails. This is super cool! I guess like elves and orcs and half elves and anything kind of human looking with different skin colours can be made now as a pretty close ~'stand in' to get the world building rolling. Hmm I wonder if Halflings and Dwarves could be prototypes as 1/2 sized and 2/3 sized humans? Either way this is massive, so many places and dungeons and very cool encounter locations can be made and spiced up with a whole world of possibilities of entity customization / visual combinations; Swords and Sandals would be proud XD.

[Danimal696]

Dorkster, that´s a great addition!. But could you go up a step further? Could you make it so we can declare a few pieces for each enemies, that is selected at random at spawning? that would allow to make enemies modular, where i can make body pieces consistant in a set, like rags armor for bandits. And they are randomly generated using one of the many pieces of the set.

[dorkster]

@Danimal696 Maybe. I would still probably prefer to keep it at one "set" per enemy and let the enemy spawner do the work versus randomizing the individual pieces. I'll keep it as is for now, but it shouldn't be too disruptive to extend the mod syntax if we want to randomize the pieces. Essentially, we'd simply allow multiple animations to be defined for the same slot, and then randomize when we fetch an enemy/NPC prototype.

[Danimal696]

I know it´s probably complex, but allowing for random combinations would be really nice, getting a colorful cast of enemies just by declaring a handful of pieces to randomly use per body part; parts Flare would already possess. Don´t get me wrong, I think this addition is awesome but it´s missing just this point to reach full potential.

A sample of what i mean:

[animation_slots]
slot=head,animations/avatar/male/bald_head.txt
slot=head,animations/avatar/male/black_hair_head.txt
slot=head,animations/avatar/male/long_hair_head.txt

Any random enemy generated with this data sheet would have any of the three heads.

[dorkster]

Yep, that's how I imagine the extended syntax looking.

The point where it gets a little complicated is how we handle spawning entities. To put it simply, when loading an entity that hasn't been loaded yet, we create a single instance of it (we call this a "prototype"). Then for each subsequent spawn, we copy the prototype. The problem is that the animations (image + frame data) get set up when creating that first instance. So if we want each entity have randomized animations, the animation set up will need to be moved to where we're copying the prototype. But we also don't want to be loading existing animations again when making the clones.

I'm not totally against the idea of randomizing each slot, but that feature won't be in 1.13.

[Danimal696]

In my opinion, randomizing animations would not be necessary; just the looks. I believe maybe you are thinking ahead of me and imaginating characters spawning with different weapons and their corresponding attacks animations, while I´m only thinking about "clothing" and not weapons at all (using just the same weapon for all clones, so the same animations for all).

Thankfully, in the future we can just split the parts of the models and build upon the current base you laid.

[dorkster]

When I was saying "animation", I was actually referring to our animation definition files, which contain the spritesheet image (aka "looks") plus the individual animations with frame data (e.g. swing or die). So I was also only talking about randomizing the "looks". Randomizing the individual animations would be something completely separate.

[WithinAmnesia]

Brevity: If you don't need to bug Justin try that first and if you absolutely have try to ask for help, try to make the solution mutually beneficial so that hopefully everyone wins. Have empathy, ask around network, to try help people and mutual dignity / respectful trust usually works in the end. For cooperation is kind of hard wired into us / that is the foundational base building block for the nature of the human spirit. ~--------------- Would there be any difference from a player perspective if the random entity 'sprite layers' were manually customized by the dev into unique non random sets and then have one set per outfit / 'sprite layer' combination? This would shift the random complexity to making each unique entity visual outfit set a possible spawn defined by the creature spawner. If the outcome / goal of random visual parts / variation for entities / creatures can be obtained as the feature currently is with one visual outfit set per entity that is spawned in via the game creature / entity spawner; then asking for more complex work might be a moot point. I worry about asking too much for Justin does this as a hobby and I would feel better if I could better support the Flare development. So with everything I ask I try to remember to think if such asks would be a pain in the neck to implement and if I am not sure of the possible complexity I try to remember to ask to better understand a subject and then maybe shift gears / reevaluate my desire / goal / ask. If I can not ask Justin for something and put the complexity (within reason / still able to ~somewhat efficiently) create new content (with no tower of hanoi please XD) on my end of things I prefer to do that to save possible burnout / everything being not interesting to work on / develop for Justin.

I remember paying people to try and code a complex 3D physics based tank game in Unity and the more complex of feature I asked for the higher the chance of burnout / lack of interest. It did not matter that I payed 5k or what ever, if something is just a pain in the neck / annoying people just won't do it. So with Justin effectively being pro bono herein (unless I get rich and donate some money) everything here is pretty much at Justin's mercy if it sees the light of day XD. If something is too complex / a pain in the neck just scrap it and try another solution / approach. Chances are there is simpler way that gives the same / very similar player experience with a much simpler / more realistic approach of implementation. Complex solutions can arise but they should be taken on voluntarily by the problem solvers with no pressure to continue, pause or scrap it. I think everyone here has a vision and people generally like to cooperate and become more than the sum of the parts. Especially with the open source / forever free nature of Open Game Art community. So I also ask myself before thinking long and hard about key / gameplay critical features in regards to if such a thing can enable more gameplay options for greater player experience and if such a thing can already be done in the engine (within work flow reason) and if such an ask is way too complex / a hassle to implement. Anyone who problem solves and can solve a complex issue for others can usually just by looking at something / a proposition have a 60-80%+ accurate guess as to how hard / complex such a potential endeavour would endure for the problem solver. People are just people like yourself with only so much time and energy and usually above all interest / motivation.

So if you really want something and there is no reasonable way for yourself to do the same goal and you really need help from without / other people. Then try to make sure to try and understand the other's perspective and try to be useful to the other person or at least try to align your goal with the problem solvers around you so the solution is mutually beneficial. If something is too much of a hassle ask around for another solution. People are amazing at solving problems for their life is just as interesting and complex as your own / your family's lives. They know probably 100+ different interesting people and chances are their friends know things you don't know and can solve things you cannot reasonably solve. Then if you care about something and believe it will help everyone else once solved then you can ask and try to inspire people to care about what you care about. If you understand the hearts of people chances are that your heart of hearts is operating on the same or very similar wavelength / rhythm of life as the vast majorly of humanity; today, yesterday, tomorrow and across all time. We all want the same things at the end of the day, we have for over 300,000 years as modern homo sapiens / humans. We all want to optimize our existence and over the eons. All of those who wanted to pessimize their existence got filtered out and become biological failures. For life is hard and working together what it took for our ancestors to overcome the insane odds for all of living humanity to be the last humans standing; after near extinctions and untold suffering and overcoming cruel yet necessary sacrifices across the eons. Everyone's human instincts are dreadfully not anywhere near random and it is a near miracle that everyone alive lives today. You and every living human today are an unbroken chain of people who had just enough strength to have children, not quite knowing why they are here and died. You are the direct heir of the fire of humanity burning in your heart of hearts heralding from every generation of humanity's existence and beyond; stretching back all the way to the dawn of time.

[dorkster]

One way to look at my suggestion vs what Danimal suggested from a design perspective is to compare it to how we handle loot vs something like Diablo.

My approach / Flare's loot system

• Pre-defined configurations with broader randomization picking from among these configurations
• "Less complex" engine implementation
• More work for game designer

Danimal's approach / Diablo's loot system

• More granular randomization affecting individual components
• "More complex" engine implementation
• Less work for game designer

That probably isn't a fair comparison, since what Danimal suggested is far less complex than implementing a Diablo-style loot system in Flare. But the concepts are similar.

From the player's perspective, both can produce near the same results (less so with loot, but I'll hand wave that). The ones affected will be the game designers / modders. So I agree with Danimal's desire for this sort of behavior. I'm just putting it in my back pocket for now while I bounce around to all the other things that need to be done :)

[WithinAmnesia]

I don't have conflicts with Danimal's approach / desire (more features usually the better from a game dev standpoint). My above comment is kind of like a ~'mind dump' / long form thought process of how I think in hopes that something can be picked through the perspective / points to be useful for other people.

Also I am trying to be real with the engine work bottle neck of ~100 game devs to 1 engine dev. If all the game devs ask the engine dev complex things it gets a bit crazy XD. So I hope all the game devs realize the bottleneck of being Justin is like 1 to 100 interactions / managing complexity / ~'herding the cats' (I love that expression XD); yet if you are a game dev then that interaction is 1 to 1.

As in the game dev is one of 100 'cats' in the herd and the engine dev is the cat herder XD. So trying to proactively manage complexity could hopefully avoid the chaos issue for Justin if say 5 cats run in different directs at once and slow down general forward progress. Lol, l am sorry, not everyone is one of Justin's 'cats'. I just thought it was kind of funny / semi-accurate to my own experiences trying to run a dev team / WoW guild / run a company with like ~20 different colourful people XD. Harmony is good.