Ранее я публиковал статью «Три года разработки своей MMO», где речь шла больше про поиск инвестиций, команду и наш путь к «успеху». К сожалению (или к счастью?), проект пришлось закрыть. В данной статье постараюсь рассмотреть допущенные ошибки и, возможно, дать хотя бы парочку полезных советов.
Про игру в двух словах
Условно Unnyworld можно разделить на две части: Сити билдер и Арены.
Часть про билдер – это некий Clash of Clans. У вас есть своя планета, которую необходимо обустраивать. И вы можете нападать на другие планеты, чтоб красть ресурсы.
Нападаете на других игроков вы одним из своих персонажей и сами им управляете.
Арены – типичная MOBA 3на3 с разными режимами (захват флага, захват точки и т.д).
У каждого персонажа свои спеллы, которые можно комбинировать с другими игроками.
Перед боем можно сменить заклинания.
Игровой цикл в целом выглядит так:
- Для прокачки спеллов нужны свитки, которые падают из сундуков. Сундуки можно получить различными бесплатными способами (за лигу, за победу в Бэтл Рояле и т.п.) или купить.
- Чтоб прокачать спелл, нужно построить и улучшить здание героя до определённого уровня.
- Для улучшения здания героя нужно улучшать другие здания (главное здание, алтарь и т.д.).
Т.е., мы пытались как-то увязать режим планеты и арен. Вероятно, мы делали всё не так.
Отсутствие чёткого плана и стратегии
Да, постоянно обсуждались многие вещи, но реализовывали их невпопад, основательно не проанализировав, что нужно делать в первую очередь.
Как следствие, пытались делать всё и сразу. Нужна ли система гильдий, когда в игре полтора пользователя? Хм, вряд ли.
Нужна ли система, позволяющая создать кастомный матч, приглашая туда друзей и согильдейцев, когда в игре маленький CCU? Не уверен.
В процессе разработки мы много чего пытались сделать того, что, вероятно, не нужно было делать на том этапе. Как следствие, не были реализованы по-настоящему необходимые вещи.
Отсутствие опыта
Т.к. раньше мы работали преимущественно лишь с синглплей играми, то наступили на большое количество грабель при выборе той или иной технологии.
Поговорим немного о технической части вопроса.
Выбор технологий
Небольшое уточнение. По больше части мы чисто клиентские разработчики. Из всей команды только у пары человек был опыт работы с серверными технологиями. Про админство я вообще молчу. Постараюсь по конкретным технологиям пройтись с небольшим summary по каждой.
Какой облачный провайдер использовать? AWS? Azure? Soft Layer?
На тот момент принципиальной разницы не было. Плюс, у нас был кредит на SoftLayer как стартапу.
Oh, boi, если бы вы только знали, как там всё плохо:
— Сапорт особо не разбирается в проблеме. Были случаи, когда я к ним обращался по поводу проблемы на определённой виртуалке (не мог приконнектиться и т.п.). На что получал ответ:
Мы ребутнули машину, теперь всё норм
— Были случаи, когда виртуалка поднималась часами. Как видите, я прождал 4 часа, а виртуалка так и не создалась.
— Частые maintance.
— Бывает, что без предупреждений ребутнут машину, или приватную сеть отрубят.
В итоге перешли на Azure. Таких проблем не было. Сапорт быстро отвечает и всегда помогает в случае чего.
Хорошо: —
Плохо: не проанализировали как следует все возможные варианты. А ведь сервера – это важнейшая часть для онлайн игры =/
Итак, вам нужно на сервере как-то запускать игровые инстансы, через какую-то систему API перекидывать после авторизации игрока на нужный инстанс. Что же будем делать? А давайте возьмём готовое решение, которое будет само в зависимости от нагрузки менеджить это дело. Ого, тут вон есть штука, называемая Kubernetes. Правда она в бете…Но всё равно, давайте попробуем!
Если отбросить тот факт, что для работы с этой технологией нужен опыт, то даже при базовой настройке этого дела оно умудрялось падать. Какие-то сервисы отваливались и т.п.
Ну ладно, а что ещё есть? Mesosphere и Apache Mesos! С ним всё тоже самое, без опыта сложно. Если что-то отваливается, то без бубна не исправить проблему.
В итоге написали всё сами. Инстансы стартуются супервизором, как и небольшой менеджер над ними (написанный на Java). Java приложение ttl’ит в сервис дискавери тулзу о статусе (количество свободных комнат на инстансах и т.п.). При авторизации и запросе на создание комнаты к API по этой информации об инстансах запрос уходит на нужную ноду, которая на нужном инстансе поднимает комнату.
Т.е. инстансы всегда предзапущены. При нехватке мы поднимаем новую VPS.
Хорошо: проанализировали альтернативы.
Плохо: потратили много времени на протип. Для первой версии нужно было вообще не думать об этих вещах, а просто стартовать инстансы без всяких апликух поверх. Можно было прям захардкодить адреса инстансов на клиенте в прототипе.
Для сервис дискавери использовали www.consul.io Это, вероятно, одно из тех решений, о котором не пожалели. Там, правда, бывают проблемы вроде таких, когда при ребуте ломается конфиг. Но это редко и при незапланированном ребуте машины. В целом, за всё время с консулом было работать одно удовольствие.
Хорошо: взяли готовое решение, а не стали пилить что-то сами.
Для развёртывания изначально использовались bash скрипты.
Позже я перевёл весь деплой на Ansible. Не могу нарадоваться и по сей день. Были, безусловно, проблемы на первых порах. Но система довольно проста в изучении, да и документации навалом.
Хорошо: быстро написать bash скрипт, особых знаний не требуется.
Плохо: при переходе на нормальную систему деплоя пришлось выбросить практически всё ранее написанное.
Для общения между своими сервисами пробовали www.rabbitmq.com. Но он просто так не в тему через несколько дней мог просто развалиться. В итоге сделали по-простому – все сервисы взаимодействуют либо посредством чистых tcp сокетов, или http запросами с keep-alive, если нужно запросы слать только в одну сторону.
Хорошо: проанализировали альтернативы. Выбрали неплохое решение.
Плохо: отсутствие опыта работы с технологией. Не нужно в продакшн тащить вещи, которые вы не сможете починить в случае проблем.
Игра онлайн, значит нужен чатик. Самим писать? Вряд ли оно будет масштабируемым. Давайте возьмём что-то готовое. XMPP? Ejabberd? Seems good. Вообще, пробовали и ежа, и MongooseIM, но остановились в итоге на еже. Были некоторые проблемы с поднятием оного на своих серваках (косяки с таймингами в сообщениях, краши и т.п.). Решили использовать их облачное решение ejabberd-saas.com. Да, оно платное. Но работало без проблем.
Хорошо: проанализировали альтернативы. Выбрали подходящий вариант.
Плохо: вместо того, чтобы разобраться в локальных проблемах, решили использовать платное облачное решение. Тарифы там от 200 евро. Регионов у нас игровых было несколько. Для инди команды это выходит в весьма существенную сумму, которую лучше было бы потратить на другие вещи.
На первых порах у нас вообще не было никакой системы по сбору метрик на серваках. Почему запрос тормозит? Что не так с сервисом? Сколько сейчас комнат свободных? Да, мы даже не могли посмотреть, сколько на данный момент свободных комнат!
Позже пришло осознание, что что—то нужно делать. Пробовали использовать Graphite + Grafana. Даже образ до докера делал со всем этим: github.com/Suvitruf/docker-grafana-graphite-diamond
Но не сложилось. Не хотелось тратить на это время, решили воспользоваться готовым чем-то. Выбор пал на www.datadoghq.com
Всё отлично. Метрки, алерты, графики. Клиентский драйвер почти тот же самый, что и для графита. Красота. Но…10+$ за каждый хост в месяц. Ииии…это выходит в 200+$ в месяц.
Осознание того, что мы просрали на это кучу денег, прошло слишком поздно. Решили, всё же, на своих серверах это делать. Настроили www.influxdata.com. В итоге одна машина за пару десятков баксов спокойно обрабатывает метрики с десятков/сотен машин.
Хорошо: пробовали сами по-быстрому. Нашли альтернативу готовую. Осознали (хоть и поздно), что решение было ошибочным. Настроили удобную систему локально.
Плохо: как следует не разобрались в вопросе. Потратили много денег.
Касательно метрик, такая же проблема и с производительностью. На первых порах мы особо ни клиент, ни сервер на профайлерели. В итоге, слишком поздно обнаружили утечки памяти на серверных инстансах игры. Определить и починить оперативно не смогли. В итоге написали так, что после создания определённого количества комнат инстанс игровой перезапускается.
Немного про концептуальные и ГД решения
Я не могу сейчас уже выстроить правильный порядок по времени всех этих событий, назову кое-какие ключевые решения, которые мы приняли.
Разделение игры по регионам
Игроки просили азиатский сервер и сервер в Южной Америке (до этого сервера были в Европе и США). Почему бы не сделать, да? Сделали. В итоге полтора юзера размазались по 4 регионам. Раз несколько регионов, то нужно сделать систему трансфера. Логично? Логично.
Хорошо: у пары человек стал лучше пинг (｡•́︿•̀｡)
Плохо: куча времени потрачено на создание регионов, системы трансфера и т.п.
Слушать советы/предложения игроков необходимо, но не следует сразу бежать и всё это реализовывать.
Замена квадратной сетки на гексы и переделка нападений на планеты
Раньше планеты выглядели вот так:
И нападения:
Переход на гексы упростил многие вещи технически. Плюс выглядеть это стало куда лучше, проще работать с элементами игровыми.
Переделана система заклинаний
Раньше выглядело так:
Сам апгрейд осуществлялся за камни, которые падали из сундуков. Всё было неочевидно, запутанно.
В итоге заменили систему камней на свитки как в Clash Royale.
Для улучшения заклинания нужно определённое количество свитков. Всё просто и понятно.
Хорошо: заметили проблемное место и переделали.
Плохо: изначально не проанализировали, как это воспримут игроки. Многие вещи, очевидные для разработчиков, игроки воспринимают совсем по-другому. Поэтому, фидбек нужно собирать на как можно ранних этапах, устраивать плейтесты и т.д.
Покупки на Твиче
Мы даже договорились с www.twitch.tv, чтобы на странице игры можно было совершать внутриигровые покупки.
Но т.к. нашу игру никто не стримил, то смысла в таком решение вообще ноль.
Хорошо: потенциальное место для честного отъёма денег у игроков.
Плохо: если вашу игру не стримят, то смысла в этом нет никакого. Просто впустую потрачено время.
Battle Royale режим
На волне хайпа решили запилит такой режим в игре. Но т.к. онлайн в игре небольшой был, то в этом режиме были практически одни боты, что нивелирует всё на нет.
Про баги
В таком проекте сложно не наделать багов. Было много относительно безобидных GUI багов.
Были баги посерьёзнее, например, когда игроки моментально умирали в центре арены. Повторить этот баг мы так и не смогли локально. Он периодически происходил у игроков, но мы так и не смогли его починить.
Забавный баг, когда при переключении персонажа не удалялась моделька предыдущего. В итоге можно было устроить пати хард.
Были и баги, связанные с платформой/движок.
К примеру, иногда всё GUI могло просто пропасть. Но если зайти в иерархию объектов и просто кликнуть по объекту, то оно снова появлялось.
Мы про эту проблему репортили Unity. Они ответили, что могут нам выделить сотрудника для помощи за 10к$ в месяц ლ(ಠ_ಠ ლ)
На платформе Facebook Gameroom была проблема со скейлом, когда игра реагировала на тачи не в том месте, где они были совершены.
Это, уже не говоря про баги в различных библиотеках. К примеру, на некоторых машинах Steamworks.NET мог падать github.com/rlabrecque/Steamworks.NET/issues/121.
Итоги
Мы почти не вкладывались в маркетинг, надеялись, что будет органический приток игроков. Игра в итоге так и не достигла то критической массы, после которой бы не нужны были боты и был бы органический приток новых игроков.
Особо никто не занимался контент менеджментом и общением с игроками, не было никаких рассылок.
Во время разработки было потеряно много времени при выборе и апробации различных технологий.
Не было чёткого плана по реализации фич/контента.
В общем-то, большая часть всех этих проблем из-за неопытности.
Что дальше?
Unnyworld был закрыт. Мы решили сделать проект поменьше в рамках текущих возможностей.
В рамках одной статьи всё не охватить. А то, о чём написал, для постороннего читателя может показаться каким-то бессвязным набором фактов. К сожалению, не мастак подобные тексты писать.
Если есть какие-то вопросы, то с радостью отвечу либо в комментариях, либо в новой статье.
Источник
