NPC animation strategy

#1
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.
Reply

#2
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.
Reply

#3
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.
Reply

#4
(2013-06-09, 08:32 PM)HwitVlf link Wrote: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)
Reply

#5
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.
Reply

#6
(2013-06-09, 09:55 PM)HwitVlf link Wrote: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)
Reply

#7
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)



Attached Files Thumbnail(s)
   
Reply

#8
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.
Reply

#9
"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
Reply

#10
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.
Reply





Users browsing this thread:
6 Guest(s)