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

Всем привет.

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

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

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

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

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

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

0

ezd,
Приведите конкретный пример. Иначе долго можно рассуждать.

0

Сообщение от Storm23 Приведите конкретный пример. Иначе долго можно рассуждать.

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

Я думаю может во все такие объекты свой такой же StateBus поместить и подписываться через тот же обсервер, типа при любом событии оповестить всех подписантов пусть они сами смотрят какое событие произошло.

0

Сообщение от ezd Ну я описал пример что я планирую. Типа есть база, которая строит юнитов, по истечению таймера нужно создать юнит, сделать оповещения игроку. Сюда же отношу всякие попадания в бою и юнит разрушен, то его надо исключить из разных групп, списков и пр. Эти события генерируются по таймеру или от другого события и ловиться должны не во View (монобех), а во всяких контроллерах. Я думаю может во все такие объекты свой такой же StateBus поместить и подписываться через тот же обсервер, типа при любом событии оповестить всех подписантов пусть они сами смотрят какое событие произошло.

это все слишком много гемороя!

для создания объекта используй Invoke или Instantiate

удалить объект Destroy(объект, время в секундах до удаления объекта)

0

Сообщение от Steroid для создания объекта используй Invoke или Instantiate удалить объект Destroy(объект, время в секундах до удаления объекта)

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

0

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

зависит от конкретной задачи

0