пятница, 6 декабря 2013 г.

Место сценариста в команде разработки игры

Здравствуйте, меня зовут Мария Кочакова, я сценарист проекта Skyforge в Allods Team. Эта статья подытоживает два года моей работы игровым сценаристом. Все это суровые реалии жизни сценаристов компьютерных игр, то, с чем мы сталкиваемся ежедневно. Категоричность формы продиктована важностью содержания.

Сценарий компьютерной игры

Нарративная (повествовательная) часть игры состоит из сеттинга, сюжета и текста.

Сеттинг — это мир игры, его законы и реалии. Примеры сеттинга: постапокалипсис, фэнтези-средневековье, киберпанк…

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

Сценарий — это форма, в которой выражается сюжет. Обычно сценарий выглядит как список сцен с описанием происходящего и диалогами. Сценаристами называют людей, которые умеют рассказывать истории в форме сценария — готового для работы остальной команды документа.

Текст — это не оптимальная форма подачи сеттинга и сюжета игры. Текст — это вспомогательный инструмент. Помните, что текст могут и не прочесть. Бывают игры с сюжетом и без текста (Machinarium). Но текст можно сделать источником фана и даже USP(Deponia, Bard’s Tale).



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

Сюжет может быть USP вашей игры, а может и мешать.

Сюжет — это лишь одна из составляющих успеха игры. Не стоит его переоценивать. Но и недооценивать силу сюжета не стоит.

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

Некоторая часть игроков хочет видеть в игре сюжет, но чаще всего игроки не хотят читать.

Проблемы с нарративом возникают в двух случаях:
  1. Когда сценарист не понимает специфику своей работы — по неопытности или из-за неверной установки. В этом случае сценарист действует неадекватно: болезненно воспринимает фидбек, принимает сырые сценарные решения, ленится, переоценивает свою роль на проекте и т. п.
  2. Когда команда не понимает специфику работы сценариста — из-за предубеждения и негативного опыта сотрудничества. В этом случае команда выдает неадекватный фидбек, необоснованно вмешивается в сценарий, требует невозможного, недооценивает роль сценариста и т. п.

Лечить проблемы следует волшебной силой просвещения — как сценариста, так и команды.
Сценарист компьютерной игры




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

Знания и навыки сценариста компьютерных игр приобретаются в результате специальной подготовки и опыта работы.

Профессионализм включает в себя не только набор умений, но и профессиональную этику — отношение к своей работе, к проекту, к коллегам, к рабочим ситуациям.

На проекте сценарист отвечает за нарратив и соответствие нарратива виденью игры.

Нарратив, как мы помним, это сеттинг, сюжет и текст.

Виденье (vision) — это суть проекта, верхняя планка, представление о том, какой игра должна получиться на выходе. Сценарист не является создателем виденья, но, вместе с артлидом, является его хранителем. В идеале сценаристы и художники вместе следят за соответствием игры виденью.

Рабочие обязанности сценариста зависят от проекта. Чем больше проект, тем уже обязанности и выше степень специализации. В маленькой команде один человек может выполнять функции и сценариста, и литературного редактора, и даже комьюнити-менеджера (написание новостей, анонсов, проведение конкурсов и т. п.). Все зависит от способностей. Ничего страшного в этом нет. Никто еще не умер от дополнительного рабочего навыка.

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

Восприятие фидбека

Большая опасность для сценариста заключается в восприятии своей работы как части себя. Когда оценивают работу, сценаристу кажется, что оценивают его как личность. Поэтому сценарист может реагировать излишне эмоционально и негативно, сразу же уходя в глухую защиту.
  1. Если фидбек адекватен (вежлив) и не является вкусовщиной, а отражает реалии проекта (нет необходимой механики, нельзя показать сюжетный ход доступными средствами и т. п.), то сценаристу следует научиться воспринимать отзыв как уточнение ТЗ и спокойно вносить требуемую правку.
  2. Если фидбек отражает только вкусы и взгляды оценивающего, то к работе он отношения не имеет, и, следовательно, может идти лесом (если только это не фидбек заказчика, в таком случае это уточнение ТЗ, а не фидбек, см. п. 1).
  3. Если фидбек неадекватен (невежлив), то он может идти лесом, даже если это фидбек заказчика. Давайте уважать друг друга.


