RES - Движок для пиксельных игр :: Создание игр :: Форум

Уже почти два года в свободное от всякой ерунды время я занимаюсь неспешным пилением небольшого игрового движка. Оказалось, что уже больше года назад я даже порывался создать на эту тему тред здесь (http://igdc.ru/forum/viewthread.php?forum_id=17&thread_id=5178&rowstart=40#p52742), но созрел только сейчас.

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

Итак. Что вообще за двиожок? Почему? Зачем?

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

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

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

Основными источниками вдохновения для создания RES послужили фэнтезийные консоли и компьютеры вроде PICO-8, TIC-80, LIKO-12 и т.п. Собственно PICO-8 прямо почти что надо, но есть существенные минусы:
- Платный, закрытый, несвободный
- Lua вместо языка программирования
- Жесткие ограничения это прикольно, но хотелось все же больше свободы.

Что же представляет из себя RES в общих чертах?
- Написан на языке Haxe. Он же является рекомендуемым языком для написания юзер-кода, но не единственным возможным. В теории юзер-код может быть написан на JavaScript, C#, Java и других. Но об этом тоже позже.
- Абстракции движка организованным таким образом, чтобы в некоторой степени имитировать взаимодействие с неким вымышленным железом. RES можно представить себе как некоторый компьютер/приставку, к которому подключены контроллеры, клавиатура, мышь. У программы, написанной для RES, есть доступ к ROM (где хранятся ресурсы), 8-битному буферу кадра (максимум 255 цветов из палитры + прозрачность), аудио системе, которую можно попросить воспроизвести PCM данные, а также к стандартной библиотеке, которая упрощает работу со всем этим делом.
- RES абсолютно платформенно независим. Отдельной абстракцией движка является BIOS (продолжаем логику с фэнтезийным железом) - в ней реализовывается вся платформенная логика. Непосредственно вывод графики и звука, а также чтение ввода пользователя. Уже сейчас доступны биосы для html5 для запуска программ в браузере, а также для HashLink - виртуальная машина от создателей Haxe для запуска программ на ПК. Нет никаких проблем реализовать BIOS через возможности любого другого движка. Уже сейчас есть биосы использующие Heaps и OpenFL. Второй в свою очередь без труда собирается под мобильные платформы и оба могут быть собраны под консоли (но уже с трудом). В теории RES может работать даже внутри Unity3d так как код написанный на Haxe транслируется в C# и подобные фокусы уже были реализованы в других проектах на Haxe.
- RES является открытым и свободным ПО распространяемым по лицензии MIT.

Думаю этого достаточно для вступления. В следующих сериях:
- Примеры кода и использования
- Больше рассказов про архитектуру
- Архив со всеми необходимыми инструментами для возможности собственноручно пощупать движок
- Больше потока сознания

редакция от KEFIR, 19.04.2023 20:12

Bullet Heaven:

Не участвую.

Опубликовано 21.04.2023 17:55 (2 года назад) #

Всегда мечтал о каком-то простом движке, без лишнего.
По сути нужно-то чтобы удобно спрайты двигал.
Что-то вроде Game Maker старого.
Но из поста не понятно что это будет, видео бы каких-нибудь.
Интересно, сколько билд пустой весит на нём?
А то на новых версиях Unity или Godot уже не получается для здешних конкурсов что-либо делать.

Bullet Heaven:

В разработке

Опубликовано 21.04.2023 18:38 (2 года назад) #

Kaps написал:
Всегда мечтал о каком-то простом движке, без лишнего.
По сути нужно-то чтобы удобно спрайты двигал.
Что-то вроде Game Maker старого.

Ниего не знаю про Game Maker, но мотивация для создания RES примерно такая и была, так что думаю это оно :)

Но из поста не понятно что это будет, видео бы каких-нибудь.

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

Интересно, сколько билд пустой весит на нём?
А то на новых версиях Unity или Godot уже не получается для здешних конкурсов что-либо делать.

Чтобы ответить на этот вопрос, нужно уточнить под какую платформу. Сейчас "из коробки" можно использовать "биосы" под html5 и HashLink. Второе это такая достаточно легковесная виртуальная машина https://hashlink.haxe.org/ - исходный код на Haxe компилится в байткод для ВМ и чтобы потом это все дело запустить где-то еще, нужно будет упаковать его вместе с бинарниками самой ВМ.

Сейчас специально посмотрел - полный набор под винду весит 5.6Мб. От туда еще можно убрать лишнее либы вроде mysql, sqlite, ssl и другие и еще уменьшить, если хочется. Все то сверху это уже байткод и ресурсы, тут как получится.

Ну а так свой "биос" написать совсем не сложно. По сути надо просто реализовать несколько абстрактных классов и интерфейсов. Можно, например, сделать это под JVM или под .Net используя какие-то сторонние движки для вывода графики/звука. Что там сейчас под них есть? XNA еще существует? Monogame? Libgdx или через стандартную библиотеку. Еще в разработке биос SDL + C++, с ним не нужна будет ВМ, но размер билда там наверно будет сопоставимый.

Stay tuned, буду писать еще.

Bullet Heaven:

