Playmaker Forum

PlayMaker News => General Discussion => Topic started by: justifun on February 09, 2012, 06:10:55 PM

Title: calculating who hit who workflow question
Post by: justifun on February 09, 2012, 06:10:55 PM
Lets say you are working on hack n slash type game where the hero player is getting attacked by several monsters at once (or in close succession).

What would be the ideal way to setup a system to calculate who's hitting who?  Would each enemy have a check when it attacks to see if it makes contact? or would the player's character constantly be checking if it got hit?
My initial thought would be that there would be 2 checks constantly going on, one for dealing damage and one for whether or not you are taking damage and same would go for the enemy's character.

Also, i read that performance and optimization probably the best way to determine if two characters attacking each other are hitting each other is to avoid using triggers overlapping (eg on their swords and bodies) but to simplify it and check their distance and facing angle to one another when they press their attack button.  But combining this with my previous question is where i'm getting confused.

Title: Re: calculating who hit who workflow question
Post by: Alex Chouls on February 11, 2012, 04:58:27 PM
Personally, unless you plan to have lots of units, I would try using triggers instead of distance/facing calculations since it's a lot easier to visualize and debug. But I wouldn't put them on weapons etc. just as sensors around the characters. Each sensor could have a simple FSM that just sends an event to the AI FSM on the character (e.g. EnemyAhead, EnemyBehind, EnemyToLeft, EnemyInMeleeRange...). The AI FSM can then decide how to react (or not) to the events.

If performance becomes an issue you could always refactor these events to be sent by distance/facing calculations instead, without changing the AI FSM.

The AI FSM has states like Idle, Walking, Running, Attacking, Blocking, Recovering, Fleeing... state changes can be driven by PlayerController FSMs, sensor events, simple logic etc. State changes could also be driven by animation events, to introduce subtle timing to the combat. E.g., in the first moments of a heavy attack the state is Vulnerable, then an animation event switches the state to HeavyAttack.

The basic idea is that you can check the current state of any unit at any time. Then the outcome of any combat between 2 units is determined by each unit's state. HeavyAttack vs Idle = LotsOfDamage, HeavyAttack vs Dodging = FallOver, HeavyAttack vs HeavyAttack = BothFallDown etc.

The HeavyAttack state could use an FSM State Switch to test the state of the target and determine the outcome. The outcome is communicated by sending events to the target. Of course, you can have more fun with events, e.g., an attacked enemy sends a HelpMe event to all friendly units nearby...

Anyway that's one high level strategy, but the devil is always in the details!

I would start simple, get some basic action/reactions working reliably between units using trigger sensors, then build on that. Iterate and make it fun...

Hope that helps some!
Title: Re: calculating who hit who workflow question
Post by: justifun on February 12, 2012, 09:09:28 AM
Thanks a lot alex, there's a lot of great info there, ill will mockup something with some cubes and report back with a tutorial video or something once i get it all up and running.

Quick followup question.  Would the idea time to check the state of the enemy probably be when the player presses their attack button? so that you arn't checking every frame for example?

And how do you differentiate between multiple specific enemies if you had several in front of you and were possibly going to connect with all of them at once?

thx again