Why is the AIController not modeled after the PlayerController?

Unity Courses Ask
,
#1

Hi, I’m working my way through the ‘Unity RPG Core Combat Creator’ and I’m currently on ‘Swappable Control Systems’. We are building an AIController for the enemies and it looks like Ben is essentially rewriting an interface for the Fighter class. Is this approach better than basing the AIController directly on the PlayerController? This is my code for the AIController below:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using RPG.Combat;
using System;


namespace RPG.Control
{
    public class AIController : MonoBehaviour
    {
        public float chaseDistance = 5f;

        GameObject player;

        void Awake(){
            player = GameObject.FindWithTag("Player");
        }

        void Update()
        {
            if (PlayerInRange()){
                if (InteractWithCombat()) return;
            }
            
            if (InteractWithMovement()) return;
            print("Nothing to do.");
        }


        void OnDrawGizmos()
        {
            Gizmos.color = Color.blue;
            Gizmos.DrawWireSphere(transform.position, chaseDistance);
        }


        private float DistanceToPlayer()
        {

            return Vector3.Distance(player.transform.position, transform.position);
        }

        private bool PlayerInRange(){
            return DistanceToPlayer() <= chaseDistance;
        }

        private bool InteractWithMovement()
        {
            GetComponent<Fighter>().Cancel();
            return false;
        }

        private bool InteractWithCombat()
        {
            if (GetComponent<Fighter>().CanAttack(player.gameObject)) {
                GetComponent<Fighter>().Attack(player.gameObject);
                return true;
            }
            return false;
        }

    }
}```
#2

Is this the current course or the archived one? :slight_smile:

While we can name the methods any way we choose, Interact in the context of the PlayerController implies user input, interacting with the player to derive movement.
In the current course, we actually name the methods with Behavior, as that’s more descriptive as to what’s happening. AttackBehavior, PatrolBehavior, etc.

#3

I’m looking at the current course.

I haven’t made it to the parts where the AIController will be handling things like Patrols but much of the code that Ben uses when he’s first writing the AIController is actually already present in Fighter. Rather than simply calling fighter for that code he’s rewriting it within the AIController.

As he’s intially building it he even says something to the affect of “See what we are doing in Fighter? We essentially want to do exactly that in AIHander”.

If we are trying to keep the namespaces separate from each other and have some logic behind each of the actions why would we write code that is already in the RPG.Combat namespace and place it in the RPG.Control namespace?

Is there something I’m missing here? Is there anything wrong with my approach? (Please ignore that InteractWithMovement essentially does nothing right now.)

#4

While the code is similar to what we’re doing in Fighter, it has a different purpose.

When Fighter.Attack() is called, a target is set, and Fighter manages moving to the character and attacking. When there is no target, Fighter() is idle.

AIController’s code is similar, but rather than always moving towards the target, it only calls Fighter Attack when the target is within “visual” range.

It’s sort of a two teir approach, AIController manages aquiring the target, Fighter manages getting to that target and making it dead.

#5
#6

Privacy & Terms