Sword of Moonlight Forum

Game Making Theory => General Theory Discussions => Topic started by: Verdite on June 09, 2013, 09:47:30 am

Title: NPC animation strategy
Post by: Verdite on June 09, 2013, 09:47:30 am
Something ive just come up with and thought i'd share, is setting one NPC to a specific position for your game (standing or sitting) and using the non-used animations for different reactions. So if you wanted a sitting NPC and have finished their sitting animation numbers (16-22), then you could pose the character in a sitting position for the 'standing' animation numbers (0-6) and have them give different reactions to their generic nod or such.

This idea would work with positive / negative feedback from NPCs if you had such a feature of good and bad counters based on player behaviour.

So I could use the standing function in the parameter editor for the Taltareg NPC in my demo. We'l call him Taltareg1 in the parameter editor, and who will have a mutual pose when you first meet him. But after breaking his barrels change the NPC to the 'sitting' version, Taltareg2 in the parameter editor, who will have a negative set of animations, but stay standing in the animations.

More examples...

After defeating an NPC have them assume a 'wounded' pose elsewhere.

NPCs working / resting.

NPCs awake / asleep.

You could do this with first time greetings from NPCs too. SOMs got immersive perks, like this, that you wont find in other game making tools.
Title: Re: NPC animation strategy
Post by: Holy_Diver on June 09, 2013, 12:16:50 pm
Is there a Stand Up / Sit Down event? Or are you just showing / hiding NPCs? If so, they may fade in and out.

Anyway, I only write to ask that you use the animation IDs for the purposes that they are intended for. Could you not as easily make two different NPCs? I know that can mean more MBs for your project. But that's par for the course for SOM.

I think the right way to approach this with an extension would be to have a separate MDL file for the alternative mood. But use the same MDO file (where the MDL would not include triangle data)

We could designate Angry IDs or whatever, but I think personality is probably better left to being a property of the NPC itself, since there could be no limit to the moods NPCs can take on, and certain kinds of NPCs would be more indicative of different kinds of moods (edited: other things such as sleeping / working seem like something that would warrant original IDs, since they would be like an extension of standing and sitting)

What would be more interesting if you ask me is figuring out how to merge NPCs and "enemies" into one format. That way you could do battle with a dark knight after interacting normally with him, or make friends with a monster. That doesn't mean they have to use the same PRT files, but it would be nice if you could transition between different representations seamlessly somehow. Since like you say, one PRT might be Angry, or Hostile, if they are ready to fight with you.

Anyway, the main thing that stands in the way of that is the disparity between the NPC and monster animation IDs. It's unfortunate that they overlap. There's no reason that they had too. That kind of gives me an idea. I reckon the way to make SOM play with alternative IDs would just be to find where the IDs are hardcoded into the game program. It might even be possible to trick SOM into treating an NPC like a monster and vice versa so you could trigger the change back and forth with an event.
Title: Re: NPC animation strategy
Post by: HwitVlf on June 09, 2013, 03:32:32 pm
Nice idea Ben. I was on the same track with my game. It's more useful to think of the animation sets in terms of what triggers them than for how SoM uses them by default.  The "stand" animation is a "trigger when activated" animation, attack animations are "trigger customized  in Parameter Editor" etc.

Another thing you can do, is make NPC's that are enemies. Use a 'indirect attack' animation set to "don't use beyond 1m" for a reaction animation when the player approaches. Then use "indirect attack #2" set to a longer range (say 10m) to set the NPCs animation when the player is somewhat close. Talking events can still be attached to enemies as "trigger when examined-display message" events. That way, you can make some very responsive NPCs that stop what they are doing when the player approaches, then actually talk to/face the player when they get very close. (Spoiler!) you can also make enemy/NPCs that follow the player.

You can even set the frequency on different "attack" animations to make some randomized and very complexly animated NPCs.

