От программиста может потребоваться хорошее знание специфики движка, на котором разрабатывается игра, особенностей операционной системы, где игра должна запускаться, или понимание, как на уровне кода защитить игру от взлома, ломающего игровой баланс или дающего одному игроку не предусмотренное правилами игры преимущество над другим.
В зависимости от сложности проекта от программистов может потребоваться решение очень специфичных задач. В отличие от художников, у программистов нет последовательной работы (например, от скетча до анимированного персонажа), но у них тоже есть специфические зоны ответственности, требующие определенного опыта и знаний.
Начнем с того, что мы, надеюсь, и так хорошо знаем: игры бывают однопользовательские и многопользовательские.
• Однопользовательские приложения выполняют простую функцию: собирают действия пользователя, обрабатывают их и визуализируют результат. Так работают не только игры, но практически все программы, работающие с локальными данными. Например, программы, входящие в офисный пакет, или графические редакторы.
• Многопользовательские же игры не могут существовать без механизма связи пользователей друг с другом. Соответственно, им нужен либо какой-то метод поиска других игроков, находящихся поблизости, с помощью Wi-Fi или Bluetooth, или вообще всех игроков в эту игру через интернет.
Вариант с игроками поблизости еще можно реализовать только одним клиентским (запускающимся у игрока) приложением. И функцию сервера (приложения, собирающего и обрабатывающего данные всех игроков) будет выполнять приложение одного из игроков. Но второй вариант неизбежно порождает необходимость иметь серверное приложение, которое будет запущено на отдельно стоящем компьютере или в облаке.
В самом простом варианте отдельное серверное приложение будет просто помогать игрокам найти друг друга, при этом в качестве боевого сервера (на котором рассчитывается бой) все равно может выступать один из клиентов. В этом случае сервер должен просто удостовериться в том, что пользователи находятся достаточно близко друг к другу, чтобы минимизировать задержки (если это важно, конечно), и установить соединение между ними.
В более сложном варианте серверное приложение будет заниматься получением команд от клиентских приложений, расчетом результатов их действий и раздачей этих результатов обратно игрокам. Это будет выполнять любой сервер в многопользовательской игре, даже устройство одного из игроков. Соответственно, клиент должен уметь отдавать серверу данные о действиях игрока, получать от сервера обработанные данные и как-то их визуализировать – функции клиентского приложения значительно отличаются от функций однопользовательского приложения. В результате мы получаем двух специалистов, один из которых занимается клиентом, а другой – сервером.
Если игра многопользовательская, то появляется необходимость администрировать пользователей. Закрывать доступ к игре для тех, кто нарушает правила игры, или начислять какому-нибудь игроку награду за победу в конкурсе, проведенном на форуме, посвященном игре. Здесь необходима разработка средств администрирования. Это может быть отдельная программа или сайт, которые недоступны простым игрокам. Сюда же можно отнести и различные аналитические сервисы, которые могут понадобиться игре.
Также, если наша игра имеет какие-то уровни, независимо от того, является ли игра шутером или головоломкой, для нее, скорее всего, придется сделать редактор уровней. С шутерами и аркадами немного проще: современные средства разработки по умолчанию имеют редактор уровней, в целом подходящий для создания игр этих жанров. А вот для игр других жанров, скорее всего, придется создавать редактор уровней с нуля.
Чтобы облегчить работу над игрой, можно воспользоваться одним из многочисленных движков для разработки клиента игры. Современные движки позволяют разрабатывать игры разного уровня сложности, качества, жанров и бизнес-моделей. При этом большинство движков бесплатны для обучения и работы и требуют лишь делиться доходом от выпущенной игры, часто после достижения довольно высоких показателей. При желании можно потратить время на разработку собственного движка, но это значительно увеличивает время разработки и риски. Это же относится и к серверной части: существуют сервисы, которые облегчают разработку серверной части игры и средств администрирования и аналитики. Они тоже бывают бесплатными и работают примерно по такой же схеме, за процент от дохода.
Среди программистов можно выделить ряд специалистов.
• Специалист по клиенту занимается реализацией игровой логики и визуализации игрового процесса на стороне запускаемой у игрока программы.
• Серверный программист создает серверную логику для того, чтобы у игрока сохранялся прогресс, чтобы игроки могли найти друг друга для битвы на арене или совместного прохождения игры, чтобы игра могла сама следить за соблюдением игроками правил.
• UI-программист занимается сборкой и настройкой интерфейсов, спроектированных гейм-дизайнерами и отрисованных художниками. Для интерфейсов важна оптимизация процессов, чтобы избежать повторения работы и добиться максимальной производительности.
• Разработчик редактора карт создает инструменты, необходимые гейм-дизайнеру для работы над игровыми уровнями. Также может возникнуть необходимость разработать инструменты для реализации в игре диалогов или более удобного и быстрого создания библиотеки игровых предметов и персонажей.
• Программист по средствам администрирования создает инструменты для работы с данными игроков, аналитики и собственно администрирования.
Контроль качества
Игры – очень сложные программы, работоспособность которых зависит от очень большого количества факторов. Компоненты самого устройства, на котором будет запускаться игра, драйвера, операционная система, внешние библиотеки, которыми игра будет пользоваться, размер и соотношение сторон экрана, качество соединения с интернетом и множество других факторов, которые почти невозможно учесть, но можно постараться проверить.
Учитывая сложность продукта, которым являются игры, и количество разных людей, участвующих в их реализации, одним из важнейших критериев качества игры является даже не исполнение отдельных ее компонентов – красивая графика, интересный игровой процесс, – а общая работоспособность, то есть отсутствие багов. И тут на сцену выходят бойцы невидимого фронта – тестировщики.
Баг (bug – «жук») – понятие бага как ошибки при выполнении какой-то программы восходит к временам, когда компьютеры были большими, и нечаянно забравшиеся в них тараканы и прочая живность могли привести к сбою. По легенде, в 1947 году сотрудники Гарвардского университета обнаружили неисправность в одном реле университетского компьютера, вызванную залезшим в него мотыльком. С тех пор все ошибки, которые могут появляться при работе проекта, называются багами.
Разработчики игры должны играть в свою игру не только для того, чтобы удостовериться в соответствии ее механик задумке или в том, что математика делает интересным игровой процесс, но и для того чтобы удостовериться в том, что игра вообще запускается и работает так, как было задумано. Тестировщики занимаются поиском проблем, которые проглядели или не догадались проверить другие члены команды. И к чисто системным проверкам различных устройств, на которых игра должна запускаться, добавляется, конечно же, проверка работы и гейм-дизайнеров с программистами. Возможно, только работа художников освобождена от зоркого взгляда тестировщиков, и то лишь потому, что художники обычно не вставляют свою работу в игру, этим занимаются дизайнеры уровней и контента.
Практически все компоненты, кроме идеологических, могут быть потенциальным источником ошибок. Интерфейс может работать не так, как ожидается, вызывая неправильные реакции: открывать не те окна, воспроизводить не те звуки. На уровнях могут быть ошибки в виде неправильно расположенных предметов: недостижимых или летающих в воздухе. Или, наоборот, игрок может зайти туда, куда не должен. Могут вызываться неправильные сценки, неправильные диалоги. В текстах могут встречаться опечатки. Могут быть неправильно настроены характеристики предметов и персонажей или неправильно выдаваться награда.
Несмотря на то что все, что может, должно быть автоматизировано, практически все тестирование в играх ручное. И человек, занимающийся тестированием, должен день за днем играть в одну и ту же игру, проверяя исправление старых ошибок и обнаруживая появление новых. При этом исследовать надо не только места, связанные с текущими задачами, но всю игру, потому что всегда что-то может пойти не так в совершенно случайном месте.
Менеджмент
Для реализации игрового проекта недостаточно руководителя, дизайнеров, художников, программистов, тестировщиков. Есть еще целый ряд работ и ролей, которые должны быть выполнены для того, чтобы получить законченный, качественный и успешный продукт.
Чтобы процесс разработки игры вообще шел, а не стоял на месте, необходимо этим процессом управлять. Кто-то должен заниматься постановкой, распределением и определением приоритетов задач. Значит, в компании должен быть человек, который не занимается программированием, документацией или артом, а занят тем, что контролирует загруженность тех или иных разработчиков и их производительность. Эта работа управленческая, и занимаются ей менеджеры.
В главе 4, посвященной процессу разработки, мы будем много говорить про итеративность этого процесса. Обычно вся работа делится на этапы, в начале которых решается, что именно будет делаться во время этапа, а в конце подводятся итоги: удалось ли выполнить все запланированное, если нет, то почему. В процессе разработки игры будет несколько различных видов этапов разной продолжительности для выполнения локальных и глобальных задач.