Неловкий момент, когда сценарист влюбляется в идею
  1. В работе сценариста компьютерных игр нет и не может быть любимых идей, есть оптимальные сценарные решения. Если решение перестает удовлетворять своим нуждам, его заменяют более оптимальным. Как говорил Хемингуэй: «Нужно убивать своих любимых». Другими словами, позиция «я так вижу» не про сценаристов. У нас все четко. Практически математика.
  2. Риск влюбиться в идею есть всегда. Нужно просто понимать, что никто не застрахован, и относиться к этому, как к неудаче в любви — немного поплачешь, и пройдет. Появится новая.
  3. Любимые идеи, к несчастью, бывают не только у сценаристов, но и у заказчиков. Чтобы убить идею заказчика, нужны веские основания. Вы должны быть твердо уверены в том, что идея отжила свое и больше не оптимальна. Подходите к убийству максимально осторожно и аккуратно. Настоятельно рекомендуется переводить стрелки на реалии проекта и тщательно прятать труп, чтобы не всплыл по весне.


Сценарное решение



Сценарное решение — основной инструмент сценариста. Это наилучший из возможных сюжетный ход, который оптимально отвечает требованиям проекта.
  1. Необходимо очень тщательно проверять свои сценарные решения, чтобы при необходимости дать «обоснуй»: зачем и почему принято именно такое решение, что оно дает проекту и какие проблемы снимает.
  2. Поиск верного сценарного решения — это путь по болоту. Один неверный шаг, и посыплется вся сюжетная линия. Ни в коем случае нельзя принимать невзвешенные сценарные решения, так называемые решения-от-балды. Лень утопит в болоте и сюжет, и вашу репутацию.
  3. Чем больше у вас информации о болоте (проекте), тем более удачный путь (решение) вы можете найти. Поэтому настоятельно рекомендуется спрашивать дорогу (инфу и фидбек) у других членов команды. Много голов лучше, чем одна. Но выбор пути за сценаристом. Это его сфера ответственности.
  4. Команде хорошо бы понимать, какой ценой дается сценаристу его сценарное решение (если это, конечно, тру-сценарист, а не сценарист-от-балды). Болота сюжетов усыпаны седыми волосами сценаристов. Уважайте их труд!


Бдительность в лоре

На плечи сценариста ложится увязка всех элементов игры (иногда даже чисто геймплейных условностей) в логичный и связный lore.
  1. Рекомендуется много читать, смотреть и играть не только для удовольствия, но и для повышения скилла «Эрудиция». Одни из самых интересных сеттинговых решений были уже приняты до нас миллионом неимоверно крутых фантастов. Наша задача, помимо создания нового, не растерять знания предков и передать их следующему поколению. Также, если сценарист может привести пару примеров похожего сценарного решения из мировой культуры, ему будет легче «продать» свою идею начальству. «Если сработало в «Стартреке», то и нам сгодится».
  2. Если создание сюжета — путь по болоту, то создание сеттинга — это бой с лернейской гидрой. На каждый отвеченный вопрос по мироустройству вылезают два новых. Тренируйте логику и не плодите сущностей — связывайте обрубки шей вместе.

Отношение к проекту

Проект надо знать.
  1. Надо знать контент, чтобы юзать и реюзать его. Сценаристу рекомендуется помнить, что час работы художника, моделлера и аниматора в сумме стоит дороже часа работы сценариста. Принимая сценарное решение, сценарист тратит деньги проекта. Такова цена творчества.
  2. Надо знать геймплей и механику. Правильно, чтобы сценарий и геймплей не пытались убить друг друга, входя в игру с разных концов ринга, а действовали сообща, делая проект интереснее. Это заблуждение, что истории можно рассказывать только текстом. Сюжетный геймплей — вот идеал сценариста компьютерных игр.
  3. Контроль качества. Сценарист не только «пишет» сценарий, но и смотрит, как сценарий ложится в игру на всех этапах разработки. Все ли так, как планировалось? Понимают ли игроки, что происходит в игре по сюжету? Никто кроме сценариста не знает, как должен выглядеть в игре задуманный им сюжет. Только сценарист может отловить сценарные баги, которые сам же и наплодил — другие члены команды могут просто не знать, что это баги, а у QA и без сценария достаточно работы.


Вывод: сценаристы, играйте в свою игру!


Отношение к команде

