Как написать свой движок игры. Как написать игровой движок? Программы для создания игр

Эта статья является первой в целом цикле материалов для тех, кто хочет стать создателем игр. Если вы молоды, амбициозны и полны идей, а руки чешутся сделать "убийцу GTA" или "MMORPG типа WoW, но круче", то вы нашли то, что искали - руководство новичка по созданию игр . Моя цель - дать читателю общее представление о том, как же всё-таки выглядит процесс создания игр и развеять те иллюзии, которые могли сложиться на этот счёт, чтобы в последствии вы смогли избежать ошибок, совершаемых многими. Как и в любом деле, половина успеха - это правильная подготовка, поэтому чем полнее вы с самого начала будете представлять себе всю картину - тем большего успеха сможете добиться.

На данный момент цикл статей включает в себя следующие материалы, который со временем будет дополняться:

1. Создание игр для начинающих

Начинающий Разработчик Игр - В Простонародии "Чайник"

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

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

Создание Игр - Развлечение?

Будьте готовы к тому, что даже относительно небольшой игровой проект может отнять у вас не один месяц времени на его завершение. Подумайте - достаточно ли у вас мотивации, чтобы продолжать работать над воплощением своей идеи даже после того, как начальный азарт угаснет?.. Наверное, не ошибусь, если скажу, что доля проектов, не доведённых до конца и брошенных на разных этапах разработки, стремится к 99%... Вы ведь не хотите пополнить это число своей идеей, правда?

Типовой Портрет Начинающего Разработчика

При ближайшем рассмотрении идея оказывается клоном чего-то популярного и известного, "но лучше". Так как представления о том, чего же, собственно, хочется, и как организовать продуктивную работу, нет, то в команду приглашаются все либо почти все. В итоге такая "команда" складывается из случайных людей, которые в течение недели-двух создают видимость бурного обсуждения "проЭкта", иногда даже что-то пытаются сделать (вроде 3D-модели из набора примитивов), но примерно через это же время былой энтузиазм сходит на "нет", у членов команды появляются неотложные дела/сессия/уроки/бабушка заболела и вся затея благополучно рассыпается как карточный домик. Знакомая картина?..

Разработка Игр - Профессия или Хобби?

Любитель , как правило, имеет иной источник дохода (в случае, если он уже достаточно взрослый человек), поэтому над ним не висит вопрос коммерческой успешности своего проекта. Аналогично для тех, кто учится в школе/ПТУ/ВУЗе - они могут работать над игрой в своё удовольствие, бросить в любой момент, реализовывать любые идеи и вообще испытывают гораздо больше свободы в своих действиях. С другой стороны, они не могут посвятить изучению инструментов и получению новых навыков достаточно времени, поэтому в постоянно меняющемся мире игр всегда серьёзно отстают технологически и качественно.

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

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

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

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

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

• Ну и в-третьих - делая ставку на свой проект, вы вкладываете в него время, деньги (хотя первоначально можно обойтись без значительных вложений) и ожидаете получить какую-то отдачу. И тут всё зависит от вас - на что наработаете, то и заработаете. Проект может быть как удачным, так и неудачным.

Цена Идеи для Игры

Не падайте в обморок, но идея сама по себе не имеет никакой цены. Ноль. Даже самая гениальная идея ничего не стоит. Идей великое множество, и некоторые из них весьма и весьма удачны. Тем не менее, идея не обладает практическим значением до тех пор, пока она не реализована в виде чего-то менее абстрактного.

Задумайтесь: когда в последний раз вы видели действительно оригинальную идею? "Аватар"? Нет - если разложить идею до уровня концепции, то всё просто: земляне из будущего добывают ресурсы на чужой планете, игнорируя интересы местного населения. Один из землян проникается сочувствием к аборигенам, становится частью их народа и возглавляет борьбу против захватчиков. Просто, не правда ли? Crysis? Классический шутер про элитного спецназовца с супер-способностями, которые ему даёт костюм, и пришельцами из космоса. World of Warcraft? Игра, действие которой происходит в богатой на события и предысторию вселенной, с высокой ролью сюжетной составляющей, разносторонними сложными взаимодействиями игроков и мощной экономической системой.

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

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

Английский Язык для Разработчика Игр

Я убеждён в том, что знание английского языка - это критический фактор , который оказывает огромное влияние на тот путь, который предстоит пройти, чтобы стать разработчиком игр. Даже с чисто практической точки зрения способность читать и понимать английские тексты - огромный козырь в борьбе за место под солнцем. Если вы откроете вакансии русских компаний-разработчиков, то в 90 % из них найдетё такой пункт, как "технический английский на уровне чтения и понимания".

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

