Input.GetKeyDown(KeyCode.D)

 var nhTrans = newHuman.transform as RectTransform;

iovchynnikov написав:

Чесно кажучи, виглядає як мішок функціонального коду обгорнутий у методи класів.
Почніть з моделювання доменних об'єктів: людини, пташки. Бо це якийсь нонсенс:

var hc = newHuman.GetComponent<HumanController>();

Я б тут очікував:

val human = new Human(args);
//abo
val human = HumanFactory.build(arg);

А потім працювати з цим Human об'єктом, який був би зв'язаний з юніті, наприклад, патерном Observer. Вийшло б досить low coupled.
Саме у Human класі має бути уся логіка, пов'язана з ним (DDD). Не робіть товстих контролерів.
Розділення на контроллери теж дивне. Варто їх розрізняти не за функціями, а за сутностями і такими, що відповідають вимозі Single responsibility principle (SOLID): GroundCtrl не має відповідати за людей (делегуйте це HumanCtrl), a MovementCtrl має увійти до BirdCtrl, котрий буде містити все що стосується птахів.

PS: абсолютно не знаюся на шарпі і юніті. Поради суто архітектурні. Можливо деякі, а може й всі, будуть не будуть пасувати до Вашого прикладу.

ну то є таке, бо класи, що наслідуються від Monobehaviour'у не мона створювати через new, їх мона додавати до об'єктів за допомогою transform.AddComponent<T>(), або в редакторі прикріпити до об'єкту, а потім отримати за допомогою transform.GetComponent<T>().
Це в юніті там якась компонентна модель архітектури, чи якось так.
І сама людина - це вже об'єкт зі скриптом, котрий збережений в юніті, називається - префаб.

Тоді мені по сути треба окремий скрипт для позиціювання мішені, ага? Бо зара код, котрий відповідає за це, знаходиться в MovementCtrl

object UnitiHumanFactory {
  def create (args) {
     val prefab = unity.createPrefab(args.prefabData)
     val prefabHumanObserver = HumanObserverPrefab(prefab)
     val human = Human(args.humanData)
     human.addObserver(prefabHumanObserver)

     return human
  }
}

class HumanObserverPrefab {
   ..
   def onMovement(distance : Long) {
      prefab.setPos(50)
   }
}

class Human {
  def exampleMove(distance : Long) {
     pos += distance
     observers.notifyMovement(distance)
  }
}

class HumanController {
  ...... {
     var human = UnitiHumanFactory.create(myArgs)
     human.exampleMove(50)
  }
}

Чесно кажучи, виглядає як мішок функціонального коду обгорнутий у методи класів.
Почніть з моделювання доменних об'єктів: людини, пташки. Бо це якийсь нонсенс:

var hc = newHuman.GetComponent<HumanController>();

Я б тут очікував:

val human = new Human(args);
//abo
val human = HumanFactory.build(arg);

А потім працювати з цим Human об'єктом, який був би зв'язаний з юніті, наприклад, патерном Observer. Вийшло б досить low coupled.
Саме у Human класі має бути уся логіка, пов'язана з ним (DDD). Не робіть товстих контролерів.
Розділення на контроллери теж дивне. Варто їх розрізняти не за функціями, а за сутностями і такими, що відповідають вимозі Single responsibility principle (SOLID): GroundCtrl не має відповідати за людей (делегуйте це HumanCtrl), a MovementCtrl має увійти до BirdCtrl, котрий буде містити все що стосується птахів.

PS: абсолютно не знаюся на шарпі і юніті. Поради суто архітектурні. Можливо деякі, а може й всі, будуть не будуть пасувати до Вашого прикладу.

GameObject newHuman = Instantiate(humanPref);

GameObject != Human

Чому "модель" має постфікс Controller?

iovchynnikov написав:

quez написав:

Слово Controller у назві класів не дає побачити, що то зовсім не контроллер із MVC. Це більше схоже на модель, зверніть увагу на поля цих класів і (особливо) на метод Update().

А ще ви очікуєте побачити фабрику гуманів, і ви її маєте:

GameObject != Human
Чому "модель" має постфікс Controller?

бо воно контролює створення хуманів