24 января 2016 г. в 09:00
by CoMiGo Games

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

Это продолжение первой части рассказа о создании игры Bitmaster. В ней будут рассказаны интересные решения и траурные лишения, баги и победа над ними, трудности и преимущества, связанные с выбором Unreal Engine и просто общие советы по тому, как создать и — самое главное! — выпустить свою собственную игру.
Помните тот снимок туду-листа? Я подозревал, что список дел может дойти до конца, но вот когда его пришлось делать в две колонки, было весело! В такой ситуации самое время вспомнить про такой термин, как Бритва Оккама.
Что это за страшное оружие? Это методологический термин, суть которого — не заниматься ненужной фигнёй Скажем так, у вас появилась идея нового моба или новой пушки, которая, разумеется, требует временные ресурсы на разработку. Когда уже и без этого проделана огромная работа, следует задать себе вопрос: «А нужно ли мне это на самом деле? Так ли это необходимо для игры и тех, кто в неё играет?»
Если всё добавлять всё новые и новые фичи (да и просто усовершенствовать игру), может произойти ужасное:
  1. вы можете увлечься, и выпуск вашей игры случится очень нескоро (если вообще случится!). True Story: человек делал и переделывал игру 13 лет, а получился, имхо, баговый платформер;
  2. у вас может получиться солянка, и игра потеряет свой стиль;
  3. если все эти фичи реально будут использоваться в игре, то она станет затруднённой в управлении.
Лично я уже этот процесс контролирую, а урезать мне пришлось несколько вещей. Так, сократилось количество пушек. Их задумывалось изначально пять: кроме лезвия, баньши, стандартной пукалки и дезинтегратора также задумывался магнитный пулемёт (в игре даже есть блупринт, но его никак не достать игроку). Однако, причин отказаться было несколько:
  1. эта пушка скопирована из стрелялки для телефонов Radiant, и там она мне не нравилась больше всего;
  2. она не работала по задумке снаряды должны были стремиться к ближайшему противнику, а при преждевременной смерти цели лететь в последнем направлении. Но по каким-то причинам не удалось успешно проводить поиск цели. Может, из-за недостатка умений или невнимания, или чего-то большего, но — не удалось, сколько ни бился;
  3. магнитная пушка — полный плагиат; взят даже внешний вид из Radiant. Учитывая, что у меня ВСЕ материалы (кроме пары SFX и совместной музыки) собственного производства, рушить карму было как-то не комильфо;
  4. новой динамики эта пушка бы не дала. Из-за своего поведения получилась бы некая смесь между баньши и лезвием — может лететь далеко, а может и не очень. Ширина поиска цели задумывалась чуть больше размера лезвия, а урон — как у простой пушки.
