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

    Привет, Хабр!

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

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


    Как-то в конце декабря 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. С удовольствием ответим на вопросы, если таковые будут.

    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 7

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.