Как создаются игровые движки. Программирование игр: программы, особенности создания и рекомендации

Приветствую. Хотите узнать как создать игру самому и какие бывают этапы создания игры? В наше время чтобы создать простую игру на PC или телефон не обязательно нужно быть в этом большим специалистом, существуют специальные программы, которые позволяют создавать игры с нуля в одиночку.

В этой статье весь мой личный опыт

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

Куда больше материалов вы можете найти на специальной странице в этом блоге:

Я выделил 7 основных этапов создания игры.

Как создать игру самому?

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

Не совсем.

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

Существуют специальные программы для создания игр, одной из которых является Game Maker. Они были созданы специально для создания игр (программа так и называется - создатель игр). Лично я работаю в Game Maker и он позволяет делать вполне качественные игры под любые платформы, от андроида, до ios.

Так-же можно посоветовать Unity или Construct 2 , в качестве хороших альтернатив.

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

Если вы выбираете Game Maker - то мой блог и канал вам существенно помогут в его освоении, ну а если вам выбор остановится на Unity или чем-то еще, тотам тоже существует огромное количество бесплатных обучающих материалов высокого качества на Русском.

В любом случае, первый (нулевой:) этап - это выбор программы для создания игр.

Первый этап - дизайн документ

Далее вам нужно создать дизайн документ для новой игры. Другими словами - вам нужна идея игры. О чём будет игра? Что там будет происходить? Какой это будет жанр? Сколько времени и денег займёт разработка? Таких вопросов очень много и перед началом создания игры очень полезно составить какой-то примерный план.

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

Ну не прям вот ужас, да? Плохо конечно, но не прям вот?

Ну вот, это я рисовал компьютерной мышкой в очень простом графическом редакторе, а учился рисовать я 1-2 месяца, рисуя по 1 картинке в неделю, максимум.

Я думаю за год можно выйти на очень неплохой уровень, если выделять по 1-3 часа в день на рисование и на изучение теоретической базы.

У меня есть видео (16 минут) :

Там я рассказываю свои мысли о том как учиться рисовать и зачем это нужно.

Четвертый этап - звук

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

Сколько органов чувств задействовано у игрока?

Обоняние? Нет. Осязание? Иногда, что связанно с некоторыми системами управления в играх. Зрение? Вот на зрении всё и строиться, это основа.

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

Если вы раньше играли в компьютерные игры, то у вас наверняка есть любимые, а так-же есть какой-то любимый OST (Музыка из игр). И игра вам могла запомниться именно за счёт музыки. Про мой любимый OST я писал вот тут:

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

Вы же знаете про всякие специальные звуки и фразы в таких играх как Unreal Tournament и насколько сильно они увеличивают фан от игры.

Другими словами - верные звуки и музыка делают игру атмосферной, эмоциональной, человечной и куда более интересной.

У меня был небольшой опыт когда я делал игру Lonely Dude.

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

Что я хочу сказать? Для простой игры совершенно необязательно сильно заморачиваться со звуком, достаточно просто поместить в игру звуки для основных действий (выстрел, взятие бонуса, завершение уровня, прыжок и т.п.) и это уже существенно усилит общее впечатление от игры. Музыку написать конечно существенно сложнее, но иногда можно купить трек за каких-то $1-5, ну или посидеть с такими программами как FL Studio, дабы написать пару простых треков для своей игры.

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

Поэтому игру нужно допиливать напильником как можно более тщательно и делать это нужно до релиза. Как нужно тестировать игру?

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

Седьмой этап - продажа игры и распространение

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

Как это можно делать я уже писал в своей старой статье:

Общие принципы сохраняются практически для любой игры.

Паблики ВК, свой ютуб канал, трейлер, базовое понимание продвижения и поисковой оптимизации и всё такое прочее.

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

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

Удачи вам в этом нелёгкое деле!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка игр на плаву, она перспективна и набирает популярность. Мы подготовили подробную инфографику о пути изучения разработки игр.

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

0. Разработка игр для детей

Многие книги ориентированы на работу с легендарной и интуитивно понятной средой разработки для детей Scratch, в том числе ScratchJr. После базиса следует информация о Python Pygame. Есть книга для пятилетних, но большая часть материалов подойдет для детей в возрасте от 8 лет.

1. Информатика

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

2. Языки программирования

Разговаривать на языке компьютера непросто, но возможно. И таких способов уйма. Например, язык C существенно повлиял на индустрию ПО, поделившись своим синтаксисом с популярными C#, C++ и Java. C++, в свою очередь, является мощным языком для создания эффективных программ и программных комплексов. Многие также пишут игры на C#: язык шустрый, удобный и позволяет быстрее стартовать разработку.

А вот Lua перенял кое-что от C++. Скрипт-язык хорош для игровой логики. Он упростит инициализацию уровня, привязку задач к объектам, смену поведения NPC в интерактивном режиме без необходимости перекомпилировать проект и многое другое.

3. Создание приложений

И если информатика – это базис теоретический, то здесь больше практики. Разработка игр – ухабистая стезя, и начать лучше с приложений. Книги с практическими заданиями, а также информацией о паттернах и UML помогут разобраться, что к чему.

4. Математика для разработки игр

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

5. Игровое программирование

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

6. Разработка игрового движка

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

7. Компьютерная графика

Да, содержимое – это важно, но именно компьютерная графика является аналогом интерфейса приложения, который будут видеть пользователи. Поэтому ей стоит уделить особое внимание.

Недаром этот раздел самый большой. Сюда включены основы программирования с Real-Time 3D, DirectX и OpenGL. Все дополнено информацией о рендеринге и технологиях. Отдельного внимания в подборке удостоились Direct3D и OpenGL.

8. Игровое аудио

Разработка игр касается и аудио: это звуки, издаваемые NPC, главным героем, явлениями или предметами, а также музыка. Аудио программирование обошлось всего двумя книгами, но в них доступно изложена необходимая информация.

9. Игровая физика и анимация

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

10. Игровой искусственный интеллект

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

11. Многопользовательское игровое программирование

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

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

Вот так вот я организовал структуру своего движка. Давайте я рассмотрю подробней. Начну с папок. Всего создано шесть папок. Первая - _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;
};

Application.cpp

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). Но запускать не советую - уйдет в бесконечность:) Мы ведь еще условий выхода не написали.

Так, теперь двигаемся дальше. Вспомним для чего нам был нужен 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; ///< высота клиентской части окна
};

Window.cpp

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)

Singleton.h

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;

Паттерн не мой, поэтому сохранен язык оригинала:-D

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

КАТЕГОРИИ