Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан Страница 34

потери. Делайте последовательные сохранения с все возрастающим номером версий, чтобы при необходимости можно было вернуться. Если вы уже используете систему контроля версий, или СКВ (инструмент для управления изменениями, внесенными в компьютерные файлы), почаще фиксируйте внесенные изменения. Вы также можете сохранять работы в онлайн-хранилище, которое при необходимости позволит вам вернуться к более ранней версии. Если вы когда-нибудь потеряете все сделанное и вам придется начинать все сначала, не переживайте по этому поводу. Повторить нужную работу во второй раз окажется проще.

На протяжении всей нашей работы над вертикальным срезом – и на протяжении всего процесса разработки – мы должны постоянно тестировать нашу игру. Мы подробно рассмотрим это в следующей главе.

Определитесь с игровым движком и аппаратной платформой

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

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

Наводите и поддерживайте порядок в проекте

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

Следите за проектной папкой следующим образом.

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

• Используйте вложенные папки, когда папка заполняется таким количеством элементов, что становится трудно быстро найти нужный файл (обычно десять файлов или около того).

Простую иерархию проектной папки можно найти на сайте этой книги, playfulproductionprocess.com, и использовать ее в качестве отправной точки.

Для поддержания в порядке вашего кода можно делать следующее.

• Структурируйте и комментируйте свой код таким образом, чтобы его было легко читать и понимать, когда вы не просматривали его в течение некоторого времени или когда другим нужно над ним поработать.

• Выбирайте описательные, но не слишком длинные имена переменных.

• Используйте стиль camelCase, чтобы сделать имена переменных более удобочитаемыми.

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

Другие хорошие практики:

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

• используйте систему контроля версий для создания онлайн-хранилища кода и ассетов, чтобы поделиться с членами команды и при необходимости вернуться к предыдущей версии.

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

Кстати, вы уже работаете не над прототипом или тестовой версией игры. Никогда не называйте ассет, папку или скрипт tempSomething. Я потерял счет тому, сколько проектов я видел, где персонаж игрока в уже продаваемой версии игры называется playerTest. Когда определенные элементы вступают в игру, они имеют тенденцию в ней оставаться и развиваться. Обычно переименовывать что-либо довольно сложно, и это может даже нарушить ход разработки игры. Ваш вертикальный срез – ваш реальный проект, поэтому выбирайте имена соответственно.

Начните добавлять функции отладки

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

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

Ошибайтесь рано, ошибайтесь быстро, ошибайтесь часто

Неудачи неизбежны в итеративном дизайне. Многое из того, что мы попробуем, не сработает. А это значит, что неудача – это не так уж плохо и мы должны скорректировать под это свой подход. Если что-то, что мы пытаемся сделать, проваливается, мы должны взять себя в руки и попробовать еще раз.