22 января 2016 г. в 10:00
by CoMiGo Games

Как делался Bitmaster — часть первая Как делался Bitmaster — часть первая


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

First of All

Время начала разработки — 26 декабря 2015 года. Как появилась идея игры? Можно сказать, что она появлялась в ходе её начальной разработки. Тем не менее, было решение сделать конкретно несложный аркадный шутер. Что-то подобное уже пытались сделать другие люди из моего окружения, но почему-то у них проект заглох, толком даже не начавшись. А назывался он, в обиходе, «Робомесиво». Поэтому старт выглядел как диалог в телеграме с руководителем того проекта, вот так:
И зловещий смех за кадром
Да, всё было спонтанно. Ассоциативным рядом выстроилось и настроение игры:
  1. Робомесиво было круто своими взрывами и обилием врагов, а также пушек, и всё это в 3D;
  2. из похожих игр мне известна старая добрая Geometry Wars;
  3. времени на разработку у меня не так уж и много — максимум до конца каникул, а это две недели;
  4. проект, по большей части, индивидуальный и включит в себя привлечение только одного человека (музыканта). Следовательно, нужно меньше уделять времени созданию контента и больше программированию и дизайну;
  5. чем проще и красочнее графика, тем быстрее создастся контент и удастся сделать конечный продукт;
  6. БАХ! делаем 3D аркаду в духе матрицы, с отсылками к Geometry Wars.
Нельзя не сказать, что до этого я играл в свежую игру Satellite Reign, которая поразила меня своей атмосферой и оформлением — как в плане графики, так и в плане музыки и шейдеров — под высокотехнологичную страну, где правят цифровые технологии. Разумеется, из неё я подчерпнул немало вдохновения.


Окей, у меня есть представление о том, что я собираюсь создать. А какие у меня на тот момент были навыки?
  1. добротное знание 3D — от пополигонального моделирования до скульптинга. Не идеальное, но хватает на создание качественных моделей;
  2. в сцепке с предыдущим — ненависть к текстурированию моделей. Делать текстуры — да, «знаю-умею-практикую», но натягивать их…
  3. продвинутые знания в Unreal Engine (блупринты);
  4. багаж знаний об играх вообще за многолетний опыт их создания, преимущественно на JS и GML;
  5. фееричные навыки графического дизайна и фотошопа;
  6. скромность.
У вас мало опыта? Не отчаивайтесь — 3-4 пункта мне не понадобились вообще. А если вдруг всё же появились трудности, не стесняйтесь привлекать сотрудников!
Тем не менее, есть при этом существенное ограничение — время. Учитывая то, что практически на всё пространство создания игры я работаю один, человеческие ресурсы надо распределять очень грамотно .
Вывод 1: правильная расстановка приоритетов, осознание имеющихся ресурсов и знание своих возможностей увеличит шансы на скорый выпуск продукта.
Следствие из 1: нельзя стараться с самого начала делать крупные проекты.

Начало разработки

Первые сутки у меня реально был «дедлайн» до конца дня. Разумеется, он потом перенёсся на конец выходных (дело было в субботу), далее до конца следующей недели… но что в этом плохого? Главное, что у меня была цель — как можно скорее сделать законченную игру.
Я не ждал магии, и магии не случилось — под утро «игрой» был лишь одиноко дрифтующий по арене кораблик. Но зато какой шейдер!

Арена к старту разработки уже была — она была подготовлена ещё для Робомесива. После этого всё (абсолютно всё) делалось самостоятельно в режиме реального времени .
Тем не менее, разработка шла семимильными шагами, и под вечер в игре уже были тупенькие мобы, намёки на графический интерфейс, прокачка единственной на то время пушки (за счёт бонусов) и полностью функционирующая менюха. Меню было сделано на UMG, а для переключения между интро и битвой был сделан отдельный актёр с вращающейся камерой на «жёрдочке» (компонент Spring Arm) и нацепленным на камеру мешем логотипа. Таким образом, у меня получалась игра с одним-единственным уровнем. В целом, всё шло по плану, и выглядело так, как и должно было выглядеть.

Вывод 2: знайте, что вы хотите сделать. При необходимости делайте скетчи, списки дел — это поможет сформулировать вашу идею и не забыть её. В условиях командной разработки же это и вовсе обязательно — чтобы создать что-то, необходимо представление о конечном результате.
Вывод 3: верьте в свои силы, и всё получится! Два дня работы — вот теперь это магия

Наполнение контентом
и первые висяки

Что я понимаю под контентом? Это, на самом деле, очень растяжимое понятие, и для меня сюда входят мобы, бонусы, пушки. Они за собой тянут новые меши, новый код, новые системы частиц и звуковые эффекты. Меши же требуют других материалов, а частицы требуют 2D графики и тонкой настройки. Звуки также нужно смешивать в Sound Cue, чтобы звуковое оформление не казалось однообразным.
Но если абстрагироваться от этой рутины (тем более, что меши простейшие, а для всех частиц и мобов есть шаблоны да общие классы), то это именно мобы и всякие игровые фишки — то, что делает игру разнообразной и уникальной.
Сюда бы ещё могли войти и уровни (дизайн карт), но не случае Bitmaster
Когда вы занимаетесь разработкой контента, лучше всего оставить на время компьютер и взять в руки тетрадь или любой другой предмет для рисования и письма — это помогает собрать мысли и позволяет сконцентрироваться на предмете разработки.
У меня были мел и доска в одной учебной аудитории. На ней я нарисовал внешний вид мобов, их характеристики, разницу между уровнями, а также виды пушек. Продемонстрировать, к сожалению, не смогу — все мои записи остались только в моей голове, ибо доску помыли без моего ведома.
После активной разработки важно не впасть в ситуацию, в которой оказался я:
Как минимум -50 минут времени. Если вспомнить первые два дня разработки, то это просто ужасная цифра!
Играть в компьютерные игры — это весело. Играть в свои собственные — ещё интересней. Но это отнимает очень много времени.
Вывод 4: не отвлекайтесь на тесты. Добавили фишку, проверили её — всё, вы молодец! Тут же забыли про неё и продолжили работу.
Совет: для продолжительных тестов и для оценки геймплея вообще лучше с самого начала найти бета-тестеров. Во-первых, они обладают мнением, отличным от вашего, и, во-вторых, более объективны, т.к. вы как автор можете и не видеть правды о динамике и механике игры.
Вывод 5: мотивация и самоконтроль — основа успешного проекта. Когда что-либо делаете, можно проговаривать про себя, что именно: вы же не скажете «захожу во Вконтакте»? Ставьте перед собой цели, общайтесь с людьми по поводу проекта, заведите TODO-лист для быстрого устранения багов и реализации новых фишек. Но не забывайте про отдых!
Как только стало понятно, что тестовые висяки съедают ну слишком много времени, я сразу же завёл себе список дел и всеми силами старался от него не отвлекаться.
Мой туду-лист второго января. Обратите внимание на последнее задание снизу.
Продуктивность с туду-листом действительно резко выросла, и дела пошли в гору. Казалось, игра на тот момент сделана на 90%. Однако многие игроделы говорят, что оставшиеся 10% проекта — это на самом деле ещё 90 (очень сильно соотносится с законом Парето). Как они были правы! А вот как Bitmaster был сделан на все 180%, будет рассказано в следующей части!

Отправить комментарий

Комментариев нет. Будете первым!

Подписка на обновления

Хорошим грех не делиться

Поиск по блогу

Последние записи в блоге

Возможно, вам понравится