Vuvk, Посмотрел видео, и должен сказать, что весьма впечатляет. Видно, что стараетесь, только вот у меня возник, возможно глупый, вопрос, а как вы будете его распространять? По какой лицензии? (Просто интересно, ведь данный продукт может просто напрочь вытеснить Raycasting game maker) Foil soldier HardBoy Questers
HelloAshKetchum, спасибо за ободрение. Может это и слишком наивно, но я мечтаю эту поделку разместить в Стим с символической стоимостью. Отклик какой-никакой уже даже сейчас есть. Стоит попробовать.
+ Добавлена новая информация в паки: версия пака (для определения совместимости пака и конструктора), интенсивность тумана, размер текстуры в паке. + Я вдруг подумал: "а какого хрена я подгоняю все загружаемые текстуры под один размер?" и отказался от этого, т.к. здесь не рейкастинг и размер не имеет такого значения, как в оригинале. Расшифровываю: если хотите загрузить текстуру 32*32, то она будет сохранена с таким размером в пак, если 256*256, то такой размер и останется и т.д. Размер подгоняется если загружаемая картинка больше 256*256 (не знаю нужно ли ещё больше?) и если размер одной из сторон картинки не является степенью двойки (1, 2, 4, 8, 16, 32, 64, 128...). Раньше любая текстура подгонялась под принятый максимум даже если она меньше этого максимума. В итоге опять получаем экономию места, быстрые текстуры (речь о POT, но не уверен, что в наше время это актуально) и отсутствие геморроя как в РГМ, где текстуры должны быть изначально "правильного" размера, потому что редактор делает сам все необходимые преобразования. + добавлена настройка фиксации спрайтов (скрин 1) - может либо смотреть всегда на игрока, либо иметь чисто горизонтальную или вертикальную ориентацию (скрин 2. Лампа не поворачивается) + кстати, увеличил максимальное количество спрайтов до тридцаточки! + увеличена максимальная скорость анимации для спрайтов/текстур до 60 к/с + добавлена возможность просмотра анимации прямо в редакторе (скрин 3. Кнопка управления проигрыванием)! + при генерации уровня загружаются в память только те текстуры/спрайты, которые используются на уровне + плавная прокрутка карты в редакторе
Ограничения обусловлены форматом хранения данных - один байт на тип объекта/номер текстуры. Итого 255 вариантов на всё про всё. В группе мне отписали, что НАДО сделать без ограничений создание объектов, текстур, спрайтов. Начинаю думать над тем, как я буду это реализовывать. Вызов принят.
Добавлено (02 Февраля 2018, 17:15) --------------------------------------------- Решил особо не ломать то, что сделано и заложить на тип объекта не байт (255 вариантов), а 2 байта (65535 вариантов) и просто увеличить максимально возможное количество загружаемых объектов до, допустим, тысячи. Этого и так будет за глаза! Да кого там, и 200 текстур было бы достаточно. Но я не жадный. При максимальной загрузке со всеми кадрами и в максимальном разрешении мы получаем пак в 1,22 Гига (256*256*4*5*1000).
Записал видео, чтобы похвастаться тем, что получается в режиме онлине, так сказать. На видео можно наблюдать: - редактирование количества текстур (как добавление, так и удаление); - загрузка текстур в созданные ячейки; - новый интерфейс со списками и вкладками, всё удобно и логично, черт возьми; - динамически подбираемое количество столбцов для отображения текстур в панели инструментов в зависимости от ширины рабочей области; - обработка карт и удаление "сбойных" элементов.
Теперь по аналогии буду делать остальные ресурсы. Но сначала предстоит лютая чистка кода.
Добавлено (23 Февраля 2018, 07:19) --------------------------------------------- Ченжлог: - бесконечные кадры для текстур и спрайтов (ну не прям уж бесконечные... 4294967295 шт. максимум); - обновленный интерфейс; - сохранение/загрузка ресурсов в архивы ZIP; - обработка текстур собственного формата; - сохранение/загрузка параметров объектов в конфиги, которые запихиваются в архив с объектами; - менеджер ресурсов вынесен в отдельную библиотеку .dll/.so; - прикручен Duktape (интерпретатор языка JS), но пока не задействован.
Конфиги+архивы дали неплохую гибкость для расширения типов. За идею спасибо одному из подписчиков моего публика во вконтакте.
Ну и коротенькое видео в придачу - смотреть. Задействованы ресурсы, которые мне подкинул в дар другой подписчик.
Добавлено (07 Марта 2018, 20:55) --------------------------------------------- Ченджлог: - сохранение и загрузка карт перенесены в архивы ZIP с конфигами. Отныне паки собственного формата вообще не используются; - окно редактирования настроек - цвет и интенсивность тумана, цвет пола/потолка, показ текстурных пола и потолка, показ неба (скайбокс в будущем); - управление количеством карт; - возможность добавления/удаления карт; - загрузка в раннере параметров: цвет и интенсивность тумана, цвет пола/потолка, показ текстурных пола и потолка. На скринах настройки в редакторе и последствия в раннере. На последних скринах демонстрируется эффект от незатекстурированных областей в полу/потолке - рисуется фон в "дырах".
Далее на повестке дня загрузка скайбоксов.
Добавлено (16 Марта 2018, 18:37) --------------------------------------------- Update: Изменена система работы с редактором и загрузчиком-запускатором. Теперь схема должна выглядеть так: 1. пользователь указывает папку, где будет лежать его проект 2. в эту папку автоматически кидаются какие-нибудь конфигурашки проекта 3. пользователь добавляет ресурсы и в папке с проектом создается папка resources, а в ней подпапки textures, sprites и т.д., в которые файлы пишутся в "родном" для конструктора формате 4. пользователь открывает проект и ресурсы в редакторе грузятся из папки resources 5. пользователь горд собой и готов распространять своё поделие. Для этого он тыркает кнопку "export" и именно в этот момент все ресурсы из папок запихиваются в один архив 6. раннер работает ТОЛЬКО с получившимся PK3-архивом
На видео: - сохранение/загрузка ресурсов редактором производится в папку проекта; - экспорт проекта в пак pk3 (прям как в Quake3 ), который будет обрабатываться раннером; - редактирование и загрузка скайбоксов; - загрузка настроек уровня - отображение неба, тумана... На видео не попало: - управление количеством скайбоксов; - возможность добавления/удаления скайбоксов; - новые функции в менеджере ресурсов: запаковать всё содержимое папки в архив, удалить все файлы в папке, загрузить файл в буффер, сохранить буффер в файл; - ну и там всякого по части кода... навалом.
После причесывания кода возьмусь за внедрение скриптового языка, т.к. последующие объекты (двери, ключи, оружие, враги и т.д.) уже должны работать на скриптах. Пока что главные претенденты это PascalScript и Pawn.
За разработкой можно следить в моем дневнике на ВКонтакте. Там же я участвую в диалоге с потенциальными пользователями или более продвинутыми программистами. Так что велкам!
Добавлено (11 Апреля 2018, 05:42) --------------------------------------------- Update: Некоторые тестеры выразили недовольство по поводу того, что нельзя рисовать карты так же, как в RGM - удерживая мышку и водя курсор по клеткам. Мне самому это вообще не нравится и потому я сделал закрашивание областями (квадратами). Но раз уж массы высказались против, то добавил рисование а-ля пэйнт, а фишку с удерживанием CTRL конечно же оставил, т.к. это всё равно удобнее и круче. Теперь по умолчанию выставлены галочки в настройках уровня для отображения текстурированных пола и потолка, т.е. их отключение - это уже что-то специфическое. Исправлен Z-fighting полов\потолков. В редактор добавлен предпросмотр скайбоксов. Грузится именно в таком положении, как оно будет выглядеть в игре. Я замечал, что в некоторых паках скайбоксов, скачанных из интернетов, надо менять левую и правую грани местами... так вот, это косяк авторов скайбоксов. Реализована подсветка граней скайбокса для идентификации сторон. После попыток внедрить Pawn и написать на нём управление игроком, я на него ЗАБИЛ. Постоянно какие-то нестыковки и то, что компилируется далеко не факт что работает. Добили какие-то необъяснимые траблы с вещественными числами. В итоге подключил duktape и буквально за час-полтора написал на javascript управление игроком (примитивное). Я решил остановиться на интерпретаторе js, короч.
На видео превью двух скайбоксов, второй с незагруженной текстурой. Видео
Сообщение отредактировал Vuvk - Пятница, 23 Февраля 2018, 07:24
Новости по проекту: - полный перенос управления игроком и камерой на скрипты JS; - разделение сущностей "камера" и "игрок", последний - это красный физический цилиндр; - решены проблемы с коллизиями объектов и мира. Оказалось, что в движке WS3D есть недочеты (нет создания коллизии из батчинг меша, некоторые вопросы с функциями обработки событий мышки) - спасибо Николаю, он всё лихо поправил/обновил; - интерпретатор duktape релизнулся до версии 2.2.1. Новая версия "внедрена" в RGC; - разобрался как добавлять свои глобальные классы (модули) в интерпретатор (типа как Math); - модули Mouse и Keyboard с методами для работы с мышью и клавиатурой (пример скрипта - https://pastebin.com/DeM2CVDR); - добавлена функция удаления выбранного цвета на спрайте (сделать прозрачным указанный). Потенциальные пользователи просили делать прозрачным белый цвет (255, 255, 255) при загрузке спрайта, как в RGM. Но я решил сотворить круче и добавить возможность сделать прозрачным любой выбранный пользователем цвет. О новой фишке короткое видео.
Добавлено (07 Мая 2018, 06:03) --------------------------------------------- Поделюсь прогрессом разработки, а то смотрю некоторые уже заскучали. Итак, 1. полностью перенесена/переписана среда запуска с ЯП Си на D. Я сразу же оценил: а. выше скорость написания кода, т.к. код на Ди прямо изобилует синтаксическим сахаром - гораздо проще работа с массивами, строками, словарями, классами и т.д. б. нет необходимости в ручном управлении памятью, а Дишный сборщик мусора очень шустрый. 2. в редакторе появилось окно редактирования дверей и ключей для них. Пока готовы только загрузка текстур, кадров дверей и установка ряда параметров "по умолчанию" - разрушаемость, необходимый урон, скорость открывания, открывается ли единожды, необходимость ключа для открывания, сообщение с текстом о необходимости ключа (по умолчанию "I need a key").
3. Реализованы функции сохранения/загрузки текстур дверей и их параметров в редакторе. Экспорт проекта с дверями. 4. В редактор добавлена новая вкладка инструментов "Doors & Keys", на которой можно выбрать ранее загруженные двери и ключи для расстановки.
5. Обработка и загрузка в раннере только тех текстур дверей, которые используются на генерируемом уровне. 6. Загрузка в раннере параметров дверей в класс дверей. Описан класс дверных нод. 7. Загрузка расположения и генерация меша двери в среде запуска. Дверь создается в одном из случаев - слева и справа стена, либо сверху и снизу стена. Во всех иных случаях дверь создана НЕ БУДЕТ. Так что уровни нужно будет делать внимательно. 8. Проигрывание анимации у двери (допустим, раскачивающийся замок, моргающая лампочка... да что угодно). 9. Зоны с полу-прозрачностью, если такие установлены на текстуре двери.
Скриншоты дверей в среде запуска
Когда дошёл до генерации дверей в раннере, то на мгновение застопорился. Я вдруг понял, что не знаю, как правильней привязать скрипты к ноде двери. Отдельный скрипт для каждого экземпляра двери? Отдельный контекст интерпретатора для каждого экземпляра двери? Оба этих варианта не кошерны. А впереди ещё враги, объекты... Т.е. эту проблему надо как-то решить уже сейчас. На данный момент схема такая: есть скрипты для разных событий для конкретного типа объектов. Например, init_door0, update_door0, destroy_door0, on_open_door0 и т.д. В главном цикле программы обрабатываются все объекты по порядку и по событию вызывается нужный скрипт. И тут возникает ситуация, что копий одного типа объектов может быть много, а скрипт на них один. Все переменные получаются общие и это неизбежно вызовет ошибки.
В итоге придумал вот что - во время обработки объекта перед запуском скрипта становится доступен указатель на обрабатываемый в данный момент объект. В скрипте его можно идентифицировать, для этого берется id какой-нибудь командой типа getObjectId и уже через этот идентификатор идет обработка. Также всплыла и другая проблема - пользователь кроме стандартных полей у класса может захотеть добавить свои любые. В голову приходит только зашить в каждый класс словарь, который можно пополнять/изменять из скриптов. Например,
addValue('health', 100); h = getValue('health'); setValue('health', h - 25);
За ходом разработки по-прежнему можно следить в моем дневнике.
До связи!
Добавлено (17 Мая 2018, 05:42) --------------------------------------------- upd: - в среде запуска появился базовый внутриигровой класс, от которого будут наследоваться все остальные классы. Написаны методы/функции для взаимодействия с этим классом и его потомками из скриптов на JS. Появилась возможность добавить к любому объекту свои переменные следующих типов: число, булеан, строка прямо из скриптов и взаимодействовать с ними. Тестовый скрипт на скрине 1, выхлоп скрипта на скрине 2. Позднее имена функций сделал покороче (objectAddVarString... objectSetVar... objectGetVar и т.д.). Функции для изменения переменных полиморфны, но при создании нужно явно указывать тип хранимого значения. Что это даёт и для чего это? Появляется возможность сильно изменять базовые объекты до неузнаваемости, т.к. все настраиваемые в редакторе параметры теперь также хранятся в словаре объекта. Вы можете их даже удалить. А можете добавить свои и ВНЕЗАПНО сделать вместо FPS какое-нибудь RPG! Для доступа к объекту используется его Id. И для работы с переменными словаря необходимо указывать где они находятся по идентификатору. Это всё делается в процедурном стиле и в довольно длинной форме. Однако никто не запрещает завернуть это в свои произвольные функции или классы на JavaScript (скрин 3).
- подсмотрел у конкурента фишку с установкой размеров для спрайтов. Я много времени трачу на обеспечение гибкости конструктора... и наконец-то это начало окупаться. Внедрил эту шнягу минут за 15;
- написаны скрипты для поведения дверей и взаимодействия игрока с ними; - попутно были добавлены служебные функции для скриптов: расстояние между точками, проверка свободности ячейки карты, проверка находится ли объект в поле видимости камеры и там по мелочи; - всего описано три шаблона поведения для дверей - открываются вбок, открываются вверх, поворачиваются; - выдуманная мной система взаимодействия скрипта с объектами, добавление переменных в словарь работают на ура; - в редакторе появилась возможность задавать коллизии для спрайтов - в процентном соотношении от размеров блока; - установка размеров коллизии у спрайта в среде запуска в зависимости от настроек редактора + масштаба объекта.
Как было до Настройка коллизии в редакторе Результат формирования коллизии в плеере
Добавлено (20 Мая 2018, 14:04) --------------------------------------------- Upd - Возможность задать имена для скайбоксов
- Возможность задать имена для карт. Имена скайбоксов отображаются те, что введены ранее
Насчет имён объектов ремарочка - по умолчанию задаётся имя по шаблону "тип #номер", например, "Level #1", "Skybox #666". Т.е. если нет желания прописывать объектам имена, то никто и не заставляет. Это сделано прежде всего для удобства. Далее и у остальных объектов появятся имена и их отображение можно будет включить в панели инструментов на главном окне. - Установка в редакторе толщины дверей (в % ) + установка текстуры на боковую грань. По умолчанию просто черный цвет
- Загрузка в плеере параметров толщины дверей и текстуры грани. Формирование меша двери с толщиной и двумя текстурами (основная и грани).
Подробнее на видео (маленький панк сотворен с помощью реализованной недавно фичи с масштабом).
И ещё: У меня возникла тут идейка как двух зайцев одним выстрелом порешать. Есть ли среди форумчан программисты на JavaScript (или те, кто готов с ним ознакомиться) с опытом разработки игровых (или около-игровых) продуктов, которые бы согласились мне посодействовать в написании скриптов для плеера? Профиты для меня: могу заострить внимание исключительно на редакторе и плеере, помощник сообщает мне каких функций для интерпретатора не хватает и я их добавляю, обкатывается плеер. Профиты для подельника: щупает самую свежую сборку плеера RGC, чувствует себя частью общего дела и получает каеф, +скилл поинты. Внимание! В команде, как показало время, я почти не умею работать, потому что являюсь кем-то вроде диктатора. Однако годные предложения всегда готов принять к сведению. Как мне представляется процесс: 1. я добавляю в редактор и раннер новую сущность. Выкладываю актуальное состояние на гитхаб 2. обновляю список функций интерпретатора на гитхабе 3. подельник получает задание, например, "двери должны открываться при наличии ключа" 4. подельнику не хватает функций (например, вывод сообщения на экран) 5. я добавляю функции при необходимости и подельник завершает квест 6. goto 1 Пишите в комментарии или в личку о своём желании. Обязательно наличие опыта разработки или написания скриптов для игр - давайте не будем тратить своё и моё время зря. Если никто не отзовётся... ничего страшного, т.к. я итак сейчас один.
Добавлено (29 Мая 2018, 06:33) --------------------------------------------- Отчитаюсь о проделанной работе за неделю. (Ух, как много было сотворено...) Прежде всего, была исправлена целая туча багов и недочетов. Всплывали ошибки там, где я и не подозревал. А именно: - при удалении предыдущего спрайта из базы спрайтов, на карте не обновлялись спрайты идущие за удалённым - то же, но с дверьми - то же с ключами - при удалении спрайта затиралась какая-нибудь текстура в паке - исправлена генерация меша двери - была ошибка с зеркалированием текстуры по X - исправлена ошибка удаления объекта из списка объектов - куча исправлений в скриптах - исправлена перезагрузка уровня (тотальный рестарт) - и там кой-чего
Дополнения в интерпретаторе: - реализована возможность перезапуска виртуальной машины без останова движка - очень удобно при отладке скриптов - добавлены векторы в хранимые переменные объектов (массив из 3 чисел) - функция distanceBetweenPoints стала полиморфной и принимает, как двух- так и трехмерные векторы - несколько новых функций. Все доступные на данный момент функции можно поглядеть здесь: API
Редактор: - возможность задать скорость движения двери в отрицательном диапазоне (при отрицательных значениях дверь будет открываться в обратную сторону, т.е., например, при положительных значениях открывается вверх, при отрицательных вниз) - возможность загружать и изменять параметры ключей - функции загрузки и сохранения ключей - имена дверей - имена ключей - имена спрайтов
Раннер: - загрузка и обработка ключей - скрипты для ключей - обновленные скрипты дверей для обработки ключей
Подробнее на видео: - рестарт интерпретатора во время запуска игры без остановки движка - разное поведение дверей - ключи и взаимодействие с ними - открывание двери по ключу
Несмотря на то, что RGC на данный момент представляет собой что-то очень сырое и еле живое, некоторые пользователи уже успели с ним поиграться. Делюсь несколькими скриншотами с их экспериментами:
Сообщение отредактировал Vuvk - Воскресенье, 20 Мая 2018, 14:06
В редакторе: v Функция удаления цвета в дверях (сделать прозрачным выбранный цвет)
v Функция удаления цвета в ключах v Все всплывающие окна редактора рисуются поверх всех окон системы v Все всплывающие окна редактора ресурсов закрываются на Escape v Кнопка для автоматической генерации solid box - выбираются крайние пикселы и по ним выстраивается коллизия
v Исправлена ошибка, возникающая при удалении всех скайбоксов из проекта v Исправлена ошибка перерисовки списка спрайтов на главном окне при добавлении новых v Исправлена ошибка присвоения имени первой карте при создании нового проекта
В раннере (скриптовая часть): v Дверь больше не нуждается в ключе, если она уже открыта ключом (удаление флага о необходимости ключа = более быстрая обработка скрипта) v При приближении игрока к закрывающейся двери, она снова переходит в открытое состояние
В раннере (среда исполнения): v Мелкие правки для повышения быстродействия
Затеял переезд с одного интерпретатора JavaScript на другой. Выбор пал на JerryScript, используемый и развиваемый, в том числе, конторкой Samsung. Изначально он предназначен для встраиваемых систем, но никто не запрещает использовать его для других целей. Есть компиляция в байт-код, ест очень мало памяти и работает на устройствах с 20 Кб ОЗУ. Переезд вынужденная мера, потому что используемый ныне duktape не очень подходит для игр - однопоточный, только интерпретация текста. И уже сейчас FPS сильно просел. А что будет, если количество объектов в игре вырастет до сотни (ответ очевиден)?
Добавлено (05 Июня 2018, 13:56) --------------------------------------------- Спустя почти неделю внедрен новый интерпретатор скриптов на JS - JerryScript. Теперь скрипты при загрузке компилируются в байткод и этот самый байткод выполняется в игре. Улучшено управление памятью. Ускорены операции очищения массивов с помощью сишных команд вместо дишных.
Скорость выполнения заметно выросла. Также прекрасно видно как часто то выделяет, то освобождает память duktape в то время, как jerry работает практически незаметно. К тому же JerryScript гораздо более гибкий - например, можно не ограничивать количество входных аргументов и проверять тип каждого. Уже задумал на будущее расширить количество поддерживаемых типов для добавления объекту - кроме уже имеющихся, стоит привинтить разные массивы. Плюс функцию objectAddVar сделать полиморфной - благодаря JerryScript это сделать чертовски просто.
Прикладываю ссылку на архив с маленькой сценкой и двумя раннерами: rgc_runner_d.exe - старый раннер с интерпретатором duktape rgc_runner_js.exe - новый раннер с интерпретатором JerryScript Намеренно отключена верт.синхронизация и ограничение кадров, чтобы можно было посмотреть максимальный FPS (что чревато багами с физикой, к сожалению).
Если кто-то будет скачивать и запускать, то отпишитесь о FPS в раннерах и есть ли ощутимая разница.
Сообщение отредактировал Vuvk - Понедельник, 04 Июня 2018, 05:58
vladhad22, спасибо за отчет. Да, проблема с коллизиями при повышении FPS известна. И она на стороне движка. Будем думать что можно с этим сделать в будущем.
Кстати, забыл приложить ссылку на гитхаб-проект с моими потугами по сотворению биндинга на D к библиотеке JerryScript. Вдруг кому-то пригодится: https://github.com/vuvk/d-jerryscript
Добавлено (29 Июля 2018, 11:17) --------------------------------------------- Всем привет! Некоторым могло показаться, что разработка заморозилась, но это не так. Я стараюсь еженедельно отписываться о прогрессе в своем паблике, а дублировать текст оттуда как-то лениво. Что ж, пришло время это исправить. В редакторе: - полностью готово окно редактирования оружия, как подбираемых объектов, оружия в руках, настройка типа пуль (лучи или видимые снаряды), настройка анимации, урона и т.д. - полностью готово окно редактирования видимых пуль - текстур, анимации, размеров и прочих параметров; - исправлено несколько досадных ошибок; - появился режим "показ пола" при рисовании стен - для удобства.
В среде запуска: - исправлен баг с коллизиями при высоких FPS; - загрузка оружия и пуль вместе с их параметрами; - исправлено несколько досадных ошибок; - создание объекта по имени из скрипта (ещё работаю над всеми фишками этого создания); - обработка паузы в скриптах (все объекты замирают); - загрузка скриптов по типам в память и их дублирование объектам при их создании, т.е. объекты берут скрипты ранее загруженные, а не загружают каждый раз необходимый - это было временное решение и я наконец-то от него избавился; - занялся чисткой кода раннера от мусора (старых комментариев, ненужных блоков, временных костылей и т.д.); - подключение и инициализация библиотеки PhysFS: реализация оберток для удобной загрузки файлов из архивов/папок, загрузка всех ресурсов с использованием нового метода работы с внешними источниками.
Добавлено (09 Ноября 2018, 08:06) --------------------------------------------- Уф, что-то я слишком давно не обновлял тему. На самом деле разработка не останавливалась и медленно, но верно движется к чему-то законченному. Особо разглагольствовать не буду, т.к. кому интересна тема, тот может подробнее почитать инфо в моих пабликах: VKontakte Facebook
По сравнению с предыдущим постом: - сменилось название на Nuke3D; - разработка среды запуска переехала на язык программирования C++. Т.е. полностью был переписан код с D на плюсы, попутно исправлены кривости в архитектуре. Это было сделано намерено для бОльшей совместимости с существующими готовыми библиотеками. Хотя D и замечателен, как язык программирования, но всё ещё сырой; - была разработана аудио-система на базе alure1.x + OpenAL. Её код вы можете взять здесь: audio_system.
Поддерживаются форматы: WAV, OGG, FLAC, MP3, XM, MPTM, IT, S3M, MIDI Поддержка прекэшированного и потокового воспроизведения как из папки, так и из архивов напрямую (спасибо библиотеке PhysFS) 2D и 3D звуки
- реализована работа со звуком: добавление звуков в редакторе, экспорт в пак, загрузка в среде запуска и управление звуками через скриптовую машину JavaScript
Последнее видео со средой запуска:
Старые видео в хронологической последовательности:
Видно, что стараетесь, только вот у меня возник, возможно глупый, вопрос, а как вы будете его распространять? По какой лицензии? (Просто интересно, ведь данный продукт может просто напрочь вытеснить Raycasting game maker)
), который будет обрабатываться раннером; 
