Постмортем UnnyWorld

Ошибки и как их можно избежать.

Ранее я публиковал статью «Три года разработки своей MMO», где речь шла больше про поиск инвестиций, команду и наш путь к «успеху». К сожалению (или к счастью?), проект пришлось закрыть. После закрытия нашей игры UnnyWorld многие знакомые разработчики просили написать постмортем по игре.

Решил поделиться конкретными примерами, коих за время разработки накопилось приличное количество. В данной статье постараюсь рассмотреть допущенные ошибки и, возможно, дать хотя бы парочку полезных советов.

Условно Unnyworld можно разделить на две части: Сити-билдер и Арены. Часть про билдер — это некий Clash of Clans. У вас есть своя планета, которую необходимо обустраивать. И вы можете нападать на другие планеты, чтобы красть ресурсы.

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

Арены — типичная MOBA 3-на-3 с разными режимами (захват флага, захват точки и так далее).

У каждого персонажа свои спеллы, которые можно комбинировать с другими игроками.

Перед боем можно сменить заклинания.

Игровой цикл в целом выглядит так.

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

Да, постоянно обсуждались многие вещи, но реализовывали их невпопад, основательно не проанализировав, что нужно делать в первую очередь.

Как следствие, пытались делать всё и сразу. Нужна ли система гильдий, когда в игре полтора пользователя? Хм, вряд ли.

Нужна ли система, позволяющая создать кастомный матч, приглашая туда друзей и согильдейцев, когда в игре маленький CCU? Не уверен.

В процессе разработки мы много пытались сделать того, что, вероятно, не нужно было делать на том этапе. Как следствие, не были реализованы по-настоящему необходимые вещи.

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

Поговорим немного о технической части вопроса.

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

Какой облачный провайдер использовать? AWS? Azure? SoftLayer?

На тот момент принципиальной разницы не было. Плюс, у нас был кредит на SoftLayer как стартапу.

Oh, boi, если бы вы только знали, как там всё плохо.

Саппорт особо не разбирается в проблеме. Были случаи, когда я к ним обращался по поводу проблемы на определённой виртуалке (не мог приконнектиться и тому подобное). На что получал ответ.

Были случаи, когда виртуалка поднималась часами. Как видите, я прождал четыре часа, а виртуалка так и не создалась.

Частые maintance.

Бывает, что без предупреждений ребутнут машину, или приватную сеть отрубят.

В итоге перешли на Azure. Таких проблем не было. Саппорт быстро отвечает и всегда помогает, в случае чего.

Хорошо: —

Плохо: не проанализировали как следует все возможные варианты. А ведь сервера — это важнейшая часть для онлайн игры.

Итак, вам нужно на сервере как-то запускать игровые инстансы, через какую-то систему API перекидывать, после авторизации игрока на нужный инстанс. Что же будем делать? А давайте возьмём готовое решение, которое будет само, в зависимости от нагрузки, менеджить это дело. Ого, тут вон есть штука, называемая Kubernetes. Правда она в бете… Но всё равно, давайте попробуем!

Если отбросить тот факт, что для работы с этой технологией нужен опыт, то даже при базовой настройке этого дела оно умудрялось падать. Какие-то сервисы отваливались и тому подобное.

Ну ладно, а что ещё есть? Mesosphere и Apache Mesos! С ним всё то же самое, без опыта сложно. Если что-то отваливается, то без бубна не исправить проблему.

В итоге написали всё сами. Инстансы стартуются супервизором, как и небольшой менеджер над ними (написанный на Java). Java приложение ttl в сервис дискавери тулзу о статусе (количество свободных комнат на инстансах и тому подобное). При авторизации и запросе на создание комнаты к API по этой информации об инстансах запрос уходит на нужную ноду, которая на нужном инстансе поднимает комнату.

То есть, инстансы всегда предзапущены. При нехватке мы поднимаем новую VPS.

Хорошо: проанализировали альтернативы.

Плохо: потратили много времени на протип. Для первой версии нужно было вообще не думать об этих вещах, а просто стартовать инстансы без всяких апликух поверх. Можно было прям захардкодить адреса инстансов на клиенте в прототипе.

Для сервис дискавери использовали consul.io Это, вероятно, одно из тех решений, о котором не пожалели. Там, правда, бывают проблемы вроде таких, когда при ребуте ломается конфиг. Но это редко и при незапланированном ребуте машины. В целом, за всё время с консулом было работать одно удовольствие.

Хорошо: взяли готовое решение, а не стали пилить что-то сами.

Для развёртывания изначально использовались bash скрипты.

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

Хорошо: быстро написать bash-скрипт, особых знаний не требуется.

Плохо: при переходе на нормальную систему деплоя пришлось выбросить практически всё ранее написанное.

Для общения между своими сервисами пробовали Rabbitmq. Но он просто так не в тему через несколько дней мог просто развалиться. В итоге, сделали по-простому – все сервисы взаимодействуют либо посредством чистых tcp-сокетов, или http-запросами с keep-alive, если нужно запросы слать только в одну сторону.

Хорошо: проанализировали альтернативы. Выбрали неплохое решение.

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

