Уроки создания игрового движка. Как написать игровой движок

Видеоигры - это уже не набирающая обороты индустрия. Она в самом расцвете. Людей, играющих в видеоигры, больше, чем когда-либо. А это значит, что появляется много возможностей для новых людей пробиться и сделать отличную игру. Это можете быть вы! Но как это сделать? Процесс создания игр очень сложен, но вы можете сделать игру самостоятельно с небольшой помощью или финансированием. Мы расскажем вам об основах, которые вам нужно будет принимать во внимание, чтобы сделать свою игру и сделать ее хорошо. Просто начните с шага 1 ниже.

Шаги

Готовимся к успеху

Разберитесь со своей игрой. Вам нужно будет довольно много планировать и думать о глобальных проблемах, если вы хотите, чтобы процесс шел гладко. В каком жанре будет ваша игра (РПГ, шутер, платформер и т.д.)? На какой платформе будет выпущена ваша игра? Какие уникальные и отличительные черты будут у вашей игры? Для ответ на каждый вопрос требуется различный набор ресурсов, навыки и планирование, так как они по-разному влияют на разработку игры.

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

Будьте реалистом. Если бы штамповать игры как Mass Effect было легко, каждый бы этим занимался. Вам нужно понимать, что вы можете и не можете сделать без огромной студии и хорошего опыта за плечами. Также нужно быть реалистичным в том, что вы можете сделать за разумный отрезок времени. Если не будете смотреть реально на свои силы, то скорее всего быстро разочаруетесь и сдадитесь. А нам не хочется, чтобы вы сдались!

1. Найдите хорошее железо и софт. Создание игры на любом уровне выше «мобильного» требует компьютер, который большинство назовет «навороченным». Если вы используете старую систему, то быстро обнаружите, что не сможете запустить на нем игру, которую делаете. Вам также понадобятся некоторые очень мощные и довольно специализированные программы для создания игр. Некоторые из них дешевы или бесплатны, но остальные могут стоить довольно дорого. Хороший софт мы рассмотрим в следующих разделах, однако можете отметить, что софт, который вам понадобится, может включать программы для 3D моделирования, редакторы изображений, текстовые редакторы, компиляторы и т.д.

   • Как минимум вам будет нужен мощный процессор (по крайней мере четырехъядерный и желательно один из новых i5 или i7), много оперативной памяти и продвинутая видеокарта.

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

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

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

Под планированием понимается:

1. Цель. Выберите какую стоит делать игру, чтобы она была полулярной, изучите рынок. Даже если вы не предполагаете продавать игру, всё равно выполните этот пункт, вам тогда будет приятнее делать игру которая имеет спрос.

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

3. Архитектура. Это логика. Применяя нисходящий подход, сделайте иерархию функций. На каком-то этапе вы не сможете делать далее нисходящую архитектуру, не из-за того, что уже всё сделали, а из-за того, что тонкости реализации задают вам свои правила, тогда вам надо продолжить создание архитектуры восходящим способом, то есть исходя из особенностей API подкорректировать интерфейс более высокого уровня.

4. Проектирование. Более высшие функции состоят из вызовов более нижних, то есть они почти реализованы на этапе создания архитектуры. Спроектируйте реализацию самых нижних функций на псевдокоде. Псевдокод не должен быть кодом на С только на русском языке. Он должен быть короче минимум в 2 раза и описательно реализовывать алгоритм, отвечать не на вопрос как, а что, должен позволить сосредоточиться на самых сложных вещах. Из хорошего псевдокода получаются хорошие комментарии, не дублирующие код, а поясняющие его. Создайте тесты для нижних функций. Попытайтесь доказать правильность программы.

5. Конструирование. Только сейчас пришёл этап кодирования. Вы должны реализовать нижние функции и тесты и получить работающую программу. Используйте псевдокод для комментариев. Придерживайтесь определённого стиля форматирования.

На тестировании и отладке останавливаться не будем.

Хорошо производить планирование публично, так как другие помогут вам выявить ошибки, которые вы сами бы не выявили и уменьшить ваше время работы и улучшить результат.

Необходимые знания:

1. Планирование.

2. Немного трёхмерной математики в случае использования трёхмерной грфики. Досконально вам знать её не надо благодаря инкапсуляции. Она описана во многих книгах и справках о

Пост о воплощении мечты и о создании игры с нуля. И о граблях разной величины.

0. Дано

Когда-то, во времена не столь от нас отдаленные, когда интернет в Уфе был ещё с помегабайтной оплатой, я занимался созданием и разработкой локальных «фришных» серверов Lineage и WoW. Но вот появились безлимитные тарифы, а локальные сервисы начали терять свою актуальность и я ушёл в вебразработку.
В некотором роде, как хобби я даже сохранил своё отношение в Геймдеву, правда, с другой стороны – разработка ботов и всего такого.
Шли года, а мысль написать что-нибудь свое, с преферансом и поэтессами не переставала меня терзать. В какой-то момент я понял, что либо сейчас, либо уже никогда.

