Re: Что будет в INSTEAD 1.6.3

По частям:

blah = animation {
  frames = { 'pic1', 'pic2', 'pic3' ... }
,rate = 100
,next = 'anotherscene'
}

В моем варианте это:

blah = cutscene {
  dsc = "{pic pic1}{pause 100}{pic pic2}{pause 100}{pic pic3}{pause 100}{walk anotherscene}"
}

В целом, мысль понятна. Я подумаю еще.

Проблема еще в том, что cutscene (мой) сейчас решает более общую задачу, чем смена кадров. Он позволяет делать постепенный вывод, например. То-есть все равно упираемся в то, что есть некая программа, так как придумать универсальную структуру сложно, или снова получится xml.

Например:
вывели название
выдали звук
пауза
стерли название
выдали строку
фейдим
выдали строку
фейдим
ждем нажатия по кнопки
выдали строку
перешли на новую сцену

Будет:

dsc = [[
Hello!
{code set_sound '1.wav'}
{pause}
{cls}
INSTEAD
{fading}
2012
{fading}
{cut Дальше}
Поехали!
{pause}
{walk nextroom}]]

Как это оформить универсальными структурами - вот в чем вопрос.

Re: Что будет в INSTEAD 1.6.3

1. Ну вот я не хочу писать {pause 100} тысячу раз. Анимация же может содержать несколько десятков кадров, а если захочется сменить частоту - править в тридцати местах. Неудобно.

2. В принципе постепенный вывод - это и есть смена кадров smile Какая разница - картинка там выводится или текст.
Собственно, вывод текста есть частный случай. Поэтому описывать весь вывод внутри строки не совсем профильно что ли.
Если изменить в текущей реализации поведение функций pause и fading, и все это вместе представить просто в виде цепочки функций, чем это по сути и является, то будет на мой взгляд гораздо лучше.

А ХМЛ придумывать не надо. Тут же нет деревьев, зачем ХМЛ smile

Достаточно лишь (названия функций условные):

{
  "Hello!",
  code("set_sound '1.wav'"),
  pause,
  cls,
  "INSTEAD",
  fading,
  "2012",
  fading,
  cut("Дальше"),
  "Поехали!",
  pause,
  walk("nextroom")
}

Re: Что будет в INSTEAD 1.6.3

По поводу того, как все это представить...

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

В принципе можно делать как-то так:

function pause(tm)
  if tm == nil then
    tm = some_default_value;
  end

  return { type = 'pause', value = tm };
end

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

Re: Что будет в INSTEAD 1.6.3

Кстати, можно сделать так, что спокойно будут поддерживаться оба варианта вызова функций, типа:

{
  pause,         -- пауза по умолчанию
  pause(100) -- пауза 100
}

Как-нибудь так:

function pause(tm)
  if tm == nil then
    return { type = 'pause', value = some_default_value };
  else
    return function()
      return { type = 'pause', value = tm };
    end
  end
end

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

Re: Что будет в INSTEAD 1.6.3

По поводу 1000 раз это не проблема. В первом варианте я делал именно так - задание фейдинга 1 раз, но это оказалось не так гибко.  Это детали, их можно изменить,

Перейти к схеме {} тоже не проблема, сейчас уже поддерживается:

dsc = {
   "a",
   "{pause}",
   "b",
}

делаешь function pause( )  return "{pause}" end или даже PAUSE = "{pause}" и пишешь:

dsc = {
   "a",
   PAUSE,
   "b",
}

Насчет смены кадров, не так просто, если моя задача дописывать по букве, или по абзацу, то каждый след кадр должен включать предыдущее?

Почему я сделал именно в тексте, тк в большинстве случаев будет писаться что-то вроде:

dsc = "Это моя игра...{cut О чем?}Про осьминогов!";

Re: Что будет в INSTEAD 1.6.3

Вообще, у меня есть сомнения не только по этому модулю.
Как быть с модулями: proxymenu (меню в стиле ZX игр), trigger, fonts...
Вроде бы это уже расширения, надо ли их совать в инстед, или держать отдельно, не ясно.

Re: Что будет в INSTEAD 1.6.3

Насчет смены кадров, не так просто, если моя задача дописывать по букве, или по абзацу, то каждый след кадр должен включать предыдущее?

А сейчас это как будет описываться?

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

Почему я сделал именно в тексте, тк в большинстве случаев будет писаться что-то вроде:

dsc = "Это моя игра...{cut О чем?}Про осьминогов!";

Хз, что там будет в большинстве случаев. Мне кажется, в большинстве случаев будет картиночная анимация.

Re: Что будет в INSTEAD 1.6.3

Peter wrote:

Вообще, у меня есть сомнения не только по этому модулю.
Как быть с модулями: proxymenu (меню в стиле ZX игр), trigger, fonts...
Вроде бы это уже расширения, надо ли их совать в инстед, или держать отдельно, не ясно.

triggers вроде полезная штука smile Мне правда не совсем ясно, зачем там on и off.

fonts создает дополнительные шрифтозависимости, что не есть круто. Хотя едвы он вроде не просит.

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

Re: Что будет в INSTEAD 1.6.3

fonts не тянет шрифты, он их эмулирует спрайтами smile То есть от автора зависит. Слишком хакерский модуль.

Насчет тек реализации катсцен, сейчас есть:
pause = вывести то что было сверху и подождать
fading = вывести то что было сверху эффектом фейдин,

то есть да - 1000 кадров будут 1000 fading обрамляться, но  думал что кат сцена -это 3-5-10 картинок а не анимация.

Фиг знает, у меня тоже сомнения, не сколько даже по конкретно размещению в dsc, сколько в том, что это уже трюки начинаются. Буду думать.

on/off удобно - например триггер включает новый триггер

---
вывод по буквам, например
a{pause}b{pause}c{pause}

будет последлвательно выводиться по символу, в конце станет: abc
a{pause}b{cls}{pause}c{cls}{pause} = со стиранием каждой буквы, в конце станет: c

Re: Что будет в INSTEAD 1.6.3

1000 кадров не будет, но кадров 20 - вполне.
По поводу последовательного вывода текста, тут между нотациями "все в строке" и "все через точку с запятой" разница только в синтаксисе, поведение-то может быть абсолютно таким же. Хотя для того, чтобы понять, как именно все должно выглядеть, надо для начала понять, какой, так сказать, основной юз-кейс. А том может так получиться, что лучше делать не одну универсальную катсцену, а несколько отдельных узкоспециализированных фишек.

А триггер всегда срабатывает только один раз или можно сделать так, чтобы он срабатывал всегда? Если только один раз, то on и off по-моему точно не нужны, есть же условие срабатывания.

Re: Что будет в INSTEAD 1.6.3

Вот давай рассмотрим пример из реальной жизни. Это по поводу катсцен.

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

Как сделать подобное на текущем движке катсцен?

Re: Что будет в INSTEAD 1.6.3

один раз (про триггеры), но:
1) зачем держать взведенным всем триггеры сразу? это нагрузка на life, которая обычно не нужна:
2) может быть цепочная зависимость триггеров, второй триггер зависит от n предыдущих, инче пришлось бы вбивать общее условие, в котором учтено состояние прошлых триггров;
3) триггер можно взвести заново, после того как он уже сработал;

Насчет катсцен, у меня тоже не универсально, чтобы сделать прогрессбар прийдется мутить с {code} и таймером, как я думаю.
С другой стороны, часто хочется простого: вывести титры, вывести текст по частям, с фейдингом. Иди драматически постепенно выводить текст. Я в основном на это ориентировался.

Подозреваю, что отдельно нужно делать: анимацию, прогрессбары итд итп....

P.S. короче надо подумать.

Re: Что будет в INSTEAD 1.6.3

В общем сделаю так, пока fonts и cutscene перенесу в doc/example. А дальше посмотрим.

Re: Что будет в INSTEAD 1.6.3

По триггерам:

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

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

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

По поводу катсцен:

Мой пример не столько о прогрессбаре, сколько о том, что иногда может потребоваться *частичная* перерисовка текста.

Подозреваю, что отдельно нужно делать: анимацию, прогрессбары итд итп....

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

Чего бы потенциально хотел видеть я из подобных фишек - это различные эффекты транзишина. Т.е. не только фейдинг, но и "схлопывание" картинки например или затемнение.

Re: Что будет в INSTEAD 1.6.3

1) триггер в пределах одной комнаты это практически синоним life.

2) ну в принципе - невостребованная доп функциональность не есть проблема.

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

3) Не так универсально, тк не факт что это свойство не меняется. Иногда я хочу чтобы триггер включался заново, иногда нет. Это зависит от кода.

Итого, хочешь автоматически взведенный  триггер? Тогда пиши: t = trigger():on()

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

trigger("Привет"):on()

----
Затемнение можно сделать переходом в черную картинку, а вот остальное -- не в 1.6.3.

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

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

Re: Что будет в INSTEAD 1.6.3

Peter wrote:

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

Со всеми остальными объектами однако не так. По умолчанию включены, а для включения/выключения используются функции enable/disable.

Re: Что будет в INSTEAD 1.6.3

Да, но disable enable и с триггерами работает. Объект триггер не является дизабленным, он только не взведен.

Наверное, основное это все таки бесполезная нагрузка на life, тк триггеров можно наделать массу, и 90% из них не нужны во время старта игры.

То есть это как взяли, и все life методы включили сразу. Есть какая то некрасивость.

43 (edited by Vorov2 2012-04-04 17:17:42)

Re: Что будет в INSTEAD 1.6.3

А чем дизаблед триггер отличается от невключенного?   smile

Я сейчас аналог триггеров использую по сути для двух вещей:

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

2) Положить по некоему условию некий объект в некую комнату.  Но такое использование мне не нравится, я бы предпочел заменить его. Для объектов, кстати, нельзя определять функции enable и disable? Это было бы идеально заменой.

Остается п.1. Для него в общем никакой механизм особый и не нужен по большому счету. Нужно вот что:

room {
  life = trigger('Туда не ходи!', code)
}

function trigger(txt, cond)
  return function(s)
    if cond then
      lifeoff(s);
      return txt;
    end
  end
end

И все.
Т.е., если так подумать, то в общем и не особо-то нужная штука  hmm

Re: Что будет в INSTEAD 1.6.3

disabled триггер не будет обрабатываться, даже если он был включен и находится в life списке.
off триггер отсутствует в life списке,

disable/enable есть у всех объектов, автоматом они есть и у триггеров.

про disabled/enabled объектов не понял. объекты можно включать и выключать, а что нужно?

Если тригер в пределах комнаты, то он становится по сути life. Только lifeon/lifeoff при входе/выходе из комнаты все равно придется делать.

Да вот и я думаю, может ну их эти триггеры smile

У меня единственное применение в entered:

trigger("Привет"):on()

Типа показать реплику - как бы act от NPC.

Триггеры по идее удобны для:
1) отслеживание состояния героя (если life < 0 конец игры)
2) управление музыкой

Но все это делают и life, просто триггер это некое упрощение. По идее, в них есть смысл, если анализируется состояние нескольких объектов/условий сразу.

45 (edited by Vorov2 2012-04-04 17:53:30)

Re: Что будет в INSTEAD 1.6.3

Peter wrote:

disabled триггер не будет обрабатываться, даже если он был включен и находится в life списке.
off триггер отсутствует в life списке,

Что с т.з. пользователя, как я понимаю, одно и то же.

По поводу объектов вот что иногда хочется:

obj1 = obj {
  ...
  ,enable = function(s)
              return true|false;
            end
}

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

Re: Что будет в INSTEAD 1.6.3

Ну выводи или не выводи dsc, для тебя это синоним я так понимаю....
Грубо говоря, просто пусть твой объект ведет себя как disabled или enabled в зависимости от твоего enable метода,

Хотя мне нравится добавлять/enable объект в событии, непосредственно связанном с логикой его появления. По-моему это понятней.

Re: Что будет в INSTEAD 1.6.3

Да, что-то я все время забываю про то, что dsc может вернуть null.  sad

Re: Что будет в INSTEAD 1.6.3

думаю что и триггеры надо в doc/ smile пока не станет понятен смысл их применения

Re: Что будет в INSTEAD 1.6.3

В общем, я понял, что люди не готовы к триггерам, шрифтам и cutscene.  big_smile
Может получиться то же, что и с xact. Так что все эти модули ушли в doc/examples.

Re: Что будет в INSTEAD 1.6.3

Поюзал тут cutscene - понравилось!
Вопрос только остался - насколько он требовательный к ресурсам?
И еще не разобрался с  {pic <what>}, не понял как он работает. Картинки делал через img  smile

Я творец! Хочу - творю, а хочу - вытворяю!