Архитектура. Кто главный юнити или игра?

Всем привет.

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

Попытаюсь понятнее объяснить.

Как обычно строится приложение. Сначала берется какой-то метод Main, который стартует наше new App(). В этом приложении создаются какие-то объекты - списки, фабрики, локаторы, загрузчики, логгеры и т.п., потом начинается основной цикл, который порождает уже сам процесс игры, игрока, сцены, врагов и т.д. (мелочи типа лези лоад не берем тут в расчет).

А что нам предлагает Юнити? Вот вам сцена, туда добавляются объекты, которые стартуют в случайном порядке, можно порождать другие объекты, но связи между ними нет, искать объекты - табу, ведь это очень напряженный и долгий процесс. У любого здравомыслящего человека возникает вопрос "а как собственно ссылаться на объекты если нельзя их искать и неизвестно кто их порождает", "как эти объекты должны общаться с движком игры" и прочее. Отсюда появляются идеи типа синглтон-менеджеров, что в свою очередь порождает проблемы с очисткой, рестартом, всякие null отсылки, и вообще большие дядьки бьют по рукам и говорят что синглтоны - ЗЛО! И многое другое.

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

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

0

Сообщение от ezd искать объекты - табу

кто такое сказал?

Сообщение от ezd синглтоны - ЗЛО!

с чего такое мнение?

Сообщение от ezd порождает проблемы с очисткой

в C# есть уже готовый GarbageCollector

Сообщение от ezd можно порождать другие объекты, но связи между ними нет

все объекты в сцене стандартно являются GameObjectами

Сообщение от ezd а как собственно ссылаться на объекты если нельзя их искать и неизвестно кто их порождает

все это известно

просто юнити очень многое упрощает для современныъ "супер разработчиков игр"!

для того чтоб понять как работает хотябы функция Update()

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

это еще не всё еще очень много разных операций про которые тут можно несколько часов тыкать по клавиатуре
всё это произходит КАЖДЫЙ фрейм на всех объектах в сцене

скажем юнити дает нам доступ к верхушке айсберга

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

Сообщение от ezd как и когда порождать объекты и как их хранить

как душе будет угодно

Сообщение от ezd именно всего приложения

читай документацию

0

Сообщение от Steroid кто такое сказал?

Сообщение от Steroid с чего такое мнение?

На этом месте я должен найти все ссылки где говорится об этом? Давайте не будем тратить время на это, я уверен, что все кто читает что-то по теме, неоднократно встречались с этим, вплоть до "лично указывать камеру, потому что иначе камера.мэйн будет искаться движком, а это дооооолго". Просто сойдемся на том, что такие мнения есть.

Сообщение от Steroid в C# есть уже готовый GarbageCollector

Не в коллекторе дело, а в очистке синглотона и обнулении всяких данных vs restart -> new Game()

Ты явно не понял о чем тема. Попробуй перечитать ещё раз. Я знаю что такое геймобджекты и что такое Update, речь о том, что объекты например должны порождаться всегда только кодом и только так всегда будет ссылка на объект из первоисточника. А дальше уже проистекают вопросы "как этим объектом управлять", будет ли объект Player == GameObject или GameObject (prefab) лишь View, которым управляет некий контроллер (игра или что-то ещё). К сожалению все эти вещи игнорируются мануалами. Если объекты все порождаются, то и сцены за исключением константных объектов, описывающих уровень, практически пустыми должны быть. И многое другое. То есть огромная куча нюансов возникает когда переходишь от этапа "сделать два шарика по мануалу" к этапу "сделать игру".

0

Сообщение от ezd То есть огромная куча нюансов возникает когда переходишь от этапа "сделать два шарика по мануалу" к этапу "сделать игру".

ну это немного труднее чем "два тапка обо....ть"

Сообщение от ezd речь о том, что объекты например должны порождаться всегда только кодом

а чем вы хотете? силой мысли?

Сообщение от ezd будет ли объект Player == GameObject или GameObject (prefab) лишь View

глубокое заблуждение

Сообщение от ezd "как этим объектом управлять"

с помошью АПИ

Сообщение от ezd Если объекты все порождаются, то и сцены за исключением константных объектов, описывающих уровень, практически пустыми должны быть

непонял, хотя зависит от того что вам нужно для игры

Сообщение от ezd которым управляет некий контроллер (игра или что-то ещё)

