BOSS MECHANIC (Not just a bag of HP or a waiting game)

[Kurambik]

BOSS MECHANIC

 

Introduction:

As an attempt to design a boss mechanic that is not just a “bag-of-hitpoints” or a “waiting game” for vulnerability periods, a theoretical mechanic is being put forth in order to try and circumvent these problems and shed light to a possibly more engaging alternative. With this idea in mind, it may serve as a gateway into possibly designing other gamemodes (I’m currently also working on an idea and will eventually link it here) and possibly more collaboration on strategies within the community. I have also designed two prototype bosses that I will eventually link here when they are ready. This tread will also be updated according to feedback and to correct any possible errors found. For a TL;DR, I think the animation provided will serve as a well enough explanation for what this mechanic is all about.

Aim:

As stated, the aim of this post is to design a boss mechanic that can serve as an alternative to the “bag-of-hitpoints” and “waiting game” approaches. The difficulty of the battle should also be attributed to how efficiently the player can take the boss down (i.e. each action the player takes against the target determines the target’s lifespan and strength).

Theory Behind the Mechanic:

As a preface brief to this section, let us set an intuitive example of what’s about to be discussed. For those knowledgeable of the adventures of Hercules, the concept of a Hydra is not very far-fetched. A many-headed beast, that for each head chopped of, it grows two more heads in its place. This is just a crude example that ultimately spirals out of control so the proposed mechanic, although seeming to be a much greater mess than the “simple” case, it counter intuitively turns out to actually be extremely easier to manage. As a second part of this preface aimed for the more mathematically inclined individuals, I’ll spare you the read through the explanation by saying the mechanic is based on the Paris-Kirby theorem from Graph Theory and the Well-Ordering theorem of Ordinals. However the proofs for these will not be included here because they’re not that important.

Onto defining the mechanic, we’ll start off by creating an abstract structure on which the entire system can be based let’s call it B (for “Boss”), and to keep with the hydra theme, it will be made up of H (“heads”), N (“necks”), C (“cardiac” i.e. heart because H is already taken), and G (“ground”).

Here are the rules of the process:

• You can only “chop-off” necks connecting H-C and H-G (i.e. only where there are H).
• Chopping-off an H-G connection destroys the H with no consequence.
• Chopping-off an H-C connection destroys the H. However as a consequence, considering the C where the neck was severed, go to a C one level lower than it and branch out n copies of anything currently above it (excluding the recently severed head of course).
• Only one H per branch from G may be chopped each turn. Nothing else may be done until the branching (if any) is complete.
• Any C that has a degree of 1 (i.e. it has only one neck coming out of it) turns into an H.

The figures below provide a visual representation of this is given below along with an evolving example where n=1

With this in mind there are a few points to note about this process and the structure of B:

• The maximum height (i.e. the amount of levels) NEVER gets higher than the maximum height at the beginning. It only gets wider.
• No matter the route taken when chopping-off the H’s you will always arrive at the point where only G remains. No matter what arbitrary value of n you take. Also building up on this even if n increases by 1 each chop (i.e. it is equal to the chop number, chop 1 ⇒ n=1, chop 2 ⇒ n=2, chop 3 ⇒ n=3, etc.) it still takes a finite number of steps to get to G.

These can be proven but for simplicity’s sake I will omit said proofs. They are left as an exercise for the adventurous readers.

Implementation:

Implementing this structure into the game, has to be done in such a way that each H and C (from now on, these will be collectively referred to as “vertices”) has a fixed amount of EHP but damage can only be dealt to the H-vertices. Each branch from G will be a separate entity (similarly to how the Hyena Pack, Lephantis’s heads, and Raptors are separate entities). Each entity (labelled E) will in effect have its EHP be a sum of the individual EHPs of the vertices. This means that the evolution of the entity’s overall EHP is determined by the actions of the player depending on the branching that occurs in response to his/her actions. As a way to scale the difficulty, the parameter n and the initial maximum height h can be adjusted rather than just straight up increasing the HP and armour levels of the target, thus circumventing the “bag-of-hitpoints” issue because the individual heads still reward players for having maxed out gear by being easy targets to take down individually.

