С чего начинаются видеоигры (ч. 3): общая информация о процессе разработки

Семь раз отмерь, один раз отрежь.
Народная мудрость
 

Вступление, которое традиционно связывает блог с предыдущими частями, а заодно вносит пару уточняющих моментов
    Идея видеоигры придумана и утверждена, дизайн-документ составлен – что дальше? Дальше начинается превращение документации непосредственно в игру. Собираются люди, распределяются обязанности, каждому достаётся свой кусочек работы; если человек один, то логично, что вся работа ложится на его плечи.
    Уточнение первое: видеоигра – это компьютерная программа. В процессе её создания используются те же инструменты, что и при разработке других программ, – электронно-вычислительные машины (компьютеры) и языки программирования (с их помощью пишется, в частности, программное обеспечение, облегчающее и автоматизирующее труд, например: интегрированные среды разработки, игровые движки, графические, текстовые и звуковые редакторы).
    Уточнение второе: видеоигры – результат комплексной работы (за исключением ранних игр, давших старт возникновению игровой индустрии, и некоторых современных исключений), и для их создания необходимы разные профессии: программист, художник, музыкант, игровой дизайнер, сценарист и другие.
 

О подходах к разработке – правильном и реальном
    В идеальном мире видеоигровых дел мастера следуют цепочке «концепт-документ – дизайн-документ – разработка игры по планам», не торопятся, думают и ничего не исправляют в предыдущих «звеньях», потому что сразу делают хорошо. Однако в реальности существуют обстоятельства, из-за которых правильный подход может быть нарушен. Если не считать привычных для любой отрасли человеческого фактора и форс-мажорных обстоятельств, то к наиболее распространённым можно отнести следующие причины:
    1. Продумать абсолютно всё заранее – задача сложная.
    В маленьких видеоиграх хватает неявных деталей, упустить которые проще простого, а уж в крупных – и того больше. Конечно, с ростом опыта игрового дизайнера увеличивается и качество составляемой им документации, но от опрометчивых решений или пропущенных и забытых кусках дизайна не застрахован никто.
    2. То, что хорошо смотрится на бумаге, необязательно будет хорошо выглядеть в игре.
    Составленные задачки на проверку окажутся простыми или, наоборот, чрезмерно сложными; историческая достоверность вызовет скуку; реалистичное управление потребует одновременного использования пятнадцати кнопок; теоретическое очарование бескрайним космосом заменится вопросом: «Что здесь делать-то?», потому что ближайшие точки интереса расположены за миллионы световых лет – лететь к ним долго, а больше заняться нечем. Одно из решений проблемы – создание прототипов: механика, головоломка, уровень – спорные части по-быстрому набрасываются и проверяются на работоспособность.
    3. Использование так называемой гибкой методологии разработки не ускоряет рабочий процесс, когда речь заходит о создании полноформатных видеоигр.
    Методология довольно распространённая, плюсы у неё есть, но минусы перевешивают. Её применение в разработке видеоигр подразумевает, что документацию придётся составлять параллельно с выполнением других рабочих задач, а значит, полного и актуального в долгосрочной перспективе диздока не будет. Результат подхода – частые переделки, потеря конечной цели, затягивание работы и сваливание в производственный ад; а получившаяся видеоигра может значительно отличается от первоначального представления (иногда и до смены жанра доходит).
 

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

ПРОГРАММНЫЙ КОД

    Столп, на котором держится всё остальное. В видеоигре может отсутствовать графика, звуки или диалоги, но код в ней будет всегда. Используется для того, чтобы аппаратная часть (компьютер, игровая консоль, смартфон) или другая программа (операционная система, среда разработки) «понимала» и воспроизводила задаваемые программистом действия и команды.
    • Видеоигра должна запускаться на ОС «Виндовс»? Нужен соответствующий код.
    • Через ярлык запуска? Нужен соответствующий код.
    • Изображения и модели должны отображаться? Нужен соответствующий код.
    • С поддержкой шейдеров? Нужен соответствующий код.
    • Персонаж должен бегать и прыгать? Нужен соответствующий код.
    • У него есть здоровье, и оно может изменяться? Нужен соответствующий код.
    И так на каждое действие, которое есть в видеоигре или необходимо для её работы.
 

Программный код из игры «Обжоры». Он направляет, двигает и уничтожает игровой объект.
 

КОМПЬЮТЕРНАЯ ГРАФИКА

    В общем случае это вся визуальная часть – то, что отображается на экране при запуске видеоигры, а именно:
    1. Спрайты (англ. sprite) – двухмерные объекты – изображения, рисунки. Создаются, как правило, в графических редакторах или вручную, на бумаге, с последующей оцифровкой и переносом в электронный вид.
    2. 3Д-модели – трёхмерные объекты. Создаются в программах для 3Д-моделирования. За счёт третьего измерения усиливается реалистичность изображения (объекты можно осмотреть со всех сторон, и они будет выглядеть более естественно, чем спрайты), появляются «честные» тени и свет (имитация природных явлений).
    Любой игровой объект может быть предоставлен в виде 3Д-модели или спрайта – выбор остаётся за разработчиком.
    3. Текстуры – двухмерные изображения. Используются в связке с 3Д-моделями для придания им цвета. Также текстуры могут имитировать рельеф небольших деталей (швы, пуговицы, шрамы), если они необходимы, но на модели отсутствуют.
    4. Шрифты – двухмерные изображения текстовых символов – букв, цифр, значков. Создаются аналогично спрайтам, но после помещаются в отдельный файл, который учитывает характеристики шрифта, вроде межсимвольного и межстрочного расстояний.
 