Engine при помощи АПИ специально созданого для облегчения управления движком
в этом и заключается смысл игрового движка

0

Сообщение от ezd идут против интуитивной разработки

Правильное слово тут - привычной.

Сообщение от ezd Как обычно строится приложение. Сначала берется какой-то метод Main, ...

За вас как раз это делает игровой двиг юнити.

Сообщение от ezd стартуют в случайном порядке,

Порядок старта скриптов можно задать.

Сообщение от ezd можно порождать другие объекты, но связи между ними нет,

Вот тут не понял.

Сообщение от ezd искать объекты - табу, ведь это очень напряженный и долгий процесс.

Искать с помощью статик метода GameObject.Find действительно нехорошо.
Никто не запрещал искать через gameObject.transform.Find()
или даже вот так transform.GetComponentsInChildren<T>()
Кроме того вам редко когда нужно знать все обо всем, кэшируйте поиск.
Если сильно хочется можно порождать все самому на пустой сцене, некоторые так и делают используя юнити только как рендер.

Сообщение от ezd говорят что синглтоны - ЗЛО!

Для корпоративного джуниор безусловно.
Но мы то игру пишем а не мегафреймворк силами корпорации.

Сообщение от ezd Как стартовать приложение, создавать объекты, всегда знать о них все, ссылаться на ресурсы игры когда запускать логгеры, соединения с базой данных, как и когда порождать объекты и как их хранить, чтобы "не искать").

Приложение стартует само.
Ваша задача в общем случае выстроить взаимодействие объектов.

Настоящее адское веселье вас ждет когда пожелаете сериализовать сцену и самый смак - десеарилизовать.
Тут даже монстры вроде Newtonsoft.Json по умолчанию падают в экзепшн нульреф луп, а после устранения пищат о депрекейт и так далее.

0

Сообщение от Kharr За вас как раз это делает игровой двиг юнити.

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

Сообщение от Kharr Вот тут не понял.

Всякие мануалы и пособия рассказывают типа сделаем ракетницу: "создаем геймобджект, в него пихаем скрипт, который будет создавать ракету" и получается что один геймобджект в котором висит скрипт порождает другой объект. А движок игры ничего об этом не знает. Все действия будто проходят где-то вне его. А если мы решили посчитать, допустим сколько игроки навыпускали ракет? Надо либо чтобы каждый игрок куда-то все сохранял (опять синглтон какой-то?) или ракеты должен создавать не любой скрипт на геймобджекте, а движок игры и сам считать, который может быть вообще на сцене не представлен.

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

Но поскольку все мануалы игнорируют этот факт, а упираются в "создадим шарик, на него повесим скрипт", получается гигантская пропасть в архитектуре приложения между обучающими материалами и реальными проектами. Вот мне и интересно как строятся реальные приложения. Как там организуется связь между объектами, кто за что отвечает.

0

Сообщение от ezd Всякие мануалы и пособия рассказывают типа сделаем ракетницу: "создаем геймобджект, в него пихаем скрипт, который будет создавать ракету" и получается что один геймобджект в котором висит скрипт порождает другой объект. А движок игры ничего об этом не знает. Все действия будто проходят где-то вне его. А если мы решили посчитать, допустим сколько игроки навыпускали ракет? Надо либо чтобы каждый игрок куда-то все сохранял (опять синглтон какой-то?) или ракеты должен создавать не любой скрипт на геймобджекте, а движок игры и сам считать, который может быть вообще на сцене не представлен.

братан "ты как с луны свалился"
конечно всё нужно делать самому, за тебя никто не будет считать твои ракеты

Сообщение от ezd Вся логика игры должна скрываться в движке игры, но никогда не геймобджектах,

ты про API слышал когданибудь?
так вот в движке какраз вся логика построения ипреобразования матриц скрывается и доступ у тебя к ней произходит через API для упрощения ТЕБЕ работы с движком

смотри обучающие видео и не говори что ты уже КУЧУ материала посмотрел.... ты бы не задавал таких вопросов!

0

ezd, да вы начните делать как умеете и увидите что и как будет лучше после N-итерации.
нет единого мнения как и что делать. да и каждая игра это считай своя уникальная вселенная. да что-то будет общее, но остальное разное.
кто на что способен так и делает.

Сообщение от ezd обучающими материалами

дают нам понимание как работает Юнити. а не как вы хотите архитектуру создать.

0

