Universal damage calculation

Franto

What would be a good way to do this? Would it be to make a table that adds a row for each seperate attack produced during game run time? Some other way?

My failed theories:

I keep hitting walls like, how would the target actor know which attack is hitting him, even if they all have individual self.# in relation to the table.

Another way: If say target detects collision with actor of tag "attack", would that collision instead produce a new actor recording the self.attributes of both actors, doing the damage calculation, and applying that damage to target: self.hp-Dameresult.

A third method: A table that has a row for each "attack" in the game, with say 20 attacks total. When target is hit by said attack, the target will run a change attribute of: self.hp-(tableattacks, rowattack#, 1), so that if it's hit by 3 different attacks, it will detect it by referring to the tablet. HOWEVER, the problem with this method MIGHT be the same as just putting a rule that detects collission with the actor of that attack, in that what if 3 of the same attack hits at the same time? Will it detect them seperately?

I find that the only for seperate detections are when the actor of the attack itself hits a target and the hp is a game attribute, they will trigger a self attribute, that will trigger the damage seperately for each. It was this method that allowed enemies to be more dangerous in groups against the player in my game{where in the past, 20 enemies just meant more targets, but their damage rate was still the same due to detecting a group of attacks as a single attack when hit.

Their must be some solution? Universal damage detection and seperate hit detection for none game.attributes. With this, it would be easier to implement attack increases for the player, as right now, my only option for this, is to copy and paste the formula for every single technique, seperately, in a big group full of all the different offensive techniques.

Right now, if I want to change a technique's damage, I gotta do it to every single instance of damage calculation in every enemy or player, as they carry damage groups to allow their hitbox to detect every individual attack. Very inefficient if I change my mind on the damage rate of an attack. And very time consuming to edit.

**With a universal damage calculator, it would just come down to editing a table or expression, basically, I want to implement this formula: (target.hp-{user.attack/target.defense}) with attack's formula being {user.self.offense*user.technique} and user.technique being a self.attribute integer/real for an attack actor. **

EDIT: What if I tried having a table record enemy HPs, but then how would an attack know if the target it overlaps refers to a particular table row?

tatiang

Store the enemy's target defense value in a table cell with the row determined by self.Row (either manually set these or set them just before spawning a new enemy by incrementing the value by one or using tableRowCount(tableName) after adding a new row.

When enemy actor collides with player actor
     Change game.enemyRow to self.Row

Then use game.enemyRow in any calculations.

Franto

@Tatiang Thank you for the input, that would work with melee attacks that depend on the player actors collision, but for projectile attacks that fire rapidly or in volleys at a group of enemies, it becomes a bit more complicated as their are many hp's on the enemy side the system needs to know what projectile actor from the players side is targeting who's hp and be able to register them seperately.

If we use that method, I would have to at least make a game.attribute for each enemy as well, but the problem then becomes, how will the projectile from the player know who's hp it's subtracting from based on the enemy actor it is overlapping.

I would have said something like, maybe if the table stores x,y, and the x,y matches that of the enemy being overlapped. Or perhaps search table function on the projectile to find IF it's(player projectile) X,Y matches an X,Y(enemy target) on that table. THEN subtract hp of the enemy in that row!! {This could be the best solution, but would it be drainy on the processor? Especially with how fast the game is moving. That loop would have to be instant, otherwise,I foresee the bug that it will not find that X.Y, unless a formula is used to give a margine of error by abotu 2-6 pixels in case the enemy is moving fast.}

And I'm not sure how this would work with AoE attacks. I might have to use a different formula for those types, unless there is a way for that single projectile to register multiple actors and each of their X,Y's within itself?

Although, these example screenshots are from an older version, as I've removed display text HPs due to how much they affect performance{I'm trying to remove all instances of display text from the game itself, although it's still present in menus}. I'm just going for visual indicators now, for example, I will probably have smoke bellowing from enemies below 50% hp, and tons of smoke with color.red,blue,green at 0.2 to indicate the enemy is at low hp.

There are two situations with player attacks. Those that shoot out in groups, which their intent was that if an enemy took all hits, would take more damage. The other attack, such as the blue projectile, has a small energy explosion, which can catch multiple targets due to it's AoE range, and thus all those targets would register that single attack actor for damage.

Melee attacks like from swords use the actor itself to detect overlap.

Note: In the final game, it will be rare for that many enemies to be on screen, if at all, 8 enemies on screen is the most there can be without taking a hit to the performance, which is fine, as 2 are already formidable to the player. {Fighting them isn't required to complete a level, as it's possible to sneak by and avoid them for more pacifist players.}

In this spoiler, extra info, but not necessary to read:

Back to the topic, notice that there are many bullet actors from the hero side, the narrower projectiles. The round projectiles like fireballs and orbs, are enemy projectiles. Their problem is solved, as there is only a single target hp for them to focus on, and despite the same actor overlap problem, they still register seperate hp damage by activating a self.bolean individually, witht he result of subtracting from hp when this bolean is true.

In any case, the only true way for "damage stacking" which is the second part of the dilemna for the player side(unless the x,y method several paragraphs above works, whcih could then use the enemies method for stacking, but from the players side), is to create up to say 10 different "damage actors" that spawn on collision. Each time an attack actor collides, it would spawn a damage actor based on an incrementing self.number that keeps track of how many damage actors there are{as well as subtracting the moment it dissapears.} These are ten seperate actors, as collisions do detect different actors seperately, but the same actor in multiple copies registers a single time until all actors of that type stop overlapping and overlap again to register.

If it were turn-based or RPG, it would be easy to do this, as the use of a "targeting" actor could just load any target's hp from a table as the hp to be affected by any attacks spawned, containing that hp within their calculations.

Anyway, another idea I have, using the "old" system, is if within the rule of registering if an attack has hit, their would be a "self.incrementing" number referring to that attack, allowing multiples of it to be detected. But it would become complicated and might put a strain on the system with so many calculations.

I guess I'll have to stick with the old system and just copy and just migrate the stats of each attack unto a table to clean up the way it's done. I really wanted damage stacking like the enemies can do to the hero using self.triggers.

Franto

I think the x,y method on projectile actors being used to identify what enemy actor they are overlapping is the best direction. But this would mean creating a table that generates and keeps track of x,y's for not only the enemies, but the projectiles the hero fires as well. And as you can see from the screenshots, even if theres only half that many enemies, the game might slow down?

Unless the X,Y is only updated upon an overlap/collision occurring. Then once updated for both, are compared, then the enemy row picked via overlapping x,y of projectile and target Then the correct hp can be subtracted from.

I wonder if the game will stutter everytime a calculation is done if I use the "check x,y of both only during collision method", or perhaps it won't, since I hear tables are really lightweight on the processor due to being static. Maybe to be safe, just have x,y's for both tracked at all times, and perhaps there will not be any slowdown? Then again, that would mean a ton of constrains, but fro what I've seen, constrain doesn't cause as much slowdown as timers or display text, would tests prove this wrong?

EDIT: Luckily, enemy attacks don't need an x,y, but if this turned into a multiplayer game {with their being 2-4 players total on screen, then I would have to make a third table keeping track of enemy projectiles.}

EDIT2: When a player projectile is born, at the very top of its behaviors page, will be a Change attribute: "table.player's offense*self.technique(0.2 to 1.5) = self.intensity(integer)

A row is then added to the player projectile table, with the following: Intensity(from the self.attribute), self.x, self.y

Those X, Y's are filled when the condition "collision with enemy tag" is true.

The enemy row with a matching x,y is found, then it's bom voyage to their HP by running a change attribute from a rule triggered by an integer/boolean, erasing the attack, attack row, and dealing damage before that.

That's pretty sound right? I can't think of anything better.