With respect to damage, the story changes. It would not seem fair to simply give each head its own fixed damage since it would not really maintain a sufficient risk factor in the process. However the suggestion would be as follows:

For each entity E, containing a heads and b hearts the damage per head D/H(E) is given by:

D/H(E) = d/a

Where d is the total damage given by:

d = (7a+4b+10/(b+1)^2)*X

For some predefined value X that scales off a function of the mission level. To help in the analysis, these formulae are combined to give:

D/H(E) = X*(7+4*(b/a)+10/a(b+1)^2)

This means that the higher the entity’s starting height, the more damage it deals for a fixed amount of heads since it has more hearts. Also the less heads per entity, the more damage each head does. To perform the analysis, we shall let X=1 so that the results obtained will apply for the coefficient (7+4*(b/a)+10/a(b+1)^2). First things first, it’s good to point out that the singularity achieved at a=0 is naturally avoided by the process since each entity cannot reach that state. Here is a plot of the value of the coefficient as a function of a and b. Courtesy of Wolfram

From this one can see that the most damaging heads are from “chain” entities where they are only one head and the rest are all hearts. And the minimum damage (in taking the limit of b=1 and very large a) that each head can do has a coefficient of 7. It’s also good to note that the entities that are “just a head” receive a significant damage increase since it’s coefficient goes up to 17. Given that they are very easy to take down given the rules of the process, this encourages the players to adopt the strategy where they are high priority targets since they can collectively deal large amounts of damage if neglected.

It is also good to note, that each head has its own independence, meaning that in the case of a squad of players, each head chooses independently where to attack. Also each entity has independent mobility from the rest. This opens up the possibility to engineer the AI in such a way that the easier-to-kill entities are more mobile than their harder to kill counterparts and maybe use them as “protection” to further avoid getting hit.

Attacks are also projectile based with ideally no area damage so that the player can avoid if skilled enough to do so.

The initial configuration of the target may be generated randomly bounded by some constraints. This makes each battle unique and keep the repeated running interesting. Also as an encouragement for players to seek greater challenges in this context, each head killed could have a guaranteed chance to drop the common resources along with a mod, a 50% chance to drop the rare resource, and possibly even a low chance to drop one of a collection of rare mods. This implies that the more heads you chop, the more chances you have at getting the rares.

Technical Disclaimer:

I am aware that due to the growing nature of this problem, the computational power required may be very large hence why I am only providing a theoretical overview. However, it’s good to put it out there since there may be methods to minimise further the complexity of the issue.

Edited April 12, 2017 by Kurambik

[CY13ERPUNK]

+9999 OP

[Kurambik]

5 minutes ago, CY13ERPUNK said:

+9999 OP

Not really. You just have to play smart and avoid the damage. If you do so you can never lose.

[Rawbeard]

I don't know about you guys, but waiting for Vay Hek to open his face is exhilarating!

[Omnipower]

Its a good idea but as far as i can interpret from this you wish for bosses to be more like corrupt vor(stomach only dmg), lephantis(target only heads) or raptor trio(each is its own enemy but singular boss) or some fusion of them. I dont know how this would work in practice but theoretically it sounds as much as a hassle as the invulnerable crap some bosses have though less so since you can do continuous damage it is just up to how fast or how hard you you can hit the boss/bosses. So in a nutshell I like the idea but if i support it cant say i need to see this in action to say if i really am on board with this.

You should do a TL;DR for this in all honesty at least for the lazy readers sometimes even they can have an insightful idea.

[direcyphre]

While a nice concept and all, it is effectively still a bullet sponge with multiple weakpoints you have to shoot. All of which seems to apply for bosses like lephantis, so it'd be nice to hear how you would theoretically revamp any other specific boss currently in game. "Change all bosses to be like Lephantis," has already been said before countless times.

2 minutes ago, Rawbeard said:

I don't know about you guys, but waiting for Vay Hek to open his face is exhilarating!

It's like a Tenno Groundhog day every minute!

[Rawbeard]

1 minute ago, direcyphre said:

It's like a Tenno Groundhog day every minute!

and when the Tenno see his Warframe's shadow the fight will last another phase!

[Kurambik]