Не участвую.

Опубликовано 22.04.2023 11:13 (2 года назад) #

Но немного про код?

После инициализации проекта (о которой отдельно нужно будет написать) можно написать вот такой hello world:

Не самый читабельный пример, но он должен иллюстрировать основные составляющие минимального проекта на RES. Подробнее по строкам:

4) Статический метод RES.boot() “запускает” экземпляр RES. Первым аргументом указываем BIOS, который будем использовать. Это (в идеале) единственный зависимый от платформы кусок кода. В данном случае используется html5 биос. Внутри него находится весь код, который отвечает за создание поверхности, на которое будет выводиться изображение, захват ввода пользователя, вывод звука и т.д.
5) Разрешение буфера кадра. Это значение нельзя будет изменить во время работы движка (нет, ну если очень хочется, то можно конечно, но по дизайну должно быть нельзя). Ограничений на разрешение нет, но нужно помнить, что мы имеем дело с растровой графикой и нам предстоит обращаться к каждому индивидуальному пикселю, а то и не раз, каждый кадр и хотелось бы иметь хотя-бы 60 FPS. Поэтому здесь нужно экспериментировать и смотреть где на каждой платформе начинаются проблемы. Но поскольку мы тут фокусируемся именно на “ретро-пиксельной” графике, то для лучшего эффекта подойдут низкие значения, близкие к разрешениям “ретро” железа.
6) Здесь происходит небольшая магия, которая возможна благодаря Haxe. Rom - это ресурсы игры. В нем хранятся все спрайты, шрифты, звуки, тайловые карты и т.д. В этой строке мы говорим, что хотим использовать директорию “rom” в качестве “исходников” рома и что мы хотим, чтобы все эти данные были встроены в саму программу. Магия заключается в том, что функция “Rom.embed()” будет выполнена во время компиляции и в скомпилированной программе вместо этой строки окажутся прямо голые данные “рома”. Об этом всем также нужно будет написать отдельно. Но основная идея такова: файлы из директории “rom” будут заархивированы и добавлены прямо в код программы, то есть она не будет использовать какие-либо внешние файлы.
Приблизительно вот так может выглядеть директория с ромом, в которой есть png файл со спрайтом.

7) main - функция, которая должна возвращать какой-то объект, у которого есть как минимум 2 метода: update и render. Этим объектом может быть экземпляр какого-нибудь класса (из коробки есть класс State, в котором есть множество дополнительных удобств) или как в этом случае просто анонимный объект с двумя функциями.
9) Собственно главная функция отрисовки. Она будет вызываться каждый раз, когда нужно будет нарисовать кадр (за это отвечает bios). fb - Frame Buffer - буфер пикселей. Здесь мы задаем цвета пикселей - после они окажутся на экране.
11) Копируем пиксели спрайта, который находится в роме, в буфер кадра. Размер спрайта 16x16, поэтому он должен оказаться в центре экрана.
12) Выводим текст Hello world используя шрифт по-умолчанию. Шрифты тоже берутся из рома. По сути шрифт это просто набор тайлов с символами и ассоциация кодов с ними. Шрифтом по-умолчанию становится первый шрифт в роме. drawPivot - функция, которая использует относительную точку внутри изображения с текстом (например x = 0.5, y = 0.5 - центр изображения, это значения по-умолчанию) как начальную. Удобно, если нужно, как в этом случае, центрировать объект.
Здесь я заметил, что неоднородность апи выглядит некрасиво. Нужно будет добавить методы drawText и drawTextPivot, а также возможность “чейнить” вызовы подобных методов.

Компилируем, запускаем и видим это:

Но что это такое? Почему спрайт выглядит не так, как оригинальный png файл? Все цвета какие-то неправильные! Что происходит??

Вот тут нужно заострить внимание на том, что RES использует ТОЛЬКО палитру цветов, добавить RGB(A) цвет в буфер кадра нельзя. Только 8-битные индексы цветов (0 - прозрачность, 1-255 - цвета из палитры). Палитра также хранится в роме. Чтобы задать палитру, достаточно добавить файл с именем palette в корень директории с исходниками рома. Это может быть png файл с палитрой, aseprite файл или текстовый файл, в котором каждая строка это hex rgb цвета. Если такого файла в роме нет, используется палитра по-умолчанию: sweetie 16 https://lospec.com/palette-list/sweetie-16

Все полноцветные файлы, добавленные в ром, преобразуются в индексные. Для каждого пикселя находится ближайший цвет из палитры и используется его индекс. Именно поэтому Марио на экране выглядит так. Возможно алгоритм выбора подходящего цвета из палитры еще нужно будет потвикать, сейчас используются самый простой: нахождение ближайшей точки в 3д пространстве (r=x, g=y, b=z), для лучше эффекта можно использовать более нюансный подход.

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

редакция от KEFIR, 22.04.2023 11:15

Bullet Heaven:

Не участвую.

Опубликовано 28.04.2023 20:45 (2 года назад) #

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

Отдельные слои можно использовать как отдельные карты, а также можно использовать тайлсеты из Aseprite файлов для создания своих тайловых карт в коде.

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