Создание игрового мира с нуля. Как создать игру самому? Этапы создания игры. Программы для создания игр

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

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

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

Как разработать RPG-игру за неделю с нуля и без бюджета. Часть I.

RPG за неделю? С нуля? Это вообще возможно?
Я рискнул, и я сделал это.

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

Tom Bampton, автор ежемесячных обзоров игр в номинации «Игра на день» (www.gameinaday.com), сказал: "Дерзай!" Затем он добавил дополнительное условие - я должен сделать это, не используя существующие игровые движки. Мне можно использовать только основные библиотеки / API.

Сначала я отказался от этой идеи. У меня не было лишнего времени, чтобы на неделю отстранится от разработки текущего игрового проекта на работе. Но потом я подумал: да черт с ним, ведь что такое неделя? В типичной компании, например в Е.А., рабочая неделя составляет 40 часов. Так почему бы не сделать игру не за календарную неделю, а за 40 чистых часов? Это уже реальнее, - но я не хотел создавать очередной тетрис или арканоид. А как насчет ролевой игры - одного из самых сложных игровых жанров? Это возможно?

Я знал, что это будет чрезвычайно трудно. Но я принял вызов.

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

Так вот, как я создал игру в течение одной недели с нуля, и без бюджета. Если вам лень читать, и вы хотите побыстрее заглянуть в конец повествования, чтобы узнать, как выглядит конечный продукт, посмотреть все его баги, вы можете скачать версию игры для Windows здесь: http://www.rampantgames.com/hackenslash.html

ПЛАНИРОВАНИЕ
Цель
Создать олдскульную RPG в стиле старых игр начала 80-х, с видом "сверху вниз", например как The Temple of Apshai, Ultima III, и Telengard. Игрок будет двигаться через комнаты в типичном подземелье, сражаясь с различными монстрами с помощью «меча и магии». Постепенно он будет совершенствовать свои возможности получая опыт, повышая уровень, приобретая магическое снаряжение.

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

Правила разработки

Правило № 1: Время разработки ограничено одной неделей (включающей 40 часов)
На разработку игры должно быть потрачено в сумме не более 40 часов. Они будут включать время, потраченное на непосредственную работу над игрой и на ее обдумывание. Перерывы в разработке больше, чем десять минут, не будут учитываться. Это будет "идеальная" рабочая неделя из 40 высокопроизводительных часов.

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

Правило № 2: Использовать только бесплатные инструменты
За исключением программного обеспечения, которое поставляется с установкой Windows, используется только свободный софт, по возможности с открытым исходным кодом. Смысл этого - показать, что не нужны дорогие (или пусть даже дешевые) инструменты для разработки игры. На оборудование, такое как сканер, микрофон и цифровая фотокамера, данное правило не действует - если у вас их нет, будем считать, что их можно у кого-то одолжить.

Правило № 3: Нет движкам, только стандартные библиотеки / API
Игра должна быть создана "с нуля" без использования существующих игровых движков. Никакого обмана, и создания игры или каких-то ее частей с помощью конструкторов игр или использования подобного программного обеспечения.

Инструменты
Код:

Python 2,3 (http://www.python.org/)
PythonWin
PyGame (http://www.pygame.org/)
Py2exe – чтобы собрать что получится в исполняемый файл для распространения. (http://starship.python.net/crew/theller/py2exe/)

Gimp 2,0 (http://gimp-win.sourceforge.net/)
MS Paint (тот что идет с Windows) - для вставки скриншотов, захваченных клавишей PrintScreen (GIMP почему-то отказался это делать)
Бесплатные текстуры были взяты (http://www.textureartist.net/textures/index.htm) и (http://www.mayang.com/textures/)

Audacity (http://audacity.sourceforge.net/) плюс мой микрофон или бесплатные.

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

Час 1-10: Базовая архитектура
Проектирование движка и основных компонентов. Получить отображения мира на экране. Я должен реализовать возможность перемещать тестового игрока по всему миру, и смотреть на вещи, а затем превратить то, что получится, в игровой редактор.

Час 11-20: Возможности игрока
Реализация всех основных возможностей для игрока - перемещение, атака, открытие дверей, смерть, подбор вещей и использование инвентаря. Создать каркас представления всех объектов в окружающей среде, для тестирования возможностей игрока во взаимодействии с миром.

Час 21-30: Оживление мира
Добавить искусственный интеллект, игровые события, ловушки, спецэффекты. К концу этого периода я должен иметь достаточно полное техно-демо, включающее все основные особенности игры.

Час 31-40: Добавление контента и правил
Получить из техно-демки полноценную игру. Добавить все дополнительное содержимое. Добиться завершенности и баланса игровой механики. Отшлифовать все, на что хватит времени, добавить спецэффекты, анимацию и т.д.

После 40 часов: Тестирование и релиз игры
Протестировать, и устранить найденные ошибки (не добавляя новые возможности!) Собрать все в кучу, и выложить в интернете. Завершить документацию.

Дневник разработчика Hackenslash: Игра за неделю

Час 1 – Дикое проектирование и базовые классы
Этот час был проведен за созданием некоторых базовых классов для игры - и использования их в дальнейшем проектировании. Мир будет представлен в виде последовательности комнат, соединенных порталом. Все в мире базируется на комнатах, подобно тому, как это было в старых адвенчурах или MUDах. Большинство объектов в игре представлены как " GameObject ", который имеет позицию и содержимое (в том числе может содержать и другие объекты - карта может содержать комнаты, в комнате может быть сундук, в сундуке - меч... и, я думаю, меч может содержать несколько комнат, но мы так делать не будем.)

Я создаю объекты creature (существо) и player (Игрок)
Я генерирую набор атрибутов для существ, и внедряю их в класс. Видимо я задрот, который играет слишком много в РПГ игры. Я пока еще не знаю точно, как будет выглядеть и работать игровая механика.
Я делаю объект room (комната), наследуемый от GameObject. У комнаты есть ширина, высота, и стены - и на текущий момент больше ничего.

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

Час 2 - PyGame 101
Цель этого часа - инициализация PyGame, ну и начать хоть что-нибудь рисовать на экране. На самом деле, я провожу большую часть времени за чтением документации PyGame, пытаясь выяснить что там и как, поскольку у меня почти нет опыта использования PyGame или SDL.

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

Час 3 - Если бы стены имели уши, я б их сильно отругал.
Цель этой часа – обозначить контуры комнаты стенами, и отобразить это на все еще черном экране. Чтобы сделать это, мне нужна комната, и мне нужна графика. Приходится много сидеть над GIMPом, правя загруженные из интернета текстуры, так чтобы они превратились в подходящие тайлы. Я создаю класс менеджера текстур. И я заполняю структуру образца комнаты. Я также потратил немного больше времени, просматривая документацию PyGame, чтобы найти что-нибудь еще, что можно использовать, дабы сделать работу легче.

Час прошел. А у меня все тот же черный экран. Стен как не было, так и нет.

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

Не имея подробного плана проекта, действительно довольно легко запутаться, когда выполнив определенную работу Вы задаетесь вопросом "Что дальше?" Я решил, что если рисунок одной комнаты хорошо, то нарисовать две – вдвойне лучше.

Для хранения созданных комнат я создал файл "minidungeon".
Я начать добавлять логику порталов "portals" - отверстий в стенах, для перехода в другие комнаты (и предоставляющих всю информацию о смещении, необходимую для правильного отображения смежных комнат).

Час 5 - Hackenslash получает больше комнат

Я изменил название окна на "Hackenslash!". Просто потому, что это круто.
Я создал карту объектов для хранения комнат, и класс MapMaster содержащий несколько карт.
Я добавил вторую комнату и подключил к первой через портал.
Соседние комнаты подключены к текущей через порталы, и теперь отображаются на экране.
Я исправил некоторые ошибки отсечения, чтобы правильно отображались стены, частично выходящие за пределы окна.

Час 6 - за который мы улучшаем скил рисования

Добавил класс дверей, а также настроил карты для размещения двери (дверь должна быть общей для двух комнат). (Правка: Жаль, что я никогда это так и не использовал!)
Я создал еще 3 тайла стен, объединил их в одно изображение.
Графический вид стен изменяется в зависимости от типа.
Я делаю простую графику для вида сверху вниз.

Часы 7-8 – Вращения и восклицания!

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

Часы 9-11 – Елементы - бррр!

И вот опять, мне нужно решить вопрос "Что дальше?".

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

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

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

Часы 12 - 13 - Нам нужен Лут!

Я создаю графику и код для вещей. Удивительно, как много времени может отнять рисование. Особенно раздражает, когда изображение имеет вид, будто курица лапой рисовала, сколько бы усилий к этому не прилагалось.

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

Час 14 - Ковры

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

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

Зато уровень теперь выглядит круто. Ну, по крайней мере круче, чем черный.

Часы 15-16 - Click! Click!

Я занялся управлением мышью и обработкой событий.
Добавил управление персонажем мышью. Движение пока происходит рывками, нет плавной прокрутки уровня.
Игрок может выйти за пределы комнаты, отсутствует проверка столкновений.
Я исправил несколько ошибок.
Помучил GIMP и создал красивые лестницы.
.
На разработку уже затрачено почти 17 часов, так что я начинаю немного нервничать. Я прошел 2/5 пути создания игры, - закончился второй "рабочий день" разработки. То, что у меня уже сделано впечатляет, но я понимаю, что сделать осталось много больше. У меня есть еще четыре часа, чтобы закончить основные возможности игрока, и вложится в график. Это будет трудно... но я все равно не жалею, что потратил лишнее время на рисование графики!

Час 17 – Плавно перемещаемся, пока не стукнемся лбом о стену

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

Час 18 - Переступаем пороги

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

Час 19 - Лестница в небо, Адское меню

Мой брат вызвался сделать музыку для игры. Он сделал музыку для Void War, и получилось довольно хорошо. Это напомнило мне, что нужно сделать воспроизведение звука (и музыки). Вроде бы в PyGame это сделать довольно просто, поэтому оно не должно занять слишком много времени. (Правка:. Я так и не нашел для этого времени, к сожалению в Hackenslash вы не услышите ни единого звука.)

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

Учу лестницы перемещать игрока в новую комнату.
Я немного проштудировал Интернет и документацию PyGame, ища, нет ли где открытых исходных кодов подобного меню на PyGame. И не нашел ничего.
Я начал делать собственное меню.

Часы 20 - 21 - Что там с меню?

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

Час 22 – Заснуть в процессе

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

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

Час 23 - Боевые параметры!

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

Час 24 - Меню игрока

Я завершил оптимизации для окна параметров.
Создал всплывающее меню, которое появляется, когда игрок кликнет на персонажа.
Я создал быстрое меню для использования зелий, кастования заклинаний и т. д.
Я исправил некоторые ошибки в работе меню.

Час 25 – До(раз)пиливаю полы и стены

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

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

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

ПЕРЕРЫВ - Кризис!

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

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

Двери: Вырезано! Я очень хочу сделать двери в игре. Жалко расставаться с этой функцией - тем более, что я уже некоторое время работал на ней. Но остается еще слишком много работ, например искусственный интеллект. И, наверное, понадобится 2-3 часа, чтобы заставить их работать, а их у меня нет.
Инвентарь: упростить! Забудьте о дополнительном инвентаре, и возможности смены оружия по желанию. Все, что подобрано и не стало текущим оснащением, будет сразу пересчитано в деньги.
Ловушки: упростить! Я хотел бы иметь множество ловушек с интересными и разнообразными последствиями их активации. Не судьба. Ловушки будет иметь простой визуальный эффект, наносить урон и временно увеличивать вероятность нарваться на случайного монстра
Луки (стрелковое оружие): Вырезано! В игре будет только оружие ближнего боя, на расстоянии можно атаковать заклинаниями.
Сохранение / загрузка игры: упростить! Сохранить можно только персонажа, а не состояние мира. (ПРАВКА: Я и этого не сделал!)
Система частиц: Отложить! Создание системы частиц перемещено в самый низ списка приоритетов. Я сомневаюсь, что придется их делать. Хотелось бы сделать впечатляющие визуальные эффекты с помощью частиц для заклинаний... но, скорее всего, этого никогда не будет.
Заклинания: упростить! У меня была серьезная концепция о заклинаниях: их можно было бы найти в виде свитков, и количество более десятка. Это грустно, но будет всего несколько заклинаний: Лечение, Урон, Ослабление, Усиление, и Восстановление. При повышении уровня, можно позволить игроку усилить заклинания за счет увеличения числа магических очков.
Анимация монстров и игроков: Вырезано! Я никудышный художник, чтобы сделать это достаточно быстро.

Принимая решение, что я не буду делать (или то, что отложу на после), не менее важно решить, что нужно сделать в первую очередь.

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

Отлично, с приоритетами разобрались, продолжаем разработку.

Час 26 - Бросим кости

Я работаю над механикой «игральных костей», - механизма, с помощью которого в игру будет внесен элемент случайности. Поскольку у нас нет ограничения реальных костей, мы можем получать случайное число любого желаемого диапазона. Например от 1 до 33, или от 6 до 17. Так что я могу бросить кости, сравнить то, что выпало со своей атакой и защитой врага. Если выпавшее число выше защиты, атака удалась.

Например, предположим, что у меня общее значение атаки 15. Я атакую монстра, у которого 10 защиты. Мои шансы 15 из 25 (25 =15 +10), или 3 из 5. Так игра будет генерировать случайное число между 1 и 25, и если оно выше десяти, я выиграю.

Для вычисления нанесенного урона используется немного другой способ. Я добавил защищающемуся параметр «броня», а атакующему "урон". Я генерирую случайное число от 1 до их суммы, а затем вычитаю броню. Если результат меньше единицы, урон не наносится. В противном случае, он равен полученному результату. Таким образом, если монстр, с уроном равным 10 атакует игрока с 5 очками брони, игра будет генерировать число от 1 до 15, из которого вычтет 5, то, что получится, и есть нанесенный урон.

Это объяснение и описание заняло больше времени, чем его реализация.

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

Your browser does not support HTML5 video.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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