На каком движке сделана лига легенд
Обновлено: 04.07.2024
Привет, дорогой друг. Я предлагаю сегодня поставить все точки над i и разобрать главные отличия масштабного тайтла leagues of legends Wild Rift, выход которого состоится уже через несколько дней и закрепивший себя проект Mobile Legends beng beng, покорившей сердца миллионов игроков. И прежде чем я начну, напиши, как ты считаешь, за какой игрой стоит будущее . Ну а я призываю дух лайчинского и силу подписотного, и желаю всем приятного прочтения. Погнали разбирать.
Moonton, разработавшие Mobile Legends уже не первый раз стали на тропу войны за плагиат. И кто бы что не говорил, мол чемпионы же отличаются, артефакты другие, да и вообще здесь продвинутая система эмблем, всё это полная ерунда. Образы героев, как и анимация заклинаниявзята у старшего преемника и немного переделана под свой личный лад, и лад мобильных устройств. Взгляни на очевидные сравнения героев из обеих версий, думаю тут не нужно быть бывалым игрокам, чтобы с первого взгляда уловить сходство . Но заслуживает ли мобла своего места, и зачем же играть в копию, если можно насладиться оригиналом? Давайте разбираться.
Частота выхода обновлений, это либо слабое место, либо наоборот, показатель заботы об игроках. Если по мобильной лиги легенд рано судить, так как в ней нет и половины контента, то вот мобла уже несколько лет зарекомендовала себя, как что-то нестабильное, лично для меня. Да, сами патчи выходят достаточно часто примерно раз в 2 недели,но вот всегда чего-то не хватает, знаешь, как будто бы испек красивый сочный торт, а вишенкой украсить забыл.
Каждый второй чемпион постоянно получается имбалансным,причем как в сильную, так и в слабую сторону. А про последние масштабное обновление я вообще молчу, оно внесло рекордное количество багов в игру. Ну а что касается лиги легенд, то тут опираться можно лишь на пк-версию, патчи выходят также примерно раз в 2 недели, если в нем присутствует критические ошибки, то сразу происходит откат. Но лично меня поражает синхронность этих обновлений, весь игровой сезон мы заботимся о балансе, внедряем косметические штучки и небольшие исправления, а в межсезонье выпускаем масштабный патч, чтобы обычный игрок успел адаптироваться к началу ранговых игр. Все сделано по графику, по-людски что ли. Ивы скажете, но ведь у write games есть намного больше сотрудников и возможности куда выше, да, наверняка эти факторы влияют на разработку, но тут вопрос самого подхода, который riot games правильно применяют и по сей день.
Рекомендую к прочтению Гайд на кайсу
Что в лиге легенд, что в мобле подготовка к игре не менее важна, чем сам процесс боя. Необходимо приобрести любимого чемпиона, оборудовать его закупом, разобраться в рунах и дополнительных заклинаниях, и хотя в Wild Riftnесть еще неизвестные нам нюансы, можно смело предполагать, что ценообразования в обеих играх находится примерно на одном уровне.
Все персонажи и скины плюс-минус будут стоить одинаково, но вот с рунами имеется существенная разница. Руны, или как их называют в MobileLegends эмблемы, это пассивные эффекты, которые слегка меняют твой стиль игры за чемпиона, усиливая его особенности или характеристики. Одни руны позволяютбыстрее перемещаться, другие усиливают твои умения и так далее. В Wild Rift чтобы воспользоваться полным функционалом рун, тебе необходимо лишь прокачивать уровень своего аккаунта, то есть по сути просто играть. И уже на начальной стадии открыт частичный функционал,выбираешь лишь рекомендованный и вперед сражаться. А вот в мобле, для того чтобы полностью вкачать страницыэмблем, необходимо потерять кучу сил и времени, мало того что бесплатная добыча рун ничтожно мала и рандомна, так еще и её полное изучение стоит столько же, сколько покупка одного, а то и нескольких чемпионов и это лишь одна страница на определенный класс персонажей.
Я активно играю больше года, и у меня до сих пор не вкачены даже половина страниц. То есть новичок, попавший в обычный бой, будет испытывать огромные проблемы с балансом, так как у соперника будут намного лучше характеристики атаки,здоровья и другие. А это все существенно влияет на геймплей и баланс в целом. Так что судите сами, но для меня это очевидный минус, переходящий на следующую тему геймплея.
Я не буду детализировать мелкие различия на карте и его лесных обитателей, но зато затрону отличительные особенности поведения чемпионов. Во-первых, байл дрифт использует больше боевых активностей, но например некоторые успели заметить, что у каждого героя 4 боевых умения, вместо трех, а в магазинах активных артефактов гораздо больше. Влияет ли это на геймплей?
Безусловно, имея дополнительный контроль или хилку, ты можешь повлиять на исход боя. А вот второе и сразу третье отличиеменяет всю динамику игры. В лиге легенд необходимо уделять большое внимание добиванию крипов, чтобы заработать голду, а предметы можно покупать только лишь на базе, в то время как в мобле, даже проходя мимо миньонов голдишка сыпет на ура, а артефакты приобретаются в любой точке карты.
Но именно эти аспекты влияют на фазу лейта, что впоследствии переходит в общую продолжительность игры. По усредненным данным закрытого бета-тестирования в Wild Rift время партии доходит до 15-20 минут, в то время как в мобле эти показатели составляют 10-12 минут, что на 30, а то и на 40 процентов времени меньше затрат, а значит и меньше сил на погружение в игру, причем чем быстрее партия, тем больше динамичности она выдает. Тут онечно спорная тема, кого-товроде меня заинтересует более легкий и быстрый вариант ведения боя, а кого-то наоборот заманят скиловые ипроработанные возможности геймплея, выбирать опять же вам.
Баланс всегда является ахиллесовой пятой любого проекта,тем более от таких как моба игры, и тут между конкурентами снова значимая разница. Как я и говорил до этого, компания rite games зачастую делает упор на общение с аудиторией, в то время как monton games взаимодействует со статистикой серверов, плюс акцентирует внимание на играх профессиональных команд. С одной стороны это неплохо, но вот как привлечение новых игроков работает почти в нулину. Сейчас я обращаюсь к игрокам MobileLegends c повторным вопросом, напишите в комментариях хотя бы двух последних вышедших героев, которые бы не являлись имбалансными. Почему то мне кажется, что таких вовсе не сыскать. Ну и главные проблемы моблы является сетевое соединение. Чтобы разрабы не говорили, как бы ни пытались побороть проблемы с серверами, но как были лаги два года назад, так они остались, причем появляются тупо на ровном месте. Не хочу уповать на то, что в LOLe не будут присутствовать подобные проблемы, но все же самиrite games говорили о том, что готовы лишний раз провести дополнительное тестирование, прежде чем донести все это до игроков. Выводы делайте сами.
Есть координальные отличия? Я вам отвечу так, лично для меня играть в wild rift намного приятнее. Вот знаешь, такое понятие, как тактильные игровые ощущения, когда ты нажимаешь одно действие за другим в быстром порядке и все работает так, как надо. Здесь не чувствуется этих микро задержек, все происходит с той плавностью, с которой ты и задумал , понимаешь? В то время как в Mobile Legends с самого старта игры так и не поборолись задержкой. А ещё в последнее время меня дико раздражает показ рекламных объявлений при заходе в игру, ну комон, ну выложите пару-тройку уведомлений и все, но нет, я насчитывал одиннадцать или двенадцать выскакивающих событий. Вы что издеваетесь? Я вообще-то поиграть пришел. В общем друзья, хотя мобла и имеет свои недостатки, играть в неёможно и даже нужно. Тут скорее дело личных интересов и привычки. Ну а на этом всё. Если вам понравилась эта статья, то лайчинский и подписонский ждут тебя прямо под статьей.
Brian «Penrif» Bossé (Tech Lead) решил поделиться мыслями об игровом движке Лиги Легенд и о том, как они принимают решения о направлении развития оного.
Существует множество направлений, в которых можно развивать движок – производительность, поддержка различных платформ, графика и т.д. В частности, в данной статье рассматривается то, как движок отражает сложность игр, реализованных на нём.
В бородатые годы в играх не было особой сложности. Они были очень просты, разрабатывались небольшими командами — часто вообще одним человеком — и за небольшой промежуток времени. По мере того, как машины становились мощнее, а ожидания игроков росли, сложность разработки также возросла. Индустрия пошла по пути, установленному Daft Punk, и ставила более сложные цели, лучшие инструменты, ускорение итераций и более…что-то там ещё. В любом случае, отрасль реагировала на эту сложность по-разному, и мало что было настолько же эффективно, как внедрение языков программирования более высокого уровня – скриптовые языки различных форм и размеров.
Где движок проводит границу между своим высокопроизводительным ядром и визуальным программирование, определяет его сложность. У вас может быть навороченный движок со сложным высокопроизводительным ядром, или же лёгкое ядро, а большая часть сложности в скриптах, ну или где-то посередине. Давайте кратко поговорим о крайностях, а затем перейдём к тому, как это относится к Лиге.
В случае с тяжёлым движком высокоуровневое программирование больше похоже на настройку, чем на, собственно, программирование. Объекты и методы, торчащие наружу, сильно абстрагированы, а их взаимодействие полностью контролируется. Если концепции движка хорошо соотносятся с потребностями игры, подобный путь подходит идеально — программисты управляют сложностью объектов и их взаимодействием, а геймдизайнеры получают песочницу с надёжными игрушками, которые легко приспособить под их прихоти. Однако если концепции не соответствуют друг другу — ждите беды.
В этом случае у вас минималистичное ядро, которое предоставляет очень простые объекты для скриптинга. Сложность использования остаётся за языком более высокого уровня, и большинство вещей в основном реализованы, если не полностью, на языке сценариев. Только критичные по производительности вещи перенесены в ядро, такие как физика и рендеринг. Сложность можно укротить с помощью программных конструкций более высокого уровня, особо не жертвуя при этом производительностью.
Определив, что оба подхода могут работать в том или ином случае, плохая новость в том, что Лига прочно обосновалась между этими двумя крайностями.
Это не самая лучшая позиция. Основное ядро предоставляет скриптовому движку как высокоуровневые конструкции, так и низкоуровневые примитивы. Язык сценариев сам по себе прост, предоставляет лишь базовые конструкции, чего и следовало ожидать от языка, работающего поверх навороченного движка, но разработчики создали сложные системы поверх него. История подобного выбора тянется далеко в прошлое, когда Брайан ещё не работал в Riot. Насколько он может судить, движок изначально был довольно легковесным, но в стремлении ускорить процесс разработки, было сделано достаточно компромиссов, вследствие чего движок уже нельзя было считать легковесным.
В нынешнем виде все части движка усложнены, и лучше бы команде выбрать один из двух стульев.
Если Лига пойдёт по этому пути, необходимо несколько важных переходов перед этим.
Другой важный переход – перевод многих существующих игровых систем, в настоящее время написанных на C++, на язык более высокого уровня, оставив только высокопроизводительное ядро. Простые действия, происходящие довольно часто, останутся в ядре, в то время как функции с большей сложностью будут вынесены из него. Например, миньоны часто пересчитывают свой путь, и их довольно много. Простая логика, которая выполняется довольно часто, поэтому останется в ядре. С другой стороны, использование заклинаний чемпионами – довольно сложная штука — множество логики вокруг мгновенного каста заклинаний, во время движения или ченнелинга — там всё сложно. Происходят они не часто, так как большинство способностей имеют существенное время перезарядки, поэтому стоимость перемещения этой сложности низка.
Эти переходы позволили бы реализовать игру, над которой гораздо проще и быстрее работать – hot-reload для кода, тоже самое и для ассетов, что существенно ускорит итерации. Наличие полнофункционального языка программирования уменьшит боль в поиске «креативных» решений для выражения игрового процесса, которые не совсем соответствуют конструкциям движка. За небольшую скорость выполнения мы получили бы скорость разработки, хорошо поддерживаемую среду разработки для всех аспектов программирования и большую часть сложности, заключенную в одной экосистеме, а не разделённой. Это компромисс, на который следует пойти.
Сегодня у Лиги значительная сложность лежит именно в сценариях. Реализация очередей заклинаний, ручное управление анимациями и VFX и т.п. Логика классификации объектов часто реализуется поверх классификаций, уже присутствующих в движке — например, проверка, является ли миньон на самом деле цветком персонажа Zyra. Движение по этому пути означает перенос большей части этой сложности в движок, который, в свою очередь, предоставит богатые существительные и глаголы высокого уровня с простыми, но достаточными логическими конструкциями для их связи. Эта реализация позволила бы нетехническим специалистам овладеть всей мощью движка, не испытывая проблем со сложностью. Инженерам будет сложнее работать с движком, но всё это будет в собственном окружении вместо того, чтобы требовать от разработчиков постоянного переключения между кодом и скриптами для полного понимания реализации.
Переход к тяжеловесному движку должен привести к резкому сокращению размера и объёма сценариев. Скорее всего, сам язык сценариев сократится, и низкоуровневые конструкции будут заменены. Например, когда была добавлена конструкция для запуска события в момент захода юнита в геометрическую область, потребность в конструкции ForEachUnitInTargetArea значительно снизилась. В результате многие из этих низкоуровневых запросов и низкоуровневых действий станут излишними и должны будут удалены из производства. Они всё ещё будут использоваться при прототипировании, т.к. ожидание реализации подобных вещей в движке может затянуться.
В скриптах, по сути, останется лишь реализация уникального геймплея. Разработчики будут проводить большую часть своего времени, программируя на C ++, предоставляя новые существительные и глаголы для использования в сценариях. Это смещение фокуса позволило бы дизайнерам гораздо меньше беспокоиться о деталях реализации, сохраняя при этом их способность настраивать пользовательский опыт. Потребовалось бы немало усилий на этом пути, но оно бы того стоило.
Оба этих варианта имеют существенные преимущества по сравнению с нынешней ситуацией, так к чему стремиться? Брайан топит за легковесное ядро. Чёткое разделение на «нужна скорость» и «должно быть выразительным» очень полезно, что позволит двигать системы через эту границу, когда производительность становится более важной, чем выразительность и visa-versa.
Вернёмся к реальности. Нашим основным соображением должен быть набор навыков наших разработчиков и то, насколько хорошо они соответствуют двум альтернативам. В команде есть группа сильных сишников, некоторые из которых имеют большой опыт работы с языками более высокого уровня, но не все. Есть много не технорей (дизайнеры и художники), которые научились манипулировать текущим скриптовым решением, но полностью выпадут из цикла даже в безупречно настроенной Python среде.
Это всё ведёт к пути с навороченным движком. Можно было бы пойти по другому пути и переобучить всех для работы с легковесным движком, но это чрезвычайно дорого по времени и усилиям. Это также может привести к тому, что некоторые очень талантливые разработчики подыщут себе другое место. Поскольку оба варианта значительно лучше текущего, нет смысла плыть по течению. Команда будет стараться изо всех по направлению к тяжеловесному движку.
Движение в сторону тяжеловесного движка (и явно в противоположную от легковесного) обеспечит более надёжную опору для возрастающей сложности Лиги. Если споры такого рода вам по душе, вы C++ ниндзя и балдеете от этого языка, команда с радостью рассмотрит вашу кандидатуру.
Сегодня компания Unity Technologies объявила о том, что Riot Games выбрала Unity для управления играми Legends of Runeterra и League of Legends: Wild Rift. Таким образом, Riot Games хочет подарить богатый мир League of Legends большему количеству игроков на различных платформах.
Брайан Чо, глава отдела корпоративного и делового развития Riot Games, сказал:
Технология Unity позволяет нам сосредоточиться на предоставлении любимого опыта League of Legends как можно большему числу игроков на максимально возможном количестве платформ. Мы хотим встретиться с нашими игроками там, где они есть, и инструменты Unity мирового класса и оптимизация платформы помогают нам достичь этого. Благодаря экспертной поддержке, предоставляемой Unity, мы смогли раскрыть всю мощь технологий Unity, как никогда раньше.
глава отдела корпоративного и делового развития Riot GamesДанн Вебстер, ведущий инженер, Legends of Runeterra, добавил:
С самого начала мы хотели, чтобы Legends of Runeterra были доступны как для ПК, так и для мобильных устройств. Таким образом, Unity была очевидным выбором. Мы в значительной степени полагались на профессиональную команду обслуживания Unity с ее постоянной поддержкой и рекомендациями по производительности; они были абсолютно неотъемлемой частью постоянного развития нашей игры.
Франшиза League of Legends насчитывает миллионы игроков в более чем 150 странах мира. Работа с Unity и ее командой профессионального сервиса, позволяет Riot Games еще больше охватить игроков, на более чем 20 платформах, учитывая что игроки общаются в игре, используя голосовой чат Vivox, часть набора инструментов Unity.
Ральф Хауверт, вице-президент по исследованиям и разработкам Unity Technologies, пришел к выводу:
Мы сосредоточены на предоставлении решений и технологий, которые позволяют разработчикам погрузить своих игроков в фантастические миры и дать богатый опыт. Riot Games создала волшебную вселенную League of Legends, и наши технологии помогут им познакомить с игрой еще большее количество игроков на различных платформах.
Brian «Penrif» Bossé (Tech Lead) решил поделиться мыслями об игровом движке Лиги Легенд и о том, как они принимают решения о направлении развития оного.
Существует множество направлений, в которых можно развивать движок – производительность, поддержка различных платформ, графика и т.д. В частности, в данной статье рассматривается то, как движок отражает сложность игр, реализованных на нём.
Типы сложности
В бородатые годы в играх не было особой сложности. Они были очень просты, разрабатывались небольшими командами — часто вообще одним человеком — и за небольшой промежуток времени. По мере того, как машины становились мощнее, а ожидания игроков росли, сложность разработки также возросла. Индустрия пошла по пути, установленному Daft Punk, и ставила более сложные цели, лучшие инструменты, ускорение итераций и более…что-то там ещё. В любом случае, отрасль реагировала на эту сложность по-разному, и мало что было настолько же эффективно, как внедрение языков программирования более высокого уровня – скриптовые языки различных форм и размеров.
Где движок проводит границу между своим высокопроизводительным ядром и визуальным программирование, определяет его сложность. У вас может быть навороченный движок со сложным высокопроизводительным ядром, или же лёгкое ядро, а большая часть сложности в скриптах, ну или где-то посередине. Давайте кратко поговорим о крайностях, а затем перейдём к тому, как это относится к Лиге.
Крайность с навороченным движком
В случае с тяжёлым движком высокоуровневое программирование больше похоже на настройку, чем на, собственно, программирование. Объекты и методы, торчащие наружу, сильно абстрагированы, а их взаимодействие полностью контролируется. Если концепции движка хорошо соотносятся с потребностями игры, подобный путь подходит идеально — программисты управляют сложностью объектов и их взаимодействием, а геймдизайнеры получают песочницу с надёжными игрушками, которые легко приспособить под их прихоти. Однако если концепции не соответствуют друг другу — ждите беды.
Крайность с легковесным движком
В этом случае у вас минималистичное ядро, которое предоставляет очень простые объекты для скриптинга. Сложность использования остаётся за языком более высокого уровня, и большинство вещей в основном реализованы, если не полностью, на языке сценариев. Только критичные по производительности вещи перенесены в ядро, такие как физика и рендеринг. Сложность можно укротить с помощью программных конструкций более высокого уровня, особо не жертвуя при этом производительностью.
А что же с Лигой?
Определив, что оба подхода могут работать в том или ином случае, плохая новость в том, что Лига прочно обосновалась между этими двумя крайностями.
Это не самая лучшая позиция. Основное ядро предоставляет скриптовому движку как высокоуровневые конструкции, так и низкоуровневые примитивы. Язык сценариев сам по себе прост, предоставляет лишь базовые конструкции, чего и следовало ожидать от языка, работающего поверх навороченного движка, но разработчики создали сложные системы поверх него. История подобного выбора тянется далеко в прошлое, когда Брайан ещё не работал в Riot. Насколько он может судить, движок изначально был довольно легковесным, но в стремлении ускорить процесс разработки, было сделано достаточно компромиссов, вследствие чего движок уже нельзя было считать легковесным.
В нынешнем виде все части движка усложнены, и лучше бы команде выбрать один из двух стульев.
Лига на пути к лёгкому движку
Если Лига пойдёт по этому пути, необходимо несколько важных переходов перед этим.
Другой важный переход – перевод многих существующих игровых систем, в настоящее время написанных на C ++, на язык более высокого уровня, оставив только высокопроизводительное ядро. Простые действия, происходящие довольно часто, останутся в ядре, в то время как функции с большей сложностью будут вынесены из него. Например, миньоны часто пересчитывают свой путь, и их довольно много. Простая логика, которая выполняется довольно часто, поэтому останется в ядре. С другой стороны, использование заклинаний чемпионами – довольно сложная штука — множество логики вокруг мгновенного каста заклинаний, во время движения или ченнелинга — там всё сложно. Происходят они не часто, так как большинство способностей имеют существенное время перезарядки, поэтому стоимость перемещения этой сложности низка.
Эти переходы позволили бы реализовать игру, над которой гораздо проще и быстрее работать – hot-reload для кода, тоже самое и для ассетов, что существенно ускорит итерации. Наличие полнофункционального языка программирования уменьшит боль в поиске «креативных» решений для выражения игрового процесса, которые не совсем соответствуют конструкциям движка. За небольшую скорость выполнения мы получили бы скорость разработки, хорошо поддерживаемую среду разработки для всех аспектов программирования и большую часть сложности, заключенную в одной экосистеме, а не разделённой. Это компромисс, на который следует пойти.
На пути к навороченному движку
Сегодня у Лиги значительная сложность лежит именно в сценариях. Реализация очередей заклинаний, ручное управление анимациями и VFX и т.п. Логика классификации объектов часто реализуется поверх классификаций, уже присутствующих в движке — например, проверка, является ли миньон на самом деле цветком персонажа Zyra. Движение по этому пути означает перенос большей части этой сложности в движок, который, в свою очередь, предоставит богатые существительные и глаголы высокого уровня с простыми, но достаточными логическими конструкциями для их связи. Эта реализация позволила бы нетехническим специалистам овладеть всей мощью движка, не испытывая проблем со сложностью. Инженерам будет сложнее работать с движком, но всё это будет в собственном окружении вместо того, чтобы требовать от разработчиков постоянного переключения между кодом и скриптами для полного понимания реализации.
Переход к тяжеловесному движку должен привести к резкому сокращению размера и объёма сценариев. Скорее всего, сам язык сценариев сократится, и низкоуровневые конструкции будут заменены. Например, когда была добавлена конструкция для запуска события в момент захода юнита в геометрическую область, потребность в конструкции ForEachUnitInTargetArea значительно снизилась. В результате многие из этих низкоуровневых запросов и низкоуровневых действий станут излишними и должны будут удалены из производства. Они всё ещё будут использоваться при прототипировании, т.к. ожидание реализации подобных вещей в движке может затянуться.
В скриптах, по сути, останется лишь реализация уникального геймплея. Разработчики будут проводить большую часть своего времени, программируя на C ++, предоставляя новые существительные и глаголы для использования в сценариях. Это смещение фокуса позволило бы дизайнерам гораздо меньше беспокоиться о деталях реализации, сохраняя при этом их способность настраивать пользовательский опыт. Потребовалось бы немало усилий на этом пути, но оно бы того стоило.
Так какой путь в итоге?
Оба этих варианта имеют существенные преимущества по сравнению с нынешней ситуацией, так к чему стремиться? Брайан топит за легковесное ядро. Чёткое разделение на «нужна скорость» и «должно быть выразительным» очень полезно, что позволит двигать системы через эту границу, когда производительность становится более важной, чем выразительность и visa-versa.
Вернёмся к реальности. Нашим основным соображением должен быть набор навыков наших разработчиков и то, насколько хорошо они соответствуют двум альтернативам. В команде есть группа сильных сишников, некоторые из которых имеют большой опыт работы с языками более высокого уровня, но не все. Есть много не технорей (дизайнеры и художники), которые научились манипулировать текущим скриптовым решением, но полностью выпадут из цикла даже в безупречно настроенной Python среде.
Это всё ведёт к пути с навороченным движком. Можно было бы пойти по другому пути и переобучить всех для работы с легковесным движком, но это чрезвычайно дорого по времени и усилиям. Это также может привести к тому, что некоторые очень талантливые разработчики подыщут себе другое место. Поскольку оба варианта значительно лучше текущего, нет смысла плыть по течению. Команда будет стараться изо всех по направлению к тяжеловесному движку.
Что дальше?
Движение в сторону тяжеловесного движка (и явно в противоположную от легковесного) обеспечит более надёжную опору для возрастающей сложности Лиги. Если споры такого рода вам по душе, вы C++ ниндзя и балдеете от этого языка, команда с радостью рассмотрит вашу кандидатуру .
Читайте также: