Как создаются игры. Основы разработки для начинающих игроделов - Григорий Радовильский

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

* * *

Среди программистов можно выделить ряд специалистов.

• Специалист по клиенту занимается реализацией игровой логики и визуализации игрового процесса на стороне запускаемой у игрока программы.

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

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

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

• Программист по средствам администрирования создает инструменты для работы с данными игроков, аналитики и собственно администрирования.

Контроль качества

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

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

Баг (bug – «жук») – понятие бага как ошибки при выполнении какой-то программы восходит к временам, когда компьютеры были большими, и нечаянно забравшиеся в них тараканы и прочая живность могли привести к сбою. По легенде, в 1947 году сотрудники Гарвардского университета обнаружили неисправность в одном реле университетского компьютера, вызванную залезшим в него мотыльком. С тех пор все ошибки, которые могут появляться при работе проекта, называются багами.

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

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

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

Менеджмент

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

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

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

Есть несколько подходов к менеджменту разработки. Например, семейство методик управления проектами Agile (гибкая методология разработки), которое позволяет заниматься постановкой и обсуждением задач не слишком часто, но и не слишком редко. При этом в процессе этапа все специалисты должны быть заняты выполнением своих задач, а не обсуждением или объяснением. Обычно рассматриваются короткие этапы, циклы работы, длящиеся одну-две недели, которые называются «спринты» (sprint – забег на короткую дистанцию). Задачи выдаются и реализовываются за это время. И после рассматриваются результаты этой итерации, выдаются оценки, выясняется, где возникли проблемы, где нужно сосредоточить больше внимания, ставятся новые приоритеты.

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

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

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

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

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

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

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

Маркетинг и продуктовая аналитика

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