Реально ли самому написать игровой движок. Игровой Движок - Написать Самому или Взять Готовый

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

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

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

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

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

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

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

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

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

Что должны учитывать будущие разработчики игр? С какого языка начать обучение? К чему стремиться? На кого равняться? И что необходимо сделать в первую очередь?

Большинство любителей рок-музыки рано или поздно берут в руки гитару. Фанаты спорта страстно мечтают о выходе на футбольное поле, баскетбольную площадку или теннисный корт. Ну а те, кто совершил сотни угонов в GTA, провел десятки часов в компьютерных клубах за Counter-Strike или достиг немалых успехов в MMORPG, наверняка задумываются о карьере разработчика игр.

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

К чему стремиться?

Перед походом в магазин вы составляете список покупок (хотя бы в голове). Перед поездкой в другой конец города – прокладываете маршрут. Ну а перед тем, как обучаться разработке игр, целесообразно задаться вопросом: чем именно вы хотите заниматься? Создавать мобильные приложения или браузерные игры? Трудиться в крупной компании или маленькой? Профессионально заниматься разработкой игр или посвящать этому свободное от работы время? И если первое, то что интересует вас больше: создание интерфейса, отшлифовка геймплея или написание скриптов?

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

Какой язык учить?

Кроме того, от цели зависит и ответ на животрепещущий вопрос: с какого языка программирования стоит начинать?

Так, будущим разработчикам игр вроде Minecraft и мобильных приложений под Android стоит обратить пристальное внимание на Java. Для начала советуем пройти интенсив , тем более, что это бесплатно. Тем, кто заглядывается в сторону iOS – на Objective-C. Для браузерных игр порой хватает знания Ruby-On-Rails. Для совсем маленьких и простых временами достаточно HTML. В производстве Flash-игр используется ActionScript, а для написания скриптов любой сложности вам понадобится JavaScript или, возможно, не столь распространенная Lua. Для создания же небольших консольных игр требуется знание C#.

Что до наиболее крупнобюджетных игр (так называемого класса AAA), то большинство из них оснащены своим или заимствованным у коллег "движком". Нередко, впрочем, весь "движок" или его большая часть написана на C++. Именно этот язык использовался при создании множества известных "игрушек" – от Doom 3 и Call Of Duty до FIFA и The Sims. В то время как классика вроде Quake была написана на C.

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

Достаточно ли одного языка?

Одна из прелестей программирования – возможность постоянного саморазвития. В разработке же игр (особенно крупных) самосовершенствование, в том числе изучение как можно большего количества языков, – не прихоть, а жизненная необходимость. Так, опытные разработчики, трудящиеся на благо гигантов игровой индустрии, нередко сталкиваются с необходимостью поочередно писать на 7-8 языках. При этом, помимо вышеуказанных языков, им приходится изучать, к примеру, Python либо и вовсе SQL (как вы понимаете, для создания баз данных).

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

С ЧЕГО НАЧАТЬ?

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

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

Что брать за ориентир?

Тот, кто мечтает стать писателем, прочитает сотни книг перед тем, как напишет хотя бы одно слово. Мастера игры на фортепиано на зубок знают лучшие произведения Штрауса, Шопена и Бетховена. Известные же художники перед крупными выставками наизусть заучивали историю искусств.

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

С недавним релизом бесплатной версии 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 – коллекция бесплатных звуковых эффектов.

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

В последнее время я занят тем, что пишу игровой движок на 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 идеально подходят для сериализации игровых ресурсов, но они всё равно стоят изучения.

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

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