When making a game with limited resources at hand limiting scope becomes very important.
One such limitation in Treacherous Journeys is that all game-logic is 2D, although it is rendered in 3D. I'm really happy that I decided on this limitation, although I'm sometimes a little irritated by how it dictates the way I design scenes in Unity.

Another such limitation is that I decided early on that the game would not let dynamic entities, like players and mobs, block each other. This way I could just do away with object avoidance and dynamic pathfinding.

I was very happy with this decision. I knew pathfinding would eat up a lot of CPU time, and seeing how this is an MMO-like game meant to support hundreds of players I really want to save where I can.

Until I actually implemented the first simple enemy AI...
The enemies would tend to clump together when hunting a player and sometimes tens of enemies would stand in the same spot swinging their swords. Take a look at the featured photo for a good illustration of how that looks.
Playtesting with strangers would also reveal that this was something they noticed right away.

Conclusion - something had to be done.
I guess I knew it all along that the monster clumping was not an acceptable behaviour, but the player feedback put the final nail in the coffin for the simplified locomotion.
Problem is - I don't have a clear-cut solution ready, and I have kinda avoided the problem in favor of implementing other features that were just a matter of getting them done. These features, like the worldbuilder, the minimap, hover texts etc. while important didn't have any technical challenges. I remember watching a Youtube video where the author stated that when creating a prototype you actually need to prototype the hardest features first, because prototyping an easily implemented feature doesn't really prototype anything (my interpretation - if someone remembers the video then feel free to post it here)

This was something that I have debated with myself for some time, because part of me just wants to leave it as it is for now and get the project closer to something that's actually a game. But there are some implementation details, mostly serverside, that I want to change to accomodate this, and these changes are better done now than later when I have more code to worry about breaking.

The first thing that has to be done is a refactoring of how I represent spatial data. Without going into much detail I'll be streamlining it and also discarding a concept that I have found to be an unnecessary complexity and a possible performance sink: I used to have 2 spatial states for each entity - a "current" and a "next". Each tick only the "next" state would be modified, and at the end of each tick the states would be swapped to make the "next" state current and also reuse the old "current" state as a new "next" state.
The idea was that this way it would be easier for me to make the simulation multi-threaded, but I have since found out that it's much better to handle multi-threading in bigger bites, and share less data between threads.
This also involves the interest manager (the object responsible for keeping track of which objects a player character should receive updates for, and send updates as necessary), since it must now use different methods to detect state changes. At the same time I have really been wanting to update the update message format for a very long time.

A couple of resources I've found - I still have to dig through them a little more and find some more, because I don't know how well they can be applied to my project, since I don't have any actual physics with forces , acceleration and inertia. I basically only have radius, position, constant velocity locomotion (except for speed differences, buffs etc.), direction vectors, paths and destinations.

https://software.intel.com/en-us/articles/reciprocal-collision-avoidance-and-navigation-for-video-games
https://gamedevelopment.tutsplus.com/tutorials/understanding-steering-behaviors-collision-avoidance--gamedev-7777