Войти
UnityФорумПрограммирование

Как лучше/правильнее реализовать архитектуру проекта игры в юнити?

Страницы: 1 2 Следующая »
#0
19:42, 13 ноя 2022

Игра карточная, 2Д, в основном идёт работа с UI, а также некоторое общение между клиентом и сервером в реальном времени посредством Вебсокета.
У меня такая идея.
Один класс (WS_Controller) отвечающий только за Вебсокет.
Другой класс — UI_Controller, в нём будут храниться ссылки на все объекты Canvas'а.
И остальные классы это на каждую логику свой класс, то есть, один класс для реализации логики ЧАТА, другой класс для логики НАСТРОЕК, например.

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

А ещё у меня такой вопрос, каким способом лучше брать объект из другого класса? Например в логике ЧАТА мне нужно будет брать переменные из класса UI_Controller

Буду благодарен за любую подсказку, наставление!

#1
21:06, 13 ноя 2022

И где наши эксперты?? Вопрос то интересный

#2
21:19, 13 ноя 2022

if(пиши так, как тебе удобней, если работаешь один)
else
Так, как понимают все члены команды

#3
(Правка: 22:33) 22:32, 13 ноя 2022

Все зависит от сложности.

Если в игре 4-5 классов, то можно просто тупо перетащить их в нужные поля в инспекторе.
В случаях посложнее используют DI-контейнеры типа Zenject (или как он там сейчас называется?).

>>UI_Controller, в нём будут храниться ссылки на все объекты Canvas'а
С этим аналогично.
Если UI простое - можно и так. А в сложных случаях (как например в фронтенд фреймворках типа Ангуляр и подобных)  - разбивают на логические части - компоненты.

Ну и sledo верно написал. Если ты новичок, пишешь один и не хочешь пока углубляться в Зенджект и т.п. - ну и фиг с ним. Пиши как тебе удобней. Главное же не использовать новейшие технологии, а игру создать.

#4
22:39, 13 ноя 2022

Ну а как я бы сделал.
1. сделал бы отдельный компонент работы с транспортной системой
2. сделал бы систему подписок на событие от сервера.

Ну и п.1 прописал что мы принимаем от сервака
и сделал бы контроллеры базовые которые делали Action при получении
того или иного пакета от сервера.
Но это так грубые нашлепки :) надо рисовать и делать варианты :)

#5
3:48, 14 ноя 2022

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

#6
(Правка: 4:58) 4:56, 14 ноя 2022

В рамках раскрутки своего ютуб канала могу посмотреть ваш код и разобрать его там, будет код и что обсуждать, а не коней в вакууме - пишите, присылайте/выкладывайте проект

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

#7
(Правка: 21:13) 21:06, 14 ноя 2022

Godson
> А ещё у меня такой вопрос, каким способом лучше брать объект из другого класса?
> Например в логике ЧАТА мне нужно будет брать переменные из класса UI_Controller
События, обычно не требуется чтобы дочерний класс знал что то о базовом.
Делаете компонентную систему, UIController -> UIElement, контроллер в данном случае базовый компонент, он раздает команды всем элементам UI. В обратной последовательности в идеале работать не должно, но если необходимо дать фидбек в наш мозг, т.е. в контроллер, делаем событие которое будет этим заниматься. Напрямую условный UIElement знать о базовом классе ничего не должен, это будет нарушение ООП. В целом все что вы описали - правильно.
На DI контейнерах так же свет клином не сошелся, если углубляться далее, есть еще порядок инициализации компонентов, в идеале мы должны самостоятельно контролировать инициализацию каждого компонента в проекте. А не пускать инициализацию каждого скрипта на самотек через void Start и прочее. Делать те подписки, и кеширование, которое нам необходимо перед началом работы, жестко контролируя все этапы.

#8
22:55, 14 ноя 2022

Спасибо всем за ответы!;
Пользу из этого я однозначно извлеку, да и другие возможно тоже;

tac
> но в принципе, начало мысли правильное, хотя названия для классов ужасные
Почему ужасные?

#9
23:14, 14 ноя 2022

ДобрыйБарин
Все это относится к уровню организации проекта. Как верно сказал seaman - все зависит от сложности. Если у автора проект, условно, из трёх строк кода, типа "загадай число, нажми на кнопку генератора чисел", то смысл во всем описанном?

Надо четко понимать что, когда и где использовать, для чего это нужно и почему это ввели. Например ещё лет десять назад нельзя было просто так взять и сравнить строку, а теперь это чуть ли не быстрее чем int. Тоже самое с гет/сетами, но люди упорно пихают их буквально везде, я даже видел их в названии классов, хотя это давно рудемент.

Godson
> tac
> > но в принципе, начало мысли правильное, хотя названия для классов ужасные
> Почему ужасные?
Потому что выбились из его шаблона понимания. Это частая болезнь у программистов.

#10
(Правка: 0:27) 0:26, 15 ноя 2022

sledo
> Это частая болезнь у программистов.
вообще да, но в данном случае это чистое самоутверждение

#11
12:44, 15 ноя 2022

Напишите все в одном методе Update одного корненого объекта, весь game_loop на кадр. Будет и больше контроля над UI и понимания. Оставьте архитектурный онанизм тем, у кого нет премиума на порнхабе. Фантазировать, кто у кого может потрогать приватные методы и не нарушает ли это принципа взаимного согласия, можно бесконечно.

#12
13:56, 15 ноя 2022

NyakNyakProduction
Наконец-то нормальные советы. Game.cs решает все проблемы, согласен. Максимум UI.cs добавить к этому.

#13
14:54, 15 ноя 2022

Godson
> Почему ужасные?
Потому что они не соответствует стилю наименования - никакому. Разделение знаком подчеркивания - моветон ... как минимум можно назвать UiController - по стилю будет нормально, но вот по логике еще нет .. лучше все же разделять по смыслу так же как и другие части кода, скажем ChatUI ...

#14
3:27, 16 ноя 2022

tac
Пхах

public int счетчик_припасов_time_control;

Сейчас мы будем наблюдать клин мозга)))

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