Спрашивается - зачем довольствоваться каплей, если можно выпить море? Знание и понимание английского - это ваш ключ к огромному массиву полезной и актуальной информации, сам факт доступа к которой даст вам десять очков форы. Компании Digital Tutors и Gnomon Workshop имеют в своём активе тысячи часов обучающего видео по всем областям применения популярных 3D-пакетов, таких как Maya или 3DS Max. Англоязычные сайты кишат статьями о геймдеве, а на форумах могут подсказать решение сложных проблем - просто потому, что количество людей ТАМ несоизмеримо выше с количеством людей ЗДЕСЬ. Берите лучшее из двух миров!

Что делать? Учить языки - оно того стоит, даже если через год вы забросите геймдев. Как? Не спать на уроках в школе, записаться на курсы, использовать самоучители - путей много, было бы желание. Особое внимание стоит уделить лексике - вам совсем необязательно уметь говорить на этом языке, главное - уметь читать и понимать прочитанное. Уже после этого можно будет начать развивать навык восприятия английской речи на слух - и в этом могут помочь видеоуроки по 3D-графике, если вы художник, или аудиоуроки по английскому языку. Ещё раз повторюсь - по ту сторону языкового барьера огромный мир, полный информации. Не иметь к нему ключей - всё равно что учиться по черновику, когда рядом есть библиотека.

С недавним релизом бесплатной версии Unreal Engine и анонсом бесплатного Source 2 у вас появилось ещё больше возможностей делать собственные игры. Но выбор движка, подходящего под ваши потребности и навыки – дело не самое простое. Давайте же пробежимся по лучшим образцам бесплатного (ну почти, о чем ниже) софта для новичков и профессионалов.

Помимо движков в данной подборке существует еще масса не очень известных, но, если сказать помягче, очень крутых движков второго эшелона. Как правило на сайте разработчика есть упоминание возможности лицензирования, но в очень сыром виде, тут придется связываться напрямую. У всех движков есть свои плюсы и минусы. Например, движок недавнего Dying Light, разрабатываемый Techland , хорошо подходит для игр с открытым миром, но у него проблемы с дальностью прорисовки.

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

На передовой технологий – CryENGINE

CryENGINE – это чрезвычайно мощный игровой движок, созданный компанией-разработчиком Crytek, впервые представленный в игре Far Cry. Он предназначен для разработки под PC и консоли, включая PlayStation 4 и Xbox One. Его графические возможности превосходят Unity и UDK, и время от времени стоят на шаг впереди Unreal Engine 4: новейшее освещение, реалистичная физика, продвинутые системы анимации и многое другое. Последней игрой на CryENGINE была Ryse: Son of Rome. По аналогии с UDK и UE4 в CryENGINE встроены мощные и интуитивные функции, касающиеся работы с дизайном уровней.

Продуктивное использование CryENGINE потребует определённого времени на его изучение, и у вас могут возникнуть затруднения при отсутствии опыта работы с другими движками. Если вам не нужна графика уровня Crysis 3 или Ryse: Son of Rome, стоит присмотреться к чему-то более дружелюбному к пользователю.

Ценовая модель CryENGINE несколько отличается от конкурентов. За использование движка . Он не полностью бесплатный, как UE4 или Unity 5, зато не требует выплаты роялти, так что $9,90 – это всё, что вам придётся платить Crytek. В зависимости от размера вашей студии и команды, отсутствие роялти может быть огромным преимуществом.

Начинающим – Stencyl или GameMaker

Если вы только начинаете делать игры и не имеете никакого опыта в программировании, вам лучше начать с простейших инструментов. Из таковых самые популярные и общепризнанные – это Stencyl и GameMaker. Оба просты в освоении новичками, и на их основе уже создано несколько качественных игр.

Stencyl позволяет делать игры без программирования. Интерфейс полностью основан на перетаскивании, игры можно выпускать на Windows, Mac, Linux, iOS, Android и Flash. Если вы когда-нибудь имели дело с чем-то вроде Scratch, вы сразу узнаете LEGO-подобный подход к построению кода посредством размещения блоков. Stencyl задуман для простого создания спрайтовых игр, поэтому чаще служит основой паззлам и сайд-скроллерам. Что-нибудь сложное сделать будет проблематично, так что если решили работать над RPG или стратегией, присмотритесь к другому софту. С помощью Stencyl на свет появилось несколько популярных игр, в том числе Impossible Pixel и Zuki’s Quest. Также в нём есть встроенное обучение, которое расскажет обо всём, что вам нужно знать.

GameMaker – другая бесплатная утилита для новичков, с помощью которой можно делать игры для Windows, Mac, iOS и Android. Как и в Stencyl, тут почти всё работает на перетаскивании, но есть ещё и хуки для многопользовательских игр, ссылки на внешние SDK, возможность покопаться в коде и многое другое. Бесплатная версия при экспорте накладывает водяные знаки, но, тем не менее, GameMaker отлично подходит для первого раза и содержит встроенное обучение основам. Тут нет такового жанрового ограничения, как в Stencyl, и можно найти отдельные руководства для разных типов игр. В GameMaker сделали оригинальную версию Spelunky и Hotline Miami.

