Как создать игровой движок

Java и создание игр: о движках от А до Я

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

Во время создания игр можно использовать разнообразные языки программирования. Некоторые разработчики предпочитают Си-семейство. Оно универсально, но новичкам «с нуля» приступить к коддингу будет трудно. Поэтому тем, кто только начинает изучать процесс разработки игр и программирования, стоит обратить внимание на Java. Это – весьма простой язык, посредством которого можно создавать уникальные перспективные проекты с минимальными трудностями. Основной принцип Джавы – меньше писать, больше делать.

Движок – это…

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

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

При помощи движка можно обеспечить:

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

Грамотно подобранный движок дает разработчику больше возможностей при коддинге. С ним создавать игры для Андроид, Windows/Mac и iOS просто и интересно. Навыки программирования могут быть минимальными.

Движки для программистов и библиотеки на Джаве

Ява – язык программирования, который пользуется у программистов очень большим спросом. Освоить его способен даже новичок без существенных затруднений. Большинство современных платформ для создания игр поддерживают Java-семейство. Это позволяет программерам и разрабам выбрать оптимальный для себя «пакет» готовых утилит при создания развлекательного контента. Далее будут перечислены лучшие движки JavaScript и библиотеки.

GDevelop

Универсальная утилита – подходит и новичкам, и продвинутым программистам. С ее помощью можно сделать:

• платформеры;
• шутеры;
• элементарные игры 8-bit.

Создана для того, чтобы дать возможность разработчикам (особенно новичкам) освоить работу с 2d-играми. Трехмерную графику не поддерживает.

GDevelop предлагает экспорт на различные платформы: Android, iOS, FaceBook (ныне Meta) Instant Games и не только. Подойдет тем, кто заинтересован в экспортировании игр, но не хочет углубляться в непосредственную разработку софта и долго изучать низкоуровневую архитектуру игровых движков.

MelonJS

Еще один вариант, если хотите научиться делать собственные 2D-игры. Подключив соответствующую библиотеку к коду, можно получить доступ к качественной поддержке:

• физики;
• столкновений;
• спрайтов;
• деформаций.

В успешных проектах все это играет огромную роль. Из минусов – не самая лучшая документация. Зато пользовательского контента у MelonJS полно. А еще имеется отличное комьюнити.

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

ImpactJS

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

Дополнительно к Impact «идут» следующие инструменты:

• редактор уровней;
• дебаггер;
• фреймворк для публикации в Ejecta.

Через Impact удается без проблем размещать утилиты в AppStore.

Babylon

Мощный инструмент, предусматривающий веб-рендеринг. Игровым движком его назвать нельзя, но на основе BabylonJS удастся создать game. Движок рендеринга предусматривает доступ к низкоуровневому функционалу.

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

PhaserJS

Среди популярных вариантов, поддерживающих Java, выделяют PhaserJS. Он позволяет программировать не только для компьютеров, но и для мобильных устройств. Обладает поддержкой WebGL. Годится для написания 2D-софта.

Это – бесплатный движок. За дополнительную плату можно подключить особые плагины, значительно увеличивающие мощь «пакета».

Pixi

Библиотека, задействованная при программировании в двухмерном пространстве. Работает с WebGL, задействуется для воплощения потрясающих интерфейсов. И не обязательно они будут размещаться в играх.

Включает в себя:

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

PlayCanvas

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

PlayCanvas – условно-бесплатный «набор программиста». Годится для небольших публичных проектов. За «тайные» коммерческие идеи предстоит платить ежемесячно.

A-Frame

Инновационное решение в программировании. A-Frame может предоставить пользователям больше возможностей, нежели предыдущие библиотеки. И все это за счет того, что ориентирован движок на VR и AR.

Синтаксис напоминает HTML-верстку. Подойдет для 3d-программирования с «полным погружением». В основном утилитой пользуются опытные программеры.

PhysicsJS

Основан на физическом взаимодействии имеющихся объектов. Используется при разработке всех видов игрушек. Для Андроид в том числе.

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

Универсальные решения для программистов

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

Unreal Engine 4

