Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

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

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

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

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

Статья будет полезна начинающим разработчикам игр. В ней мы рассмотрим преимущества и способы создания и рендеринга трёхмерных объектов для изометрических 2D-игр на примере Blender. В статье не будет каких-то сложных операций, достаточно начальных знаний 3D-редактора. Для примера рендеринга и анимации я взял башню из Dune2, и, чтобы ей было не так скучно одной, дополнил двумя постройками из Desert Strike.

Вместо предисловия

Vue используется во всех проектах FunCorp. Мы внимательно следим за развитием фреймворка, постоянно улучшаем процесс разработки и внедряем лучшие практики. И, конечно же, мы не могли пройти мимо и не перевести статью Филиппа Раковски, сооснователя VueStorefront, про новые фичи Vue 3, серьёзно влияющие на написание кода.


В прошлый раз мы рассматривали фичи, которые влияют на производительность Vue 3. Нам уже известно, что приложения, написанные на новой версии фреймворка, работают очень быстро, но производительность — не самое важное изменение. Для большинства разработчиков намного важнее то, как Vue 3 повлияет на стиль написания кода.

В этом посте описывается алгоритм, используемый в Generate Worlds — инструменте, позволяющем пользователям создавать и исследовать процедурные миры построением небольших множеств воксельных тайлов. Я приведу краткое описание алгоритма, а в следующих постах расскажу о его преимуществах в скорости и гибкости по сравнению с другими методами. Чтобы подробнее узнать о том, что такое процедурная генерация на основе ограничений (constraint-based procedural generation) и о том, чем она интересна, рекомендую прочитать мой предыдущий пост.

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

Одна из моих любимых частей спецификации CSS Grid — это grid-gap. Они позволяют легко создавать отступы между элементами внутри сетки.

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

W3C порекомендовала отказаться от свойства grid-gap в пользу простого gap и его использования в Flexbox и Multi-Column.

В этом руководстве мы посмотрим, как добавляли margins в Flexbox раньше и как это делает свойство gap, позволяя нам получить внутренние отступы без дополнительных ухищрений.

Привет Хабр.

Raspberry Pi наверное есть дома почти у каждого, и рискну предположить, что у многих она валяется без дела. А ведь Raspberry это не только ценный мех, но и вполне мощный fanless-компьютер с Linux. Сегодня мы рассмотрим полезные возможности Raspberry Pi, для использования которых код писать не придется совсем.

Для тех кому интересно, подробности под катом. Статья рассчитана для начинающих.

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

Введение

Цель этого проекта — создание клона движка DOOM, использующего ресурсы, выпущенные вместе с Ultimate DOOM (версия со Steam).

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

У меня нет опыта создания игр или игровых движков, и мало опыта в написании статей, поэтому можете предлагать свои изменения или даже полностью переписать код.

Вот список ресурсов и ссылок.

Книга Game Engine Black Book: DOOM Фабьена Санглара. Одна из лучших книг по внутреннему устройству DOOM.

Doom Wiki

Исходный код DOOM

Исходный код Chocolate Doom

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

Разработка под старые консоли документирована вдоль и поперек, но именно по NES 99% информации относятся к разработке на Ассемблере. Меня почему-то зарубило, что надо освоить именно работу с С.

следующая >>>

Холивар о том, нужно ли использовать для создания игр движки, начался сразу после появления первых игровых движков. Этот пост на reddit не является идеальным примером разумных контраргументов против постоянного использования движков, но я считаю, что непреодолимое желание их применения немного отдаёт фанатизмом.

Давайте рассуждать разумно

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

Уровень навыков

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

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

Есть промежуточное состояние между полным отсутствием навыков и профессиональным уровнем. В основном он находится в стране скриптовых языков: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D и т.д. Все они для тех, кто желает получить определённый уровень технических знаний, чтобы быстро достичь результатов.

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

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

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

Если вам это знакомо, то данная статья как раз для вас, так что продолжайте читать.

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

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

