ТЕМА: На смертном одре - отчёт

Это отчёт по созданию игры На смертном одре (далее НСО) для юбилейного GotW.

Каждый раз, когда я берусь участвовать в конкурсе, моя главная проблема - это успеть сделать проект, который не жалко сдать, за как можно более короткое время. В отличие от многих участников, работа не позволяет мне трудиться над сколько-нибудь трудозатратным хобби по будням, а если я выделяю на ГотВ слишком большой кусок выходных (да и на тех надо успеть отдохнуть) - то страдают основные проекты, обязательства по которым и так с трудом удаётся выполнять после устройства на работу. Короче, главный мой кордон и наибольшее возможное достижение в конкурсе - это успешное планирование.

Поэтому я выбрала сделать проект на Юнити. Казалось бы, тоже мне способ сэкономить время - изучать новый движок (до этого я на нём проектов не делала) в дополнение к созданию игры! Но на тот момент я посмотрела все базовые и ряд продвинутых обучалок по Юнити и довольно неплохо представляла себе его работу, а также кое-что теоретически знала об особенностях C# по сравнению с привычными мне Яваскриптом, Руби и php. (Кстати, когда говорят, что в Юнити есть Яваскрипт - не верьте. Хотя авторы настаивают на названии "Яваскрипт", большая часть называет этот язык Юнитискрипт, потому что отличия огромны, начиная со строгой типизации переменных.)

В Юнити есть готовые, встроенные решения для большинства основных проблем 3D-игр. В частности, на меня произвело впечатление, как можно заставить объекты двигаться по физике, всего-то сделав несколько манипуляций! Не требуется ни кода, ни сложных настроек... В общем, из этого родилась идея совместить падающие по физике кубики с литературным талантом Армата, чтобы сотворить маленькую атмосферную игру про человека, играющего в кости со смертью и ставящего на кон близких ему людей.

Следует также знать, что создание игр на Юнити во многом состоит из использования готовых пакетов из Unity3d Asset Store, как бесплатных, так и платных. Это также призвано экономить время. Об этом позже.

Работа с пистелем
Изложив идею Армату, я заслужила его интерес, и он сразу смог ответить на один из вопросов игры: почему человек может ставить на кон своих родственников? Он предложил короля, торгующегося со смертью - конечно же, король располагает определённым правом распоряжения своими подданными.

Армат, будучи занятым человеком, смог написать текст только в пятницу вечером (какое счастье, что на игру недели на самом-то деле давалось 9 дней, то есть двое выходных). Первые версии были в формате .doc, я предложила Гуглдоки, чтобы можно было вносить изменения совместно и сразу видеть обновления, а не перебрасываться файлами. Этот инструмент себя оправдала, и удобные, вполне привычно устроенные Гуглдоки не вызвали у Армата сопротивления.

Повествование должно к тому же должно быть быть нелинейным. Мне оно представлялось в виде соединённых стрелками линейных диалогов (так устроена большая часть диалоговых пакетов). Армату такой формат был незнаком и чужд, а больше всего он боялся (как я потом выяснила), что я заставлю его работать в таблице. Писатели не любят таблиц. Но ему всё равно надо было как-то обозначать переходы между блоками. Выход из положения был найден на книжной полке, где стояло полное собрание Бой-книг - серии, любимой нами обоими (ещё бы, это же недурные переводы Fighting Fantasy). Далее Армат изложил тексты игры в формате нумерованных абзацев.

Кстати, в игре оказалось пять концовок:


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

Я уже была готова к тому, что бесплатно доступны только какие-то куцые поделки, а цены полнофункциональных пакетов начинаются с $10 - как мне попался Fungus, бесплатный пакет, созданный сообществом любителей литературных игр ради всеобщего блага. И он оказался великолепен! Может, у него не было столько типов сообщений и встроенной Луа, как у лидера рынка, но свою работу он выполнял чётко и отлаженно, его инструменты были почти безупречны (правда, почему-то заставляли процессор сильно греться - именно во время редактирования). Он даже поддерживал постепенный вывод сообщения, паузы после знаков препинания и озвучку (в том числе условный JRPG-шный голос). Средства интеграции с остальной игрой были естественны и удобны для использования, а система команд - не хуже, чем у событий в Мейкере, так что в основном моя разработка дальше происходила в Фунгусе.

Конечная схема выглядела вот так:


Настройка внешнего вида сообщений также не заняла много времени, я просто убрала рамку и фон, выключив соответствующие объекты, а также подобрала шрифт (см. Графика).

Пакет кубиков
А вот с пакетом кубиков, как ни странно, меня ждала засада. Как я уже говорила, заставить в Юнити катиться кубик по физике - дело нескольких кликов, но я хотела по максимуму сэкономить усилия и решила воспользоваться готовым пакетом, чтобы не писать свой бросатель, детектор значений, не текстурировать кубик... Естественным выбором оказался Dice Pack, а точнее, его бесплатная демо-версия. В демо-версии были только шестигранники и десятигранники, но мне вообще нужны были только первые.