1. Идея и Прототип

С чего начинается разработка? C прототипа. А прототип - с идеи. Для первого проекта стоит создать что-то небольшое и простое. Питая любовь к головоломкам и пошаговым стратегиям, я увлекся мыслью, что нужно сделать какую-нибудь пошаговую головоломку. Поразмыслив, вспомнил одну интересную игру времён Спектрума (стоит отметить, что автор не так стар, как может показаться) идея которой была прекрасна в своей простоте. Игрок ходит на 1 клетку, обходя препятствия, а враги его преследуют и ходят на 2 клетки, но препятствия не обходят.

Если взять ситуацию “A,” то мы можем спокойно ходить вверх и вниз, а монстр просто будет упираться в стену. В ситуации “B” монстр находится в загончике, а мы можем спокойно ходить справа, сверху и снизу от него. Поскольку игра у нас детерминированная, то существуют два типа монстров, которые отличаются по цветам и алгоритму поиска пути. Это для того чтобы не было неопределённости куда пойдёт монстр, когда он стоит наискосок. Красный всегда сначала сокращает расстояние до нуля по оси X ситуация “C”, в ней монстр зайдёт в загончик и упрётся в стенку. Фиолетовый же по оси Y ситуация “D”, в ней монстр пойдёт вниз, а потом уже направо и съедает главного героя.

Тут ещё мог бы быть большой абзац про выбор «движка» для написания игры. Но, пожалуй, можно обойтись и парой слов; перед тем как попробовать Unity3D, я поковырялся в нативном Obj-C, Corona SDK, UE, Cocos2d и ещё пару 2D Фреймворках, название которых, так глубоко в стеке памяти, что уже и не откопать.
В итоге, выбор пал на Unity3D, он мне показался оптимальным и я неспешно начал писать. Через месяц появилось вот такое приложение для iPad.

В нём мы играли за мужичка в красном и убегали от мужичков в синем, параллельно собирали сердца – читай звезды. В тот момент мы ещё использовали кубы как стены, но затем для экономии пространства на экране заменили их.
Хотелось бы отметить, что до этого момента, я никогда не писал на C#, но писал на JS, поэтому прототип был написан UnityScript (это такой диалект JS в рамках Unity3D). И это были первые большие грабли, послужившие нам уроком. Пришлось переписывать всё на C# и это заняло пару месяцев.

2. Команда

Как верно то, что я писал на десятке языков, так верно и то, что я не в состоянии нарисовать даже прямую линию. Поэтому после создания прототипа я начал искать художника\3Dшника, для этого я зашёл на сайт по фрилансу и посмотрел первых три сотни человек, с десятком - списался. Найти человека, за долю в довольно рискованном проекте, задача не из легких. Но она разрешилась, и в проекте появился талантливый художник Рамиль; итак – нас стало двое.
Параллельно я искал инвестора. Дело не в отсутствии денег, чтобы купить плагины или устройства для теста, а в том, чтобы создать обязательства, которые помогут не забить (не сложить с себя полномочия) при определенных обстоятельствах. И такой инвестор нашелся, в виде друга, решившего вложить свои кровные, в эту сомнительную, как ему казалось, затею. Итак, нас стало трое. Отмечу, что к моменту запуска, бюджет игры составил всего около 100.000р., при этом, в эту сумму входит покупка нескольких Android устройств для тестирования, плагинов и озвучки.

3. Расширение базовой концепции игры

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

Концепт Арт

Основной фишкой игры мы планировали сделать то, что персонаж может вернуться во времени, на несколько ходов назад. Т.е. не отмену хода, а возможность переместиться 1 раз за уровень на клетку, где персонаж был 3 хода назад. Это давало огромное количество вариантов хода, но на первых же тестах выяснилось, что обычные игроки не в состоянии пройти такие уровни. Слишком сложно. Может стоить таки сделать Brainiac Edition?

Также мы много экспериментировали с размером уровней, в итоге остановились на том что весь уровень должен вмещаться на экран, даже на устройствах с небольшим экраном. Так у нас получились уровни 5х8 клеток. Но при этом у нас есть pinch zoom, для большепальцых или уровней 6х10. Кроме сокращения размера уровней, отключения возврата во времени, для упрощения была ещё добавлена отмена хода, до 5 раз за попытку.

4. 2D vs 3D

В какой-то момент наши тестовые билды выглядели так:

Ужас ужас

Скриншоты из сцены