Mick, I mentioned (when I fixed the reversed NPC greeting animations) that simple changing the single byte animation number in the file will change which animation SoM plays for sitting standing etc. Since Ex already has memory hooks setup, why don't you just make a hot-swap setup that swaps in/out animations when needed. You could make an almost limitless number of animation sets in a single model. Since you already have hooks into player location, damage etc, it shouldn't be hard to design a panel of new triggers, then simply swap in the desired animation when the trigger was met.
Title: Re: NPC animation strategy
Post by: Holy_Diver on June 09, 2013, 04:02:50 pm
Mick, I mentioned (when I fixed the reversed NPC greeting animations) that simple changing the single byte animation number in the file will change which animation SoM plays for sitting standing etc. Since Ex already has memory hooks setup, why don't you just make a hot-swap setup that swaps in/out animations when needed. You could make an almost limitless number of animation sets in a single model. Since you already have hooks into player location, damage etc, it shouldn't be hard to design a panel of new triggers, then simply swap in the desired animation when the trigger was met.

My impression is you changed the ID assignment in the MDL file. Since the IDs were simply assigned incorrectly then that in and of itself doesn't really amount to anything new.

My working assumption is the function of the IDs are hardwired into the game program. When an ID is matched the program probably records the address of that animation somewhere in an prescribed ID table.

Even if you rewrote the addresses in that hypothetical table to playback normally inaccessible animations, you'd still be stuck with the same trigger regime.

I expect the game program just ignores IDs it doesn't recognize. The animations are probably still loaded into memory with everything else. But I'd be surprised if you set the currently playing animation ID to a custom ID if the game would be able to play it.

I actually did notice the "currently playing ID" memory when looking at doors a little while back. Oddly enough the playtime wasn't anywhere nearby. Probably there is a shortlist of currently playing animations somewhere else with time kept nearby. There was a timer for the delay between the opening and closing animation nearby.


PS: Unfortunately using an enemy as an NPC is not all its cracked up for. They don't have all the little touches like turning to face you. So they feel like second class company. I think the right approach would be to just live with the division for back compatibility. Maybe it having different MDL files for different moods makes sense, then just having one "mood" being "enemy" would be the best way to think about that.

EDITED: BTW, I've never really given any thought to how to trigger new kinds of animations for NPCs. The only thing that makes sense to me is controlling them directly with events. But that is only useful for cut scene like sequences. I would be open to ideas (of course if you can just rewire the IDs in a way that makes sense, replace "sitting" with "working" or whatever, then that would work just fine)
Title: Re: NPC animation strategy
Post by: HwitVlf on June 09, 2013, 04:55:06 pm
You would have to set up a panel of triggers too of course- but that was my point: player location+damage detection= quite a few interesting new possible triggers. If you're worried about hard coded animation IDs, PCs almost always use a comparison check when evaluating any number- as in:

If Animation ID# = "5",
then jump to (play animation)
else
do something else.

It is probably as simple as modifying a single byte (5 in above example) in the game.exe to change which animation # is played for any given trigger.  Hence why I say it should be easy to hot-swap animations with a memory hook.

For instance, I'm assuming Ex's memory hooking could remove the player's ability to directly trigger an "examined" animation and instead, initiate the "examined" animation whenever Ex decides certain criteria are met (player location, damage,equipment etc). When Ex detects that a trigger criteria-set is matched,  it would hot-swap the number checked for in the PC's animation # "evaluation" and initiate a "false examined" event. Thus allowing Ex to play any animation when it detects the appropriate triggers. You could theoretically swap an endless number of animations in a loop through a single SoM trigger.

If each animation is loaded into a specific table "slot", instead of being looked up each time they are triggered, you could just juggle animations in/out of any particular memory slot instead of swapping the 'evaluation' number.   

Actually, unlike NPCs, enemies can be set to face the player even before they are "examined".  They don't have a "turn left/right" when examined trigger, but an attack animation can be designed to make them turn toward the player when the player gents near BEFORE they are examined. That seems more real to me than if they don't react UNTIL the player examines them.
Title: Re: NPC animation strategy
Post by: Holy_Diver on June 10, 2013, 08:47:50 am
You would have to set up a panel of triggers too of course- but that was my point: player location+damage detection= quite a few interesting new possible triggers. If you're worried about hard coded animation IDs, PCs almost always use a comparison check when evaluating any number- as in:

If Animation ID# = "5",
then jump to (play animation)
else
do something else.

It is probably as simple as modifying a single byte (5 in above example) in the game.exe to change which animation # is played for any given trigger.  Hence why I say it should be easy to hot-swap animations with a memory hook.

First of all, I made some edits that I thought I'd already made, and one word "backed" well I don't know where that came from.

Anyway, changes like this are never easy. Not for me anyway. There's no telling how the logic works programming wise, even though the basic model is pretty straightforward (upon hit: stop idle animation and do one of X)

Quote
For instance, I'm assuming Ex's memory hooking could remove the player's ability to directly trigger an "examined" animation and instead, initiate the "examined" animation whenever Ex decides certain criteria are met (player location, damage,equipment etc). When Ex detects that a trigger criteria-set is matched,  it would hot-swap the number checked for in the PC's animation # "evaluation" and initiate a "false examined" event. Thus allowing Ex to play any animation when it detects the appropriate triggers. You could theoretically swap an endless number of animations in a loop through a single SoM trigger.

What is currently possible in this regard is very little. Things like this aren't hooks as you say. They boil down to literal reprogramming. It's only even very recently that I've become comfortable enough to stare at some binary code for what usually amounts to an afternoon in order to arrive at a solution for something that would've otherwise taken 1 minute to add to an open source piece of software. I get a headache just thinking about it.

I am generally reticent to take responsibility away from SOM. But if I was going to figure out new triggers, I'd start by just taking control completely away from SOM. So every time you do that a little piece of SOM goes away. And I consider the AI to be kind of the core. If it goes there is nothing that remains. Even though animations aren't strictly AI they are pretty closely related.

Quote
Actually, unlike NPCs, enemies can be set to face the player even before they are "examined".  They don't have a "turn left/right" when examined trigger, but an attack animation can be designed to make them turn toward the player when the player gents near BEFORE they are examined. That seems more real to me than if they don't react UNTIL the player examines them.

Well I think the recognition animation is more poignant. But yeah, something is better than nothing, so if there is no other way to do what you want to do you do whatever you have to. I use monsters as NPCs too. Though I'd prefer the MDL was converted into a proper NPC at least. The one place where you could reasonably filter IDs as you describe would be if you had a MDL file that could be an NPC or an enemy. Then you could reassign the IDs in the file as SOM reads it into memory to make it "choose a side" at the last second (and you could develop a stand alone tool to convert the MDL file to one or the other)

Otherwise, there are cosmetic changes that I think would be worthwhile. Like having a "hit in the back" and "hit in the sides" animations. Then you could blend them so that the stun animation is omnidirectional. I intend to implement that. I think Verdite is eager to setup these animations for his models. But I think it will only work with a do_3d extension that basically tells SomEx.dll to use the Somplayer.dll emulation code to render all of the 3D elements of the game. At that point cosmetic fixes are pretty trivial to implement.

Beyond that, other than injuries, I can't think of any new combat animation IDs that would be useful off the top of my head (injuries would mean that there are two different versions of every ID so that each part of the monster is blended individually between the two animations according to its per part HP)
Title: Re: NPC animation strategy
Post by: Verdite on June 10, 2013, 10:48:50 am
Dont mean to veer the more technical discussion off course, but about what John said having the NPCs as enemies is actually... A pretty damn good workaround for NPC reactions. Not forgetting that you can assign sounds to enemies, meaning that each reaction could have a sound attached to it. While sounds tend to get tedious if you hear them too much, sound is just as immersive in games as a visual aspect is.

It would be cool if I could get recordings from the members here.  :wink:

Not forgetting SFX on enemies. NPCs could carry lanterns with the flame setting for example. (Im refering to Johns .prf editor here)