Сообщение от Steroid так вот в движке какраз вся логика построения ипреобразования матриц скрывается и доступ у тебя к ней произходит через API для упрощения ТЕБЕ работы с движком

Ох. Юнити это скорее фреймворк, а движок игры, включающий ее логику, это class MySuperPuperGame. Меня интересует как строить логику такой программы для эффективного взаимодействия с Unity.

Добавлено через 3 минуты

Сообщение от MuaddibFremen ezd, да вы начните делать как умеете и увидите что и как будет лучше после N-итерации. нет единого мнения как и что делать. да и каждая игра это считай своя уникальная вселенная. да что-то будет общее, но остальное разное. кто на что способен так и делает.

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

0

ezd,
по любому запустится хотя бы одна сцена.
вот на ней и городите игровой цикл("свой движок").
не хотите пользоваться методами unity Update/Start/Awake/etc - не пользуйтесь. уберите их и сами контролируйте в gameLoop все обьекты.

0

логика движка и логика игры 2 разные вещи

0

ezd, возможно, будет более конструктивно, если вы сформулируете конкретные вопросы по отдельным интересующим вас проблемам. Вроде, как лучше сделать "такую" штуку?

0

Сообщение от ezd Архитектура. Кто главный юнити или игра?

Я понимаю ваш вопрос. И он не простой.
С одной стороны, конечно общие принципы и паттерны никто не отменял, но с другой стороны Unity вносит свои ограничения, которые сильно влияют на архитектуру. Есть разные подходы - от создания врапперов поверх юнити и дальнейшая работа в привычных парадигмах, до забития на все паттерны и развешивания скриптов на gameobject-ы как к тому подталкивает сам движок. Однако большинство все таки работают где-то посередине.

Для начала я вам советую посмотреть на такой паттерн как EventBus (или просто Bus, шина сообщений и т.д.).
Пример реализации - есть здесь https://www.cyberforum.ru/blog... g5507.html
Там же есть пример приложения, в которой части более-менее независимы друг от друга, благодаря шине сообщений.
Помимо Bus, есть также подходы, связанные с внедрением зависимостей (см например Zenject), а также реактивное программирование (правда оно скорее о другом, не о связанности) - например UniRx.

Если будут более конкретные вопросы - спрашивайте. На конкретику отвечу.

1

Сообщение от ezd необходимо инициализировать окружение игры типа базы данных,

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

Сообщение от ezd А движок игры ничего об этом не знает. ... А если мы решили посчитать, допустим сколько игроки навыпускали ракет?

Знает. Вы же дергаете для порождения его АПИ Createinstance. а раз вы его дергаете то можно и посчитать легко.
Это вопрос архитектуры.

Сообщение от ezd редактор юнити нужен только для создания константных сцен, тестирования, создания префабов

Логично, а еще там в инспекторе в делегатах можно выбрать "разрешить скрипт в редакторе" или непосредственно в скрипте прописать атрибут.

Сообщение от ezd и т.д. Вся логика игры должна скрываться в движке игры.

Движок не может учесть всех пожеланий игростроя, потому он лишь обслуживает АПИ управления сценой и объектами и поддерживает для них внутренние коннекторы типа апдейт физиксапдейт старт итп.

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

Согласен. Ютуб переполнен поделками начинающих и нужно потратить время на то чтобы отыскать поначалу что-то стоящее.

Сообщение от ezd Вот мне и интересно как строятся реальные приложения. Как там организуется связь между объектами, кто за что отвечает.

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

0

ezd, у меня опыт в юнити нулевой. Относительное серьёзное знакомство с игровыми движками ограничено ковырянием в Сталкере. Там, например, то же вся логика на lua-скриптах, децентрализована и разнесена по разным объектам. Игра - это список и состояние всех объектов включая состояние скриптовой логики. Централизованная логика завязана на главного героя, игрок это то же объект игры. UI, в основном, отображает состояние главного героя, так что никаких заморочек с добыванием информации для отображения нет. Хотя, может и не в кассу я со своим примером...

0