Сэкономить на графике мне пакет помог... А вот код пакета пришлось наполовину переписать. С точки зрения хорошего программирования он был написан ужасно, в частности, весь код бросков был в статических членах класса Dice! Это плохо не только по философии Юнити, но и просто по объекто-ориентированному программированию. Кроме того, этот класс не был снабжён событиями для интеграции его с остальной игрой. Что касается кода самих кубиков, те определяли верхнюю грань каким-то хитрым способом, который давал сбои. Эту часть я переписала полностью, прилепив к каждой грани кубика по пустому объекту и просто подсчитывая, который выше на момент остановки. Кстати, механизм остановки тоже пришлось доработать, чтобы остановка засчитывалась через секунду спокойного лежания кубика, а значение в этот момент кэшировалось. Так мне удалось избавиться от всех случаев, когда в броске оказывались неизвестные значения.

Но не удалось - от случаев выпадения кубиков за границы блюда, хотя вообще-то она была обёрнута невидимыми стенками не хуже блендера.



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

Суммарно возня с кубиками заняла, наверное, 30% времени разработки.

Графика

За всё время разработки мне пришлось запускать графический редактор всего один раз: чтобы заменить строну кубика с единицей на коронованный череп. Смерть, человеческие черепа, блюдо и кубики - всё это пришло из магазина Юнити. Денег мне стоил только человеческий череп, и всего $2. Не знаю, заметили ли вы мерцающий свет, как от факела, но он тоже из магазина Юнити (в общем-то, он должен был влиять на атмосферу на подсознательном уровне). А шрифты были взяты из свободных источников. Кстати, иконка коронованного черепа тоже - с замечательного Game Icons.

Удивительно, что никто не спросил, почему у Смерти - бычий череп. Первоначально это было, конечно, потому что не нашлось бесплатного человеческого - не хотелось тратить деньги, когда ещё не было ясно, что мы доделаем игру. А потом стало привычно, и заменять уже не захотелось. То, что никого не удивило такое положение вещей, подтверждает верность решения. К тому же смерть с человеческим черепом пришлось бы переанимировать, такие покачивающиеся движения бы для него не подошли. Да и выразительность от него ожидалась бы побольше, например, блеск в глазах.

Анимация
В игре анимировано всего три вещи: покачивание головы Смерти, подъём блюда и падение черепов в конце. Движение камеры между Смертью и блюдом тоже можно считать анимацией, поскольку сделано это по той же технологии. А именно - с помощью инструмента Animator в Юнити. Не буду разглагольствоваться о нём, поскольку хотя и добилась своего, но не до конца поняла его логику... Во всяком случае падающие черепа анимированы уже программно: не было времени разбираться, заставить череп двигаться по той же траектории, но из произвольной точки, а сдать игру уже хотелось. Так или иначе, инструмент произвёл на меня огромное впечатление: он может управлять любыми параметрами и делать это в зависимости от поступающих внутрь значений, так что художник-аниматор в жизни не должен будет даже заглядывать в код.

Звуки
Вся музыка в игре - свободная и взята с сайта Purple Planet (из треков, доступных свободно). Надо сказать, что по запросу free ambient nusic в Гугле преимущественно находится royalty-free music - то, что можно купить один раз и больше не платить отчислений! И цена у каждого такого трека обычно немалая.

Звуки в игре - также свободные, с сайта Free Sound. В частности, потусторонний вздох Смерти взят из коллекции A Portrait of A Woman (в двух частях), где автор выложила очень специфические ремиксы голосов женщин. Вот так, кто-нибудь сказал бы - кому может понадобиться этот гротеск, эта детская игра со звуковым редактором, а мне они пришлись кстати! Помимо двух звуков смерти, в игре также использован звук для стуканья кубиков - на самом деле это падение Лего.

Правила игры в кости
Подбор правил для игры в кости - вот это была настоящая гейм-дизайнерская задача, то есть профильная для меня. Армат, однако, тоже поучаствовал. Мы рассмотрели многие игры, но большая часть из них не подошла: либо бросался один кубик, либо нужно было выписывать счёт, либо бросали две стороны, а мне хотелось ограничиться одним бросоком. В конечном итоге правила были выдуманы из смеси игр свинья, очко и покер на кубиках. Кстати, сначала я пробовала в качестве магического числа 20, поскольку с 21 выпавшие двойки вообще не нужны: нет такой комбинации четырёх кубиков, составляющей 21, в которой была бы двойка. Но с целевым числом 20 выиграть было слишком просто, а получить самую плохую концовку - почти невозможно.

Объём работ
Задача Армата была довольно предсказуема: ему нужно было написать определённый объём текста и составить его в схему, причём сделать это в срок, достаточно полно и самостоятельно (иначе мне бы не удалось сэкономить своё время). Он с ней справился, а также помог с выбором игр в кости и с тестированием.

Моей задачей было сделать всё остальное. Кажется, что это не очень много, особенно учитывая, что столько решений было взято готовых. Но дьявол кроется в мелочах. Мне сильно помогло предварительное знание о некоторых тонкостях Юнити и C#, хоть плотно я с ними до сих пор не работало. Например, должен ли финальный экран с черепами быть отдельной сценой или всё той же? Если да, как сделать, чтобы на нём в итоге появлялось такое же меню, как на главном экране? Можно ли просто сделать объект диалога перманентным? (Нет, это не сработало, пришлось делать отдельный мини-диалог на сцене с черепами.) Как передать в диалог результат броска? Как настроить мерцающий факел, чтобы он был с одной стороны виден, а с другой - не мешал своим миганием? Как объяснить игроку, что он может кликать на кубики? (Подсветку я писала сама.) Как плавно поменять музыку? Когда это следует сделать?

Но в целом проект удался: я сдала его за несколько часов до срока и даже не самой последней. Значит, Юнити справилась со своей задачей - сэкономить мне время.