Архитектура игрового клиента многопользовательской Tower Defence. Новогодняя история

Привет!

Некоторые, возможно, помнят что полгода назад я писал о том как мы за полгода запилили прототип многопользовательской игры ^[1].
По итогам голосования тогда аудитория решила, что стоит написать продолжение об архитектуре игры. Под катом вторая серия в незаслуженно забытом ныне жанре производственной драмы, много картинок, видео актуального на данный момент геймплея и новогодний котик.

Краткое содержание предыдущих серий

Как-то в конце декабря 2014 года команда из четверых человек решила создать клон одного из самых популярных модов к WarCraft 3 — Legion TD. Собрав за полгода в свободное от работы время простейший прототип, юные душой программисты внезапно поняли, что им позарез нужны художники, моделлеры и дизайнеры. Вступив на скользкую дорожку спама в профильных сообществах и группах, параллельно переписывая игровой сервер на Go, им удалось привлечь на темную сторону целую группу замечательных специалистов с просторов бСССР. А в это время далеко за океаном аналогичный клон на протяжении трех лет разрабатывал простой американский паренек Брент «Lisk» Батас. Он имел хорошие наработки по арту и практически нулевые по коду, но отказался сотрудничать с нашими героями. Даже продемонстрированная во время командировки в Сан-Франциско a11aud ^[2]'ом рабочая связка сервер-клиент не убедила американца. Было принято решение продолжать разработку опираясь лишь на собственные силы. Моделлеры, текстурщики и дизайнеры трудились не покладая стилусов чтобы успеть выкатить 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. С удовольствием ответим на вопросы, если таковые будут.

Автор: MrPeterLink

Источник ^[3]