Архитектура игр на Unity

[Qbit]

Добрый день, уважаемые коллеги! Я недавно начал изучать Unity, и накопилось несколько вопросов. Их удобно объединить в одну пачку «best practices», чтоб не вводить искусственное разделение.

Какой подход к архитектуре игр принят в Юнити? Какова специфика по сравнению с разработкой под другие платформы и общими для геймдева подходами?

Где точка входа, в которой можно настроить совместно используемые IoC-контейнер, service locator, всякие контроллеры, фабрики и прочий стафф? Где инстанцировать объекты, как управлять временем их жизни, организовать владение и ссылки между ними?

Как отделить логику от представления? Какие обычно применяются паттерны проектирования? Какие дополнительные сущности типа менеджеров, провайдеров и т.п. обычно создаются?

Как организовать исходный код, который в общем случае не просто MonoBehaviour-скрипты, а произвольные переиспользуемые классы? Как управлять зависимостями между ними?

Можно ли использовать классическую событийную модель типа .NET events или Rx вместо (или совместно с) пофреймового update()?

Заранее благодарен за ответы!

[Neodrop]

Я думаю, как только вы пройдёте первые Уроки, вам сразу всё станет ясно. Потратьте пару дней, чтобы избавить и себя и нас от лишних вопросов.
З.Ы. все они уже сотню раз обсуждались на форуме. И уроки их действительно решают.
Смотрим сюда.

[Qbit]

Я думаю, как только вы пройдёте первые Уроки, вам сразу всё станет ясно. Потратьте пару дней, чтобы избавить и себя и нас от лишних вопросов.
З.Ы. все они уже сотню раз обсуждались на форуме. И уроки их действительно решают.
Смотрим сюда.

Спасибо за ответ! Но не могли бы вы дать ссылки на посты, где непосредственно рассматриваются ответы на некоторые из перечисленных мной вопросов? (Желательно на оригиналы статей, не на переводы.)

Дело в том, что базовое представление о среде Unity, компонентной модели и скриптовании я имею; прочитал половину мануала, некоторые туториалы, поэкспериментировал с разными возможностями. Но в промышленном программировании, в отличие от «инди-геймдева», требования по качеству предъявляются не только к выходному продукту, но и к его исходному коду. Мало просто добиться от игры той или иной функциональности, нужно чтобы при этом исходный код был легко сопровождаем и модифицируем, причём посторонними людьми. То есть мне не нужно, чтоб оно просто работало, мне нужно, чтоб оно было спроектировано грамотно. Вот о подходах к правильному проектированию я и спрашиваю.

По предложенной ссылке я увидел много интересных, но технических деталей, как добиться от Юнити того или иного поведения. Эти детали, возможно, понадобятся в дальнейшем по мере прогресса. Сейчас же меня интересуют общие аспекты разработки под Юнити, а не частные возможности платформы.

[DbIMok]

думаю "подход к правильному проектированию" и "общие аспекты" в не отличаются от обычных (за исключением технических деталей)

[Qbit]

думаю "подход к правильному проектированию" и "общие аспекты" в не отличаются от обычных (за исключением технических деталей)

«Обычных» подходов много, они отличаются для разных платформ и типов приложений (это если грубо и упрощённо).

Вот смотрите. Если, например, я делаю GUI-приложение, скажем, на WPF, то я использую паттерн MVVM. В точке входа я создаю (явно, или разрешаю из IoC-контейнера) главное представление (View), параметризуемое моделью представления (ViewModel), параметризуемую доменной моделью (Model). Если я делаю веб-сайт, то использую, соответственно, архитектурный паттерн MVC, там инстанцирование View происходит в Action'ах Controller'ов. Если делаю какую-то библиотеку, в которой реализую какой-то класс, то можно начать с создания TestRunner'а, в котором инстанцировать Mock'и для интерфейсов, от котрых зависит класс. И так далее. Это если в самых общих чертах.

Как опыт разработки подобных «обычных» приложений распространяется на Unity-игры? Я этого пока не вижу.

[Tolking]

ИМХО подходы не отличаются. Отличается реализация. Если Вы понимаете какой принцип заложен в подход, то сможете его реализовать где угодно. Если же Вы знаете какую-то конкретную реализацию подхода, не понимая принципов, то платформа не виновата.

Мне, как ламеру, странно слышать о «best practices» для мультиплатформенного движка в геймдеве. Скорее уж можно говорить о "bad practices".

В Юнити доступно все, что доступно в .net в ущерб мульти платформенности (без ущерба все, что доступно в Mono)

[Neodrop]

Unity приложение в целом ничем не отличается от любого другого дотнет приложения. Пишите и используйте те паттерны, которые вам удобны и привычны. Тут нет правил или рамок, только ваш опыт, выбор и предпочтения.

Разве что нет фиксированной "точки входа", но вы вполне можете создать её себе самостоятельно как для GUI, так и для всех прочих внутренних циклов (Update, FixedUpdate и пр.)

[DbIMok]

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

наверное "технические детали" влияют? )

[Qbit]

наверное "технические детали" влияют? )

Да, может, и так быть.

[Qbit]

Если Вы понимаете какой принцип заложен в подход, то сможете его реализовать где угодно.

