Question on: FSM, Behavior Tree with variable boss fight behavior.

[Megamike55]

Not sure how many people have bothered to program their bot to handle boss fights, but if anyone has, I'd love to hear about it.

My bot right now uses a combination of FSM (for things like "walking to waypoint" or "walking to enemy" or "eating and drinking") and simplistic "Behavior Trees" (for when my FSM is in state "combat"), but nothing more fancy than a big mesh of if else statements that has started to make my head spin as time goes on....

My combat system started out super simple. Things like "Lets spam 1 a lot! lol". And then I made it more and more complex and irritating to maintain the combat code. It has gotten out of hand since I started *trying* to modify combat behavior based on whether the player is in combat with a boss.

[Edit: A great quick example is Nexus final boss, where you have to move every once in a while]

The way I have it right now, each spec of each class has its own combat function. Into that, I want to insert role-based (tank, heal, ranged dps, melee dps) behavior for boss fights. I could program the behavior in four different functions, splitting each function into huge switch statements that check what boss we are on, and then big if blocks that help the bot decide on things to do blah blah blah but I Think this is a down right god awful approach. Anyone have some wisdom to share on this?

[Sychotix]

If I understand what your wanting to do, you should create a certain "global" kind of boss logic. For example, if a boss is casting some sort of spell that needs to be interrupted, ask the class's combat logic if it is able to silence. If so, it will. If not, there was nothing you could do for it anyways.

The combat logic should also be semi-global. You should only have to call a couple functions, which can have some simple switch statements in it to call the specific class functions, which inside that function has a switch statement depending on spec to call the spec specific functions.

For Example:

void CombatLogic()
{
GlobalCC.Combat();
}

void GlobalCC::Combat()
{
switch(class)
{
case 'mage':
MageCC.Combat();
break;
}
}

void MageCC::Combat()
{
switch(spec)
{
case 'Fire':
MageCC.Fire.Combat();
break;
}
}

void Fire::Combat()
{
AttackAllTheMobsAndShit();
}

EDIT: btw, may not be the most efficient way, but it works and doesn't make your code clunky.

[Bananenbrot]

You could also derive from an CC interface and implement methods like Interrupt() as needed.
You may need enum return values if you want to check wether the Interrupt suceeded (which would be obvious), if it's on cd or if the caracter doesn't have any interrupting ability.
Or you implement properties like InterruptCooldown which would again require some if and else's.

What I think MegaMike55 actually means, is that his FSM gets much more complex because of 'extra' boss transitions on top of the combat system.
Farming mobs is as simple as bringing every target down, heal yourself or something like that.
If you prepare your FSM for specific Bosses, your code is bloating exponentionally.
This may be a point where a transition to a 'real' behaviour tree may be worthwhile.

[amadmonk]

Edit: removing wordgasm. Thinking about the relationship of HFSM's to BT's now.