Тёмная тема
- Salamandr
- Участник
Advanced: Тема повышенной сложности или важная.
tac
> такой ценности не существует
Речь идёт о тестах, которая Юнити поддерживает. Так что, это так же важно как и сам код. Можно конечно всю игру делать одним программистом, держать в голове большую часть проекта, вот только на одну игру уйдут годы или десятилетия.
В команде, проще использовать тесты, чтобы каждый кусок делал свою роль. Чтобы не было такого что выпустили в релиз и потом еще 100 раз правим.
Кроме того знаю по личному опыту, что 2019.4 не показывала нам ошибки и работало всё отлично, которые были обнаружены лишь при переходе на 2020.1.4. Вопрос, как он работал раньше при этом совершенно правильно? Парадокс? Как код с ошибкой мог стабильно работать? Так и останется загадкой. То есть код привязан ещё и к версии.
Ну и вообще, правила нужны только новичкам. Код написанный некрасиво, при этом рабочий, ценнее любого самого красивого и оптимизированного и при этом не законченного решения. При чём это не 1 и не два проекта. Майнкрафт, Сталкер, в их коде я ковырялся лично.
И в тестируемом коде проще разобраться, по тому что тесты не только проверяют какую то часть, но и показывают как одна часть взаимодействует с другими. Это гораздо проще понять, чем сниферить по всем файлам игры в поиске ответов, чтобы добавить лишь пару кнопок сохранения и загрузки игры.
Ты знакомишься постепенно и сразу с нужными файлами для твоей задачи.
Добавлю ещё про тесты. Это не решение всех проблем, тесты решают конкретную задачу, совместимость различных зависимостей, которые, опять же, делают люди..
Если зависимостей нет или их мало, они в общем то не нужны.
уровень твоего текущего мышления понятен :)
грубо это называется "монобехайвор головного мозга"
или более мягко "скриптинг" (в отношении людей работающих с редактором юнити типа геймдизайнеров и артистов) - когда для решения простой задачи нужно применить простую логику.
Скриптинг и программирование не одно и то же. Первый нужен для быстрого прототипирования - что бы получить результат здесь и сейчас, не заботясь о качестве.
Результатом же работы программиста является качественный код и такой код должен отвечать определенным требованиям.
Если тестируемость (и как следствие автоматическая модульность со всеми вытекающими получаемая при написании тестируемого кода) для тебя не является ценностью - то скорее всего твой код так и останется на уровне скриптинга (херакс херакс и в продакшн :).
Это совсем не плохо для прототипов и соло проектов, но вряд ли это можно будет назвать хорошим кодом с точки зрения работы программиста.
это кстати весьма распространенная практинга для мобильных игр - называется AB тестирование
patsanchik3
Salamandr
> это кстати весьма распространенная практинга для мобильных игр - называется AB
> тестирование
надо рассказать чувакам которые игры в ранненом доступе годами маринуют, а потом выходит все равно дырявое гавно. Будь то инди поделка или ААА.
видно не знают про тестирование в играх.
сами не смешно обманываться то.
ps: да и хватит в геймдев тащить интерпрайзную ссанину
tac
> Бонус. Расскажу, почему MVC в геймдеве вообще не место.
ты прав на все 100
ну и еще хотят те же данные, ввиде отчета, отчет может быть xml, и pdf, и html
и тд.
forwhile
Рассуждай токмо о том, о чем понятия твои тебе сие дозволяют. Так: не зная законов языка ирокезского, можешь ли ты делать такое суждение по сему предмету, которое не было бы неосновательно и глупо?
(Козьма Прутков)
Salamandr
> Кроме того знаю по личному опыту, что 2019.4 не показывала нам ошибки и
> работало всё отлично, которые были обнаружены лишь при переходе на 2020.1.4.
> Вопрос, как он работал раньше при этом совершенно правильно? Парадокс? Как код
> с ошибкой мог стабильно работать? Так и останется загадкой. То есть код
> привязан ещё и к версии.
тесты тебе тут помогут))
расскажешь мне потом.как тебе помогли тесты, когда юники в очередной раз сломали/переделали рендер, или изменяться/сломаются настройки проекта, сцены, ассеты.
Salamandr
> Всё можно проверить и подтвердить тестами, каждый пиксель на экране можно
> проверять
ты это серьезно?скажи что рофлишь
patsanchik3
возражений по сути, я так и не увидел ... даже минимального, почему монобехавиур вам так претит?
tac
Да просто индюшатина сложнее пинг понга ничего не пишет.
И хуже не то что кто то не может навернуть правильно MVC на Unity.
Хуже что кто то не может писать не обмазываясь монобехами с ног до головы даже там где они нафиг не нужны.
У нас вот ни разу не MVC
Но есть модель, в основе которой лежит World полностью отделенный от юнити. Он общитывает состояние. Юнити со сцены провайдит в мир инпут через эвенты во View.
И отображает состояние мира на сцену.
При чем всякий пыщь пыщь эффекты, анимашки живет только в сцене, миру на них вообще на чхать. Бывают ситуации что вью развалилось, потому что кто нить ченить забыл подключить. Но мир продолжает ехать дальше.
И самое главное это нам позволяет использовать один и тот же мир для проигрывание реплеев, для синхронизации и восстановления состояния мира при игре по сети. А потом еще и использовать одну и туже логику на клиенте с монобехами во вью и на сервере для валидации результатов боя.
Но разумеется это ни когда же не требуется в геймдеве да... Или просто кто то не может?
Потуги юнитеков родить ECS, намекают как бы на то что ни одними монобехами можно игры писать.
cNoNim
чуть интереснее ...
cNoNim
> World полностью отделенный от юнити
и в чем ценность?
cNoNim
> для синхронизации и восстановления состояния мира при игре по сети
про сеть можем поговорить отдельно ... что у вас на стороне сервера? тоже юнити? в частности меня интересует как вы проверяете столкновения в мире ..
tac
> и в чем ценность?
А в чем ценность обмазывания монобехами?
tac
> в частности меня интересует как вы проверяете столкновения в мире ..
Детерменированный мир, вычисления на интах, упрощенная модель взаимодействия...
Вообще это все оффтопик и к теме мало относится.
cNoNim
> Детерменированный мир, вычисления на интах, упрощенная модель взаимодействия...
> Вообще это все оффтопик и к теме мало относится.
это прямо относится, т.е. вы предложили мне только что отказаться от всей физики в юнити ... и лишь бы отделиться от монобехавиора? а не у вас ли это "пунктик" в голове?
tac
> и в чем ценность?
Как минимум - разделение труда.
Можно взять программиста, не знакомого с юнити и посадить его писать модель и контроллер. Я вьюшку оставить юнитчикам
tac
Ммм друх тебе не кажется что для разных задач могут быть разные инструменты?
Ты без физики юнити ни чего не сможешь же реализовать, не так ли...
Но давай расскажи чего ты там такого крутецкого с физикой реализовывал.
Как то уже 4й проект делаем и полноценная физика как то не пригождалась.
Но ты разумеется делаешь смесь убийцы кризиса и crayon physics deluxe.
При этом в двух проектах то была физика.
Для определения столкновений.
Но лучше бы ее не было.
BEETON
> Можно взять программиста, не знакомого с юнити и
и послать его учить юнити ...
cNoNim
> и полноценная физика как то не пригождалась.
видимо еще те проекты ))
сомнение не закралось, что правильно отделяете? вы не отделяете, вы отказываетесь от юнити, почему бы тогда все не делать без движка?