Сообщение от Storm23 Я понимаю ваш вопрос. И он не простой. С одной стороны, конечно общие принципы и паттерны никто не отменял, но с другой стороны Unity вносит свои ограничения, которые сильно влияют на архитектуру. Есть разные подходы - от создания врапперов поверх юнити и дальнейшая работа в привычных парадигмах, до забития на все паттерны и развешивания скриптов на gameobject-ы как к тому подталкивает сам движок. Однако большинство все таки работают где-то посередине. Для начала я вам советую посмотреть на такой паттерн как EventBus (или просто Bus, шина сообщений и т.д.). Пример реализации - есть здесь https://www.cyberforum.ru/blog... g5507.html Там же есть пример приложения, в которой части более-менее независимы друг от друга, благодаря шине сообщений. Помимо Bus, есть также подходы, связанные с внедрением зависимостей (см например Zenject), а также реактивное программирование (правда оно скорее о другом, не о связанности) - например UniRx. Если будут более конкретные вопросы - спрашивайте. На конкретику отвечу.

Спасибо. Интересный подход.

Есть пара вопросов.

1) Можно ли как-то в этом подходе реализовать передачу дополнительной информации типа отправителя и чего-то ещё? Или все дополнительные данные должны быть сохранены в какой-то определенный объект типа StateBus.MessageType - где MessageType это объект или массив определенных объектов?

2) Как может получить сообщение код, не являющийся MonoBehavior (не имеет Update)? По логике кто должен это сообщить игре?

П.С. Долго отвечал, потому что времени не было.

0

1. Завести структуру/класс, где одно из полей sender, ну или расширить класс мессенджера)
2. Создать менеджер, который будет в апдейте все проверять и отсылать сообщения не MonoBehavior классам, как вариант.

0

Сообщение от 1max1 1. Завести структуру/класс, где одно из полей sender, ну или расширить класс мессенджера)

И этот класс должен быть StateBus.ЭТОТ_КЛАСС или как?

Сообщение от 1max1 2. Создать менеджер, который будет в апдейте все проверять и отсылать сообщения не MonoBehavior классам, как вариант.

И этот менеджер будет MessageBus со всеми вытекающими последствиями? Он должен знать кому отправлять и что - получается связанность. Чтобы ее не было - надо делать подписчиков... и тут мы пришли к тому с чего начали Я в принципе против подписчиков и провайдеров ничего не имею, но идея же вроде от этого подхода отказаться. И в принципе в рамках юнити когда и так есть Update - такой вариант подходит.

0

Сообщение от ezd 1) Можно ли как-то в этом подходе реализовать передачу дополнительной информации типа отправителя и чего-то ещё? Или все дополнительные данные должны быть сохранены в какой-то определенный объект типа StateBus.MessageType - где MessageType это объект или массив определенных объектов?

Нужно определить свой класс MyClass, в котором перечислены все необходимые поля.
А затем создать событие или состояние:

Сообщение от ezd 2) Как может получить сообщение код, не являющийся MonoBehavior (не имеет Update)? По логике кто должен это сообщить игре?

В выложенной версии Bus получать сообщения могут только MonoBehaviour (хотя я реально пользуюсь немного другой версией - там возможно подписать любой объект).
Но передавать сообщения в объекты данных - немного неправильно. Если реализовывать MVC-like pattern, то должен быть контроллер, который передает данные из View в DataDomain. И этот контроллер обычно является MonoBehaviour и он же и ловит сообщения шины. Поэтому реально нет необходимости ловить шину из доменного объекта.

Сообщение от ezd Он должен знать кому отправлять и что - получается связанность

Опишите конкретную проблему, которую вы решаете. Шина сообщений позволяет разрывать связность. Если у вас это не так - значит вы что-то делаете неправильно.

0

Сообщение от Storm23 В выложенной версии Bus получать сообщения могут только MonoBehaviour (хотя я реально пользуюсь немного другой версией - там возможно подписать любой объект).

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

Сообщение от Storm23 Но передавать сообщения в объекты данных - немного неправильно.

EventArgs же, не? Я так понял StateBus.MyType и есть EventArgs только с собственной сигнатурой, а не общей.

Я вот как раз думаю об MVC, только я себе представляю View=монобех, а контроллер должен ловить всякие нажатия клавиш и давать всякие команды в модель. Модель должна изменять себя под действием команд и View должен быть как-то подписан на изменения в модели чтобы перечитывать изменения в ней и обновлять себя (это решается обсервером). Но проблема в том что на эту модель должны подписываться и другие компоненты игры типа на события "апгрейд завершен" или "юнит построен". Такие сообщения как мне кажется не должны ловиться во всех View (монобех) в игре каждый кадр. Поэтому я себе представляю это опять же через подписку на события.

0