Игра онлайн, значит нужен чатик. Самим писать? Вряд ли оно будет масштабируемым. Давайте возьмём что-то готовое. XMPP? Ejabberd? Seems good. Вообще, пробовали и «ежа», и MongooseIM, но остановились в итоге на «еже». Были некоторые проблемы с поднятием оного на своих серверах (косяки с таймингами в сообщениях, краши и тому подобное). Решили использовать их облачное решение. Да, оно платное. Но работало без проблем.

Хорошо: проанализировали альтернативы. Выбрали подходящий вариант.

Плохо: вместо того, чтобы разобраться в локальных проблемах, решили использовать платное облачное решение. Тарифы там от 200 евро. Регионов у нас игровых было несколько. Для инди-команды это выходит в весьма существенную сумму, которую лучше было бы потратить на другие вещи.

На первых порах у нас вообще не было никакой системы по сбору метрик на серваках. Почему запрос тормозит? Что не так с сервисом? Сколько сейчас комнат свободных? Да, мы даже не могли посмотреть, сколько на данный момент свободных комнат!

Позже пришло осознание, что что-то нужно делать. Пробовали использовать Graphite + Grafana. Даже образ до докера делал со всем этим.

Но не сложилось. Не хотелось тратить на это время, решили воспользоваться готовым чем-то. Выбор пал на Datadog.

Всё отлично. Метрки, алерты, графики. Клиентский драйвер почти тот же самый, что и для графита. Красота. Но…Больше 10 долларов за каждый хост в месяц. Это выходит в более чем 200 долларов в месяц.

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

Хорошо: пробовали сами по-быстрому. Нашли альтернативу готовую. Осознали (хоть и поздно), что решение было ошибочным. Настроили удобную систему локально.

Плохо: как следует не разобрались в вопросе. Потратили много денег.

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

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

Игроки просили азиатский сервер и сервер в Южной Америке (до этого сервера были в Европе и США). Почему бы не сделать, да? Сделали. В итоге полтора юзера размазались по четырём регионам. Раз несколько регионов, то нужно сделать систему трансфера. Логично? Логично.

Хорошо: у пары человек стал лучше пинг.

Плохо: куча времени потрачено на создание регионов, системы трансфера и тому подобное.

Слушать советы и предложения игроков необходимо, но не следует сразу бежать и всё это реализовывать.

Раньше планеты выглядели вот так.

И нападения.

Переход на гексы упростил многие вещи технически. Плюс выглядеть это стало куда лучше, проще работать с элементами игровыми.

Раньше выглядело так.

Сам апгрейд осуществлялся за камни, которые падали из сундуков. Всё было неочевидно, запутанно.

В итоге заменили систему камней на свитки как в Clash Royale.

Для улучшения заклинания нужно определённое количество свитков. Всё просто и понятно.

Хорошо: заметили проблемное место и переделали.

Плохо: изначально не проанализировали, как это воспримут игроки. Многие вещи, очевидные для разработчиков, игроки воспринимают совсем по-другому. Поэтому, фидбек нужно собирать на как можно ранних этапах, устраивать плейтесты и так далее.

Мы даже договорились с Twitch, чтобы на странице игры можно было совершать внутриигровые покупки.

Но так как нашу игру никто не стримил, то смысла в таком решении вообще было ноль.

Хорошо: потенциальное место для честного отъёма денег у игроков.

Плохо: если вашу игру не стримят, то смысла в этом нет никакого. Просто впустую потрачено время.

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

В таком проекте сложно не наделать багов. Было много относительно безобидных GUI-багов.

Были баги посерьёзнее, например, когда игроки моментально умирали в центре арены. Повторить этот баг мы так и не смогли локально. Он периодически происходил у игроков, но мы так и не смогли его починить.

Забавный баг, когда при переключении персонажа не удалялась моделька предыдущего. В итоге можно было устроить пати хард.

Были и баги, связанные с платформой и движком.

К примеру, иногда всё GUI могло просто пропасть. Но если зайти в иерархию объектов и просто кликнуть по объекту, то оно снова появлялось.

Мы про эту проблему репортили Unity. Они ответили, что могут нам выделить сотрудника для помощи за 10 тысяч долларов в месяц.

На платформе Facebook Gameroom была проблема со скейлом, когда игра реагировала на тачи не в том месте, где они были совершены.

Это, уже не говоря про баги в различных библиотеках. К примеру, на некоторых машинах Steamworks.NET мог падать.

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

Особо никто не занимался контент-менеджментом и общением с игроками, не было никаких рассылок.

Во время разработки было потеряно много времени при выборе и апробации различных технологий.

Не было чёткого плана по реализации фич и контента.

В общем-то, большая часть всех этих проблем из-за неопытности.

Unnyworld был закрыт. Мы решили сделать проект поменьше в рамках текущих возможностей. Сейчас работаем над айдлером Hero Masters. Будем рады новым бета-тестерам и любому фидбеку.

В данный момент в поиске издателя или инвестора.

В рамках одной статьи всё не охватить. А то, о чём написал, для постороннего читателя может показаться каким-то бессвязным набором фактов. К сожалению, я не мастак подобные тексты писать.

Если есть какие-то вопросы, то с радостью отвечу либо в комментариях, либо в новой статье.