Виртуальные функции и наследование

[lol]

Это возможно в скриптах? Т.е. допустим для AI монстров, когда есть базовый класс монстра и общие методы, и есть классы наследники со своими методами. Есть ли где-то примеры, как это писать, чтобы Unity, это правильно обрабатывал?

[gnoblin]

Можно... Почти 1 в 1 с обычным кодом на C#.

[Neodrop]

Слава, не "почти", а 1 х 1
Просто

[Const_47]

Шарп то он шарп, но вот подход к проектированию будет несколько отличатся, учитывая особенности GameObject и в часности MonoBehaviour

[Const_47]

Примитивный пример(сама структура)

Базовый класс для всех монсторов, лежит в папочке в асете

Код: Выделить всё

using UnityEngine;

public class MonsterBase : MonoBehaviour {

   protected string monsterName;
   protected int monsterHeals;
   
}


Один из скорее всего востребованных вами интерфейсов, тоже лежит в папочке;

Код: Выделить всё

public interface IMonster  {
   
   void Run();
   void Attack();
   void Dead();

}


А вот это конкретный монстр, этот скрипт не только лежит в папочке, также он должен быть "навешан" на GameObject

Код: Выделить всё

using UnityEngine;
using System.Collections;

public class ConcreteMonster : MonsterBase,IMonster{

}


Каждый скрипт который мы хотим повесить на ГО, должен быть так или иначе унаследован от МоноБеха; Вот именно эту особенность нужно учитывать. А так, Шарп как Шарп.

[gnoblin]

Я о том, что вместо конструктора, к примеру, используем Awake()\Start()

[Const_47]

Да. Точно.
Но блин не как придирка, а что бы не вводить в заблуждение случаем.

Для монобеховских скриптов, мы ничего на самом деле не используем вместо конструктора. Просто в Awake()\Start() удобно инициализировать поля класса - скрипта. Некий аналог конструктора по умолчанию.
Для таких скриптов конструктор описывать низя, потому что в контексте Юнити мы работаем не с классом, а с прототипом, то есть с некой областью памяти.

Для не наследуемых от монобеха скриптов, например у нас есть потребность описать свой тип. С конструкторами все ок.

[Const_47]

Иногда нам нужно описать свой ТИП. Причем желательно сделать так, что бы не засорять Hierarchy "лишними" обжектами.
1)Для "второстепенных" типов не имеющих прямого отношения к визуальному редагированнию из под редактора, это лишено смысла.
2)Использовать GameObject(монобеха) без повода и необходимости, есть расточительство ресурсов.
3)Нам нужен полноценный конструктор, а как правило набор из перегруженных конструкторов.

Но при всем этом мы хотим
1)что бы наш ТИП был так же понятен для Инспектора редактора как и любой родной тип
2)Удалялся так же, как и GameObject, без всяких заморочек с сборщиком или контролем над сцилями.
3)Был полноценной частью Юнити( с всеми удобствами UnityEngine.Object), а не "виртуальной приблудой" в памяти.

Так вот, в Юнити есть весь необходимый арсенал средств.

Наш тип лежит в папочке, никого не трогает

Код: Выделить всё

using UnityEngine;
using System.Collections;

public class Test : ScriptableObject{
   
   private int myInt = 0;
   private float myFloat = 0;
   
   //Конструкторы
   public Test(int inputMyInt,float inputMyFloat, string inputName)
   {
      myInt = inputMyInt;
      myFloat = inputMyFloat;
      this.name = inputName;
   }
   
   public Test()
   {
      myInt = 0;
      myFloat = 0;
      this.name = "MyName";
   }
   
   //Вместо деструктора
   public void Destructor()
   {
      Destroy(this);
   }
}


А вот это "исполняющий" скрипт - монобех, лежит в папочке и висит на ГО. Он демонстрирует создания инстансов своего Типа, доступность для инспектора и корректное удаление.

Код: Выделить всё

using UnityEngine;
using System.Collections;


public class Main : MonoBehaviour {
   /*
   Cпециально не инициализирую эту сциль(mainTest), что бы кидало исключение, пока ручками
   в инспекторе не вставим один из ниже созданных инстансов свого типа
   */
   public Test mainTest;
   
   
   void Awake()
   {
      Test abra        = new Test(5,10f,"abra");
      Test cadabra   = new Test(10,6.5f,"cadabra");
      Test shvabra   = new  Test(15,8.5f,"shvabra");
      Test ups         = new  Test();
   }
   
   void Update()
   {
       if(Input.GetMouseButtonUp(1))
      {
         mainTest.Destructor();
      }
   }

}


[Gava]

Пардон за реанимацию, но может кто поможет сэкономить время
В продолжение темы:

Доп скрипты использовать можем. Это хорошо.
Но может ткнете пальцем в ту сторону, где искать наиболее подходящий способ реализации:

1. Запускаем игру. Пустая сцена. Даже ветерка нет. Пусто. Но в это время идут просчеты, парсеры, загрузки баз данных, проверка обновлений на сервере, но ни на одном объекте нет никаких скриптов. Просто где-то что-то параллельно себе грузится. Такое вообще возможно? или это так противоречит философии геймдева, что разработчики такого мощного пакета даже мысли не допускают что мне просто порой что-то надо параллельно просчитать не выкидывая пустой объект в сцену?

Поделитесь мыслями. В чем принципиальность такого подхода?

[AndreyMust19]

Статический класс. Ему не нужно никаких игровых объектов.
Также есть аттрибут (не помню названия), к-й заставляет движок инициализировать этот класс сразу после начала игры.

[Gava]

спасибо, хотя бы понятно в какую сторону копать