Привет, Хабр!
Некоторые, возможно, помнят что полгода назад я писал о том как мы за полгода запилили прототип многопользовательской игры.
По итогам голосования тогда аудитория решила, что стоит написать продолжение об архитектуре игры. Под катом вторая серия в незаслуженно забытом ныне жанре производственной драмы, много картинок, видео актуального на данный момент геймплея и новогодний котик.
Краткое содержание предыдущих серий
Как-то в конце декабря 2014 года команда из четверых человек решила создать клон одного из самых популярных модов к WarCraft 3 — Legion TD. Собрав за полгода в свободное от работы время простейший прототип, юные душой программисты внезапно поняли, что им позарез нужны художники, моделлеры и дизайнеры. Вступив на скользкую дорожку спама в профильных сообществах и группах, параллельно переписывая игровой сервер на Go, им удалось привлечь на темную сторону целую группу замечательных специалистов с просторов бСССР. А в это время далеко за океаном аналогичный клон на протяжении трех лет разрабатывал простой американский паренек Брент «Lisk» Батас. Он имел хорошие наработки по арту и практически нулевые по коду, но отказался сотрудничать с нашими героями. Даже продемонстрированная во время командировки в Сан-Франциско a11aud‘ом рабочая связка сервер-клиент не убедила американца. Было принято решение продолжать разработку опираясь лишь на собственные силы. Моделлеры, текстурщики и дизайнеры трудились не покладая стилусов чтобы успеть выкатить MVP к назначенному сроку — кануну нового 2016 года. И в целом нам это удалось.
А что собственно сделано?
Итого к настоящему времени совместными усилиями мы имеем тауэр-дефенс с первой игровой расой, постоянно улучшающейся графикой:
- Cверхбыстрый масштабируемый авторитарный игровой сервер на Go с ботами, поддержкой реконнекта и записи реплеев.
- Кроссплатформенный клиент со свистелками.
- Лобби-сервер с ботами и матчмейкингом
- Кроссплатформенный лаунчер
Но вернемся к обещанной теме. Я постараюсь привести основные проектные решения, которые подтвердили свою состоятельность. Многим они наверняка покажутся очевидными, но поверьте, как оказалось, это не совсем так. Низкий порог вхождения в Unity делает возможными даже самые детские ошибки проектирования.
Мысль первая
Если игровое состояние описывается сложной сериализованной структурой данных, как в нашем случае, вы должны всегда иметь простой доступ к любой интересующей вас информации. Поскольку наш проект несколько сложнее казуального мейнстрима, готовые рецепты Unity нам не подходят. В силу того, что мы использовали свой собственный стек технологий, сериализация и десериализация не делается в два счета. Напомню, что в нашем проекте сервер рассылает восьми игрокам дельта-состояния игры в формате json 10 раз в секунду. В качестве решения мы написали синглтон, который парсит сообщения сервера, обновляет состояние игры на клиенте и предоставляет удобный интерфейс к любым игровым данным.
При таком подходе получить нужную информацию для разных компонент клиентов, например, координаты для менеджера юнитов и мини-карты не составляет труда.
Как бы ни был велик соблазн навесить на такой класс всю функциональность вплоть до
StateHub.Instance.GetLastKilledWithBlackMagicDwarfUID() , будьте благоразумны, помните про God Object. Видимо это имел в виду Сергей Сычев в своем выступлении на тему ООП в Unity на последней встрече Unity User Group в Питере (я добавлю ссылку на доклад, когда он будет опубликован), когда призывал не использовать синглтоны совсем. Но мне кажется, что чувство меры и здравый смысл подскажут вам, когда пора остановиться.
Мысль вторая
В нашем случае есть смысл использовать событийную модель. В «Легионе» существует понятие фазы. Есть фаза строительства, фаза боя, фаза битвы на арене. Как уже сказано выше, сервер шлет обновления состояния 10 раз в секунду. Мы генерируем события прилета нового сообщения и смены фаз. Этого вполне достаточно, чтобы просто и логично организовать инстанциирование юнитов, сборку трупов, переключение музыкальных тем и прочие утилитарные операции. Поскольку наш игровой клиент не рассчитывает никакой игровой логики и является по сути просто “телевизором с пультом”, этих нескольких эвентов достаточно.
Мысль третья
Разделение MonoBehaviour как View и непосредственно игровой информации для юнитов. Вещь тривиальная, но, как оказалось немало программистов Unity пишут чуть ли не весь код в одном скрипте. Это не страшно в небольшом проекте, но если вы задумываете нечто серьезнее флэппиберда, лучше об этом подумать заранее.
До и после
Полгода назад
Сейчас
Работы еще много, конечно, но прогресс налицо.
В следующих сериях
Брент «Lisk» Батас объявил о намерении выйти на краудфандинг к концу февраля и начать закрытый бета-тест к концу 2016 года.
Наша команда Spiced Jackal планирует продолжать разработку, поиск инвестиций, продвижение игры под названием KrownGuards и успеть раньше конкурентов. Таковы итоги года нашей напряженной работы. Мы хотим поблагодарить всех, кто с нами работал и работает и поздравить всех с наступающим новым годом. До встречи в 2016!
P.S. С удовольствием ответим на вопросы, если таковые будут.
ссылка на оригинал статьи http://habrahabr.ru/post/274367/
Добавить комментарий