1 minute ago, Omnipower said:

Its a good idea but as far as i can interpret from this you wish for bosses to be more like corrupt vor(stomach only dmg), lephantis(target only heads) or raptor trio(each is its own enemy but singular boss) or some fusion of them. I dont know how this would work in practice but theoretically it sounds as much as a hassle as the invulnerable crap some bosses have though less so since you can do continuous damage it is just up to how fast or how hard you you can hit the boss/bosses. So in a nutshell I like the idea but if i support it cant say i need to see this in action to say if i really am on board with this.

You should do a TL;DR for this in all honesty at least for the lazy readers sometimes even they can have an insightful idea.

You are right but hopefully the target area would be much larger than Corrupted Vor's tiny stomach or Sargas Ruk's glowy bits (that I personally always had trouble hitting with all the teleporting he does) and will always be vulnerable to attack. And you have every right to be skeptical because even I am still not 100% on board that it is well designed.

The TL;DR is being worked on too ;)

[chaotea]

14 minutes ago, Rawbeard said:

I don't know about you guys, but waiting for Vay Hek to open his face is exhilarating!

Especially when the game doesnt sync properly and the animation only happens a few seconds after he actually takes damage.

[Kurambik]

7 minutes ago, direcyphre said:

While a nice concept and all, it is effectively still a bullet sponge with multiple weakpoints you have to shoot. All of which seems to apply for bosses like lephantis, so it'd be nice to hear how you would theoretically revamp any other specific boss currently in game. "Change all bosses to be like Lephantis," has already been said before countless times.

It's like a Tenno Groundhog day every minute!

I did not have a specific boss in mind when I did this in fact I had a few concepts of my own that I'm still working on. With regards to the HP issue, if you have a powerful enough weapon you can easily one-shot each head since they do not have much HP innately. It's the overall entity that determines the total HP which can be taken care of by mowing down the heads one by one or splitting it into 2 entities. The latter allows you to damage more heads at once since heads on separate entities do not effect the branching of each other. 

[------Solo------]

I doubt people would even try such new mechanic, not because they will find it hard or confusing but simply cus of lazyness.

[Kurambik]

19 minutes ago, PrimeDCookieMonstah said:

I doubt people would even try such new mechanic, not because they will find it hard or confusing but simply cus of lazyness.

That is always an issue. Not just with a mechanic like this but with everything. :/

[Cephalon_Blue]

1 hour ago, Kurambik said:

BOSS MECHANIC

 

Introduction:

As an attempt to design a boss mechanic that is not just a “bag-of-hitpoints” or a “waiting game” for vulnerability periods, a theoretical mechanic is being put forth in order to try and circumvent these problems and shed light to a possibly more engaging alternative. With this idea in mind, it may serve as a gateway into possibly designing other gamemodes (I’m currently also working on an idea and will eventually link it here) and possibly more collaboration on strategies within the community. I have also designed two prototype bosses that I will eventually link here when they are ready. This tread will also be updated according to feedback and to correct any possible errors found. For a TL;DR, I think the animation provided will serve as a well enough explanation for what this mechanic is all about.

Aim:

As stated, the aim of this post is to design a boss mechanic that can serve as an alternative to the “bag-of-hitpoints” and “waiting game” approaches. The difficulty of the battle should also be attributed to how efficiently the player can take the boss down (i.e. each action the player takes against the target determines the target’s lifespan and strength).

Theory Behind the Mechanic:

As a preface brief to this section, let us set an intuitive example of what’s about to be discussed. For those knowledgeable of the adventures of Hercules, the concept of a Hydra is not very far-fetched. A many-headed beast, that for each head chopped of, it grows two more heads in its place. This is just a crude example that ultimately spirals out of control so the proposed mechanic, although seeming to be a much greater mess than the “simple” case, it counter intuitively turns out to actually be extremely easier to manage. As a second part of this preface aimed for the more mathematically inclined individuals, I’ll spare you the read through the explanation by saying the mechanic is based on the Paris-Kirby theorem from Graph Theory and the Well-Ordering theorem of Ordinals. However the proofs for these will not be included here because they’re not that important.