Команду надо знать и по возможности любить.
  1. Хорошо, когда сценарист представляет себе сильные стороны членов команды и может использовать их при создании сюжета. Если художник лучше всего рисует пони, возможно, есть смысл вписать пони в сюжет. Если левел-дизайнер лучше всего делает лабиринты, возможно, есть смысл вписать в сюжет лабиринт. В противном случае сценарист рискует, что лабиринт впишут в сюжет без его помощи. Это примерно как ногу пришить к лицу без анестезии, ага.
  2. Хорошо, когда сценарист представляет себе слабые стороны членов команды. Возможно, если у левел-дизайнера не ладится с лабиринтами, не стоит вводить лабиринт в сюжет. Обреченная на провал попытка побороть чужую некомпетентность чревата слезами на похоронах любимой идеи.
  3. Сценаристы, подстраивайтесь под команду. Это люди, чьими руками вы будете вводить в игру сюжет. Нужно действовать заодно, а не самоутверждаться за счет проекта.
  4. Есть еще тонкий момент. Иногда бывает, что член команды предлагает лучшее решение, чем сценарист. Тут сценаристу не следует идти на поводу у гордости и добиваться принятия своего решения, во что бы то ни стало. Задача сценариста — выбрать оптимальное решение, даже если это не его решение. Это называется профессионализм.


Сценаристы, помните, что главное — проект, а не эго. В соавторстве с другими людьми скрыты бездны интересных идей и оригинальных решений.
Сценаристу не стоит воспринимать команду как врагов, которые ставят палки в колеса его творческому гению. Живое общение — это не только фидбек, но и возможность убедить(ся) в правильности своего решения.

Стоит ценить заинтересованность команды в сюжете и желание (пусть и не всегда уместное) поучаствовать в его создании. Если им станет все равно — вот тогда стоит волноваться.
Заключение

У меня есть мечта — профессиональное сообщество сценаристов компьютерных игр.



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

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

Например, в моей практике был болезненный случай, когда я взялась за проект, не въехав толком в виденье. Не имея представления о целевой аудитории, играх-референсах и том, что должно получиться на выходе, я самозабвенно шпарила сценарий с большим удовольствием. В итоге игра просела именно на соответствии ожиданиям ЦА (классическая ошибка!). Сеттинг потерял фокус, вышел размытым и неоднозначным, местами чересчур жестким, местами слишком детским. Было обидно за потраченное время и стыдно перед командой. Ущерба проекту можно было избежать, заранее озаботившись вижн-доком и тщательно обговорив его с начальством.

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

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

четверг, 5 декабря 2013 г.

Интерфейсы в Skyforge

Здравствуйте, я Антон Кругляков, руководитель команды User Interface проекта Skyforge. В этой статье я расскажу о нашем опыте проектирования дизайна интерфейса. Я старался максимально уменьшить теоретическую часть, но, глядя на финальный результат, понимаю, что не особо преуспел в этом.











Уникальные отличия



В семье пользовательских интерфейсов игровой интерфейс находится на особом положении. Он позволяет себе активно использовать графику, нестандартные звуки и материализм в любых пределах, но все это меркнет перед одним простым фактом — другая мотивация пользователя. Все достаточно просто и вместе с тем очень сложно: офисные программы служат для достижения цели, игры же существуют для получения удовольствия. Что это меняет с точки зрения интерфейсов?

В случае с офисной программой проектировщики интерфейсов исходят из цели, которую хочет достичь пользователь. Разрабатывая игру, мы должны понимать, что приносит пользователю наибольшее удовольствие, и ставить для него цели, которые позволят это удовольствие получить. Постойте, а как же мы определим, что приносит удовольствие? К счастью, все это уже выяснили до нас. Оказывается, факторов, обеспечивающих удовольствие от игры, не так много. По простой классификации Бартла игроки делятся на 4 типа, каждый из которых ориентирован на достижение своих целей.



Вкратце их можно описать так:
  • карьеристы (achievers) — всегда в поисках достижений;
  • исследователи (explorers) — «роют носом землю» ради информации;
  • социофилы (socialisers) — формируют сообщества, получают удовольствие от разговоров;
  • киллеры (killers) — стремятся самоутвердиться за счет окружающих.

Если мы знаем свою аудиторию, то знаем, что мотивирует игрока, и легко можем создать геймплей, который будет по нраву нашим пользователям. Здесь мы приходим к простому, но важному факту: перед игроком стоят искусственно поставленные цели, которых он должен добиться в системе с уникальными правилами и атмосферой.

Второй по важности фактор, который присутствует во многих играх, это способ взаимодействия игрока с информацией, в нашем случае — с миром игры. Оно происходит не напрямую, а через цепочку промежуточных объектов (через персонажа, игровую камеру и т. п.).



У игровых интерфейсов, в отличие от офисных, есть и другие задачи. Если интерфейс PowerPoint спроектирован так, чтобы максимально облегчить путь пользователя к цели, то задача игрового не только удобно транслировать игроку его цель, но и передавать атмосферу игры. Часть элементов может быть стилизована под мир игры, а часть — выполнена абстрактно. Некоторые группы элементов могут быть внесены в мир игры и доступны только посредством персонажа, а некоторые — напрямую пользователю. Вариантов реализации достаточно много, и все они влияют на удобство, уровень погружения в атмосферу игры и другие нюансы.

Наблюдаемо персонажемНаблюдаемо только игрокомМетаощущения
В пространстве игрыинтерактивные объектыгеометрические элементы интерфейсапространственные ощущения персонажа
Вне пространства игрыметаобъектыиндикаторысобственные ощущения персонажа


Элементы интерфейса

Объекты в мире игры, наблюдаемые персонажем и игроком



Объекты, которые видите вы на экране монитора и ваш персонаж в игровой вселенной. Это может быть карта галактики в пространстве мира игры, на которой отображаются планеты и информация о них.

Плюс:
  • передача информации без отрыва от мира игры.

Минусы:
  • ограничения по оформлению информации, связанные с атмосферой игры;
  • сложность доступа, требуется перемещение персонажа.


Объекты вне мира, наблюдаемые персонажем и игроком



Скевоморфные к миру игры двухмерные или трехмерные интерфейсы, существующие вне мира игры. Наглядный пример — карманный компьютер персонажа, который игрок не может видеть в пространстве игры.

Плюсы:
  • передача информации без отрыва от мира игры;
  • быстрый доступ к информации;
  • игрок взаимодействует с интерфейсом напрямую.

Минус:
  • ограничения по оформлению информации, связанные с атмосферой игры.


Объекты в игре, невидимые персонажу



Объекты, воспринимаемые только игроком и относящиеся к информации, которая не имеет смысла в рамках атмосферы игры. Примером подобных объектов является подсветка выбранной сущности или сектора. Она не имеет никакого смысла для персонажа и не существует в рамках повествования, но видна игроку и показывает объект, с которым будет происходить взаимодействие.

Плюсы:
  • пространственная привязка;
  • игрок взаимодействует с интерфейсом напрямую.

Минус:
  • портит картинку с художественной точки зрения.


Объекты вне пространства игры, невидимые персонажу



Любые интерфейсы, не связанные с атмосферой и находящиеся вне пространства мира игры.

Плюсы:
  • игрок взаимодействует с интерфейсом напрямую;
  • возможность подавать информацию игроку в наиболее удобной и понятной форме.

Минус:
  • при чрезмерном использовании быстро низводит игру до таблицы.


Метавосприятие в пространстве мира игры



Особая группа интерфейсов, связанная с передачей состояния персонажа, его ощущений и восприятия мира. Примером может быть как визуализация слышимых героем звуков, так и изменения, связанные с восприятием, к примеру, эффект «ночного зрения».

Плюс:
  • пространственная привязка.

Минусы:
  • ограниченное применение;
  • большая степень абстракции.


Метавосприятие вне пространства игры



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

Плюс:
  • заметность.

Минусы:
  • ограниченное применение;
  • большая степень абстракции.


MMORPG — это просто и понятно

Жанр MMORPG имеет богатую историю и набор стандартных механик, которые игроки ожидают увидеть в игре. Если коротко сформулировать наши цели, мы хотели реализовать все многообразие принятых механик и не получить картинку, как на примере ниже.



При всей простоте критерия большинство разработчиков MMO продолжают об него спотыкаться. Не так-то просто взять и внести все необходимые индикаторы в мир. Но есть игры, в которых сделано именно так. К сожалению, такое решение имеет два основных недостатка:
  1. Индикаторы принимают все ограничения, связанные с миром игры.
  2. Доступ к такому индикатору усложняется.

В случаях, когда нельзя пожертвовать удобством, приходится возвращаться к старым добрым индикаторам. В общем же случае дизайнеры игры готовы пожертвовать удобством примерно… никогда. Чтобы избежать этого, мы выработали три простых правила:
  1. HUD — бой, целеуказание.
  2. Интерфейсные окна — стратегическое планирование (выбор новой цели, ситуация вокруг игрока).
  3. Интерфейсы в мире игры — тактическое планирование, информация о мире.

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

HUD

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



  1. Важное, срочное, с максимально емкой подачей:
    • состояние персонажа;
    • возможные действия;
    • урон;
    • контроль состояния врагов и дружественных персонажей поблизости;
    • оповещения от game-мастеров.
  2. Средней важности, не срочное, с детализацией:
    • обновление состояния заданий;
    • выполнение заданий;
    • получение предметов;
    • события, требующие решения игрока (приглашение в группу).
  3. Маловажное, не срочное, с детализацией:
    • оповещения от разных игровых механик (аукцион, ремесло);
    • социальные функции.
  4. Важное, не срочное, с максимальной полнотой:
    • механики игры, относящиеся к долгосрочным целям: развитие персонажа, ремесло и т. п.

Для разных групп используется разный подход к визуализации и разное место на экране. Мы разделили экран условно на 3 вида зон:



Зона 1. Используется для информации группы «Важное, срочное, с максимальной полнотой». Это область, куда игрок смотрит больше всего. Сюда помещено все самое важное, без чего играть невозможно.

Зона 2. Используется для группы «Средней важности, не срочное, с детализацией». Эта область хорошо заметна в спокойном состоянии, но в бою игрок может попасть в «поток», который характеризуется сужением области зрения, концентрацией на основной задаче. К примеру, если вы играете в интересную игру и ваш персонаж умирает, рядом могут ограбить банк, но вы этого не заметите. Чтобы привлечь внимание игрока к этим областям, нужно приложить больше усилий. Мы с этой целью применяем:
  • простые анимации. Они работают плохо, так как баннерную слепоту еще никто не отменял.
  • «анимированные хлебные крошки», когда показываем какую-то сущность в зоне 1 компактно и связываем анимацией с областью в зоне 2, где даем дополнительную информацию.

Зона 3. Используется для группы «Маловажное, не срочное, с максимальной полнотой». Это та информация, которую игрок может спокойно прочитать вне боя, в безопасной для персонажа зоне.

Окна

Всю информацию, которая не требуется в рамках боя, но часто нужна игроку «в мирном режиме» и требует структурированной подачи, мы оформили в виде отдельных окон. Окна, объединенные по функциональному признаку, являются хабами, охватывающими все, что относится к отдельной, законченной функции игры, к примеру, аукцион или социализация. Я не буду подробно описывать подходы, которые мы применяли для дизайна окон. Этот процесс очень близок к тем, что применяются для разработки web и офисных приложений. Отмечу только, что для игр из-за нестандартного графического оформления интерфейса обязательно следует разработать guideline, правила оформления и примеры, а 
также описание всех возможных реакций и поведений.



Полноэкранные интерфейсы и интерфейсы в мире игры

В некоторых ситуациях, когда скорость принятия решения не так важна, а погружение в мир игры является критически важным, мы делаем интерфейсы полноэкранными. К примеру, в Skyforge к таким интерфейсам отнесены интерфейс выбора приключения, который оформлен как единый объект в мире и интерфейсе. За счёт особого оформления, мы усилили ощущение связанности событий у игрока, одновременно показав масштабность происходящих событий. Аналогичные подходы были применены для рада других интерфейсов, о которых вам в будущем с радостью расскажет наш блог разработчиков.

Системность

Недаром есть поговорка «Встречают по одежке ...». В нашей жизни огромную роль играют системы кодировок. Возьмем, к примеру, одежду. Это кодировка социального статуса. В игровом интерфейсе мы применили три основных вида кодировки: цветом, формой и стилистикой.

Кодировка цветом наиболее простая. Она используется, чтобы обозначить отношение цели к игроку (агрессивное, нейтральное или дружественное) и полезность предметов.



Кодировку формой мы используем для умений и заклинаний персонажа — по типу их воздействия. Система добавляет дополнительный уровень узнавания и удобства.



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

Заключение

Игровой интерфейс состоит не только из классификаций и подходов. Это кропотливая работа художников, дизайнеров, программистов и сценаристов проекта. Наша задача как команды интерфейсов — сделать вход пользователя в игру максимально простым, а процесс игры — максимально прозрачным.

Несмотря на кажущуюся простоту, такую систему весьма сложно поддерживать. Всему виной сам принцип разработки игр, его переменчивость и нечеткая цель — «доставить удовольствие игроку» — в условиях, когда предпочтения аудитории и разработчиков могут изменяться.

Если вам интересно узнать о технической стороне процесса и о том, как мы делали UI в Adobe Flash и на ActionScript 3 на 160 тысяч строк кода, напишите об этом в комментариях, и мы подготовим ещё одну статью. Удачи!
Related Posts Plugin for WordPress, Blogger...