Настоящая легенда в сфере gaming programming. Разрабатывался «пакет» с 1998 года. С тех пор все время совершенствуется и дорабатывается. Современная версия UE 4 является универсальной. При помощи нее создаются развлекательные приложения для:

• игровых консолей;
• мобильных платформ;
• компьютеров.

Является частично бесплатным. Платить за использование оного не нужно, если прибыль с созданного приложения в месяц не переваливает за 3 000 долларов США. В противном случае предстоит переводить создателям движка проценты с получаемых доходов.

Unity

Юнити – популярный вариант среди разработчиков. Обошел иные платформы для создания игр, благодаря простоте осваивания. Развивается с 2005 года.

Подойдет для 3D-игрушек. Как и предыдущий вариант, является кроссплатформенным. На Юнити пишут не только простые игры (головоломки, аркады), но и шутеры от первого лица с тщательно проработанным игровым миром.

Недостаток один – графика в созданных утилитах далека от 100% реалистичности. Если разработчику важна графическая составляющая, лучше пользоваться UE 4. Несмотря на это, более половины утилит для Android написаны именно на Unity. Подходит как новичкам, так и продвинутым программистам.

Corona

Программы для создания игрушек можно перечислять бесконечно долго. И выбрать что-то одно бывает непросто. Добавить к списку наиболее успешных и популярных «пакетов» можно утилиту под названием Corona SDK.

Он выступает в качестве платформы для двухмерных игр. Предусматривает:

• поддержку API;
• сложные функции в 2D-играх;
• в основе API используется Luna;
• монетизацию через Corona Ads.

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

Обладает разнообразными полезными фитчами:

• Sublime Text;
• Corona Editor;
• Composer GUI.

Через Corona’s Physycs Engine можно отслеживать взаимодействие игровых объектов между собой. Этот прием позволяет довести физику в развлекательном софте до идеального состояния с минимальными временными потерями.

Как создать собственную игру – советы

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

1. Самообразование. Результат виден лишь у целеустремленных будущих программистов. В интернете полно полезной информации по рассмотренной тематике. И не всегда за нее нужно платить.
2. Обучение в ВУЗе. Подойдет направление «Программирование». В некоторых университетах есть вариант «геймдев». Долгий и дорогостоящий вариант, но в результате на руках окажется диплом. Выпускник сможет писать сложные программы.
3. Прохождение курсов.

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

Преимуществом такого подхода является то, что человек может выбрать узкую направленность. Пример – изучение только процесса создания игр на Android или iOS. В конце обучения (длится до года) выдается сертификат установленного образца. При желании можно изучать движки для игр iOS, Windows, Android более подробно. Для самых популярных «утилит» существуют отдельные курсы. Делятся они по уровню навыков. Подходящие уроки подберет себе и новичок, и продвинутый программер.

Игровые движки без кода: возможности и ограничения

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

Ниже приведен список популярных игровых движков на платформах Steam и itch.io:

На платформе Steam:

1. Unity: Unity является одним из самых популярных игровых движков, предоставляющих широкие возможности для разработки игр различных жанров.
2. Unreal Engine: Unreal Engine также является известным и мощным движком, используемым для создания высококачественных и реалистичных игр.
3. GameMaker Studio: GameMaker Studio предоставляет простой и интуитивно понятный интерфейс для создания 2D-игр без необходимости писать код.
4. RPG Maker: RPG Maker специализируется на создании ролевых игр (RPG) и предоставляет готовые ресурсы и инструменты для этого жанра.
5. Godot Engine: Godot Engine является бесплатным и открытым исходным кодом движком, который предлагает мощные инструменты для создания игр разных типов.

На платформе itch.io:

1. Unity: Unity также популярен на платформе itch.io и предоставляет разработчикам гибкость и возможности для создания игр различных жанров.
2. GameMaker Studio: GameMaker Studio остается популярным на itch.io из-за своей простоты использования и возможности создания 2D-игр.
3. Ren’Py: Ren’Py — это движок, специализирующийся на создании визуальных новелл и исторических игр с поддержкой графики и текста.
4. Bitsy: Bitsy — это простой и минималистичный движок, который позволяет создавать короткие истории и мини-игры с помощью ограниченных ресурсов.
5. Twine: Twine предоставляет инструменты для создания интерактивных текстовых приключений и визуальных историй с использованием гиперссылок и скриптового языка.