Onto defining the mechanic, we’ll start off by creating an abstract structure on which the entire system can be based let’s call it B (for “Boss”), and to keep with the hydra theme, it will be made up of H (“heads”), N (“necks”), C (“cardiac” i.e. heart because H is already taken), and G (“ground”).

Here are the rules of the process:

• You can only “chop-off” necks connecting H-C and H-G (i.e. only where there are H).
• Chopping-off an H-G connection destroys the H with no consequence.
• Chopping-off an H-C connection destroys the H. However as a consequence, considering the C where the neck was severed, go to a C one level lower than it and branch out n copies of anything currently above it (excluding the recently severed head of course).
• Only one H per branch from G may be chopped each turn. Nothing else may be done until the branching (if any) is complete.
• Any C that has a degree of 1 (i.e. it has only one neck coming out of it) turns into an H.

The figures below provide a visual representation of this is given below along with an evolving example where n=1

With this in mind there are a few points to note about this process and the structure of B:

• The maximum height (i.e. the amount of levels) NEVER gets higher than the maximum height at the beginning. It only gets wider.
• No matter the route taken when chopping-off the H’s you will always arrive at the point where only G remains. No matter what arbitrary value of n you take. Also building up on this even if n increases by 1 each chop (i.e. it is equal to the chop number, chop 1 ⇒ n=1, chop 2 ⇒ n=2, chop 3 ⇒ n=3, etc.) it still takes a finite number of steps to get to G.

These can be proven but for simplicity’s sake I will omit said proofs. They are left as an exercise for the adventurous readers.

Implementation:

Implementing this structure into the game, has to be done in such a way that each H and C (from now on, these will be collectively referred to as “vertices”) has a fixed amount of EHP but damage can only be dealt to the H-vertices. Each branch from G will be a separate entity (similarly to how the Hyena Pack, Lephantis’s heads, and Raptors are separate entities). Each entity (labelled E) will in effect have its EHP be a sum of the individual EHPs of the vertices. This means that the evolution of the entity’s overall EHP is determined by the actions of the player depending on the branching that occurs in response to his/her actions. As a way to scale the difficulty, the parameter n and the initial maximum height h can be adjusted rather than just straight up increasing the HP and armour levels of the target, thus circumventing the “bag-of-hitpoints” issue because the individual heads still reward players for having maxed out gear by being easy targets to take down individually.

With respect to damage, the story changes. It would not seem fair to simply give each head its own fixed damage since it would not really maintain a sufficient risk factor in the process. However the suggestion would be as follows:

For each entity E, containing a heads and b hearts the damage per head D/H(E) is given by:

D/H(E) = d/a

Where d is the total damage given by:

d = (7a+4b+10/(b+1)^2)*X

For some predefined value X that scales off a function of the mission level. To help in the analysis, these formulae are combined to give:

D/H(E) = X*(7+4*(b/a)+10/a(b+1)^2)

This means that the higher the entity’s starting height, the more damage it deals for a fixed amount of heads since it has more hearts. Also the less heads per entity, the more damage each head does. To perform the analysis, we shall let X=1 so that the results obtained will apply for the coefficient (7+4*(b/a)+10/a(b+1)^2). First things first, it’s good to point out that the singularity achieved at a=0 is naturally avoided by the process since each entity cannot reach that state. Here is a plot of the value of the coefficient as a function of a and b. Courtesy of Wolfram

From this one can see that the most damaging heads are from “chain” entities where they are only one head and the rest are all hearts. And the minimum damage (in taking the limit of b=1 and very large a) that each head can do has a coefficient of 7. It’s also good to note that the entities that are “just a head” receive a significant damage increase since it’s coefficient goes up to 17. Given that they are very easy to take down given the rules of the process, this encourages the players to adopt the strategy where they are high priority targets since they can collectively deal large amounts of damage if neglected.

It is also good to note, that each head has its own independence, meaning that in the case of a squad of players, each head chooses independently where to attack. Also each entity has independent mobility from the rest. This opens up the possibility to engineer the AI in such a way that the easier-to-kill entities are more mobile than their harder to kill counterparts and maybe use them as “protection” to further avoid getting hit.

Attacks are also projectile based with ideally no area damage so that the player can avoid if skilled enough to do so.

