Войти
ПрограммированиеФорумОбщее

[Unity]: Готовые решения которые вы используете в своих проектах.

Страницы: 1 2 3 Следующая »
#0
12:32, 3 окт. 2017

Привет.

Хочу попросить многоуважаемую публику и профессиональных разработчиков чтобы Вы рассказали о том какие готовые решения вы используете в своих проектах. Я всё время писал велосипеды и в общем-то в юнити пока плохо ориентируюсь, особенно по архитектуре.

Если можно, в таком формате: 2D/3D и список тулзов, которые вы юзаете.

Заранее спасибо.


#1
14:58, 3 окт. 2017

FinalIK, Shader Forge, Dynamic Decals, ProBuilder, Aquas Water и прочее

#2
15:37, 3 окт. 2017

Zenject
Rewired
Stateless
TextMesh Pro

#3
10:23, 4 окт. 2017

Спасибо.

Dan Diamond
Для каких целей Вы используете Zenject ? Что-то я посмотрел, эта штука позволяет сделать внедрение зависимостей, что как по мне довольно сложная и врядли имеющая место быть в геймдеве штука.

#4
10:31, 4 окт. 2017

Gladiator
Dependency injection весьма полезная штука иногда. Доводилось в крупном игровом проекте использовать Ninject.

#5
10:50, 4 окт. 2017

bool
А зачем она нужна в игровых проектах ? Зачем в игровом проекте очень слабо-связный код ?

Я немного читал о том, что это такое, но понял лишь суть.. Как работает не совсем понял.

#6
11:32, 4 окт. 2017

здесь довольно доходчиво о IoC, зачем и почему
Inversion of Control with Unity3D

#7
11:35, 4 окт. 2017

Gladiator
> А зачем она нужна в игровых проектах ?
Проще писать и меньше багов.

#8
18:05, 4 окт. 2017

greencrazycat
Эта серия статей просто восхитительна! Спасибо!

#9
20:22, 4 окт. 2017

Пишу все руками, яжмужик.

#10
10:35, 5 окт. 2017

greencrazycat
Какая-то бессмысленная статья. Если человек хотел получить доступ к функциональности других объектов, мог использовать внедрение зависимостей на полях компонентов.
Его подход необходим в случае, если мы хотим делать тесты и мокать функциональность в тестах. Но про тесты не написано ни слова.
Опять же, если делать тесты, то покрывать ими 100% смысла нет, да и невозможно практически, т.к. требует много ресурсов на актуализацию тестов.
А нетривиальный функционал можно вынести в объектную модель на интерфейсах, которую дёргать из наших компонентов и мокать в случае тестов.

#11
11:28, 5 окт. 2017

fornetjob
> Его подход необходим в случае, если мы хотим делать тесты и мокать
> функциональность в тестах. Но про тесты не написано ни слова.
хорошая архитектура это не только возможность тестирования,
как вариант следовать SOLID принципам, а инверсия зависимостей вполне этому способствует
От STUPID кода к SOLID коду

к сожалению в примерах от юнити вопросы архитектуры практически не рассматриваются

#12
11:46, 5 окт. 2017

greencrazycat
> как вариант следовать SOLID принципам
Ну как бы название MonoBehaviour уже подразумевает одно поведение. Да и сама парадигма компонентно-ориентированного программирования этому тоже способствует.
С таким же успехом, он мог сделать интерфейс сервис локатора, который реализовать в компоненте и вывести все сервисы на поля для инициализации из студии.
В случае если нужно инициализировать из теста, замокать методы доступа к этим полям.

greencrazycat
> к сожалению в примерах от юнити вопросы архитектуры практически не
> рассматриваются
Ну вот, к примеру: http://gameprogrammingpatterns.com/contents.html

#13
11:58, 5 окт. 2017

fornetjob
> > к сожалению в примерах от юнити вопросы архитектуры практически не
> > рассматриваются
> Ну вот, к примеру: http://gameprogrammingpatterns.com/contents.html
по твоему архитектура это только использование паттернов ? :)

использовать принципы ioc или нет - это твой выбор, КОП также хорош - но не всегда
это всего лишь инструменты - и что из них использовать в конкретных проектах выбор разработчика

#14
12:10, 5 окт. 2017

greencrazycat
> по твоему архитектура это только использование паттернов ?
Просветите, если не трудно, чем на ваш взгляд является архитектура?

greencrazycat
> использовать принципы ioc или нет - это твой выбор, КОП также хорош - но не
> всегда
Смысла в противопоставлении не вижу, одно другому не противоречит,.

У меня подозрение, что основная проблема лежит в том, что люди с сайтостроения и формоделия переходят на разработку игр в юнити и тянут за собой наработанные опыт и шаблоны, которые применимы в 10% задач, оставшиеся делаются путём натягивания совы на глобус.
Не зря же в статье человек демонстрирует мвп, вместо того чтобы показать как он запрограммил стейтмашину с крутым поведение монстров, к примеру.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.