Title: Re: NPC animation strategy
Post by: Holy_Diver on June 10, 2013, 11:41:56 am
Do NPCs really not have "flames"? If so it would be because CPs were not implemented for them or something like that.

Anyway (@Verdite) you never said whether having two different NPCs would work just as well for what you are describing in the top post or not.

Also Verdite was just telling me about a weird phenomenon where if you make a monster/NPC that faces backwards and walks in the same direction, by some mechanism it will be a monster that flees from the player. My guess would be the AI tries to chase the player but the walk animation fights it by going in the opposite direction. I suppose its not really fighting it, as the AI probably just aligns the monster and leaves the rest to the animation.

Anyway, if it were possible to replace the walk ID with a flight and or backpedal ID that would be a pretty simple way to interfere with the AI without pulling the proverbial rug out from under SOM out right.  Someone should be making a list of this sort of stuff if you want to see it happen.
Title: Re: NPC animation strategy
Post by: Verdite on June 10, 2013, 12:06:24 pm
"Anyway (@Verdite) you never said whether having two different NPCs would work just as well for what you are describing in the top post or not."

It would work fine. I'm just size conscientious these days.  :smile:
Title: Re: NPC animation strategy
Post by: Verdite on June 12, 2013, 08:33:08 am
John just to add, the 'spoken to from side' animations wont fit with an enemy, because they'll just keep doing the attack and resetting rather than turn and lock, like an NPC would.
That said if the NPC was set up like an enemy they would turn constantly if you wanted, which is fine if a bit threatening! I suppose 'neutral' or slightly hostile NPCs could be setup this way. To be honest I like the idea of an NPC pushing you back if you get too close. A zero damage attack, you could set it up by keeping the NPC still while the root bone pushes into the player. 

I know that when an enemy turns it uses (possibly) the first ten frames in its walking animation.
Title: Re: NPC animation strategy
Post by: Holy_Diver on June 12, 2013, 12:03:54 pm
John just to add, the 'spoken to from side' animations wont fit with an enemy, because they'll just keep doing the attack and resetting rather than turn and lock, like an NPC would.
That said if the NPC was set up like an enemy they would turn constantly if you wanted, which is fine if a bit threatening! I suppose 'neutral' or slightly hostile NPCs could be setup this way. To be honest I like the idea of an NPC pushing you back if you get too close. A zero damage attack, you could set it up by keeping the NPC still while the root bone pushes into the player. 

I know that when an enemy turns it uses (possibly) the first ten frames in its walking animation.

Not so. The turn to acknowledge animations don't actually play until you trigger the event. At which point the game freezes in time. And the text pops up when the animation is finished (then I guess it plays in reverse after the text is cancelled, but I can't say for certain)
Title: Re: NPC animation strategy
Post by: Verdite on June 12, 2013, 05:18:04 pm
Actually with some animations the full animation length isnt played fully before the text pop-up. You can set when the animation triggers the text pop-up but its something ive not conquered completely.

I was probably not being clear before, by turn and lock I meant when you activate them from the side.
Title: Re: NPC animation strategy
Post by: HwitVlf on June 13, 2013, 03:20:47 pm
I thought that "talk" was a single animation whose first half played before the message popup and its second half after the message. But I remember having trouble getting the message to pop at the correct time.

Inspector Clouseau: "Do you have for me the massage?"
Hotel Clerk:  "Sir, I don't give massages."
Inspector Clouseau: "But you gave me one early this morning."
Hotel Clerk: "Sir, you are mistaken!"
Inspector Clouseau:: "But I received a massage this morning from Inspector Quinlan of the Yard of Scotland."
Hotel Clerk: "He gave you a massage, sir?!"
Inspector Clouseau: "No, it was you that gave it to me." 
Hotel Clerk: "...  ... a message Sir?"
Inspector Clouseau: "Yes, you fool! Now give me my massage!" 
 :rofl:

Ben, can you give the enemy/npc's a long attack animation and lower the AI emphasis so that it doesn't continually repeat a quick loop?



