ТЕМА: Leaf Engine (эволюция бурундуков)

ZX_Lost_Soul пишет:
Давно пора разобрать похожие игрушки на коллекцию графики.

На счёт графики в Лиге Ангелов - согласен. Там очень не плохие модельки есть. Особенно нравятся эти демонески. Хотел даже с ними игру сделать, управлять такой бестией. Но это надо как-то оцифровать её позы все с игры.

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

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

Lekste, формат каких данных? Карты и база данных сохраняются в json, как у RPG Maker MV, но сама структура другая совсем. Возможно, сделаю возможность импорта, но только карт, не ивентов. Импорта ивентов с мейкерского проекта точно не будет, т.к. тут они немного иначе устроены (см. первый пост).

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

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

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

Lekste, ты не совсем верно понял задумку. Структура действий событий не стала проще - она осталась такой же, как в мейкере, со всеми командами, ветвлениями и т.д.
Изменился способ вызова действий - в мейкере он привязан к взаимодействию с конкретным ивентом (активация, касание, столкновение), либо не привязан вообще (автоматические, параллельные), а тут их можно привязать к чему угодно (ивент входит в регион, персонаж получает урон, нажата кнопка на клавиатуре). Это добавляет гибкости, т.к. нам не обязательно указывать конкретные варианты.
Раздел "условий" может содержать множество условий и нужен лишь для некоторого удобства. В мейкере эту роль выполняют галочки слева, где можно выбрать конкретный переключатель/переменную в качестве условия. Вообще я подумываю отказаться от него, дабы не сбивать с толку, оставить только "событие" и "действия", но пока не уверен.

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

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

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

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


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

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

Что-то вроде такого:


При этом, в вызываемом отдельном фрагменте ивента, также могут быть вызовы других отдельных фрагментов.

Если что, в активной команде должен был быть "If" вместо "Is". Опечатался немного.

Lekste, попробую привести пример.



Задача: игрок находится на букве S. В левой комнате находятся монстры, они движутся случайным образом. Человек в броне - защитник правой комнаты. Если монстры случайно подойдут на одну из клеток рядом с ним, на монстре должна показаться анимация удара, а сам монстр исчезнуть.

Решение на мейкере:
А если мы захотим добавить ещё одного монстра - придётся лезть в этот ивент и копировать всё ещё и для него.

Как это выглядит на Leaf Engine:
Рисуем регион рядом с войном и называем Регион 1, ивентам монстров добавляем тег "монстр".
Дальше мы можем спокойно размножать ивенты монстров и не париться, кого мы уже добавили в обработку, а кого нет.

Это все супер, но я писал не о перечне доступных команд мейкера, а о принципе формирования логики ивента.

При твоем наборе возможностей и описанном мной, принципе, список команд выглядел бы как-то так:

Если номер региона, где стоит ивент = 1
call 'Реагировать на вход в регион 1'
end

Реагировать на вход в регион 1:
Если {Этот ивент} имеет аттрибут 'монстр'
play anim 'slash'
Иначе
call 'Освободить проход'
end

Где 'Освободить проход' также отдельная цепочка команд с описанием перемещения ивентов.

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

А если будет требование: Ивент входит в Регион 1, при этом тип ивента "Монстр", у него меньше 25% HP, сейчас день и в радиусе 3x3 нет других монстров, а также есть хотябы 1 страж в регионе, то проиграть анимацию атаки, после этого, при условии, что не прошло хотябы 5 ходов с последней атаки монстров на регион и число активных стражей меньше трех, снизить моральный дух стражей, а затем, если моральный дух меньше 10, то снизить число стражей на 1.

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

Либо этот порядок зависел от другого условия, например, успел ли игрок нажать кнопку "Защита".

Lekste, и всё равно мы говорим о разном

Изначально речь шла о том, что действия (вся цепочка) привязываются не к конкретному ивенту, а к определённому событию. То есть они находятся не внутри персонажей или невидимых кубиков, а в отдельном списке событий карты. Это как раз-таки добавляет вариативности того, чем будет являться {этот ивент}.

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

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

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

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

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

А в сообщении я говорил о необходимости поддерживать создание 2-х и более цепочек команд на один тип события.
Как в примере из того сообщения:
Вход ивента 1 в регион 1: Проиграть анимацию удара
Вход ивента 1 в регион 1: Изменить дух стражей

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

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

А никто не пробовал с телефона демку открывать? Интересен вопрос производительности, будет ли нормальный показатель FPS у всех. Лучше всего идёт в Google Chrome.

Я запускал с планшета через хром. 120 fps показывало.
Через сафари иногда до 60 падает.

ZX_Lost_Soul пишет:
Sony Xperia Compact Z1, что в FF, что в Chrome примерно одинаково, от 60 до 110fps, правда иногда бывают вбырки до 44fps, но в целом весьма симпатично всё ходит.

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

А при чём тут бурундуки?

Фред Канниг пишет: Я две недели думал над ответом и вот он:


Теперь что касается прогресса.
1. Появилась поддержка звука и музыки. В связи с этим замечательным событием добавлена возможность ставить фоновую музыку локациям. Работает точно так же как в мукере - если у двух карт указана одна и та же BGM, то при переходе между ними музыка продолжит играть, если разная - старая остановится, а новая заиграет с начала.
2. Появилась возможность выбрать тип карты - интерьер. Такие карты не будут стараться растянуться на весь экран, а всегда выдерживать нужную высоту экрана и держаться посередине. Пустое место по бокам они заливают фоновым цветом, который указывается в настройках игры. Такой тип хорош для любых интерьерных локаций, находящихся в "черноте".
3. Переделан счётчик fps (старый не умел считать кадры при слишком сильных тормозах).
4. Добавлена кнопочка включения полноэкранного режима игры. Работает как на компьютере, так и на телефоне.
5. Доработаны ивенты. Чтобы избежать непоняток, сразу проясню: то, что в мукере называлось ивентами (event), в Leaf Engine называется сущностями (entity). Сделано это для удобства понимания, поскольку ивентами будут называться сами события, а не объекты на карте. Сути же в целом это не меняет - сущностью может быть как дверь/сундук, так и персонаж, в общем всё, что может потребоваться двигать/анимировать/активировать.
Пока добавлены всего два события (сущность входит в регион, клик на сущность) и два действия (перемещение на другую карту, движение сущности). Другие на подходе.
6. Оптимизирован/исправлен старый код.

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

А теперь небольшой вопрос для оживления темы. Игра, которую я делаю - так сказать, фанатский сиквел на старую jrpg. Поскольку игра старая, графика в ней довольно низкого разрешения. Возникает вопрос - использовать её как есть или же переделывать в "HD"
Для сравнения выставляю пиксельный оригинал и мою переделку.
Оригинал
Переделка

Что лучше смотрится? Пиксели или мазня?

ZX_Lost_Soul пишет: Лично я за пиксели

Интересно пощупать) Если движок использует pixi и будет поддержка сторонних плагинов, то думаю, что портировать DKTools не составит большого труда