Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remake Enemy Logic #14

Open
TheYellowArchitect opened this issue Aug 11, 2022 · 0 comments
Open

Remake Enemy Logic #14

TheYellowArchitect opened this issue Aug 11, 2022 · 0 comments
Labels
enemy ai Anything related to the logic and behaviour of monsters low priority Not important or to be focused

Comments

@TheYellowArchitect
Copy link
Owner

TheYellowArchitect commented Aug 11, 2022

It is no secret that the code for the enemies is not well-designed. After all, it was made back in 2018, I didn't even know a design pattern back then.
I didn't read on AI either, it was quite literally handmade without any guidance, I still remember the "breakthroughs" and how making the AI felt like exploring, happy times.
There are some good things, like the split of enemy onto pathfinder and behaviour, and the attacks being split in classes, hence monsters are "modular" (e.g. hollow with some clicks, could get the jump attack of satyr, or the rush attack of centaur and minotaur)

However! There are 5 horrible things, which linger to this very day, as I didn't know anything about AI, and I was coding whatever came into my head:

  1. Attack Detection Hitbox and Attack Damage Hitbox are MERGED
    Yes, this is as horrible as it sounds. The same hitbox which says "if in X range, use your first attack" is also the hitbox which checks for applying damage within X range.
    It isn't really noticeable in-game, because with the above, enemies attack when they get in range of their attack. But it is noticeable for Harpy's spin attack.
    Harpy's spinattack is clunky/janky, because of this flawed design.

  2. Sidewalled Bug
    A serious bug, where enemies at wall sides have bugged AI (e.g. they run towards you but cannot move towards you...)

  3. Flying Type
    Instead of splitting EnemyBehaviour into Grounded and Flying, I slapped Flying code onto default EnemyBehaviour. And if (flying) then bloated code overrides default.
    Not a bug, not wrong, but it makes the code ugly and bloated.

  4. Delete IDamageable
    My first experience with Interfaces, and I did it with monsters. Unity is not meant for interfaces, it goes against its component system. And if you override them, you create insane spagghetti.

  5. Decouple State Machine from Physics.velocity
    Its such a mess. Physics.velocity is set on Update() and pathfinder, and FixedUpdate()
    This is the only part which is worse than WarriorMovement

For this reason, netcoding enemies was impossible, and I just disabled EnemyBehaviour altogether for the client.

@TheYellowArchitect TheYellowArchitect added enemy ai Anything related to the logic and behaviour of monsters low priority Not important or to be focused labels Aug 11, 2022
@TheYellowArchitect TheYellowArchitect changed the title Remake Enemy Behaviour Remake Enemy Logic Aug 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enemy ai Anything related to the logic and behaviour of monsters low priority Not important or to be focused
Projects
None yet
Development

No branches or pull requests

1 participant