Title: Re: NPC animation strategy
Post by: Verdite on June 10, 2014, 09:27:42 am
Okay I apologise John, I came here to post some new ideas and just saw your question

Quote
Ben, can you give the enemy/npc's a long attack animation and lower the AI emphasis so that it doesn't continually repeat a quick loop?

You could effectively, and lower the attack speed of the NPC. Anyway in the end I just stuck to the usual NPCs, the spoken to front / side is important to use though...

Anyway if you had an 'enemy npc' with a quick turn rate the spoken to left / right wouldnt matter, because when the player approached them they would begin turning when the player entered their 'set distance' or 'visibility' radius. You could set it low enough to have them turn when needed, and use the reset option to have them return to their set positions, like in warband. I saw a few videos online poking fun at Kings Field's 'when spoken to' animations. http://youtu.be/koqwTYg4qEU

Having NPCs as enemies would work really well because you have a trigger (possibility for a wave, beerchug etc) , and six possible different movement animations, range detected (for 'attacks'), voices, and sounds.

Anyway I came to post about using the 'seated to standing' to change from one set of animations to another. For example a seated enemy that is asleep, then woken up by the player.



Title: Re: NPC animation strategy
Post by: HwitVlf on June 12, 2014, 01:43:29 pm
Thank you for catching that question Verdite   :smile:

It made me think, the enemy PRF files have ~16 unused slots for additional animation effects.  I wonder if SoM actually has additional animations-triggers that just weren't utilized in the default models?

To test, you would have to make a model that included a normally unused animation number, then write an FX into the corresponding PRF slot and see if anything triggered that animation in-game. 

Attached is a chart of the animation sounds and FX for each enemy animation in SoM.  The unlabeled areas are all unused "slots".
Title: Re: NPC animation strategy
Post by: Verdite on January 24, 2015, 12:46:09 am
John, could you elaborate a bit on the 16 unused slots post? I downloaded hxd, though the display is different to your screenshot.

I would like to test, to see if there is anything hidden that we dont know about.
Title: Re: NPC animation strategy
Post by: HwitVlf on January 24, 2015, 03:21:50 am
That's a dusty memory, but I'll try! If you go to "view > byte group size > 4" in HxD, it should look more like my picture and it will make understanding the PRFs much easier.

The sound effect and FX charts have "fixed" locations (aka always the same) in the PRF file starting at 0x134. I think the top chart (see picture) is for sounds, the bottom one is for FX. Each slot in a chart is 4 bytes long, but the values written in them will differ depending on how many sounds/FXs the model uses.

The empty "slots" are the 4-byte-long areas in the above picture that are not labeled.  The reason they have data in them (0x00003402 etc) is because Fromsoft's PRF making tool just continues writing the last-used value in each slot until it reaches another active slot.  You'll notice that the chart's slots correspond to the SoM animation number for each action (Slot0=animation 0 (Idle), Slot1= animation 1 (Walk), Slot2=Empty, Slot3=Empty, Slot4= animation 4 (Dying) etc.

A slot's format is as follows:
First 2 bytes = number of sounds/FX used for current animation.
Last 2 bytes = start location of animation's sounds/FX definiton (written backwards: 34 02= 0234 in PRF)
Note that many PRFs have odd junk data written in unused areas like the "FF003402" in the third slot in the picture. The 00FF would normally signify 256 sounds used for this animation, but the model doesn't have an "animation #2" (aka 3rd slot) so this value is never ever read by the game.

These slots just hold the info for the sounds/FX, not the animation itself. But their existence may mean that non-standard animation numbers (ie 2, 3, 5, 8, 13, 14, 18, 19, 21-30) might be triggered in game if they exist in the model. It's fairly common for SoM to have built in features that aren't used by the default model set.

If you want to see, just make a model with animations numbered for the unused slots and see if you can do anything to trigger them in game. That's assuming x2mdl actually processes those non-standard animations correctly.

Does that make sense...bet you're sorry you asked!  :drool: