Продолжаю рассказывать, как это - учиться в Вышке (она же НИУ ВШЭ) делать игры. Предыдущая часть здесь.
На этой неделе у меня случился новый опыт - лекция шла вживую, а слушала я её по зуму. Доехать до вуза не позволило, во-первых, пошатнувшееся здоровье, а во-вторых, здравый смысл - именно в этот день на улице началось форменное безобразие с признаками апокалипсиса.
Слышно лекцию было отлично, эффект присутствия полный, так что, отказавшись от поездки в вуз, я ничего не потеряла. Но! Раз такое дело, позволю себе немного поворчать в духе “а вот в моё время!”. Жалею, конечно, современных студентов. Раньше как - заболел (или решил, что заболел) - просто не идёшь на пары! И всё. А сейчас они со своими зумами в самую глубину жизни проникли - даже не прогуляешь по-человечески.
Недостижимо прекрасные игровые механики
Эта неделя началась у нас с игровых механик с Владимиром Агарёвым. Поймала себя на мысли, что никак не привыкну к фразам лектора вроде: “на прошлой лекции мы обсудили Call of Duty, а на этой поговорим про Pacman”. В такие моменты меня накрывает эйфория от осознания, ЧЕМУ я учусь и насколько этого всего ХОЧУ.
Итак, в этот раз мы говорили про типы игровых механик:
- Физические (имитации взаимодействия). Например, поместить объект в игровую среду, переместить его, удалить оттуда. А ещё - прыгать и залезать, расти и уменьшаться, соединять и разделять и так далее.
- Экономические (управление ресурсами). В основном это - собрать или отнять.
- Ментальные (использование мыслительных процессов игрока). Например, создать или распознать шаблон, запомнить, выбрать.
У каждой механики есть тип (простая/комплексная), цель и характерные параметры. Так, у ментальной механики “выбрать” есть варианты выбора.
Всё это кажется очевидным, пока мы не попробуем из нескольких простых механик собрать одну комплексную. Всеми “любимая” механика match из игр вроде “три в ряд” в разобранном виде выглядит вот так:
А механика выстрела, похоже, выносит мозги не только врагам, но и разработчикам.
А самое интересное, что совсем скоро нам самим предстоит рисовать такие схемы - сначала на практическом занятии, а потом на зачёте.
На другой лекции об игровых механиках мы говорили про ещё одну важнейшую штуку - оценку их качества. Здесь перед создателями игр встают сложные (а порой - риторические) вопросы: будет ли интересно играть в такую механику? Захочется ли долго играть? Соответствует ли механика ожиданиям игроков? А соотносится ли она с эстетикой игры? И всё это на фоне изменчивости мира (ведь интересные и актуальные вещи быстро перестают быть таковыми).
Дополнительная сложность при оценке механик, которая зацепила лично меня - нестандартные и уникальные механики оценить сложнее всего. И, пожалуй, главная сложность - признаться себе, что твоя механика не уникальная, а просто унылая:(
Однако не всё так плохо - у механик всё-таки есть критерии качества.
Механика должна быть:
- Понятной (можно освоить за 10-15 секунд и даже интуитивно понять, глядя на скриншот игры). К слову - когда показываешь кому-то свою игру, не стоит подсказывать играющему, как работают простые механики - пусть сам поймёт - тогда можно оценить, действительно ли эти механики просты.
- Интересной (вызывает яркие эмоции, заставляет повторять действия снова и снова, соответствует ожиданиям игрока).
- Запоминающейся (не надоедает быстро, игроку хочется вернуться).
- Глубокой (у игрока есть ощущение роста навыка, что позволяет быстрее достигать игровых целей).
- Масштабируемой (механику ещё можно расширить, дополнить и улучшить). Похоже, на этом критерии сыпятся сотни механик и головы геймдизов - придумать механику легко, а вот масштабировать…
При оценке механик, кажется, не обойтись без сторонней оценки - ведь геймдизайнер погружён в собственную игру, он знает её досконально, поэтому и не может оценить со стороны. Но ещё до публичного тестирования можно пробежаться по чек-листу, чтобы самостоятельно оценить механику.
Например, вот такие вопросы можно себе задать:
1. Понятна ли атмосфера игры, есть ли визуальные подсказки и ориентиры к целям игры?
2. Правила простые, механика интуитивная, цели ясные?
3. Ясна ли локальная цель, которая достижима при помощи механики?
4. Раскрывает ли механика рост навыка игрока со временем?
5. Можно ли масштабировать механику?
6. Игроку интуитивно понятно, как контролируются игровые объекты? Достаточно ли у игрока возможностей? Или перебор, или маловато?
7. Легко ли выживать в игре и можно ли исправить ошибку до полного поражения?
Проверила чек-лист на себе - ну, пока получилось только похвалить себя за атмосферную игру с интуитивно понятными механиками. Я-ясно, всё-таки нужна сторонняя оценка:)
Пайплайн, интерактив и снова пайплайн
На этой неделе у нас начался новый предмет - “Технические основы разработки игровых продуктов” (ТОРИП). Его ведут сразу два преподавателя - Андрей Белоусов и Илья Бойцов - руководители игровой студии и выпускники Вышки, которые в своё время прошли ту же программу “Менеджмент игровых проектов”.
Занятие оказалось интерактивным - нам задавали много вопросов, мы подключались, рассуждали, искали метафоры и проводили аналогии. В чём секрет такой активности? Тут одно из двух - или все засиделись по домам, и хотелось пообщаться, или (к этому варианту я склоняюсь больше) - преподаватели очень удачно по времени, в начале лекции, проанонсировали, что экзамен можно получить автоматом. Причём пока неясно, что именно нужно сделать, но вариант “резко активизироваться” со всем сторон кажется выигрышным.
Мы поговорили про пайплайн на примере оркестра, строительной компании и производства фильмов, узнали, что пайплайн - это документ, описывающий и финально закрепляющий некий процесс и принципы взаимодействия. Немножко затронули понятия фичей и игровых механик (даже подискутировали, чем они друг от друга отличаются), а также ассетов. Это была вводная лекция, поэтому, очевидно, дальше будет подробнее.
На лекции по административному и проектному менеджменту с Константином Сахновым мы говорили, не поверите, про пайплайны! Впрочем, зато теперь забыть понятие пайплайна и принципы его построения можно разве что отправившись в мир иной.
Итак, ещё разок, но другими словами:) Пайплайн - это алгоритм, который описывает многократно повторяющийся типовой процесс.
Зачем он нужен? Чтобы ускорить процесс разработки и коммуникации, уменьшить число ошибок, устранить типовые вопросы, а также назначить ответственных.
Пайплайн может быть проектным - и тогда он определяет последовательность действий по разработке продукта или его элемента. Или административным - а это уже регламент выполнения управленческой задачи, например, увольнение сотрудника.
Как в целом может выглядеть пайплайн по задаче:
Те, кто уже работает в той же Jira, ничего нового для себя не извлекут, но для начинающих это, думаю, вполне полезно. Нам бы такой экскурс не помешал где-нибудь в августе, когда мы только начали плотно заниматься игрой и понятия не имели, как работать с документацией и распределять задачи. Сейчас, когда все ошибки успешно совершены, а roadmap дважды переделан - со вздохом приходится констатировать - “А… Вот так надо было делать, ну ок”.
А на этом пока всё! Следующая учебная неделя должна получиться очень горячей - у нас будет первый учебный питч. Утром в субботу. Честь представлять наш проект и команду выпала, разумеется, мне. При этом накануне питча, в пятницу вечером, мы идём на концерт The Hatters, короче говоря, приключений должно быть много, а в нормальном состоянии я не буду питчить уже, видимо, никогда.
Спасибо за то, что прочитали! Подписывайтесь на меня, если хотите, и до встречи на следующей неделе!
P. S. Читать Student Simulator также можно в VK, твиттере и телеге.
P. P. S. Меня уже несколько раз в комментариях и личных сообщениях спрашивали про расписание, цену курса и прочее, давайте я оставлю ссылку на программу “Менеджмент игровых проектов” - на случай, если кого-то заинтересуют технические подробности:) Если это лишнее - отпишитесь в комментариях, и я больше так не буду:):)
