So, the last sprint lasted an entire month, and had way more content than any of the other previous sprints. I’m going to approach this sprint a little more carefully, and try to figure out exactly what needs to be done, and try to limit the scope, and possibly separate it into another sprint if it grows too large.

This sprint is about combat and damage. Lets try to list out some of the concepts, to get started:

  • Some quantity of damage should be done when a hostile effect or projectile makes contact.
  • The above implies that we have some collision detection going on.
  • The above also implies that we have a way of knowing how much damage to do.
  • Damage numbers should be displayed when it occurs.

Okay, already there are some interesting points to be made. Lets start off with talking about collision detection. Collision detection will occur on things like melee attacks, and projectile attacks. With projectiles, the answer is obvious. The projectile hits the target, and damage is dealt. However, when we talk about melee weapons, the answer is not so obvious.

For example, suppose my character is standing still, and is surrounded by two enemies. The enemies are standing as close as possible to each other, while also standing as close as possible to me. Lets visualize.

melee_considerations

So, on the left hand side, we see the player surrounded by enemies. On the right hand side we see the green circle the represents the collision circle that is created to figure out if anything is hit. The question now, is how do we assign damage? Lets look at some options.

  1. We assign 100% of damage to the first thing detected.
  2. We assign damage equally among the things hit.
  3. We don’t use a circle, and instead use a single point.
  4. We assign damage to each of the units, giving them both 100% damage.

Each of these possibilities has some interesting implications. Again, lets look at them.

If we assign damage to the first thing detected, then we might get some weird results. It might be hard to hit certain things because nearby enemies are absorbing the hits.

If we assign damage equally, I feel like that isn’t very realistic. In real-life, weapons aren’t AOE. Once you hit something, whatever you’re using will probably get stuck, or caught, or at least slow down. Plus, again, this makes it hard to focus things.

If we don’t use a circle, and just detect the first thing at our position, this might be the best way to approach the problem. This could also mean that we might miss our target, because we clicked just outside of the collider. Well, we might remedy this by giving it some search room. Actually, this brings us back to approach #1. We could use a circle collider cast, and just hit the thing that is closest to the center of our circle collider. This will give us the most accurate results.

#4 is kinda bad, and makes fighters want to AOE things down, which I think is bad. This is unfortunately how most games do it.

Since we’re on the topic of collision detection, we need to collision detection with the shields. So, a shield will have some ‘block chance’ which will just be a percentage. The shield will ‘block’ (destroy) some percentage of projectiles that hit it. We will limit this to just physical projectiles for now.

Now, this brings me to another point on our original list. Damage. The quantity of damage to be dealt. In reality, this would be calculated in a very complex way. For example a melee attack would use sword skill, weapon damage, and figure out some number, which would then be applied to some creature’s defensive stats such as armor, or shielding or whatever.

Since I’m a bit traumatized from the last sprint, I’m going to just use set numbers for weapons. For example, a spike sword will do 5 damage, and a spear 2. Just for testing purposes. We can also go back and fix this once we have all of the details of the stat system figured out.

This brings me to damage numbers. When damage is dealt, numbers should appear above the character that took the damage. We’ll re-use some of the existing code that handles chat messages, and improve upon it. We’ll call this section ‘floating combat text’.

Now, for testing purposes, it would be nice to have some regen. Regen will help fill up health, mana, and stamina for our characters, so that we can play around a bit and not run out of those resources. I’m not going to write a ‘regen’ component, as in the sense of anything final, I’ll probably just hack this in for testing.

Maybe I’m missing something but this is a pretty decent start for this sprint. The scope is quite small, so thats good, as I expext (like last time) that the scope will grow on its own.

Sprint List

  • Collision detection for projectiles.
  • Collision detection for melee attacks.
  • Weapon damage numbers.
  • Shield/projectile collision.
  • Floating combat damage

Further Considerations

Upon starting the floating combat text part of the sprint, I realized that a lot of old code was hanging about. This was in regards to the following scripts:

  • Text Manager
  • Chat Message
  • Name

The text manager… manages text. It knows what text is where. This is necessary to allow for chat messages to be placed in such a way that they don’t overlap each other. However, all of this is old, and very horrible code, that really should get re-written. That’s no problem. The issue is how to re-write it, and how to unify all of these text-related components.

First off, I want to make them all inherit from a class called Floating Text. This means that the display of them is handled by the Text Manager. This means keeping track of their positions, as well as assigning them to the right canvas so they are displayed at the correct floor.

Now each script has its own behavior. Even though they are all text components, they all handle their display in a different way. For example, lets list out how they are different.

  • Chat Message: This is a piece of text that is displayed at an empty location, so that it does not overlap other chat messages.
  • Name: This is a piece of text that is tied to a creature, and follows them around. We are not concerned about overlap.
  • Combat Text: This is a piece of text that is generated at a specific position, and then moves upwards, in the usual way. We are not concerned about overlap.

With the way the text manager is setup right now, all of the rect transforms for each of these components is tracked. This would mean that while a chat message is looking for a good position, it would avoid nameplates, and it would avoid combat text. This is bad because it makes it increasingly likely that a chat message ends up showing up somewhere completely unwanted because of other player’s names, or combat text that is currently displayed.

So this means that our Text Manager only handles the correct assignment of UI components to their respective canvases. It seems that our text manager is really a canvas manager (as things like healthbars need to talk to it too), and the other functionality in the text manager is really a chat message manager.

Additionally there is something interesting happening when it comes to world positions, and screen positions. A chat message is expected to stay at its world position, while the character is moving, despite the screen position changing. This means that per update, the chat message has to update its position. This code is shared between the above 3 text types, and we can stuff that into the parent class.

So let me summarize a little bit, because I’m starting to see how this should look.

  • Text Manager becomes:
    • Canvas Manager – manages the assignment of objects to their correct canvas.
    • Chat Message Manager – relays information about where to display, to chat messages.
  • Components to be re-written:
    • Name
    • Chat Message
  • Components that will be changed:
    • Healthbar
  • New Components
    • Floating Text