В итоге на iphone4, слева(3D) было всего 20 кадров в секунду, а справа(2D), стабильные 60. При этом, справа, качество картинки, как вы видите, на порядок лучше. Сейчас конечно если ориентироваться на минимальную производительность уровня iphone5+ и делать специально несколько квадратную графику, кошерные шейдеры + lightmapping + lightp robes, можно и для 3D сделать отличную графику

В итоге было принято решение всё переделывать на 2D. Но тут мы совершили ошибку, которую уже потом было не исправить. 2D анимация может быть 2 типов, первый это последовательность кадров, второй это наложение и смещение спрайтов.

Наглядное сравнение

Поскольку у нас были 3D модели, мы выбрали первый вариант. В итоге это выльется в большой вес приложения, даже с учётом огромного кол-ва оптимизаций мы не сможем уложиться в 50 мегабайт.

5. Форс-мажоры - это возможность

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

Для тех кто не понял о чём речь

6. Техническая часть

Думаю, настало время поднять градус гиковости. Значимую часть времени разработки заняло создание генератора уровней. Генератор писался на питоне, потому как он был мне духовно близок и numpy позволял быстро оперировать матрицами.
Сам генератор на выходе создавал txt файл(который парсился Юнити для создания сцены) и серию картинок, показывающих пошаговое прохождение уровня.

Сейчас я могу сказать, что писание внешнего генератора на другом языке, это - плохая идея. Главным образом, тем, что игровая логика начинает прописываться в двух разных местах. А это - риск рассинхрона. Особенно, если учесть, что внутри игры, есть такие понятия, как анимация и время её исполнения. И в генераторе, и в игре каждая клетка сама следила за тем, что в ней происходит: кто вошёл, кто вышел, кто умер и т.д. Но клетки, вида телепорт или мухобойка (атакует близлежащие клетки), связывали несколько клеток между собой. И если в генераторе это не вызывало проблем, то в игре повторить то же было сложнее т.к. анимации персонажей из разных клеток должны были засинхронизироваться между собой.

Огромный кусок времени заняла интеграция нативных библиотек. Cкажу прямо: если можно купить готовую реализацию того, что вам нужно, смело покупайте. При этом желательно всё брать у одного продавца, потому как в Unity3D в манифесте (Андроид), есть такая штука как mainactivity и это место где разные плагины могут конфликтовать. Потом для iOS, скорее всего, у вас будут плагины, которые занимаются различным постпроцессингом, это тоже место для конфликтов. В целом нативные либы, это место где вы легко можете получить очень трудно выявляемые ошибки. Поэтому, почти всё, что связанно с нативным кодом, мы покупали у Prime31.

Полный список плагинов и несколько слов о каждом

7. Статистика

В релизе около 400кб, написанного мной кода. Ещё 150кб - это генератор и некоторые смежные скрипты.
В самой игре, на данный момент, 3 главы по 16 отобранных уровней. Также есть режим Испытаний, где ещё около 700 уровней, динамически распределённых по сложности.
В среднем уровень без звёзд можно пройти за 25 ходов. Самые сложные уровни со звёздами около 55.

8. Монетизация и продвижение

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

Это пятая статья из цикла материалов для начинающих разработчиков игр: Игровой движок - написать самому или взять готовый?

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

Почему не стоит писать свой игровой движок

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

Помимо бесплатных систем разработки игр, многие коммерческие игровые движки, полностью готовые к немедленному началу использования в игровых проектах, предлагают сразу несколько очень привлекательных схем лицензирования : полностью бесплатную (Unity 3D в бывшей Indie-редакции), смешанную схему с выплатой Royalties (Unreal Development Kit ) - 99 $ взнос за лицензию и выплаты 25 % прибыли после первых заработанных 5000 $, либо же доступную стоимость полновесной коммерческой лицензии (Unity Pro за 1500 $).

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

Для 95 % игровых проектов любого жанра и направленности возможно найти адекватное их потребностям готовое решение. Времена, когда игровые движки были диковинкой для отечественного рынка разработки игр и стоили больших денег, прошли - а вместе с ними закончились аргументы в пользу написания собственного игрового движка.

Более того, желание непременно написать всё самостоятельно вкупе с иллюзией того, что такое решение будет лучшим продуктом, чем уже существующие аналоги, может сыграть очень злую шутку с начинающими разработчиками, когда и так весьма ограниченные ресурсы вкладываются в совершенно не нужную задачу (личный опыт), в итоге приводя к преждевременной смерти проекта.

Подводим итог : написанием собственного игрового движка могут заниматься те, кто чётко представляет, что именно и зачем ему это нужно, видит адекватные преимущества такого подхода и способен за вменяемые сроки претворить свой план в жизнь. Всем остальным следует поискать готовое решение, благо оных в последнее время появилось достаточно - взять хотя бы те же Unity 3D и UDK.