В разработке как оно есть

Что надо знать на этапе подготовки и внедрения фич.

Когда перед тобой стоит огромное количество задач, то иногда что-то упускаешь, а это влечёт за собой колоссальные последствия. Наше дело: поделиться с вами опытом и деталями разработки игры.

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

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

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

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

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

Итого, этап «Идеи» состоит из следующих подэтапов:

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

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

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

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

Либо, если ваша ЦА — это дети от 0 до 8 лет, то вводить в игру маньяка с кровавыми топорами — не лучшая идея. Однако на этапе брейншторма такие идеи не должны отметаться ни в коем случае.

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

Этим этапом у нас занимается геймдизайнер. Собирает в кучу ещё раз то, что обсуждалось на предыдущем этапе, и переводит это в «слова на бумаге», составляя техническое задание. Здесь идёт полное подробное разъяснение по работе элементов игры.

В основном описывается несколько типовых документов: для художника и для программиста и ещё 3D-моделлера. В первом случае описывается элемент с визуальной стороны, во втором – с технической. Эти процессы могут показаться немного скучными, но геймдизайнер совсем так не считает и говорит что получает от этого «огромное удовольствие». Из этих документов образуется что-то ценное, значимое и целостное.

Что мы предлагаем для решения как творческих задач так и технических:

Декомпозиция. Разбивайте задачу на более мелкие части. В конечном результате, это сэкономит довольно много времени, каким бы это не казалось ресурсоёмким во всех смыслах.

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

Упрощение. Задачи, вызывающие затруднения при решении, чаще всего сложны по структуре и относятся уже к сфере деятельности программистов. Хороший способ справиться с такой задачей — это упростить её настолько, насколько возможно. Нередко удачно выбранная форма наглядного представления задачи сама способствует её упрощению, поскольку позволяет «увидеть» эффективный путь решения. примером этому послужит «Декомпозиция».

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

Как правило, большинство начинающих команд пропускают этот момент. Зачем заниматься какой-то «писаниной», когда можно собрать команду и сразу писать код? Существует большая вероятность возникновения ошибок организации игровой механики или ошибок реализации. Совет для геймдизайнера, который будет заниматься написанием ТЗ в вашем команде: пройдёт время, прежде чем вы добьётесь того, чтобы писать такое ТЗ, которое будет идеально подходить конкретно для членов вашей команды.

Также составление документации полезно для вас самих чтобы самому получить полноценное представление о конечном результате и оценить объём работ.

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

При построении игры на движке объединение объектов происходит постепенно с самого начала процесса. Не забывайте о ваших ресурсах и возможностях.

Время. При определении времени, которое планируется на написание кода, часто делают одну ошибку – не учитывают затраты времени на исправление багов и отладку кода.

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

Нерешаемые ошибки. Бывает, что разработчик сталкивается с нерешаемыми проблемами (либо решаемыми крайне тяжело), и ему приходиться пересматривать чуть ли не весь проект. Психологически это очень трудно. Совет один: будьте готовы пересмотреть весь проект и выполнить работу заново.

Не пытаться объять необъятное. Это пункт про трезвую оценку своих сил. Лично мне всегда нужно сделать больше, чем я реально могу сделать, и, забыв об этом в процессе разработки, можно попасть в очень неприятную ситуацию.

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

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

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

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

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

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

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

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

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

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

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

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

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

А как у вас проходит разработка? Делитесь своим опытом, мы всегда будем рады вашему фидбеку. По моему мнению, обмен опытом между командами разработчиков способствует как более качественной разработке, так и новым контактам, которые, в свою очередь, всем пригодятся!

Всем спасибо за внимание и желаю успешных релизов ваших проектов!