Не вижу области применения для такого решения.Другие свои классы можно в том же файле объявлять и описывать, и они работают - проверил уже. Но, даже если мы объявим статический класс со статическими полями же, из другого скрипта миссии его видно не будет.
Интерфейсы это хорошо, но решение сделать AMision, Player и ABattle именно классами вполне, имхо, логично. В будущем в аддоне мы сможем наследоваться от этих классов, писать собственную реализацию (скажем для миссии под каждое событие сделать делать соотв запись в базу или лог), а в скрипте наследоваться от собственного класса миссии, просто не забывая вызывать базовую реализацию методов. В случае интерфейса нам бы пришлось каждый раз все заново писать. Тоже самое и для ABattle и Player. Таким образом сделаны миссии для кампании - в скрипте мы наследуемся не от AMission, а от специфичного для кампаний класса.
Пока мне реально не хватает только доступа к статикам.





Другие свои классы можно в том же файле объявлять и описывать, и они работают - проверил уже. Но, даже если мы объявим статический класс со статическими полями же, из другого скрипта миссии его видно не будет.
Ответить с цитированием