Можно подумать о AIManager, который просто говорит:
foreach(GameObject go in m_myObjects) // m_myObjects is a list of all objects that require updating
{
go.Update(); // standard GameObject function
}
После этого каждый класс должен заботиться о своем фрагменте кода. Так что обновление работает в самом классе.
Итак, Человек говорит:
// just a class which is a gameObject and also has moving behaviour
// do the same with monster
public class Human : GameObject, IMoveBehaviour
{
public override Update()
{
GoMove();
}
public void GoMove()
{
// human specific logic here
}
}
// This interface describes that some movement
// will happen with the implementing class
public interface IMoveBehaviour
{
void GoMove();
}
Используя интерфейс, вы можете сделать определенный язык частью класса, и вам не нужно ТАКЖЕ создавать какой-то класс, который будет обрабатывать это для вас. Конечно, это возможно. Но в реальной жизни человек / монстр движется, а не какой-то предмет, который он несет.
UPDATE
Ответ на комментарий. Поскольку есть AIManager, или даже полный GameObjectManager, было бы неплохо сохранить все GameObjects, вы можете попросить AIManager указать место, куда вы не могли бы пойти.
Поскольку поиск путей в большинстве случаев выполняется с использованием некоторой навигационной сетки или указанной сетки, GameObjectManager может возвращать конкретную сетку со всеми навигационными точками на ней. Вы наверняка не должны определять все позиции каждого монстра. Потому что большую часть времени монстр точно не знает, где все находятся (в реальной жизни). Поэтому знание того, куда не следует идти, действительно хорошо, но знание того, где все находятся, даст вашему ИИ слишком большое преимущество.
Итак, подумайте о возвращении сетки с точками, куда идти, а где нет, вместо того, чтобы поддерживать такие вещи внутри монстра / человека. Всегда проверяйте, где вы должны что-то оставить, думая о том, что будет в реальной жизни.