# Combat system presentation

# Talking points

- What's a session?
- A combat session is a period of time that begins when the first seeker initiates combat with an enemy tile
- A session is over when either
- A) The enemy's health reaches 0
- B) A fixed period of time has elapsed (currently 100 ticks in this test)
- What's a tick?
- Currently a tick equals one 1 block which on Polygon is mined every 2 to 5 seconds.
- Explain how yields work
- Enemy has a set amount of health and a reward supply (e.g. gold)
- The amount of damage inflicted to enemy is calculated each tick
- The damage percentage a seeker inflicts on an enemy is reflected by the same percentage of the supply being awarded
- Combat tile stats
- health: 1000
- sessionSupply: 500
- bonusSupply: 100

# Code review

- Is it weird how I'm equipping mods via the combat system? I've done it that way so the mods don't have to
- A) Know about the combat system
- B) We don't have to find what session the seeker is currently in

# The tests
- First few tests are testing my dummy Mod and Seeker contracts
- Minting seekers with a set of base stats (attack 1)
- Minting a couple of mods attack +10
- Equpping mod should return modded stats
- The 3rd stat is attack and we can see the mod has increased the stat by 10
- Should instantiate and join a session
- We can see the first seeker joined at tick 0. As the session contract is instatiated by the first joiner and then that block is mined, the other two seekers both start on the next tick (I believe that's what is happening here)
- Seeker that leaves before the others should get a lower yield
- Here I'm showing what the yield would be for a full session. The first two have the same yield as they are present for the full battle whereas the third seeker has a much lower yield as they leave 10 ticks after joining
- The yield is 49 so I might be off by one somewhere? They might not do damage on the first tick?
- 100 damage / 1000 health * 500 supply = 50
- Equipping mod mid battle should increase yield
- You can see seeker 2's yield is much higher than seeker 1's (294 compared to 49)
- So the combat system knows about the mod that is being equipped I equip the mod THROUGH the combat system (something to talk about with code team later)
- Defeating Enemy should yield bonus
- If the enemy is defeated before the session period ends, then the bonus is split between the participants (100 awkwardly split 3 ways)
- NOTE: The bonus doesn't diminish on each regeneration
- Claiming yields
- Next few tests I'm testing claiming up to the currently mined block (tick 52) works
- Testing that doctoring the yields or the battle events (JOIN, LEAVE, EQUIP) should fail claim validation
- Testing that leaving and coming back allows you to claim
- Session Regen
- Testing that a seeker that had left battle (seeker 3 never rejoined) cannot rejoin after the session has ended
- Diminishing returns
- In a loop I am...
- Mining enough blocks that we enter the time a seeker can start a new session
- Using seeker 3 to join the session
- Asking the contract for what the yield would be for the entire battle time
- Comparing that this session has yielded less than the previous session
- On each loop the yield is 10% less of the inital supply i.e. 100% of initial supply, 90% of initial supply, 80% of initial supply
- The maths is cheaper than compounding the decay e.g. 90% of the init supply, then 90% of the value of the prev iteration and so on
- Cannot join a session after maxSpawn has been reached
- Testing that an enemy tile only respawns a finite amount of times (currently 11 times)

## TODO

- Mods to modify more than one attribute
- No so much a combat system problem
- Sessions to support multiple rewards
- Check with Simon if this is actually true
- TileData's `sessionDuration` isn't referenced and instead we always use `NUM_TICKS`.
- Ticks to have a definable block length so we can alter duration
- Regen currently starts after the fixed session time NOT at the point of enemy defeat.
- Currently calculated when a session is initialsed
- Solving this to calculate after an enemy is defeated would mean it needs to be calculated at the point a claim has been made after an enemy has been defeated. Would mean the first claimant would have to pay a little bit more gas to update the state
- Bonus doesn't diminish like the supply does, should it?
- Bonus is equally split between participants, should it be based on the damage percentage?
- Resonance isn't implemented
- Seemed simple enough, resonance is divided up into bands. If you fall within the same band then bonus and if you are close to it you get a fraction of the bonus