Конечно, всё не ограничивается этими двумя вариантами. Buildbox – относительно новая утилита, доступная в течение пробного периода и предлагающая тренировочную программу для изучения её работы, а GameSalad – уже давно известная популярная платформа, правда на неё жалуются из-за багов и нестабильной работы. Construct стоит внимания, если хотите делать игры на HTML5. В каждом случае главная проблема в том, что придётся сдерживать свои дизайнерские идеи. Это софт для новичков, и вы просто сломаете его в попытке сделать что-то сложное. То есть, игры получатся забагованными и нерабочими, если вы попытаетесь выйти за рамки задуманной системы. И всё же, это превосходное место для старта и подходящий вариант при отсутствии опыта в программировании.

Программистам среднего уровня, нацеленным на 2D-игры – Cocos2D

Cocos2D – это программа с открытым исходным кодом для создания 2D-игр. Игры можно выпускать на Windows, Mac, Android, iOS, Windows Phone или на веб-платформе.

Большая часть того, что вы будете делать в Cocos2D – это работа с C++ (также есть поддержка Lua и JavaScript), так что вам нужно освоить этот язык программирования, прежде чем вообще браться за Cocos2D. Однако, при знании упомянутых языков, программа становится довольно простой в использовании. В ней есть полноценная IDE, и она совершенно бесплатна, без каких-либо условностей. Как понятно по названию, утилита предназначена для создания двумерных игр, так что и работает она лучше с простыми спрайтовыми играми, где 3D ни к чему. 2D-игры можно делать и на Unity (который мы рассмотрим чуть далее), но в Cocos2D вникнуть попроще, если вы только начинаете (и конечно, знаете C++).

На Cocos2D создано немало успешных игр различных жанров, включая увенчанную наградами Badland.

Разработчикам, нацеленным на мобильные платформы – Unreal Engine или Unity

Если вы заинтересованы в сложных, трёхмерных играх, два наиболее популярных инструмента для их создания – это Unreal Engine и Unity. У обоих есть свои сильные и слабые стороны и разные моменты в лицензионных соглашениях, с которыми стоит ознакомиться перед принятием окончательного решения.

Unity позволяет вам делать трёхмерные и двумерные игры практически для любой платформы, включая Windows, Mac, Xbox, Playstation, Android, iOS и не только. Он поддерживает игровые ресурсы, созданные в 3ds Max, Maya, Softimage, Cinema 4D, Blender и другом софте. Unity использует C#, наряду с собственным языком программирования, так что не помешает для начала хорошенько их изучить. Если сравнивать Unity и Unreal, первый, пожалуй, попроще в освоении. У него есть богатый набор готовых поведений и встроенная библиотека игровых ресурсов, в которой довольно просто за ними следить. Во время работы над этим текстом я общался с несколькими разработчиками, и они думают, что Unity – лучший движок для первых проектов, потому что его проще понять и изучить, чем Unreal. Если вы уже сделали игру, скажем, на GameMaker, то сразу разберётесь, что к чему в Unity. Ещё Unity поддерживает альтернативные модели оплаты прямо в движке, включая несколько free-to-play моделей монетизации.

Функционал бесплатной персональной версии уже достаточно богат для вашего первого проекта. Создав игру на бесплатной версии, вам не нужно платить лицензионные отчисления или роялти, но тут есть некоторые оговорки, а именно – вы не сможете получить больше $100000 спонсирования /прибыли. В помощь начинающим разработчикам по Unity написано множество обучающих статей. Популярные игры на этом движке: Alto’s Adventure, Gone Home и находящаяся в разработке .

Unreal Engine 4 использует C++, так что при должном знании этого языка можно остановить свой выбор на нём, впрочем, игры можно будет создавать и не углубляясь в сам язык. Игры, сделанные на Unreal, Engine можно выпускать на PC, Mac, iOS, Android, Xbox One и Playstation 4. В Unreal в движок встроено практически всё, что вам понадобится, включая 3D-моделирование и работу с ландшафтом. Из-за столь богатого наполнения, освоить Unreal Engine 4 сложнее других инструментов разработки, и даже при хорошем знании C++ вам стоит приготовиться к изучению множества новых вещей. Зато вы сможете создавать по-настоящему впечатляющие игры. О тонкостях устройства Unreal можно узнать больше с помощью реверс-инжиниринга, но всё же без предварительного опыта разобраться с ним будет нелегко. Unreal Engine 4 – относительно новый движок, но на нём уже вышли такие игры, как Daylight и Tekken 7.

Для использования Unreal Engine 4, вам нужно дать согласие на выплату роялти, если ваша игра будет продаваться. После начала продаж игры или приложения вы платите за квартал. Может показаться, что это слишком большие деньги, но с учётом прибыли, которую будет приносить игра, это не так уж много.

Также стоит присмотреться к движку Source 2 от Valve, который в этом году тоже должен стать бесплатным.

Обновлено 01.10.15: В августе на GDC . Stingray работает на ядре технологии Bitsquid и основан на 64-разрядной архитектуре. Stingray был разработан, чтобы быть очень гибким и работать с всеми популярными платформами, от мобильных до виртуальной реальности. Технологии модульной структуры и управляемых данных означают, что разработчикам гораздо проще вносить изменения и можно сразу увидеть результаты сразу на нескольких подключенных устройствах, без повторной компиляции. Плюс к этому возможен быстрый перенос объектов между продуктами Autodesk. Прорыва с автоматизацией разработки пока не случилось. Если вы уже используете Unity или Unreal, то переходить не стоит, выигрыш пока не очень заметен. Позже мы расскажем подробней.

Король разработки – Source 2

На GDC 2015 Valve сделала несколько громких анонсов, и самым главным для игрового сообщества из них, наверное, был анонс Source 2. Это преемник движка Source, использовавшегося в Counter-Strike: Source, Half-Life 2 и множестве других игр. Разработчики уже несколько лет с нетерпением ждали движка следующего поколения в арсенале Valve. На пресс-конференции Джей Стелли (Jay Stelly) из Valve сказал: « для разработчиков контента. Наряду с анонсами Epic и Unity это поможет PC оставаться доминирующей платформой создания контента». Очевидно, Valve решила присоединиться к гонке движков вместе с Epic и Unity, предложив разработчикам больше вариантов на выбор. Однако, пока не совсем ясно, что значит «бесплатно для разработчиков контента»: речь о любых зарекомендовавших себя разработчиках или это какая-то особенная категория?

О дате релиза конкретной информации нет, известно лишь, что Source 2 выйдет в ближайшем будущем. Джей Стелли также заявил: «Мы нацелены на повышение продуктивности авторов контента. Учитывая, насколько важным становится пользовательский контент, Source 2 предназначен не только для профессионалов, он позволяет и самим игрокам принимать участие в разработке своих любимых игр». По этим словам можно предположить, что Source 2 будет доступен не только профессиональным студиям, но и любителям и моддерам, что сделали многие игры Valve такими популярными.

Мы обратились к Valve за дополнительной информацией, и эта статья будет дополнена, когда о новом движке будет известно больше. Но уже сейчас можно сказать наверняка, что Source 2 станет серьёзным конкурентом тяжеловесам в лице Unity и Unreal Engine 4, ведь, по словам Джелли, он тоже будет бесплатным.

Писателям – Twine/RPG Maker/AXMA

Не все мы эксперты в программировании, и даже Stencyl многим может показаться сложноватым. Если вы рассматриваете себя больше как рассказчика историй, у вас на выбор есть два прекрасных варианта: Twine и RPG Maker.

Для создания интерактивных нелинейных историй. Проще говоря, можно сделать игру в жанре «выбери своё приключение». Утилита невероятно проста в использовании. Вы соединяете сюжетные отрезки с помощью различных переходов, примерно как в диаграммах связей. Каждый доступный игроку выбор ведёт к новому тексту. Когда закончите, можете сразу разместить результат на сайте. Всё вполне понятно, но если где-то застряли или хотите добавить что-нибудь ещё, вам поможет руководство для начинающих. Популярные игры, созданные в Twine: A Kiss и Cry$tal Warrior Ke$ha.

Если Twine кажется вам чересчур старомодным, попробуйте RPG Maker. В бесплатной версии меньше возможностей, чем в платных альтернативах, но и она на многое способна. В изучении система проста: графика перетаскивается, диалоги добавляются в один клик. Чтобы сделать что-нибудь поинтереснее обычной RPG, придётся мыслить нестандартно, но примеры в лице тепло принятых публикой To the Moon и LISA дают понять, что это возможно. Вы можете пользоваться бесплатной музыкой и изображениями, так что даже рисовать уметь не нужно. Встроенное обучение, опять же, поможет вам в создании первой игры. Популярные игры на RPGMaker: Clock of Atonement и One Night. У Twine существует отечественный аналог AXMA Story Maker к которому также стоит присмотреться.

Бесплатный софт для игровых ресурсов

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

Tiled – простой редактор карт для Cocos2D, Unity и других инструментов.

OpenGamesArt – бесплатные изображения и графические заглушки.

Free Music Archive – бесплатная музыка с лицензиями Creative Commons.

FreeSound – коллекция бесплатных звуковых эффектов.

Всё это поможет вам делать игры без особых затрат. Разумеется, придётся вкладывать в них своё время, кровь, пот и слёзы, но, по крайней мере, ваш кошелёк не попадёт под удар.

Я определил, какие у движка должны быть библиотеки. Но то была больше теория. Сегодня я создал проект и применил теорию на практике. Вот что у меня получилось:

Вот так вот я организовал структуру своего движка. Давайте я рассмотрю подробней. Начну с папок. Всего создано шесть папок. Первая - _Doc, будет содержать ссылки на используемую документацию по движку (история, лист задач и т.д.). Фишка: обратили внимание на подчеркивание? Так вот, это сделано специально чтобы папка была в самом вверху и не смешивалась с папками движка (папки сортируются по имени).
Application - это уровень приложения. Как вы видите в ней всего один проект с тем же именем. Данный проект - это динамическая библиотека (подробнее о видах библиотек можете прочитать http://ru.wikipedia.org/wiki/Библиотека_(программирование)). Пользователь в идеале должен будет работать только с этой библиотекой.
Папка Core - это основа из схемы. Она содержит 4 проекта. Каждый проект - это статическая библиотека.
Папка Engine - это ядро из схемы. Все проекты из папки, также являются статическими библиотеками.
Папка Framework пуста, потому что пока нет смысла в ней что-то делать.
И папка Test будет хранить приложения для тестирования частей движка.

То есть в итоге у нас одна динамическая библиотека, одинадцать статических которые будут линковаться к динамической. И проект.

Я не стану пояснять как я создал такой проект, так как это долго. Да и не расчитанно на новичков.

На этом подготовка завершена. Продолжим.

Любое приложение должно с чего-то начинаться. Это называется точкой старта (или входа) приложения. Обычно это или main() или WinMain(), а также все их производные... Но в движке нет точки старта, потому что движок не запускается сам по себе. Точку старта задает пользователь при создании приложения. Но я начну именно с нее проектировать и писать код. Наша точка старта будет в приложении test.

Пользователь должен при старте, создать наследника от класса Application, полиморфировать нужные методы, инициализировать наследник, запустить его на выполнение и затем очистить ресурсы.
То есть получается так:

Поясню. Start - это условный момент запуска приложения. End - это условный момент завершения приложения. WinMain и MyApplication - это уровень приложения. Данные сущности пишутся пользователем. iApplication - это интерфейс из библиотеки Application. Как вы видите, я выделил их цветом согласно схемы из предыдущей статьи. Я так буду поступать и дальше чтобы вам было легче ориентироваться.

Начнем писать код. Для начала создадим класс приложения. Находим Application и пишем:
Application.h

200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once

#include "export.h"

Class ENGINE_DLL Application
{
public:
Application();
virtual ~Application();

// Инициализация приложения.
bool Create();

// выполнение одного кадра
bool RunOneFrame();

// Выполнение приложения.
void Run();

// Завершение приложения.
void Shutdown();

Bool IsInit(){return _isinit;}
bool IsExit() {return _exit;}

Protected:
virtual bool _init() = 0;
// пользовательский кадр
virtual bool _frame() = 0;
// пользовательская очистка
virtual void _close() = 0;

Private:
bool _isinit;
bool _exit;
};

200?"200px":""+(this.scrollHeight+5)+"px");">
#include "Application.h"

Application::Application() :
_isinit(false),
_exit(false)
{
}

Application::~Application()
{
// чистим за нерадивым программистом
if (_isinit==true)
Shutdown();
}

Bool Application::Create()
{
/*
Инициализация всех систем движка
*/

// пользовательская инициализация
if (_init() == false)
return false;
// сообщаем что приложение инициализировано
_isinit=true;
// сбрасываем флаг сообщающий о выходе
_exit = false;
return true;
}

Bool Application::RunOneFrame()
{
// следим чтобы не было попытки рисовать при неудачно инициализации
if (_isinit == false)
return false;

Return _frame();
}

Void Application::Run()
{
// Инициализируем
if(_isinit == false)
Create();

// выполняем бесконечный цикл
while (_exit==false && _isinit==true)
{
_exit = !(RunOneFrame());
}

// очищаем ресурсы
Shutdown();
}

Void Application::Shutdown()
{
_isinit = false;
}

Если вам нужен файл export.h, то он такой:

200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once

#ifdef WIN32
#ifdef _BUILD_ENGINE
#define ENGINE_DLL __declspec(dllexport)
#else
#define ENGINE_DLL __declspec(dllimport)
#endif
#else
#define ENGINE_DLL
#endif

При этом, где-то в Application должен быть объявлен _BUILD_ENGINE. В проекте на который я дал ссылку выше, все это уже есть.

Теперь вернемся к приложению:
main.cpp

200?"200px":""+(this.scrollHeight+5)+"px");">
#include
#include "../Application/Application.h"

Class MyApp: public Application
{
private:
protected:
// пишем пользовательские классы
virtual bool _init() { return true; }
virtual bool _frame() { return true; }
virtual void _close() {}
};

Int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pScmdline, int iCmdshow)
{
MyApp app;

Return 0;
}