Если возьмётесь за работу очень усердно, то, возможно, получите неплохие результаты через несколько месяцев.

JS-приложения, сайты и другие ресурсы становятся сложнее и инструменты сборки — это реальность веб-разработки. Бандлеры помогают упаковывать, компилировать и организовывать библиотеки. Один из мощных и гибких инструментов с открытым исходным кодом, который можно идеально настроить для сборки клиентского приложения — Webpack.

Максим Соснов (crazymax11) — Frontend Lead в N1.RU внедрил Webpack в несколько больших проектов, на которых до этого была своя кастомная сборка, и контрибьютил с ним несколько проектов. Максим знает, как с Webpack собрать бандл мечты, сделать это быстро и конфигурировать так, чтобы конфиг оставался чистым, поддерживаемым и модульным.


Расшифровка отличается от доклада — это сильно усовершенствованная пруфлинками версия. По всей расшифровке рассыпаны пасхалочки на статьи, плагины, минификаторы, опции, транспайлеры и пруфы слов докладчика, ссылки на которые просто не поставить в выступление. Если собрать все, то откроется бонусный уровень в Webpack :-)

→ Скачать XAMPP

XAMPP ver. 1.8.3-3 for Mac OS X ver. 10.9.2

Первоначальная настройка

Изначально XAMPP имеет один адрес это localhost
При загрузке — должна открыться страница с информацией о сервере, версии PHP ссылками на phpmyadmin и пр.

Для создания своего хоста Apache VirtualHosts

1. Открываем конфигурационный файл — /Applications/XAMPP/xamppfiles/etc/httpd.conf

1.1. Изменить User daemon на User username (стр. 173)

171      #running httpd, as with most system services. 
172      # 
173      User daemon 
174      Group daemon 
175  </IfModule> 

где username — имя вашего пользователя в системе Mac OS X

171      #running httpd, as with most system services. 
172      # 
173      User username
174      Group daemon 
175  </IfModule>  

1.2. Включаем VirtualHosts — раскомментировав (стр. 488)

• Include etc/extra/httpd-vhosts.conf

487    #Virtual hosts
488    #Include etc/extra/httpd-vhosts.conf

убрать решетку перед Include

487    #Virtual hosts                  
488    Include etc/extra/httpd-vhosts.conf 

James Kyle как-то раз взял и написал пост про структуры данных, добавив их реализацию на JavaScript. А я взял и перевёл.

Дисклеймер: в посте много ascii-графики. Не стоит его читать с мобильного устройства — вас разочарует форматирование текста.

Мы занимаемся поиском, а не итерациями

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

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

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

Такие «итерации» совсем непохожи на линейные изменения, которые обычно происходят в «итерациях» компьютерного кода; гораздо больше они напоминают поиск в лабиринте со множеством резких поворотов и вынужденных возвратов назад. Часто они приближают нас к цели, но часто оказывается непонятно, улучшилась ли от них игра. Иногда обнаруживается, что изменения дизайна, которые, по нашему мнению, должны были улучшить игру, имеют непредвиденные изъяны и нам нужно откатить них или попробовать заново.

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

Введение

Алгоритм был написан как часть работы на получение степени бакалавра и основан на статье Ma et al (2014). Целью работы было ускорение алгоритма и дополнение его новыми функциями. Я вполне доволен результатом, потому что мы сделали алгоритм достаточно быстрым, чтобы использовать его во время выполнения игры. После завершения бакалаврской работы мы решили превратить её в статью и отправить на конференцию Game-ON 2018.

Алгоритм

Для создания уровня игры алгоритм получает в качестве входных данных набор полигональных строительных блоков и граф связности уровня (топологию уровня). Узлы графа обозначают комнаты, а рёбра определяют связи между ними. Цель алгоритма — назначить каждому узлу графа форму и расположение комнаты таким образом, чтобы никакие две формы комнат не пересекались, и каждая пара соседних комнат могла соединяться дверьми.