Из блупринта бонуса — магнитной пушки
По причине 2 мне также пришлось сделать «боксеров» (это те розовые и красные параллелепипеды с четырьмя вокруг) тупее: по задумке они должны были убегать от снарядов — ад для лезвий!
Тем не менее, я не зарываю их в землю — обновления будут, и в следующих релизах, надеюсь, проблемы с этими боксерами удастся победить!
Вывод 6: контролируйте список дел — вы не должны вечно усовершенствовать продукт. Не существует идеальных продуктов. Если так и зацикливаться на новых идеях, если гнаться за моднейшими тенденциями, за усовершенствованиями, то можно впасть в бесконечный цикл . Лучше сохраняйте блистательные идеи на потом — вы же не на один раз игру пишете?
Следствие из 6: распределяйте своё время на важное для ваших игроков.
Когда разнообразие мобов набралось и на арене их стали появляться десятки, возник эпичный вопрос: Что. За. Лаги. ?! При сравнительно небольшом количестве противников игра стала жутко тормозить — FPS серьёзно падал до 3х при наличии эдак сотни, что было критично.
В чём была истинная проблема — в графике или самой игре? Статистика показала, что обработка графики занимает считанные миллисекунды, а вот игровая петля составляла до 95% от всей обработки. Сюда входил Spawn объектов, обновление коллизии и абстрактное "Blueprints". Как были реализованы мобы? В целом, такой комплекс проблем мог быть вызван только их движением, которое реализовано просто как изменение глобальных координат согласно вектору скорости. Даже в браузерных играх оно является простейшим и позволяет генерировать тысячи объектов. Однако…
И оно стало, как бы это ни было странно.
Как оказалось, лучше перемещать объекты через встроенные компоненты вроде Character Movement или Projectile Movement. Также было понижено Tick Time у противников. Эти меры позволили ускорить игру эдак в десяток раз.
Верю, что можно сделать и ещё лучше — всё-таки нагрузка при Spawn объектов ещё велика.
Вывод 7: по закону подлости проблемы будут появляться из самых кошмарных и нежелательных мест. Тем не менее, все проблемы решаемы.
Что касаемо Unreal Engine, быстро в нём работают только стандартные крупные c++ классы: всё то, что пишется на блюпринтах и касается физики, перемещения, динамики вообще, обречено на лаги. Благо встроенные решения очень гибкие, разнообразные, отчего находят широкое применение в играх и сокращают время разработки.
Помимо чистки и оптимизации было очень интересно разбираться в системах частиц, в том, как их покрасивее завихрять, как просто и понятно реализовать эффект телепорта. При этом их надо было сделать экономными — оттого они все плоские.
Изучение чего-то нового, вообще, великолепная вещь для разрядки мозгов — так, я опробовал себя в роли звукача и клепал все 8-битные эффекты. Они не идеальны и не сложные, но это моё, и это круто Музыка тоже совместно делалась с музыкантом — так у нас есть трек общий, трек чисто мой и ещё один — музыканта. Использовались, кстати, Chiptone для SFX и Magix Music Maker для написания внутриигровой музыки.
Вывод 8: иногда полезно отвлекаться на другие дела (но не сильно!) — это помогает освежить мысли, взгляд на игру, а также не даёт вам «сгореть» — ведь от постоянного кодинга может надоесть даже разработка вашей собственной игры!
Вывод 9: собственный контент, независимость от чужих разработок — это великолепное явление. Во-первых, у вас никогда не будет проблем с авторскими правами, во-вторых — это полезно для общего развития в индивидуальном порядке и необходимо для относительно крупных проектов, а в-третьих — ваш проект будет именно таким, каким вы его задумывали, и уж точно будет выглядеть как единое целое.
Когда уже более чем основная часть игры готова, начинаются мелкие и покрупнее исправления, улучшения, которые делают пребывание в игре мягким и спокойным. Для меня это выразилось в интерфейсе и управлении —  так, было переделано главное меню: добавлена строка управления графикой и смена разрешения/фулскрин. Что смешно, эти кнопки для изменения отображения просто отправляют в консоль строковые команды — другой возможности даже включить полноэкранный режим в двиге попросту нет.
Я не стал делать сложного меню для настроек, а сделал всего одну кнопку с двумя режимами — для высоких и низких настроек графики. И не потому, что лень или не вышло, а потому что для игры моего масштаба такая сложная форма настроек не к месту, да и настройки «для блондинок» точно никого не запутают.
Что более важно, была добавлена информационная страница со всеми контролами и краткой информацией о геймплее:

Как видно, одни и те же действия можно выполнить множеством способов. Контролы удовлетворяют и «стрелочников», и «WASD-шников», и даже есть поддержка геймпада (его настройка и тестирование — это отдельная история). Кроме того, смена оружия может производиться ещё и с помощью внутриигрового графического интерфейса. В общем, задачей было сделать так, чтобы просто методом тыка на первых секундах можно было найти удобное для себя управление.
Вывод 10: справки и туториалы наряду с удобным управлением критичны для хорошего геймплея. Если в первые минуты игроку не будет подана самая база, то это вызовет крупные проблемы у играющего на протяжении всей игры, ибо именно эта база складывается в навыки, необходимые для прохождения.
Формат и размер справки специфичен для каждого жанра и даже для отдельных игр. Так, в шутерах, как и в Bitmaster, больше уделяется внимание интуитивности управления и динамике, нежели смыслу игры или вступительных испытаний. Вам когда-нибудь предлагали пройти туториал в Zombee Shooter или, скажем, Crimson Land? Помните ли вы сюжет?
В самом конце делались иконки, сплеш-экраны (проще всего это делать прямо в Unreal Engine, делая High Resolution Screenshot), готовились страницы на сайте.
Вот так по крупицам и появилась эта игра .
Если у вас есть вопросы по технической части — смело задавайте их в комментариях! Процесс программирования не вошёл в формат статьи, но мы готовы поделиться и с особенностями реализации. Военной тайны не раскроем, но на правильный путь наведём .

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

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

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

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

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

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

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