Так, теперь двигаемся дальше. Вспомним для чего нам был нужен Application - для обертывания остальных сущностей. Среди которых главной была Engine. Значит теперь ее нужно создать. Далее, по текущей задаче мы должны создать окно и инициализировать рендер. Значит в модуле рендера появляются два класса - Window и Render. Но так как мы решили что сущность рендера абстрактна, то тогда нужен еще один класс RenderDX11 и WindowWin32, которые будут выполнять реализацию использования в рендере DirectX 11 в окне операционной системы Windows.

Схема усложняется:).
Начнем выполнение с конца. Находим библиотеку рендера и пишем код:
Window.h

200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once

#include

Class Window
{
public:
Window();
virtual ~Window();

/// Создать окно
virtual bool createWindow(const std::wstring &caption, unsigned int width, unsigned int height)=0;

/// Закрыть окно.
virtual void closeWindow()=0;

/** Показать/Скрыть окно.
@param
value определяет, показывать ли окно (при true) или не показывать.
*/
virtual void showWindow(bool value)=0;

/// Вернуть заголовок окна
virtual const std::wstring& getWindowName() const {return _caption;}

/// Изменить заголовок окна.
virtual void setWindowCaption(const std::wstring& _caption)=0;

Protected:
std::wstring _caption; ///< заголовок окна
unsigned int _width; ///< ширина клиентской части окна
unsigned int _height; ///< высота клиентской части окна
};

200?"200px":""+(this.scrollHeight+5)+"px");">
#include "Window.h"

Window::Window()
{
_width = 800;
_height= 600;
_caption = L"Engine";
}

Window::~Window()
{
}

Теперь нам нужен класс Render. Но тут я хочу сказать вот что - наш рендер должен быть единственным. Реализуем мы это через паттерн синглтон (погуглите, кому интересны подробности, прям по запросу "паттерн синглтон"). Так что сначала надо написать сам паттерн. Переходим к библиотеке Common. и пишем:
macros.h

200?"200px":""+(this.scrollHeight+5)+"px");">#pragma once

#include

#define Assert(a, b) assert(a && b)

200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once

#include "macros.h"

/** Singleton pattern implemented using templates.
@remarks
Using singleton is useful for objects such as engine
or managers which should have no more than a single
instance in the whole application.
@remarks
If you want to make object of some class singleton you
have to derive this class from Singleton class.
@remarks
If something goes wrong during singleton object creation,
deletion or on attempt to access it, assertion arises.
By "something going wrong" I also mean attempts to create
more than single object of class marked singleton.
*/
template
class Singleton
{
public:
/** Creates singleton of type T.
*/
Singleton()
{
Assert(!s_pSingleton, "Singleton class already instantiated.");

#if defined(_MSC_VER) && _MSC_VER < 1200
int offset=(int)(T*)1-(int)(Singleton *)(T*)1;
s_pSingleton=(T*)((int)this+offset);
#else
s_pSingleton=static_cast(this);
#endif
}

Virtual ~Singleton()
{
s_pSingleton=0;
}

/** Returns reference to a singleton.
*/
static T& getSingleton()
{
Assert(s_pSingleton, "Singleton class not instantiated.");
return(*s_pSingleton);
}

/** Returns pointer to a singleton.
*/
static T* getSingletonPtr()
{
return s_pSingleton;
}

/// A static pointer to an object of T type.
/// This is the core member of the singleton.
/// As it is declared as static no more than
/// one object of this type can exist at the time.
static T* s_pSingleton;
};

Template T* Singleton ::s_pSingleton=0;

Вообщем, я к сожалением на сегодня на этом завершаю:-(Хотел бы написать дальше, но 12 часов - пора спать. Ждите до завтра, будет продолжение. Мы наконец-то создадим окно и инициализируем движок.

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out . Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)

Your browser does not support HTML5 video.

Hop Out - та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры - перекрасить каждую из платформ, как в Q*Bert.

С чего бы кому-то хотеть написать игровой движок? Возможных причин много:

• Вы - ремесленник. Вам нравится строить системы с нуля и видеть, как они оживают.
• Вы хотите узнать больше о разработке игр. Я в игровой индустрии 14 лет и всё ещё пытаюсь в ней разобраться. Я даже не был уверен, что смогу написать движок с чистого листа, ведь это так сильно отличается от повседневных рабочих обязанностей программиста в большой студии. Я хотел проверить.
• Вам нравится ощущение контроля. Организовать код именно так, как вам хочется, и всегда знать, где что находится - это приносит удовольствие.
• Вас вдохновляют классические игровые движки, такие как AGI (1984), id Tech 1 (1993), Build (1995), и гиганты индустрии вроде Unity и Unreal.
• Вы верите, что мы, индустрия игр, должны сбросить покров таинственности с процесса разработки движков. Мы пока не очень-то освоили искусство разработки игр - куда там! Чем тщательнее мы рассмотрим этот процесс, тем выше наши шансы усовершенствовать его.

