Тёмная тема
Игра карточная, 2Д, в основном идёт работа с UI, а также некоторое общение между клиентом и сервером в реальном времени посредством Вебсокета.
У меня такая идея.
Один класс (WS_Controller) отвечающий только за Вебсокет.
Другой класс — UI_Controller, в нём будут храниться ссылки на все объекты Canvas'а.
И остальные классы это на каждую логику свой класс, то есть, один класс для реализации логики ЧАТА, другой класс для логики НАСТРОЕК, например.
Вообще не понимаю, как это делается правильно. Не хочу говнокод писать и считаю, что нормальный программист, должен всегда преобразовывать повторяющийся код в метод/функцию и делать всё грамотно, без хаоса.
А ещё у меня такой вопрос, каким способом лучше брать объект из другого класса? Например в логике ЧАТА мне нужно будет брать переменные из класса UI_Controller
Буду благодарен за любую подсказку, наставление!
И где наши эксперты?? Вопрос то интересный
if(пиши так, как тебе удобней, если работаешь один)
else
Так, как понимают все члены команды
Все зависит от сложности.
Если в игре 4-5 классов, то можно просто тупо перетащить их в нужные поля в инспекторе.
В случаях посложнее используют DI-контейнеры типа Zenject (или как он там сейчас называется?).
>>UI_Controller, в нём будут храниться ссылки на все объекты Canvas'а
С этим аналогично.
Если UI простое - можно и так. А в сложных случаях (как например в фронтенд фреймворках типа Ангуляр и подобных) - разбивают на логические части - компоненты.
Ну и sledo верно написал. Если ты новичок, пишешь один и не хочешь пока углубляться в Зенджект и т.п. - ну и фиг с ним. Пиши как тебе удобней. Главное же не использовать новейшие технологии, а игру создать.
Ну а как я бы сделал.
1. сделал бы отдельный компонент работы с транспортной системой
2. сделал бы систему подписок на событие от сервера.
Ну и п.1 прописал что мы принимаем от сервака
и сделал бы контроллеры базовые которые делали Action при получении
того или иного пакета от сервера.
Но это так грубые нашлепки :) надо рисовать и делать варианты :)
Godson
увы, чтобы стать нормальным программистом, нужно пописать говнокод и сформировать собственное мнение о том как делать лучше. особенно в сфере разработки на Unity, где просто нет какого-то единственно верного стандартного подхода.
В рамках раскрутки своего ютуб канала могу посмотреть ваш код и разобрать его там, будет код и что обсуждать, а не коней в вакууме - пишите, присылайте/выкладывайте проект
но в принципе, начало мысли правильное, хотя названия для классов ужасные
Godson
> А ещё у меня такой вопрос, каким способом лучше брать объект из другого класса?
> Например в логике ЧАТА мне нужно будет брать переменные из класса UI_Controller
События, обычно не требуется чтобы дочерний класс знал что то о базовом.
Делаете компонентную систему, UIController -> UIElement, контроллер в данном случае базовый компонент, он раздает команды всем элементам UI. В обратной последовательности в идеале работать не должно, но если необходимо дать фидбек в наш мозг, т.е. в контроллер, делаем событие которое будет этим заниматься. Напрямую условный UIElement знать о базовом классе ничего не должен, это будет нарушение ООП. В целом все что вы описали - правильно.
На DI контейнерах так же свет клином не сошелся, если углубляться далее, есть еще порядок инициализации компонентов, в идеале мы должны самостоятельно контролировать инициализацию каждого компонента в проекте. А не пускать инициализацию каждого скрипта на самотек через void Start и прочее. Делать те подписки, и кеширование, которое нам необходимо перед началом работы, жестко контролируя все этапы.
Спасибо всем за ответы!;
Пользу из этого я однозначно извлеку, да и другие возможно тоже;
tac
> но в принципе, начало мысли правильное, хотя названия для классов ужасные
Почему ужасные?
ДобрыйБарин
Все это относится к уровню организации проекта. Как верно сказал seaman - все зависит от сложности. Если у автора проект, условно, из трёх строк кода, типа "загадай число, нажми на кнопку генератора чисел", то смысл во всем описанном?
Надо четко понимать что, когда и где использовать, для чего это нужно и почему это ввели. Например ещё лет десять назад нельзя было просто так взять и сравнить строку, а теперь это чуть ли не быстрее чем int. Тоже самое с гет/сетами, но люди упорно пихают их буквально везде, я даже видел их в названии классов, хотя это давно рудемент.
Godson
> tac
> > но в принципе, начало мысли правильное, хотя названия для классов ужасные
> Почему ужасные?
Потому что выбились из его шаблона понимания. Это частая болезнь у программистов.
sledo
> Это частая болезнь у программистов.
вообще да, но в данном случае это чистое самоутверждение
Напишите все в одном методе Update одного корненого объекта, весь game_loop на кадр. Будет и больше контроля над UI и понимания. Оставьте архитектурный онанизм тем, у кого нет премиума на порнхабе. Фантазировать, кто у кого может потрогать приватные методы и не нарушает ли это принципа взаимного согласия, можно бесконечно.
NyakNyakProduction
Наконец-то нормальные советы. Game.cs решает все проблемы, согласен. Максимум UI.cs добавить к этому.
Godson
> Почему ужасные?
Потому что они не соответствует стилю наименования - никакому. Разделение знаком подчеркивания - моветон ... как минимум можно назвать UiController - по стилю будет нормально, но вот по логике еще нет .. лучше все же разделять по смыслу так же как и другие части кода, скажем ChatUI ...
tac
Пхах
public int счетчик_припасов_time_control;
Сейчас мы будем наблюдать клин мозга)))