Оба списка представляют только некоторые из популярных игровых движков, доступных на платформах Steam и itch.io. Разработчики могут выбрать подходящий движок в зависимости от своих потребностей и предпочтений.

Если вы еще не начали карьеру в IT, приходите на наш бесплатный вебинар, чтобы узнать, как начать зарабатывать с помощью зерокодинга и нейросетей!

Особенности игровых движков без кода

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

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

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

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

Как выбрать подходящий игровой движок без кода

При выборе игрового движка без кода следует учитывать несколько критериев, таких как:

• Жанр игры;
• Количество доступных элементов и инструментов;
• Уровень сложности использования;
• Возможность экспорта игры в различные платформы;
• Цена программы.

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

Создание игры при помощи игровых движков без кода

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

1. Создание концепции игры и планирование игрового процесса;
2. Работа с графикой и звуком;
3. Создание уровней и других элементов игры;
4. Тестирование игры;
5. Публикация игры на платформах.

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

Использование игровых движков без кода имеет свои преимущества и недостатки. Среди преимуществ можно выделить:

• Возможность создания игры без знаний программирования;
• Большой выбор инструментов и элементов для создания игры;
• Экономия времени и средств на обучение программированию.

Среди недостатков можно выделить:

• Ограниченность возможностей по сравнению с профессиональными игровыми движками;
• Высокая стоимость некоторых программ;
• Ограниченный выбор платформ для публикации игры.

Заключение

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

Как создать игровой движок

Моя игра Speebot выпущена в Steam! Бесплатная demo версия прилагается.

Я разрабатывал эту игру с января 2016 года в своё свободное время в одиночку. Мною выполнено всё программирование, дизайн игрового процесса, создание графики и музыки. Кроме того, я написал собственный игровой движок с нуля.

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

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

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

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

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

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

Ну и наконец: написание собственного движка — это очень интересно.

Разработка движка началась в январе 2016 года. Я назвал его YUME («мечта» по-японски). Он написан на Haxe, C++ и OpenGL. Я использую модифицированную версию библиотеки Lime, которая включает в себя несколько полезных функций, например, позволяет загружать ресурсы и открывает доступ к OpenGL.

Вот так движок выглядел после первой недели разработки.

До начала создания движка я почти ничего не знал о разработке 3D игр. Нужно было разбираться в OpenGL читая документацию, форумы и уроки, предназначенные для других языков (Java и C++). Через пару месяцев у меня получился довольно стабильный 3D-визуализатор.

Кроме самого 3D-визуализатора, нужно было с нуля создать множество разных систем: 2D-визуализатор, машину состояний, систему временных шагов (об этом позже), систему интерфейсов, систему управления мышью, клавиатурой и джойстиками, динамические тени, 3D звуковую систему (используя OpenAL), загрузку моделей (в собственном формате, основанном на IQM), «скелетные» анимации, иерархию объектов, эффект зеркального отражения в реальном времени, отображения текста и так далее.

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

Система временных шагов гарантирует, что движок обрабатывает и показывает кадры игры с определённым интервалом. В YUME нет ограничения по количеству кадров в секунду, т.е. нет привязанности к 30 или 60 кадрам в секунду. Частота кадров может быть любая, а игра всё равно будет работать с одной и той же скоростью, потому что частота обновления логики не связана с частотой обновления экрана. На компьютерах разных мощностей может быть разная производительность, и время для показа одного кадра может быть любым. А логика всегда привязана к частоте 62.5 циклов в секунду (16 миллисекунд на каждый цикл). В этом основной принцип системы временных шагов, хотя есть некоторые крайние случаи.

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

Ранняя версия YUME.

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

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

Движок автоматически определяет, какую 3D модель использовать для отображения каждой плитки, в зависимости от соседних плиток. Придумал способ, как объединить все плитки в одну общую 3D модель, чтобы видеокарте не нужно было рисовать каждую плитку индивидуально. Вся карта рисуется за один раз, что очень сильно улучшает производительность.