Игровые платформы в 2017-ом - мобильные, консоли и ПК - очень мощные и во многом похожи друг на друга. Разработка игрового движка перестала быть борьбой со слабым и редким железом, как это было в прошлом. По-моему, теперь это скорее борьба со сложностью вашего собственного произведения . Запросто можно сотворить монстра! Вот почему все советы в этой статье вращаются вокруг того, как сохранить код управляемым. Я объединил их в три группы:

1. Осознайте, что сериализация - обширная тема.

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

Используйте итеративный подход

Мой первый совет - не задерживаясь заставьте что-нибудь (что угодно!) работать, затем повторите.

По возможности, начните с образца приложения, которое инициализирует устройство и рисует что-нибудь на экране. В данном случае я скачал SDL , открыл Xcode-iOS/Test/TestiPhoneOS.xcodeproj , затем запустил на своём iPhone пример testgles2 .

Вуаля! У меня появился замечательный вращающийся кубик, использующий OpenGL ES 2.0.

Моим следующим шагом было скачивание сделанной кем-то 3D-модели Марио. Я быстро написал черновой загрузчик OBJ-файлов - этот формат не так уж сложен - и подправил пример, чтобы он отрисовывал Марио вместо кубика. Ещё я интегрировал SDL_Image , чтобы загружать текстуры.

Затем я реализовал управление двумя стиками, чтобы перемещать Марио. (Поначалу я рассматривал идею создания dual-stick шутера. Впрочем, не с Марио).

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

К тому моменту я отказался от формата OBJ и написал скрипт на Python для экспорта собственных JSON-файлов из Blender. Эти JSON-файлы описывали заскиненный меш, скелет и данные анимации. Я загружал эти файлы в игру с помощью библиотеки C++ JSON .

Как только всё заработало, я вернулся в Blender и создал более проработанного персонажа (Это был первый сделанный и зариганный мной трёхмерный человек. Я им весьма гордился.)

В течение следующих нескольких месяцев я сделал такие шаги:

• Начал выделять функции работы с векторами и матрицами в собственную библиотеку трёхмерной математики.
• Заменил.xcodeproj на проект CMake
• Заставил движок запускаться и на Windows, и на iOS, потому что мне нравится работать в Visual Studio.
• Начал перемещать код в отдельные библиотеки "engine" и "game". Со временем, я разделил их на ещё более мелкие библиотеки.
• Написал отдельное приложение, чтобы конвертировать мои JSON-файлы в бинарные данные, которые игра может загружать напрямую.
• В какой-то момент убрал все библиотеки SDL из iOS-сборки. (Cборка для Windows всё ещё использует SDL.)

Ключевой момент в следующем: я не планировал архитектуру движка до того как начал программировать . Это был осознанный выбор. Вместо этого я всего лишь писал максимально простой код, реализующий следующую часть функционала, затем смотрел на него, чтобы увидеть, какая архитектура возникла естественным образом. Под "архитектурой движка" я понимаю набор модулей, которые составляют игровой движок, зависимости между этими модулями и API для взаимодействия с каждым модулем.

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

Готов поспорить, что больше времени тратится при противоположном подходе: пытаться заранее продумать архитектуру, которая будет делать всё, что вам понадобится. Две моих любимых статьи про опасности чрезмерной инженерии - The Vicious Circle of Generalization Томаша Дабровски и Don’t Let Architecture Astronauts Scare You Джоэла Спольски.

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

Итеративный подход дал мне куда более элегантную архитектуру, чем я мог бы вообразить, глядя на чистый лист бумаги. iOS-сборка моего движка сегодня на 100% состоит из оригинального кода, включая собственную математическую библиотеку, шаблоны контейнеров, систему рефлексии/сериализации, фреймворк рендеринга, физику и аудио микшер. У меня были причины писать каждый из этих модулей самостоятельно, но для вас это может быть необязательным. Вместо этого есть множество отличных библиотек с открытым исходным кодом и разрешительной лицензией, которые могут оказаться подходящими вашему движку. GLM , Bullet Physics и STB headers - лишь некоторые из интересных примеров.

Дважды подумайте, прежде чем слишком обобщать

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

Время от времени нарушайте принцип DRY

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

• Owned<> для динамически выделяемых объектов, имеющих единственного владельца.
• Reference<> использует подсчёт ссылок чтобы позволить объекту иметь несколько владельцев.
• audio::AppOwned<> используется кодом за пределами аудио микшера. Это позволяет игровым системам владеть объектами, которые аудио микшер использует, такими как голос, который в данный момент воспроизводится.
• audio::AudioHandle<> использует систему подсчёта ссылок, внутреннюю для аудио микшера.

