[Feature/Dev] Improving the Mobv2 development experience

[MaxIsJoe]

As of right now, we have a pretty solid and good structure for creating advanced mobs on HealthV2 that can also be playable by other players thanks to the efforts of I and Bod; However, the sheer amount of power we gave ourselves came with a slight pinch of complexity and made the approach to V2 mobs not an easy thing to get into from the perspective of outsiders who have not touched V2 mobs before.

This issue aims to list down a few tasks and discussions to help make working with MobV2s a lot easier and quicker with less chances of creating mistakes by newcomers or other current developers.

Prerequisite info: How do MobV2s function?

• MobV2s work exactly like current players, any change you make for players also applies to mobs; as MobV2s are prefab varients of Player_V4(Unet)
• MobV2s have a special Mob component that defines things such as their name and character sheet, because MobV2s are spawned as NPCs, not players, so they require a special component to initialize important info about them for the PlayerScript component.
• When MobV2s spawn, they spawn with souls and minds, just like players; The only difference is that Mobs spawn with a NotImportantMind flag which disregards them as NPCs.
• When a MobV2's gets initialized, it will use RaceSOs to define what body it will have and what Health systems it will spawn with. (See Arial for example)
• MobV2s can have "blueprint" prefabs, which allows us to make one prefab of an NPC then change its properties via lightweight prefabs that can also act as items in-game. (See slimes for example)

Prerequisite info: How does the AI for MobV2s function?

• V2s use a state-machine like system for processing different state of a mob's AI, called MobAI and BrainMobAI.
• MobAI allows mobs to have more than one state active at the same time, allowing complex behaviors; such as running and gunning at the same time, without creating monolithic components that handle more than one behavior at the same time.
• Each state has its own blacklist of states it cannot co-exist with, giving programmers and designers an easy way to avoid state conflicts without writing a lot of checks in-code (Example: A happy state has a blacklist for a sad state, thus preventing the AI from processing the happy and sad state at the same time)
• States can be pre-configured to run periodically over time or over every Update and FixedUpdate call on the UpdateManager
• All states have a EnterState, ExitState and HasGoal and Tick functions, names are self-explanatory.
• HasGoal can be used to tell other states that a state is not aimless and has a clear objective to follow. (Example: An NPC sees a hostile player in sight, and it has an active goal to attack the player. If there is no player, the HasGoal returns false)

Issues / Required Features

• [x] Create an editor tool to easily create/modify mobs from one centralized tool to avoid creating mistakes in project structure, and help newcomers easily create new NPCs without manually digging through a bunch of different steps and systems.
• [ ] Delete MobAI and make BrainMobAI the primary way of handling AIs on mobs.
• [ ] Move the body setup steps outside PlayerSprites and make it its own component.
• [ ] Add a proper AI pathfinding system, as the current one uses a terrible drunk pathfinding algorithm that can quite literally be blocked by surrounding a mob with a wall of pickupable items. (Also, it can't find its way across large distances or interact with its environment)
• [ ] Investigate the possibility of making MobV2s use the exact same movement as players, instead of relying on TilePush.

Nice to haves

• Create an automatic tool that converts all MobV1s to V2 while using the current project structure to define what components and AI states the V2 mobs should have.
• • Their bodies will be just a single chest and their current sprites will be implanted on the chest. (like how CowV2s are at the moment)
• Look into the ability for mobs to have shared blackboards for performance and complex grouping systems.