Design Looking for advice on isometric game


Hi. I am looking for things to consider when making an isometric game.
Here is a video of an early prototype I made with random assets off the internet:

What I have so far:
As you can see in the video I have the math working for drawing the tiles and positioning the player and enemies. All the logic is of course a tilemap in the room editor and while the game runs I can actually toggle between isometric and a flat top down view for debug purposes.
Depth sorting is working good. The particles are also using depth. I did this by making an array of particle systems, then just pick the next in the list and set its depth before having the particle made on screen.
The pathfinding is there, but just an mp_grid and nothing yet done to stop bunching up and overlapping.

What I'm hoping to learn if anyone has advice:

1. Normal 8-directional movement code needs to be rotated by 45 degrees so that directional input feels correct. I'm mostly just asking for confirmation that I did this correctly, or if there are other methods that are better. When I added an 8-directional sprite for the enemy (not in video) it worked and I had to add what I felt was not good code to get it's correct sprite to line up with its path direction, so maybe there are tricks out there someone know?

2. Enemies overlapping. I know this is a HUGE topic and there is no one answer since every game has different things to account for. My main goals are, melee enemies will surround the player with minimal overlapping at times. Ranged enemies should be easier and just try to keep at the right distance to attack. For the melee ones, my idea is to create an array that represents "spots around the player". And have enemies request a spot, then if one is open they can pathfind to that spot. The array will check a spot on an interval to see if that spot is still used or if the enemy instance is even alive and "clean" those spots.

3. This relates to number 1. Analog over 8-directional consideration. I prefer to make it analog movement, but was wondering if it turns out bad without actual 3d models? I certainly can program a player hitbox or whatever to move in 360 directions, but since I am going to use 2d sprites in an isometric projection, is there any trick to rotating them to look correct. I know If it was 100% top down I could change the image angle and call it a day, but with this view point each animation has 8 versions and was thinking they could be rotated within their 45 degree arc without looking odd? Or do people do something similar with a 16-directional looking sprite... something that sounds like too much of a headache.

Anyway, thanks for reading. I'm just looking for concepts and ideas or what best methods I can learn here. I wasn't hoping for answers with actual code, I can code something once I know the concept behind it.



1) I decided to use classic isometric coordinates(e.g. if NPC gives you a quest to the "north", it's -y), so no 45d rotation. WASD movement should always make the diagonals with 2 keys imo.
Also now i'm adding furniture/lootable objects(chests etc) that can have 4 rotations and north variation that match the 2d grid's north makes it easier to place.

You can post your sprite change code.

2) I'm using A*, because the mp_grid started to lag on large map. It's grid based and the enemies surround the player properly. No overlapping while moving either.

3) For better detail/content you'll need to render/draw more anlges. I have images for 5 angles and mirror 3 to get 8. 9 with 7 mirrored for 16 and so on. 32 anlges would make the game too heavy but some devs went for that too.
However it can still look choppy at a sudden angle switch, unless you add a smooth turning but overall i think more angles won't add much to the game. Design is most important and graphics take a lot of the dev time already.