Нет, это не так. Для разных технологий естественными могут быть разные идиоматические подходы, и ломать их — себе дороже. Тот же MVVM крайне тяжело применять при написании GUI на WinForms, а на платформах с богатыми возможностями DataBinding'а — только в путь. В Unity в этом отношении всё не так.

Мне, как ламеру, странно слышать о «best practices» для мультиплатформенного движка в геймдеве.

Движки движкам рознь. Какие-то более «библиотеко-подобные», какие-то более «фреймворко-подобные». Первое примерно означает, что пользовательский код чаще вызывает библиотечный код; второе — наоборот, код фреймворка вызывает пользовательский.

В Юнити доступно все, что доступно в .net в ущерб мульти платформенности (без ущерба все, что доступно в Mono)

Работа со стандартной библиотекой классов в .NET отличается от работы с каркасами типа Юнити в указанном выше смысле. В первом случае я сам выбираю, где, как и в какой последовательности инстанцировать экземпляры классов, я же вызываю их методы. Во втором случае, как я понял, преобладает обратное: каркас фиксирован фреймворком Юнити, и требуется предоставить ему мои функции, чтобы он их вызывал.

[Neodrop]

Qbit, боюсь ваш опыт и глубокие теоретические познания слишком тяжеловесны для дискуссии на нашем форуме. К примеру, я с трудом перевожу для себя ваши вопросы.
Мне искренне кажется, что ответить вам на уровне ваших запросов, тут, может оказаться некому.

Предлагаю немного понизить планку. Примерно до уровня 1-2 курса политеха, не выше.

[DbIMok]

вот, подобрались хоть к какой-то конкретике, "интересным, но техническим деталям"

В первом случае я сам выбираю, где, как и в какой последовательности инстанцировать экземпляры классов

в рамках предложенной событийной последовательности вы можете инстанцировать экземпляры где и как угодно.

Во втором случае, как я понял, преобладает обратное: каркас фиксирован фреймворком Юнити, и требуется предоставить ему мои функции, чтобы он их вызывал.

насколько я себе представляю, C++ движок при помощи рефлексии в определенные моменты времени вызывает определенные функции компонентов игровых объектов + запрещает обращаться к элементам движка из потоков. вот и весь "фиксированный каркас". в остальном делайте что хотите. хотите, вызывайте ф-ии движка, хотите, давайте ему вызывать свои функции... )

[Qbit]

Предлагаю немного понизить планку. Примерно до уровня 1-2 курса политеха, не выше. :ympeace:

:) Ну вот, например, в политехе наверняка изучают что-нибудь вроде Delphi или WinForms. И тот стиль программирования, который преподают, скорее всего выглядит как т.н. «button1_Click style». Т.е. понатягать на форму кнопочек, IDE сгенерит для них обработчики, засунуть туда логику — работает же! Оно действительно работает. Поначалу. На тестовых примерах. Но в реальной жизни такого не бывает, чтоб чётко было поставлено задание, его достаточно реализовать и забыть. Код приходится сопровождать, поддерживать, добавлять фичи, рефакторить, искать ошибки, удовлетворять меняющимся требованиям. Т.е. он эволюционирует во времени, а не тупо переходит от состояния «не готов» к состоянию «готов». Возникают требования не только к функциональности программы, но и к качеству её исходного кода (несмотря на то, что конечный пользователь никак прямо оценить не может). Если код изначально пишется неряшливо, то асимптотическая сложность добавления новой фичи меняется от константной до квадратичной. Т.е. новые фичи становится всё сложнее и сложнее добавлять так, чтоб старые не отвалились. Скорость внесения изменений падает, увеличивается среднее число ошибок на единицу функционала в единицу времени, всё труднее согласовывать работу разных разработчиков. Для преодоления роста сложности вырабатываются эмпирические правила. Ну типа, не засовывать логику в обработчики GUI, а создать промежуточную сущность, которая будет подписана на события от представления, и будет транслировать их в слой бизнес логики, обновлять интерфейс при изменениях в Модели, etc.

Так вот, когда я пытаюсь писать на Unity, нет ощущения цельности наивного подхода. То есть работать оно работает, но нет уверенности что ситуация не будет усугубляться в будущем.

[DbIMok]

если я правильно понял про наивный подход... юнити тут не при чем. в нем все сделано по классической схеме, о нас с вами (и совсем начинающих) максимально позаботились. очень помогает функционал редактора. можно делать под свои задачи инструменты, сильно упрощающие жизнь. в плане проектирования самого приложения работают те самые общие принципы (совершенный код и т.д. и т.п.) юнити тут не помеха. можете писать что хотите и как хотите. надеюсь, разговор с "облаков" асимптотически ) спустится на землю и вы поделитесь с нами, что же конкретно вас тревожит и в чем затруднения. желательно на примерах с кодом )

[Crackman]

Нет, это не так. Для разных технологий естественными могут быть разные идиоматические подходы, и ломать их — себе дороже. Тот же MVVM крайне тяжело применять при написании GUI на WinForms, а на платформах с богатыми возможностями DataBinding'а — только в путь. В Unity в этом отношении всё не так.

Добрый день, применительно к UI, возможно будет интересно, есть такая вот штука: http://tools.artofbytes.com/demo, MVVM как по учебнику. Распространить такой же подход для привязки произвольных gameobject-ов к свойствам в ModelView скорее всего получится, но за пределами UI это уже не так актуально, есть ли смысл абсолютно всю логику игры строить на MVVM паттерне?