0
\$\begingroup\$

for turn based game, units can get buffed/debuffed with status effects, like poison, etc. I would like to ask the advisable place where to put amount of poison in the data structure. I can think of two approaches, one is, on the Status Effect object itself, or the Status Effect will just reference it from base ability used. I would like to ask for best practice, and if there are better approaches aside from 2 below. And if possible, I'd like to ask the pros and cons. Thank you very much.

I. On the Status Effect object itself

// Unit model
{   
  "unit_identifier": "some_unit_identifier1",
  "status_effects": [
    {
      "status_identifier": "some_identifier1",
        "status_type": "poison",
        "custom_value": 50,
        //... other properties
    } 
  ]
}

II. Status Effect will just reference it from base ability used. "some_status_effect_identifier2" will be used to get what ability was used. And get the value of poison from there.

// Unit model
{   
  "unit_identifier": "some_unit_identifier1",
  "status_effects": [
    {
       "status_identifier": "some_status_effect_identifier2",
       "status_type": "poison",
        //... other properties
    } 
  ]
}
\$\endgroup\$
3
  • \$\begingroup\$ Is your poison always a fixed same value or can there be different values for it? \$\endgroup\$ Commented Oct 8, 2023 at 17:30
  • \$\begingroup\$ I want it to be dynamic. There are many status effects, and I prefer it to be scalable as much as possible. For example, in poison, some poisons can be fixed, some can be different values depending of which remaining duration it has, eg. 20 damage on first turn, 15, 10, and so on. Even if it it is 20, 15, 10, this collection of values can be stored in the Ability object, and Status Effect object can just contain the duration counter. Then status effect value, can be retrieved from there, so again both approaches can be applied in this scenario. \$\endgroup\$ Commented Oct 9, 2023 at 0:40
  • 1
    \$\begingroup\$ Your first option makes it easier for cases like power up buffs. Had a buff running that increases your damage for 50%? Applied a poison within the last second of that buff? With method one the custom value would contain the extra 50% even if the damage buff ended. Model 2 gets the base value of the poison effect each time, but only the first poison tick would contain the extra dmg. \$\endgroup\$ Commented Oct 9, 2023 at 5:44

1 Answer 1

Reset to default
2
\$\begingroup\$

The main difference will be in cases you have buff/ debuffs. A self buff that increases your damage by 50% for 10sec would with the first model not care when you hit the enemy with the poison - as long as you manage to apply it with even one second left on the buff, the whole poison duration is profitting from it. With the second approach on each poison tick you need to check if there are buffs/ debuffs currently active, the poison only deals extra dmg during the duration of the buff and will be weaker once it runs out. There is as well more lookups needed to do (one check on skill start for the first method vs one check for each skill tick)

For me the second interaction in games always felt wrong. How does a debuff/ status effect on the enemy knows that I got stronger/ weaker? But there might be as well play styles that try to add as many debuffs on the enemy before using a self buff and increasing the damage for all of them.

Both the first or second method are giving the same result on self buffs for the enemy. If the enemy has 25% poison resist, the initial value of 50 would be still 50. The resist should be factored in at the time when the actual damage is dealt (in addition to any other buffs that are currently running at that time on the enemy)

\$\endgroup\$
2
  • \$\begingroup\$ Thank you. The first approach was my initial thoughts as well, for the reason that i feel it is more scalable, coz i dont know what i might want to implement in d future. However, a friend of mine, argued the fact that, the "status_effect" object could become big and since there will be multiple units, and possibly multiple status_effects, thats why i was considering approach number 2. \$\endgroup\$ Commented Oct 9, 2023 at 15:55
  • \$\begingroup\$ The size in status_effect will be the same for both methods. The difference is where you store the actual values of your effect and therefore how they interact. Multiple units even with multiple status effects are trivial for the computer to handle. Your code should be the same complexity, if it can handle two effects, it can handle ten as well without code change. \$\endgroup\$ Commented Oct 10, 2023 at 7:31

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.