После закрытия нашей игры UnnyWorld многие разработчики знакомые просили написать постмортем по игре. Решил поделиться конкретными примерами, коих за время разработки накопилось приличное количество. Будут рассмотренные ошибки, которые мы допустили, постараюсь дать парочку полезных советов.
Ранее я публиковал статью «Три года разработки своей 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, чтобы на странице игры можно было совершать внутриигровые покупки.
Но т.к. нашу игру никто не стримил, то смысла в таком решение вообще ноль.
Хорошо: потенциальное место для честного отъёма денег у игроков.
Плохо: если вашу игру не стримят, то смысла в этом нет никакого. Просто впустую потрачено время.
На волне хайпа решили запилит такой режим в игре. Но т.к. онлайн в игре небольшой был, то в этом режиме были практически одни боты, что нивелирует всё на нет.
В таком проекте сложно не наделать багов. Было много относительно безобидных GUI багов.
Были баги посерьёзнее, например, когда игроки моментально умирали в центре арены. Повторить этот баг мы так и не смогли локально. Он периодически происходил у игроков, но мы так и не смогли его починить.
Забавный баг, когда при переключении персонажа не удалялась моделька предыдущего. В итоге можно было устроить пати хард.
Были и баги, связанные с платформой/движок.
К примеру, иногда всё GUI могло просто пропасть. Но если зайти в иерархию объектов и просто кликнуть по объекту, то оно снова появлялось.
Мы про эту проблему репортили Unity. Они ответили, что могут нам выделить сотрудника для помощи за 10к$ в месяц ლ(ಠ_ಠ ლ)
На платформе Facebook Gameroom была проблема со скейлом, когда игра реагировала на тачи не в том месте, где они были совершены.
Это, уже не говоря про баги в различных библиотеках. К примеру, на некоторых машинах Steamworks.NET мог падать github.com/rlabrecque/Steamworks.NET/issues/121.
Мы почти не вкладывались в маркетинг, надеялись, что будет органический приток игроков. Игра в итоге так и не достигла то критической массы, после которой бы не нужны были боты и был бы органический приток новых игроков.
Особо никто не занимался контент менеджментом и общением с игроками, не было никаких рассылок.
Во время разработки было потеряно много времени при выборе и апробации различных технологий.
Не было чёткого плана по реализации фич/контента.
В общем-то, большая часть всех этих проблем из-за неопытности.
Unnyworld был закрыт. Мы решили сделать проект поменьше в рамках текущих возможностей.
В рамках одной статьи всё не охватить. А то, о чём написал, для постороннего читателя может показаться каким-то бессвязным набором фактов. К сожалению, не мастак подобные тексты писать.
Если есть какие-то вопросы, то с радостью отвечу либо в комментариях, либо в новой статье.
Ранее я публиковал статью «Три года разработки своей 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 был закрыт. Мы решили сделать проект поменьше в рамках текущих возможностей.
В рамках одной статьи всё не охватить. А то, о чём написал, для постороннего читателя может показаться каким-то бессвязным набором фактов. К сожалению, не мастак подобные тексты писать.
Если есть какие-то вопросы, то с радостью отвечу либо в комментариях, либо в новой статье.