Уровни можно редактировать и тестировать сразу. Для продуктивности — то что нужно.

Я написал простую систему игровой физики и начал экспериментировать с игровым процессом. Через несколько недель был готов первый прототип игры, в котором игрок мог перемещать цилиндр по 3D уровню.

Прототип Speebot в июле 2016 года.

YUME продолжал развиваться параллельно с разработкой Speebot (примерно в это время я выбрал такое название для игры). Было найдено и устранено несколько проблем с архитектурой движка, добавилось несколько новых функций: физика, частицы, отражения на поверхности воды, инструменты для анимации камеры, интерактивные объекты. Постепенно библиотека эволюционировала в игровой движок.

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

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

В конце 2016 года я сделал паузу от разработки игры, и посвятил несколько месяцев изучению и практике написания музыки. У меня нет музыкального образования, но это — моё хобби. У меня уже был небольшой опыт в композиции музыки для моей предыдущей игры Hypnorain, но я хотел улучшить свои навыки, поэтому снова погрузился в изучение музыкальной теории. Для композиции музыки я использовал программу SunVox, которая является виртуальным модульным синтезатором. В финальной версии игры Speebot всего 23 трека, которые вместе составляют более часа оригинальной музыки. Я удовлетворён результатом, и продолжу улучшать свои навыки для следующей игры.

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

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

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

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

Следующая статья

Hypnorain, Speebot со скидкой! Прогресс по движку YUME 2

15 Января 2018

Подписаться

Получайте уведомления о новых статьях, чтобы:

Следить за процессом разработки моей следующей игры.

Читать статьи об искусстве и технологиях создания игр и движков.

Получать новости об изменениях в моих играх.

Подписка бесплатная, просто нажмите на кнопку!

О себе

Я — Кирилл Полетаев, ака KEYREAL, индивидуальный разработчик компьютерных игр.

Этот сайт посвящён моим проектам.

Подписаться

Получайте уведомления о новых статьях, чтобы:

Следить за процессом разработки моей следующей игры.

Читать статьи об искусстве и технологиях создания игр и движков.

Получать новости об изменениях в моих играх.

Подписка бесплатная, просто нажмите на кнопку!

Избранное

• Игра Citadelic теперь доступна
• Модификация базы для разных стилей игры в Citadelic
• Добавление разнообразия с помощью игровых модификаторов
• Генерация растровых шрифтов в играх
• Как я создаю игры на своём 3D движке
• Почему я использую собственный движок 3D игр
• Создание собственного сценарного языка для моего игрового движка
• Как я создал собственный 3D движок и игру на нём за 20 месяцев

Разработка собственного движка, напутствие

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

АТЕНШОН, МНОГА ТЕКСТА НЕТ ПИКЧ

Предостережение

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

Поясню — что бы написать минимально рабочую игру, тебе нужно: обработка ввода, вывод графики и игровой цикл с логикой. Можно сказать — «всего 3 компоненты и ты уже можешь делать свои крестики-нолики или тетрисы!». Но для звания «великого игрового движка», при мысли о котором ты возбуждаешься, явно не хватает всего 3х компонент. Различные механизмы подгрузки данных, гибкие системы рендера, система скриптов, встроенные редакторы уровней — всё это требует времени на реализацию, и чем больше ты хочешь, тем больше времени у тебя уйдёт на разработку «движка с 0», а сколько времени потратится на написание самой игры?

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

А как писать?

Для начала нужно подвести черту между двумя кардинально разными подходами в написании этих ваших «движков». Я обозвал их так.

• «Динамические движи», это те в которых вся игровая логика содержится внутри объектов, которые можно передать в другие бинарные модули. (Прим — .dll библиотеки)
• «Статические движки», это те в которых вся логика содержится внутри самого движка и определяется на этапе компиляции.

Какие нюансы я обнаружил при такой классификации?
«Статические движки»

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

«Динамические движки»

