AT
Я про то иговорю вы можете воротить что хотите но место вашему коду в компоненте
Так почему в компоненте-то? Вся логика будет отделана от unity, а в PlayerView будут использоваться только данные от этих объектов
Size: a a a
2018 September 28
MD
Как ты ее отделяешь от юнити?
MD
Я вот написал логику в монобехаваире . А ты в монобехавиоре создал класс и написал логику там
MD
это ты отделлил?
AT
Изменение HP, положение игрока, инвентарь. Все это прекрасно может существовать независимо от Unity
MD
Разницы что-то не вижу особо
MD
Ну ты вынес в подкласс просто
AT
Когда все эти "подклассы" взаимодействуют отдельно и вся твоя игра может играться без юнити, но может визуализироваться с помощью go. Это тоже считается за жесткую привзяку к Unity?
MD
Я таких примеров не видел
MD
Именно чтобы оно реально работало так с тестами
MD
По сути это действительно нужно пожалуй в мультиплеере только на мой взгляд
ДС
Player не наследует от монобехайвир. Чистый класс. Чистая логика.
ДС
Чтобы playerView заработал ему нужно параметром кинуть Player. Player вообще может быть структурой в простейших случаях.
АТ
@alprog , правильно ли я понимаю, что вы в своем проекте пытаетесь сделать максимально адаптивный код?
Сможете ли вы при меньших затратах, относительно стандартной стратегии работы с Бетти, перейти на другой движок или на свой движок с другим средством отрисовки?
Сможете ли вы при меньших затратах, относительно стандартной стратегии работы с Бетти, перейти на другой движок или на свой движок с другим средством отрисовки?
Нет, не сможем. Кода визуализации тоже очень много. Ну и сцены создаются в Unity.
АТ
@alprog А что теперь настраивает геймдиз, вы данные храните в экселе или они SO в юнити крутят?
Редактор entity есть в самой Unity через customeditor и editorwindow. Но может быть и внешним. Например, локализация выгружается/загружается в экселевский формат.
АТ
Пипец вот это уровень заморочки
Это ещё не заморочки. Вот сериализация у нас действительно замороченная. А это так - норма жизни.
АТ
Я про то иговорю вы можете воротить что хотите но место вашему коду в компоненте
Нет, не в монобехе. А в своих классах. Они могут жить и в чистом C#
MP
Редактор entity есть в самой Unity через customeditor и editorwindow. Но может быть и внешним. Например, локализация выгружается/загружается в экселевский формат.
Я для рпг составляющей упёрся в то что выбор всяких эффектов, модификаторой, это чертов энум на дахуя значений, хотел это обойти путём создание, один SO один модификатор и его драгдропать в нужное место, но встала проблема с изменениями его параметров, теперь это какой то франкиштейн, который по энуму генерит классы через контейнер с статами.
MP
Была идея в рантайме в эдиторе сериализовывать поля нужного класса и гонять строкой его поля в JSON формате, а потом собирать назад, когда потребуется
АТ
Так что сопротивление бесполезно. примите Юнити систему и не выдумываете лишнего
Боюсь, у тебя юнитология. Болезнь поклонения Unity. Принцип "если я этим не пользуюсь, значит, это никому не нужно" очень плохой. Хороших программистов с таким подходом обычно не получается, только unity-программисты. Не стоит что-то отрицать только потому, что не понимаешь. Это называется невежество и ещё ни к чему хорошему не приводило. Не понимаешь зачем надо - не используй. Имей своё мнение, но не навязывай его другим и расширяй кругозор. Глядишь, через N лет будет стыдно, что раньше говорил.