The initial configuration of the target may be generated randomly bounded by some constraints. This makes each battle unique and keep the repeated running interesting. Also as an encouragement for players to seek greater challenges in this context, each head killed could have a guaranteed chance to drop the common resources along with a mod, a 50% chance to drop the rare resource, and possibly even a low chance to drop one of a collection of rare mods. This implies that the more heads you chop, the more chances you have at getting the rares.

Technical Disclaimer:

I am aware that due to the growing nature of this problem, the computational power required may be very large hence why I am only providing a theoretical overview. However, it’s good to put it out there since there may be methods to minimise further the complexity of the issue.

I don't have the time to fully look over this stuff, but I think it sounds awesome, I can tell you put a lot of work into this, so I will leave an upvote and congratulate you for this.

Bosses need something new, after all.

[Kurambik]

15 minutes ago, BlueLTO said:

I don't have the time to fully look over this stuff, but I think it sounds awesome, I can tell you put a lot of work into this, so I will leave an upvote and congratulate you for this.

Bosses need something new, after all.

Yes a proper TL;DR is on its way sorry about that, it's somewhat difficult to summerise because I feel that most of the detail is crucial. However if you ever find some time feel free to have a read and see what you really think :)

[CY13ERPUNK]

9 hours ago, Kurambik said:

Not really. You just have to play smart and avoid the damage. If you do so you can never lose.

.... XD

um what? dude i was saying +1 Original Post , ie +1 OP with lots of !!!!!!!, ie +9999 OP ..... ie I was agreeing with you... XD

stop being such a victim/fragile/gentle/defensive =D

[Serialkillerwhale]

Ever play Metroid Prime? What if the "Vulnerable" stage was something you force on them through some other action? Like lurring them over exposed wiring to stun them temporarily, or causing it's attacks to backfire on it? Vulnerable phases shouldn't be random AI mechanics but something you can control.

Edited April 1, 2017 by Serialkillerwhale

[Kurambik]

9 hours ago, CY13ERPUNK said:

.... XD

um what? dude i was saying +1 Original Post , ie +1 OP with lots of !!!!!!!, ie +9999 OP ..... ie I was agreeing with you... XD

stop being such a victim/fragile/gentle/defensive =D

lol I thought OP was referring to "over powered" xD . Apologies kind sir

[Kurambik]

1 hour ago, Serialkillerwhale said:

Ever play Metroid Prime? What if the "Vulnerable" stage was something you force on them through some other action? Like lurring them over exposed wiring to stun them temporarily, or causing it's attacks to backfire on it? Vulnerable phases shouldn't be random AI mechanics but something you can control.

The vulnerable points are always there (the heads) no need to wait for stages because you can just blast them off one by one until there's none left ;)

[Reifnir]

Interesting, let's see how (if at all) DE reacts to that. ^^

I myself tried putting together a draft of a "non-bullet sponge" boss fight some time ago, although admittedly, I went for a general description instead of theory/mechanics. The result? It sunk into oblivion.

Maybe this hydra will get some attention, at least - Warframe sorely needs boss fights that are something more than just "hit it, wait out the invulnerability phase, hit it again"...

Edited April 1, 2017 by Reifnir

[Akavakaku]

I think I get what you're proposing, but I don't see why. Aside from the number of targets changing over the course of the battle based on which ones you choose to attack, what makes this any different from a multi-boss like Hyena Pack?

[Kurambik]

On 4/2/2017 at 0:08 AM, Akavakaku said:

I think I get what you're proposing, but I don't see why. Aside from the number of targets changing over the course of the battle based on which ones you choose to attack, what makes this any different from a multi-boss like Hyena Pack?

With bosses like Hyena Pack, there are always 3 of them regardless of enemy level. With a mechanic of this type, you can scale the difficulty based on the number of initial vertices (to use the collective term) this means that if it has other advantages tied to it (like for example what I mentioned about the rewards) it means that the rewards also scale with the difficulty which is something that would make scaling seem a bit more worth the hassle. As a side note, I had another idea that builds-on and takes advantage of the layout of this mechanic but I think it be too exhaustive to put everything in one post.