Друзья!
Не так давно была опубликована увлекательная история, посвященная созданию рейдовых приключений в «Аллодах Онлайн». Сегодня мы представляем вашему вниманию вторую часть этого рассказа, написанного Аркадием Буяком, дизайнером игровой механики из студии Allods Team.
Итак, из первой части мы узнали, что рейды начинаются со сценарной и артовой подготовки. После этого разработчики плавно подходят к написанию дизайна боссов - тут-то и начинается самое интересное...
Наступает время войны. Войны «новинок» против «костылей». Звучит круто, кто же спорит. Так вот, все новое – это не хорошо забытое старое; это дни, а иногда и недели работ программистов разных команд (да-да, программисты бывают разные). Далеко не всегда целесообразно создавать какие-то новые сущности. Иногда это очень дорого по ресурсам, иногда – просто нереализуемо на движке. Всякое бывает.
В такие моменты на помощь приходит самый страшный грех разработчика – костыль. Костылями мы называем конструкции, которые нетривиальным и порой не очень красивым способом решают задачи, которые на обычной механике и обычными методами решить невозможно. Чаще всего костыли приходится добавлять для визуальных составляющих.
Самым хорошим примером такой ситуации может служить искра на третьей фазе Морока. Как это выглядит в жизни – искра вылетает из разбитого генератора, попадает в первую иллюзию, разрушает ее, попадает во вторую иллюзию, разрушает ее и так далее. Вроде все просто.
Но на самом деле все не так. Достаточно сложно запускать визуал (искру) с одного существа на другое (и так несколько раз подряд) в ситуации, когда они никак друг с другом не связаны. Когда одна сущность запускает заклинание в другую – тут все просто и понятно. А когда из воздуха надо взять да и отправить что-то куда-то – тут, извините, надо попотеть. На нормальную работу этой искры у меня ушло около 2 недель.
Периодически приходится менять и переписывать дизайн из-за нестыковок с возможностями. Это еще одна серьезная вещь, которую надо учитывать при дизайне – возможности движка, механики. Что-то может не поддерживаться, а что-то просто сильно нагрузит клиент и приведет к лагам.
Заказ FX – это последняя (на самом деле не совсем последняя, есть еще озвучка и музыка, но это уже потом) часть, которую нужно заказать, и которая не зависит лично от меня. Все, что начинается после – целиком и полностью моя работа, моя забота, печаль и радость. Ибо приходит время игровой механики.
Что из себя вообще представляет механика? Грубо говоря – это набор команд, поддерживаемых сервером и клиентом, которые определяют поведение мобов, содержание их спелов и способностей, их действия и все-все-все.
Если нет механики, то каким бы красивым и привлекательным не был моб, какие бы замечательные заклинания у него не были – ничего работать не будет. Даже не так. Просто – ничего не будет. Поэтому работы по механике – самая главная, самая сложная часть. Именно здесь рождаются и уничтожаются толпами разные баги, глюки, пробелы. Механика – ядро игры.
Работы по механике идут очень долго. Усложняются они все по тем же причинам – в рейдах применяется более сложная механика. При этом с каждым новым рейдом обязательно появляется и создается что-то, чего до этого момента никто и никогда не делал. И приходится изобретать, проявлять фантазию, пить кровь программистов сервера, поедать мозги программистов клиента. Здорово, одним словом.
Чтобы понять, что в общих чертах собой представляет механика, разберем простой пример – огненный шар мага. Это заклинание с определенной дальностью каста (пусть будет 40), определенным визуалом, кастуется в одну цель, наносит ей огненный урон. В редакторе это выглядит примерно так:
Достаточно просто и понятно, да? А теперь представьте себе, например, спелл, который кастуется только на цели, у которых здоровье выше определенного уровня. При этом накладывает на них один бафф, если их здоровье меньше 50%, или другой, если здоровье больше 50%. При этом первый бафф оглушает цель и его можно рассеивать, а при рассеивании наносится урон всем вокруг. Второй бафф вешает на цель дот и при окончании действия оставляет после себя лужу, которая заражает всех вошедших третьим баффом, который при рассеивании увеличивает урон, наносимый боссом. И все это – одна способность. Уже не так просто?
Для упрощения работ для каждого босса заводится отдельное пространство, которое называется воркспейс. Там хранятся все его способности, все сопутствующие мобы, все стадии, все фазы – все, что связано именно с этим боссом. Когда все в одном месте – гораздо удобнее работать.
Самой главной задачей для механика является создание рабочей системы, которая, во-первых, будет наименее багоопасной и, во-вторых, максимально лаконичной. Если с лаконичностью все понятно – конструкция из 10 шагов, проверок и перепроверок будет значительно хуже конструкции из 2 шагов и одной проверки, выполняющей те же действия, то вот с багоопасностью все гораздо сложнее.
Под багоопасностью подразумевают ситуацию, когда нельзя с большой долей уверенности оценить механику. Если вернуться к примерам выше, в которых я описал принципы работы механики, то пример с огненным шаром мага минимально опасен, в то время как пример сложного заклинания босса очень опасен.
Почему так? Дело в том, что в игре много классов. У каждого из них свои особенности. Есть защиты от заклинаний, есть защиты от физических атак, есть разные баблы, бессмертия, орехи, есть сопротивления, а еще есть множество вех. Чтобы на 100% быть уверенным в отсутствии багов, нужно проверить ВСЕ комбинации ВСЕХ заклинаний и ВСЕХ вех друг с другом и во ВСЕХ сочетаниях. И так для каждого случая. Представьте, сколько сотен лет это займет.
Был интересный пример такой ситуации, когда, исходя из механики, все должно работать идеально. Но не работает почему-то. Босс ведет себя нормально, а потом непонятно из-за чего берет и ломается. Причину очень долго не могли найти. В конце концов, после недели работы программистов клиента выяснилось, что одно из умений паладина принудительно проигрывало на целях эффект, который своим высоким приоритетом перекрывал все анимации и действия босса, и тому от такого вмешательства становилось очень плохо. Самое забавное в этой ситуации — то, что у паладина это умение было с начала времён и никогда ничего не ломало, а тут такой сюрприз.
Безусловно, часть работы автоматизирована, есть чекеры и скрипты, которые это проверяют. Есть боты, которые на специальных тестовых серверах гоняют механику туда-сюда в поисках ошибок. Но этого мало. Нельзя целиком и полностью представить и эмулировать поведение игроков. Поэтому дизайнеру очень важно и представлять последствия своей работы, и эту работу вручную проверять.
Работы по механике делятся на несколько этапов – геймплейная болванка, рабочая механика, полишинг. Первый этап – это когда нет никаких объектов, никаких моделей, просто в ровном поле расставлены совершенно одинаковые мобы (обычно тролли), к которым подключена механика боссов. Дизайнер, иногда при поддержке пары человек, «играет» в это и смотрит – насколько вообще интересно, насколько это работает и получается ли то, что запланировано.
После этого идет доработка механики. На этом этапе сама механика уже готова на 99.13%, остаются какие-то шероховатости, но совершенно отсутствуют конкретные цифры (как сильно бьет босс, сколько у него здоровья, как часто появляются адды и т. д.). На этом этапе обычно есть все или большинство моделей (как строений, так и боссов), присутствует хотя бы в драфте большая часть FX. В этот момент собирается пати из 6 человек с танком, хилом, – все как положено, и проверяется – как оно играется и работает. После таких тестов механика может меняться.
Очень много переделок было у Нихиль. То, что сейчас видят игроки – примерно шестая версия финальной механики. Изначально у нее не было фаз, все заклинания она кастовала сразу же, игрокам постоянно нужно было бегать под щитом, отпрыгивать от черных дыр. При этом в бою присутствовал еще один девайс, которым нужно было нацеливать пушки Нихиль на нее саму. И еще много чего было. В итоге поиграли во все это и поняли, что мозг просто вытекает через глаза. Было принято решение разделить весь бой на фазы, которые чередуются между собой. После этого было еще несколько итераций.
Последняя фаза – полишинг. В этот момент дизайнер добавляет уже актуальные цифры урона, здоровья, настраивает тайминги, проверяет FX, сводит озвучку и вообще занимается тонной всяческой разной работы. Самое сложное тут, как вы понимаете, это цифры.
Со стороны, кажется, что всё просто – босс должен бить на 200 000. Пусть бьет. На деле все несколько сложнее – урон босса прогоняется через множество характеристик как самого босса, так и игроков, по которым он бьет.
Так, урон босса модифицируется через: его уровень; его тип (босс, рейд-босс, обычный моб и т. д.); его сложность; модификаторы его характеристик; модификаторы заклинаний. После этого вышедший урон прогоняется через: уровень игрока; его резисты; его вехи; его характеристики. В итоге урон в 200 000 у нас в редакторе выглядит как «Магический урон – 19 единиц». И эти 19 единиц после всех перемножений, скейлеров, калкеров и проверок превратятся в 200 000.
Объем работ тут грандиозный. Именно для проверки таких работ обычно проводятся плейтесты с игроками. Пара десятков человек приходят в офис и играют там несколько часов. На таких плейтестах (если они не страдают от технических неполадок) очень хорошо видно, что получилось, а что - нет.
По результатам плейтестов (как с игроками, так и внутри компании) меняется очень многое. Так, например, на одном из маленьких плейтестов, когда смотрели Морока, меня очень смутила его анимация обычной атаки. После этого Мороку щупальца заменили на когтистые лапы:
После завершения всех работ рейд уходит в тестирование. Там его в течение нескольких недель гоняют специалисты QA в попытках найти баги или просто неправильные (не соответствующие дизайну) моменты.
Перед выдачей контента игрокам каждому боссу добавляется специальная способность, которая называется Spy. Это такая хитрая штука, которая пишет реплеи всех боев, в которые вступает босс с данной способностью. Так что мы всегда можем посмотреть – как и что проделывают игроки с нашими творениями.
Помимо этого всегда ведется статистика боссфайтов – каким составом ходят игроки, как часто вайпаются, кто сколько урона наносит и какими способностями, – исходя из этой информации можно смотреть и на эффективность классов, и на качество дизайна босса.
Создание рейда – это очень долгий, сложный, сопряженный с множеством трудностей и рисков процесс. Над рейдом в общей сложности трудится около сотни человек, начиная от художников и заканчивая QA, и все они прикладывают максимум усилий для того, чтобы потом игрокам было приятно и интересно.
Не так давно была опубликована увлекательная история, посвященная созданию рейдовых приключений в «Аллодах Онлайн». Сегодня мы представляем вашему вниманию вторую часть этого рассказа, написанного Аркадием Буяком, дизайнером игровой механики из студии Allods Team.
Итак, из первой части мы узнали, что рейды начинаются со сценарной и артовой подготовки. После этого разработчики плавно подходят к написанию дизайна боссов - тут-то и начинается самое интересное...
Наступает время войны. Войны «новинок» против «костылей». Звучит круто, кто же спорит. Так вот, все новое – это не хорошо забытое старое; это дни, а иногда и недели работ программистов разных команд (да-да, программисты бывают разные). Далеко не всегда целесообразно создавать какие-то новые сущности. Иногда это очень дорого по ресурсам, иногда – просто нереализуемо на движке. Всякое бывает.
В такие моменты на помощь приходит самый страшный грех разработчика – костыль. Костылями мы называем конструкции, которые нетривиальным и порой не очень красивым способом решают задачи, которые на обычной механике и обычными методами решить невозможно. Чаще всего костыли приходится добавлять для визуальных составляющих.
Самым хорошим примером такой ситуации может служить искра на третьей фазе Морока. Как это выглядит в жизни – искра вылетает из разбитого генератора, попадает в первую иллюзию, разрушает ее, попадает во вторую иллюзию, разрушает ее и так далее. Вроде все просто.
Но на самом деле все не так. Достаточно сложно запускать визуал (искру) с одного существа на другое (и так несколько раз подряд) в ситуации, когда они никак друг с другом не связаны. Когда одна сущность запускает заклинание в другую – тут все просто и понятно. А когда из воздуха надо взять да и отправить что-то куда-то – тут, извините, надо попотеть. На нормальную работу этой искры у меня ушло около 2 недель.
Периодически приходится менять и переписывать дизайн из-за нестыковок с возможностями. Это еще одна серьезная вещь, которую надо учитывать при дизайне – возможности движка, механики. Что-то может не поддерживаться, а что-то просто сильно нагрузит клиент и приведет к лагам.
Заказ FX – это последняя (на самом деле не совсем последняя, есть еще озвучка и музыка, но это уже потом) часть, которую нужно заказать, и которая не зависит лично от меня. Все, что начинается после – целиком и полностью моя работа, моя забота, печаль и радость. Ибо приходит время игровой механики.
Что из себя вообще представляет механика? Грубо говоря – это набор команд, поддерживаемых сервером и клиентом, которые определяют поведение мобов, содержание их спелов и способностей, их действия и все-все-все.
Если нет механики, то каким бы красивым и привлекательным не был моб, какие бы замечательные заклинания у него не были – ничего работать не будет. Даже не так. Просто – ничего не будет. Поэтому работы по механике – самая главная, самая сложная часть. Именно здесь рождаются и уничтожаются толпами разные баги, глюки, пробелы. Механика – ядро игры.
Работы по механике идут очень долго. Усложняются они все по тем же причинам – в рейдах применяется более сложная механика. При этом с каждым новым рейдом обязательно появляется и создается что-то, чего до этого момента никто и никогда не делал. И приходится изобретать, проявлять фантазию, пить кровь программистов сервера, поедать мозги программистов клиента. Здорово, одним словом.
Чтобы понять, что в общих чертах собой представляет механика, разберем простой пример – огненный шар мага. Это заклинание с определенной дальностью каста (пусть будет 40), определенным визуалом, кастуется в одну цель, наносит ей огненный урон. В редакторе это выглядит примерно так:
Достаточно просто и понятно, да? А теперь представьте себе, например, спелл, который кастуется только на цели, у которых здоровье выше определенного уровня. При этом накладывает на них один бафф, если их здоровье меньше 50%, или другой, если здоровье больше 50%. При этом первый бафф оглушает цель и его можно рассеивать, а при рассеивании наносится урон всем вокруг. Второй бафф вешает на цель дот и при окончании действия оставляет после себя лужу, которая заражает всех вошедших третьим баффом, который при рассеивании увеличивает урон, наносимый боссом. И все это – одна способность. Уже не так просто?
Для упрощения работ для каждого босса заводится отдельное пространство, которое называется воркспейс. Там хранятся все его способности, все сопутствующие мобы, все стадии, все фазы – все, что связано именно с этим боссом. Когда все в одном месте – гораздо удобнее работать.
Самой главной задачей для механика является создание рабочей системы, которая, во-первых, будет наименее багоопасной и, во-вторых, максимально лаконичной. Если с лаконичностью все понятно – конструкция из 10 шагов, проверок и перепроверок будет значительно хуже конструкции из 2 шагов и одной проверки, выполняющей те же действия, то вот с багоопасностью все гораздо сложнее.
Под багоопасностью подразумевают ситуацию, когда нельзя с большой долей уверенности оценить механику. Если вернуться к примерам выше, в которых я описал принципы работы механики, то пример с огненным шаром мага минимально опасен, в то время как пример сложного заклинания босса очень опасен.
Почему так? Дело в том, что в игре много классов. У каждого из них свои особенности. Есть защиты от заклинаний, есть защиты от физических атак, есть разные баблы, бессмертия, орехи, есть сопротивления, а еще есть множество вех. Чтобы на 100% быть уверенным в отсутствии багов, нужно проверить ВСЕ комбинации ВСЕХ заклинаний и ВСЕХ вех друг с другом и во ВСЕХ сочетаниях. И так для каждого случая. Представьте, сколько сотен лет это займет.
Был интересный пример такой ситуации, когда, исходя из механики, все должно работать идеально. Но не работает почему-то. Босс ведет себя нормально, а потом непонятно из-за чего берет и ломается. Причину очень долго не могли найти. В конце концов, после недели работы программистов клиента выяснилось, что одно из умений паладина принудительно проигрывало на целях эффект, который своим высоким приоритетом перекрывал все анимации и действия босса, и тому от такого вмешательства становилось очень плохо. Самое забавное в этой ситуации — то, что у паладина это умение было с начала времён и никогда ничего не ломало, а тут такой сюрприз.
Безусловно, часть работы автоматизирована, есть чекеры и скрипты, которые это проверяют. Есть боты, которые на специальных тестовых серверах гоняют механику туда-сюда в поисках ошибок. Но этого мало. Нельзя целиком и полностью представить и эмулировать поведение игроков. Поэтому дизайнеру очень важно и представлять последствия своей работы, и эту работу вручную проверять.
Работы по механике делятся на несколько этапов – геймплейная болванка, рабочая механика, полишинг. Первый этап – это когда нет никаких объектов, никаких моделей, просто в ровном поле расставлены совершенно одинаковые мобы (обычно тролли), к которым подключена механика боссов. Дизайнер, иногда при поддержке пары человек, «играет» в это и смотрит – насколько вообще интересно, насколько это работает и получается ли то, что запланировано.
После этого идет доработка механики. На этом этапе сама механика уже готова на 99.13%, остаются какие-то шероховатости, но совершенно отсутствуют конкретные цифры (как сильно бьет босс, сколько у него здоровья, как часто появляются адды и т. д.). На этом этапе обычно есть все или большинство моделей (как строений, так и боссов), присутствует хотя бы в драфте большая часть FX. В этот момент собирается пати из 6 человек с танком, хилом, – все как положено, и проверяется – как оно играется и работает. После таких тестов механика может меняться.
Очень много переделок было у Нихиль. То, что сейчас видят игроки – примерно шестая версия финальной механики. Изначально у нее не было фаз, все заклинания она кастовала сразу же, игрокам постоянно нужно было бегать под щитом, отпрыгивать от черных дыр. При этом в бою присутствовал еще один девайс, которым нужно было нацеливать пушки Нихиль на нее саму. И еще много чего было. В итоге поиграли во все это и поняли, что мозг просто вытекает через глаза. Было принято решение разделить весь бой на фазы, которые чередуются между собой. После этого было еще несколько итераций.
Последняя фаза – полишинг. В этот момент дизайнер добавляет уже актуальные цифры урона, здоровья, настраивает тайминги, проверяет FX, сводит озвучку и вообще занимается тонной всяческой разной работы. Самое сложное тут, как вы понимаете, это цифры.
Со стороны, кажется, что всё просто – босс должен бить на 200 000. Пусть бьет. На деле все несколько сложнее – урон босса прогоняется через множество характеристик как самого босса, так и игроков, по которым он бьет.
Так, урон босса модифицируется через: его уровень; его тип (босс, рейд-босс, обычный моб и т. д.); его сложность; модификаторы его характеристик; модификаторы заклинаний. После этого вышедший урон прогоняется через: уровень игрока; его резисты; его вехи; его характеристики. В итоге урон в 200 000 у нас в редакторе выглядит как «Магический урон – 19 единиц». И эти 19 единиц после всех перемножений, скейлеров, калкеров и проверок превратятся в 200 000.
Объем работ тут грандиозный. Именно для проверки таких работ обычно проводятся плейтесты с игроками. Пара десятков человек приходят в офис и играют там несколько часов. На таких плейтестах (если они не страдают от технических неполадок) очень хорошо видно, что получилось, а что - нет.
По результатам плейтестов (как с игроками, так и внутри компании) меняется очень многое. Так, например, на одном из маленьких плейтестов, когда смотрели Морока, меня очень смутила его анимация обычной атаки. После этого Мороку щупальца заменили на когтистые лапы:
После завершения всех работ рейд уходит в тестирование. Там его в течение нескольких недель гоняют специалисты QA в попытках найти баги или просто неправильные (не соответствующие дизайну) моменты.
Перед выдачей контента игрокам каждому боссу добавляется специальная способность, которая называется Spy. Это такая хитрая штука, которая пишет реплеи всех боев, в которые вступает босс с данной способностью. Так что мы всегда можем посмотреть – как и что проделывают игроки с нашими творениями.
Помимо этого всегда ведется статистика боссфайтов – каким составом ходят игроки, как часто вайпаются, кто сколько урона наносит и какими способностями, – исходя из этой информации можно смотреть и на эффективность классов, и на качество дизайна босса.
Создание рейда – это очень долгий, сложный, сопряженный с множеством трудностей и рисков процесс. Над рейдом в общей сложности трудится около сотни человек, начиная от художников и заканчивая QA, и все они прикладывают максимум усилий для того, чтобы потом игрокам было приятно и интересно.
Надеюсь, что статья была и полезной, и интересной. See ya.
Комментариев нет:
Отправить комментарий