• Требуют глубокого понимания матчасти, из-за виртуализации объектов.
• Код можно разбить на независимые модули и подключать буквально на лету. В некоторых играх есть моды которые реализуют «движок в движке», которые используют другие подключаемые модули.
• Большинство инструментов для отладки придётся писать самому, если это не встроено в сам язык. То есть, если ты не пишешь на .NET/JAVA/Lua?
• «Скрипты» могут быть реализованы в виде скомпилированных бинарников обёрнутого в объекты, от чего «потанцевал» при добавлении контента может быть больше (в плане производительности).

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

Кроссплатформенность

Это боль. (вся глава моё нытьё. )
Первая мысль которая должна посетить твою голову — как распространить игру на максимально широкую аудиторию.
Ты можешь использовать кроссплатформенные библиотеки, но их функционал крайне ограничен, так как они пытаются создать абстракцию которая «будет жить на любой платформе». Ты конечно можете написать свою библиотеку. Но вот в чомъ мем
Проблема в том, что платформы достаточно сильно отличаются даже в самых базовых вещах. Как пример — Windows при старте программы не имеет потоков ввода-вывода и для этого ей нужно создавать консоль, но консоль можно создать 2 различными способами и у каждого способа есть куча параметров, для лююююбых потребностей. В Linux же всё проще, у тебя со старта приложения есть потоки ввода-вывода и что бы «увидеть их» нужно просто перенаправить их в файл или создать окно-терминал. КАК ты даже ТАКУЮ простую проблему будешь решать, я не представляю. (я это уже сделал)
Чего уже говорить о создании графического контекста.

Вот ты пытался в OpenGL на Windows? Знаешь что на официальном сайте написано использовать GetDC() при связывании контекста окна и OpenGL? А ты знал что это DC на самом деле может быть принтером? Может быть целым монитором? Видеокартой? Просто окном? «Ресурсом менеджера окон»? А то что в Linux ты должен ручками выбрать нужный тебе монитор для запуска? Всякие драйверы-сервера запускать? И не один. И это надо как-то собрать в одну единую абстракцию и непринуждённо дёргать по воле случая.

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

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

Делаем игры, наивно

В начале статьи я ввёл понятие «компонента». На самом деле я называю так любую штуку «которая делает что-то другое» )))

Любой код можно разбить на некое число компонент-модулей. Самое примитивное приложение состоит всего из 3 модулей

• Обработка ввода
• Вывод изображения
• Логика (зачастую на стейт машинах)

Уже это позволяет писать тебе довольно простые игры. Скажем крестики нолики или «давилку мух»? Давай вместе представим как оно может работать.

• Загружаем нужные ресурсы
• — В цикле.
• Рисуем: фон > картиночки
• Обрабатываем ввод
  — Если нажата мышка, проверяем хитбоксы объектов
  — Если прошли проверку, меняем «игровое состояние»
• (для «давилки мух») Раз в Х циклов запускаем новую муху по некоторой траектории. И обрабатываем перемещение живых мух.

И это уже можно назвать игрой. «Погоди» — скажешь ты — «Но фактически тут 4 модуля, загрузка ресурсов!!». Хах, но если ты чуть-чуть разбираешься в линковке приложения, то ты можешь вшить данные в бинарник) И тебе не нужно будет загружать никаких данных. Поведение мух, также, вшито в движок и относится к логике, потому фактически тут именно 3 модуля.

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

Я бы сказал так — «движок занимается обработкой пользовательских данных и может иметь изменяемую логику»

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

• Конкретная загрузка ресурсов
• Обработка ввода, который конвертируется в абстракции
• Вывод изображения, который обходит множество объектов
• Игровая логика, которая уже разбита на несколько частей
  — Обработка загрузки-переходов уровней
  — Информация о сцене
  — Нахождение коллизий и проверки на триггеры
  — Обработка поведения ИИ?
  — Обработка ввода от игрока
  — Скриптовый процессор

Теперь, как прошлый раз, давай разберём поэтапно, что и как движок должен делать.
— Для начала опишем «минимальную» логику.

• Информация о сцене (уровне)
  — Какой фон
  — Набор тайлсетов (2D матрица)
  — Предметы
  — Юниты
  *** Всё кроме фона должно иметь информацию о себе, типа — «текстура», «какие-то свойства», есть ли «триггер», «скрит» или «поведение»
