Комментарии 6
спасибо было познавательно )
Очень качественная статья, на русском языке таких очень мало!
Я сейчас работаю над https://store.steampowered.com/app/2603930/Adventurers_Gambit_Dungeons_of_Fortune/
Сам писал систему с 0, движок Юнити, фреймворк для мультиплеера - FishNet. Есть базовый класс Ability: NetworkBehaviour , который содержит только общие методы (запуск логики куртина т.к. удобно делать задержки, выбор целей и т.д.) и ScriptableObject со статичными данными (название, применяется ли на союзников, на врагов, на себя и т.д.). Способности наследуются от него и перезаписывают методы: действия, текста описания, формулы расчета. На сцене присутствует AbilityManager, который держит в себе все абилки как компоненты и проверяет валидность применения ну и по входным данным (ид способности, точка применения, цель применения и т.д.) запускает действие способности.
1)Не совсем понял что вы имели ввиду под "представлением",
2)шины команд у меня нет, чем это чревато?
3)Тряска камеры реализована на контроллере который управляет камерой, но там видимо судя по вашей статье одним методом который делает тряску не обойтись, тряску ещё в способности не включал. Можно ли поподробнее услышать архитектуру как лучше ее настроить
4)можете высказать в целом ваше мнение о моем подходе?
Нечасто удаётся встретить реальных пользователей FishNet на реальных и серьёзных проектах – классный кейс 👍
Если текущая реализация не доставляет проблем, работа с ней всем на проекте удобна и понятна, геймдизы получают что хотят, а игровые сервера (при их наличии) не бьют по кошельку, то отличный подход.
Цели разработки:
- чтобы работало;
- чтобы дальше расширялось;
- чтобы входные требования удовлетворялись;
- чтобы отдел разработки не страдал.
Если все цели достигнуты, то не нужно бежать за «лучшей жизнью» и решать «надуманные проблемы». Всё уже сделано.
В описанной схеме красных флажков не увидел. С точки оптимизации, если на каждую абилку нужно создавать новый GameObject с навешанным NetworkBehaviour, то стоит завести пул сетевых объектов (если его ещё нет). А если FishNet позволяет динамически NetworkBehaviour навешивать, без инстанциирования лишних GameObject, то замечательно.
Представление – это Presentation Layer, если выражаться терминами N-Layer. Или View, если выражаться терминами MVx. Слой приложения, который отвечает за взаимодействие с пользователем: считывание инпута, отрисовка картинки, воспроизведение звуков, вибро и пр. Опосредованная связь с этим слоем позволяет менять его реализации или убирать совсем, чтобы, например, запускать в режиме игрового сервера как терминальное приложение.
Шина команд нужна, если требуется наладить координацию между модулями или слоями проекта без явного связывания. Т.е. это один из инструментов для налаживания общения с Представлением, если не хочется, чтобы от него кто-то явно зависел.
То, что тряска камеры находится в контроллере камеры – ничего страшного нет, если так удобно. Кто это и как это вызывает – более важный аспект. Но беспокоит ли это? Если явных проблем с механикой нет, то лучше гнездо лишний раз не тормошить. Хорошее сделать лучше сложно 😁
Заметка про реализацию системы способностей в играх