Может показаться, что некоторые из этих классов дублируют функциональность других, нарушая принцип DRY . В самом деле, в начале разработки я пытался повторно использовать существующий класс Reference<> как можно больше. Однако, я выяснил, что время жизни аудио-объекта подчиняется особым правилам: если объект закончил воспроизведение фрагмента, и игра не владеет указателем на этот объект, его можно сразу же поместить в очередь на удаление. Если игра захватила указатель, тогда аудио-объект не должен быть удалён. А если игра захватила указатель, но владелец указателя уничтожен до того, как воспроизведение закончилось, оно должно быть отменено. Вместо того чтобы усложнять Reference<> , я решил, что будет практичнее ввести отдельные классы шаблонов.

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

Использовать разные соглашения о вызове - это нормально

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

В моём C++ движке некоторые функции принадлежат классами, а некоторые - нет. Например, каждый противник в игре - это класс, и бо́льшая часть поведения противника реализована в этом классе, как и следовало ожидать. С другой стороны, в моём движке выполняются вызовом sphereCast() , функции в пространстве имён physics . sphereCast() не принадлежит какому-либо классу - это просто часть модуля physics . У меня есть система сборки, которая управляет зависимостями между модулями, что сохраняет код достаточно (для меня) хорошо организованным. Заворачивание этой функции в произвольный класс никоим образом не улучшит организацию кода.

Как минимум, постарайтесь представить, насколько сложными будут ваши требования. Если вы делаете маленькую игру вроде Flappy Bird, с несколькими ассетами, вам скорее всего не придётся много думать о сериализации. Вероятно, вы можете загружать текстуры напрямую из PNG и этого будет достаточно. Если вам нужен компактный бинарный формат с обратной совместимостью, но вы не хотите разрабатывать свой - взгляните на сторонние библиотеки, такие как Cereal или Boost.Serialization . Не думаю, что Google Protocol Buffers идеально подходят для сериализации игровых ресурсов, но они всё равно стоят изучения.

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

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

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

Разработка игр

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

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

Создание игр. Программирование

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

В первую очередь нужно освоить хотя бы несколько самых популярных языков программирования. Без этого создать качественную игру вряд ли получится. Почему же несколько языков? Неужели одного недостаточно? Дело в том, что каждый programming language имеет свою четкую область применения. Ниже мы рассмотрим самые востребованные языки и их применение при программировании игр.

Языки

Пожалуй, наиболее универсальным языком в плане программирования игр является C++. Большинство современных игр и движков для них пишутся именно на нем. В чем же особенность данного языка? Пожалуй, одно из главных достоинств C++ заключается в огромном количестве всеобъемлющих библиотек. Благодаря этому посредством данного языка можно написать все что угодно: от маленькой инди игрушки до крупного проекта ААА класса.

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

Python — это, пожалуй, лучший выбор для начинающего геймдева. Во-первых, синтаксис языка довольно прост. Для того чтобы начать программировать на Пайтоне, достаточно прочитать туториал и обладать нативным уровнем английского. Во-вторых, возможности данного языка программирования достаточно широки. Конечно, Пайтону не угнаться за C++ в плане функциональности. Тем не менее посредством Python можно создать вполне достойный софт (в том числе и игру). К примеру, на Пайтоне написаны такие игры, как "Батлфилд" (2005), "Цивилизация 4", "Симс 4" и много других проектов, которые стали настоящими хитами.

Java — еще один претендент, который определенно достоин внимания. Пожалуй, главное достоинство данного языка — полная кроссплатформенность. Это означает, что софт, написаный посредством "Ява", поддерживается всеми операционными системами ("Виндовс", "Линукс", "Андроид" и т.д.). Это позволяет быстро переделать игру под любую платформу. Помимо этого, Java дает программисту массу возможностей. За примерами далеко ходить не нужно. Вышеупомянутый "Майнкрафт" был написан именно на "Яве".

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

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

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

Программы для создания игр

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

Пожалуй, сама известная программа для разработки игр — Game Maker. Она предназначена для создания двухмерных проектов. Делать игры можно без навыков программирования. Вместо строчек кода пользователю предоставляют набор готовых действий. Все, что нужно сделать — создать объекты и определить правила взаимодействия между ними. Также стоит подметить, что рисовать спрайты можно прямо в Game Maker без использования посторонних программ. Поэтому софт является вполне самодостаточным. Мало того, Гейм Мейкер не обидит и продвинутых юзеров, которые обладают навыками программирования. Ведь в программе есть возможность добавлять свой исходный код. Посредством Game Maker можно создавать игры с видом сверху (РПГ, тактический шутер и т.д.) и сбоку (платформер).

Construct 2 — это еще один конструктор для разработки 2D-игр. Пожалуй, главная особенность данной программы — мультиплатформенность. Посредством "Конструкта" можно создавать игры для iOS, Android, Windows, Web и т.д. В плане функциональности Construct 2 ничем не уступает тому же "Гейм Мейкеру".

Вывод

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