• Вшитые в движок «примитивы»
  — Триггеры (какие бывают, что проверяют, что вызывают. прим — если хибоксы пересекаются — запускает смену уровня)
  — Поведение (хардкодное поведение, что делает объект. прим — триггернутый предмет увеличивает свойство Х, у объекта который триггернул. Объект Х движется в одну сторону и случайное время меняет направление. Это можно оформить в виде «функций» для скриптового языка. )
  — Свойства (Что за свойства, определяемые скриптами свойства)
  — Процессор скриптов
• Обработка передвижений-триггеров-физики?

Ну и сам игровой цикл будет состоять примерно из такой логики

• Загружаем информацию об уровне (описание уровня)
• Загружаем нужные ресурсы (текстуры и скрипты)
• — В цикле.
• Рисуем: фон > тайлест > предметы > юниты
• Обрабатываем ввод
  — Абстрагируемся от кнопок и просто передаём «Идти влево»
• Обрабатываем логику
  — Проходимся по всем единицам со скриптами
  — Проходимся по тем, у кого базовое поведение
  — Что-то делаем с игроком?
  — Проверяем коллизии-физику? (вызываем триггеры если что-то нашли)
  — Двигаем юнитов-предметы

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

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

Поясню за скрипты — для многих это будет открытием, но скрипты можно делать и в виде виртуальной машины-процессора. Твоя задача будет — написать парсер текста, описать виртуальную машину и придумать как именно получать информацию о сцене-объектах. В качестве примера, можно использовать многострадальные стековые процессоры, по типу forth. Они очень легко делаются, но к их логике нужно привыкать. По сути это единственный выход написать «быстро» ваш собственный «скриптовый процессор».
*** Обязательно сделай вывод логов при сборке скрипта, или при его работе.
*** Старайся избегать логики типа [INT a += «Lord»]. Писать нетипизрованный код опасно, но можно выделить отдельные команды для работы с конкретными типами.
*** ДА, ТЫ БУДЕШЬ ПИСАТЬ СКРИПТЫ НА АССЕМБЛЕРЕ.
*** Для написания простого ассемблера, хватит и знаний типа — Sting.indexof(«ADD»); и подобного говнокода. Но что бы написать нормально, или хотя бы простенький язык, вам нужны знания о «регулярных выражениях» или «парсерных комбинаторах».
*** Не надо упарываться в «полноценный язык», посмотрите как писались языки программирования в бородатых 80х, даже тот же Pascal. Они работают просто и честно, такие реализации займут у вас в разы меньше времени, чем описание «очередного» . C\Rust\Haskell.

Типа канец?

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

Изначально, решился написать эту статью, ради привлечения инвестиций, на время разработки своей «базовой +18 новеллы». (инициатива друга)
Так что ты это, кнопочку то нажми, а?

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

• Как лучше работать с памятью-данными.
• Проблемы STL библиотек. (C++)
• Детали виртуализации объектов, микро рекомендации.
• Как можно делать «моды».
• Профилирование и Логирование, почему это важно.
• Что нужно знать о многопотоке, вводные-подводные.
• Асинхронно или параллельно? Как это работает?
• Работа с текстом-кодировками, и почему это настоящий ад.

На счёт моего кода — не будет опенсорса. Когда я релизнусь, я выложу лишь API к бинарнику. По сути, я использую «динамический» подход, который описывал выше. Потому запустить свою игру, можно будет просто собрав .dll и запустить бинарник запихнув либу в аргументы строки. Но вот когда это случится. Когда я перестану морить себя голодом? Кто знает

PS — Под конец получилось немного сумбурно, ибо я писал всё за один заход. В целом я описал лишь поверхностно многие вещи. Если будет спрос, могу углубится.
PPS — Мне тут говорят что бы я сделал бусти и публиковался впредь там, раз в месяцок публикуя «фри контент». Может в следующий раз? Я просто не знаю о чём там можно писать, лол.
PPPS — «Статья слишкам длинная устал читать, пиши кароче»