Спрайты элементов меню, спрайт персонажа, спрайт объекта, модель без текстуры и с текстурой, шрифт, ASCII-графика
 

ЗВУКИ

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

Выбор инструментов
    Для начала необходимо определиться, какой из языков программирования и какие программы использовать для разработки. Подход во многом индивидуален, зависит от выбранной видеоигры, имеющегося опыта, удобства, личных предпочтений – и всё же некоторые обобщения можно сделать. Среди языков отдают предпочтение Си-подобным – «Си++» (англ. С++), «Си шарп» (англ. C#), «Ява» (англ. Java; примечание: иногда употребляют как «Джава», разница связана с неоднозначностью правил произношения и написания заимствованных слов). С программами сложнее – их слишком много, но в качестве ориентира можно выделить:
    1. Для написания кода – «Вижуал студия» (англ. Visual Studio), «Нетбинс» (англ. NetBeans);
    2. Для создания и редактирования изображений (спрайты, текстуры) – «Фотошоп» (англ. Photoshop), «ГИМП» (англ. GIMP);
    3. Для создания 3Д-моделей – «3дс Макс» (англ. 3ds Max), «Блендер» (англ. Blender);
    4. Для записи и обработки звука – «Саунд форж» (англ. Sound Forge), «Рипер» (англ. REAPER).
    5. Игровые движки – «Анриал Энджин» (англ. Unreal Engine), «Юнити» (англ. Unity), «Гейм мейкер студия» (англ. GameMaker: Studio).
 

Краткая справка, в которой раскрывается понятие «игровой движок»
    Она необходима, потому что больше всего споров, по негласной традиции, возникает вокруг игрового движка: насколько «название движка №1» лучше «название движка №2»? брать готовое решение или написать его самостоятельно? если готовое, то из свободного доступа или лицензировать внутренний движков какой-либо компании?
    Когда видеоигры только начали появляться, для каждой из них писали собственную кодовую базу, с нуля. Со временем игр становилось всё больше, а вместе с ними увеличивалось и количество реализаций различных функций. Часть этих функций выполняла одни и те же задачи и была написана очень схожим или вовсе одинаковым образом. Для того чтобы избежать повторов, часть кода, который дублировал сам себя, начали выносить отдельно. Так в видеоиграх появились свои системы – отрисовки (рендеринг кадра), расчёта столкновений, кодирования, обработки звуков, построения уровней и многие, многие другие. Системы строились таким образом, чтобы взаимодействовать друг с другом и не быть связанными с конкретной игрой.

Схематичное изображение условного игрового движка (количество систем от движка к движку отличается: один движок не умеет работать с 3Д-моделями, другой – с физикой, третий – только с физикой и умеет, четвёртый работает со всем подряд и так далее). Системы состоят из модулей (коричневые квадраты), а те – делятся на отдельные функции, каждая из которых исполняет свою узкую задачу.
 

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

Игровые движки – «Анриал Энджин», «Юнити», «Гейм мейкер студия», «Край Энджин» (англ. CryEngine), «Годо» (англ. Godot).
 

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

    Основные положения из дизайн-документа:
    1. Игра – аркада, двухмерная;
    2. Персонажи игры – младенцы, отличаются внешним видом, навыками;
    3. У персонажей есть очки жизни;
    4. Активный персонаж стоит на месте, может поворачиваться влево и вправо;
    5. С левой и с правой сторон в персонажа летят продукты – свежие и пропавшие, свежие продукты надо ловить, пропавшие – не надо;
    6. Игрок получает очки за качество, количество и последовательность съеденных продуктов;
    7. Разнообразие продуктов зависит от уровня;
    8. Уровни начинаются и завершаются по таймеру;
    9. Уровни находятся на одной локации, камера статичная;
    10. Победой считается прохождение всех уровней;
 

    Что нужно запрограммировать (при условии использования готового движка):
    1. Меню – главное и внутри уровня: выход из приложения, запуск уровня, возврат в главное меню из уровня, окно настроек, окно обучения, окно выбора персонажей, окна завершения игры при проигрыше и при победе, таймер, очки жизни;
    2. Персонажа – управление, характеристики (жизнь, навыки) и условия их изменения, действия персонажа при победе и проигрыше;
    3. Продукты – управление, характеристики (очки), условия появления и отключения;
    4. Таймер.
 

    Что нужно нарисовать:
    1. Меню – окна, кнопки;
    2. Сделать / подобрать шрифт;
    3. Персонажей – в полный рост для игры, портрет для выбора в меню, внешний вид при победе и проигрыше;
    4. Продукты;
    5. Фоны – главного меню и уровня;
 

    Что нужно озвучить:
    1. Меню – нажатия кнопок;
    2. Персонажей – реакцию на свежие и пропавшие продукты;
    3. Таймер – отсчёт последних секунд;
    4. Звуки проигрыша и победы;
    5. Написать фоновую музыку.
 

1. Пустой проект, заготовка под будущую видеоигру. 2. Файлы игры – анимация, звуки, графика, код и другие. 3. Эти же файлы игры, но в более привычном виде – в папке на жёстком диске. 4. Один из файлов игры (изображение) и его свойства. 5. Игровой объект (персонаж) и его свойства (выделено красным). Свойства объекта зависят также и от информации, полученной из файлов – в данном случае это внешний вид (изображение из предыдущего пункта), анимации движения, управление и реакция на другие объекты (выделено зелёным). 6. Как выглядит готовая игра… 7.… и как она выглядит на самом деле.
 

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

«Обжоры» в магазине «Майкрософт»
 

«Обжоры» на «Дропбоксе»