As some of you knows, Elysium has been suffering from a problem for quite a while now, that made it impossible to attack IG a close enemy. To give a quick explanation to this problem, here is a picture.

In blue, the automated navigation block from the tree, which need to be bigger than the actual sprite, because it uses the center position of the different entities to decide if they can or not continue to walk (this was made like this to avoid using actual physics, way slower than this method). This meant however than when we added a check for if the enemy was not behind a wall (to avoid people attacking enemies hidden or in another room) we encountered a problem, where the check (also working without collider, for the same reason as before) got stuck in the collision block, even though in reality, the attack should have been possible.  Once the problem was clear, we started looking for a fix for it. 

Here is an explanation of the first idea that we settled to fix this precise problem.

The first solution was quite simple. Instead of just making a straight check, we first checked the straight line, then what would have been the path the character would have to take to reach it. If the variation in length between each path is smaller than the one needed to pass one tile, it means that the player & the monster are not separated by a wall, but by an object with too big of a lock zone. 

This solution revealed effective, however, we quickly noticed a few problems with it. This solution was slow. Really slow. Path processing in a single frame is a complicated thing to do, without multi-threading the action. and multi-threading in unity can also take multiple frames usually to setup so it was not really an option. We had to find something else.

That is when we remembered something. This first straight check we did, similar to a ray cast, without the physics simulation, is fast, fast, so doing a few more would not be a problem. 

Since we can do a lot of them, let us check for each corner of our sprite. if one of them does not hit, this means both can see each other, problem fixed! 

And yeah, funnily enough, this worked fine... for one player and one monster. If we want this to scale to the entire server, this needs to be optimized. there are multiples things that can be done then. First, most of the time where this function is called does not actually need a real 100 % fidelity check. If, for example, a monster is checking if he can aggro on a certain entity, a basic check is enough, since this will happen every frame, there will always be a time where the player is not in this zone, and we only need to do this check on attacking, for repositioning between others. 

There is also a lot of check there that can be evited. First, all rays going through the back are done for. They do not have any purpose. Neither does most one that are inside the two main rays as well.

we arrived at this solution. simply check for the mains ones, ignore the back one, ignore most of the central rays as well. At applying it in reality however, we quickly noticed that all those check to eliminate all unnecessary rays where actually slower than doing the rays themselves, so we finally ended up only doing distance check, reaching this result: 

with simply 9 rays instead of one, we can do all the needed check.

This worked perfectly for everyone except the archer, which was quickly fixed after noticing how the arrows had dumb base check that could be easily removed. For example, an arrow, once started, should be able to attack the final entity, even if the player already moved behind a tree. 

 That is all for today, remember, the wizard will be added soon ;)