Так как часто возникают вопросы, а что такое собственно INSTEAD, выкладываю подборку *исторических* статей:

Как все начиналось: http://instead.syscall.ru/ru/2010/05/09/history/
Обзор INSTEAD 1.2.0: http://instead.syscall.ru/ru//2010/09/12/instead-1-2-0-review/
Ответ на одно письмо: https://instead.syscall.ru/wiki/ru/gamedev/quickstart
Что такое метапарсер?: https://instead.syscall.ru/wiki/ru/gamedev/modules/metaparser/article
Выпуски printed: http://printed.syscall.ru/

Напомню, что скоро грядет INSTEAD 3 - который по большей части переписан.
Про STEAD3 мы записали подкаст: http://instead.syscall.ru/podcasts/podcast_05.ogg
Другие подкасты тут: http://instead.syscall.ru/ru/about/

Кому интересно, почитайте. :)

А пока вы тут настраиваете idec софт, true-grue перевел статью: 12 правил для игр-приключений от Рона Гилберта

Читать на новом принтеде ;)

http://printed.syscall.ru/post/12-pravil-dlya-igr-priklyuchenij-ot-rona-gilberta

эх, мы в глубоком детстве тоже игры на бейчике писали :) правда, мы файтинг писали про членов нашего двора, как мы друг друга круто мочим :)

блин, не туда ответил - это про Леночку

Статья Рона Гилберта.

Рон Ги́лберт — американский разработчик игр, программист и продюсер, работавший над серией квестов компании LucasArts, один из разработчиков игрового движка SCUMM.

http://printed.syscall.ru/post/12-pravil-dlya-igr-priklyuchenij-ot-rona-gilberta

true-grue опубликовал небольшую заметку на полях ПРИНТЕДА:
http://printed.syscall.ru/post/ponimanie-komiksa

Привет, друзья! С радость сообщаю о выходе нового INSTEAD 3.0! Этот выпуск готовился целый год, и для него бессмысленно писать список изменений, ведь новое в нем – практически все. В этой версии появился совершенно новый стек STEAD3, который уже успели оценить авторы игр. В нем учтен весь многолетний опыт предыдущего стека, который теперь называется STEAD2, и он также включен в INSTEAD. Так что все старые игры по прежнему работают! Документация по новому стеку написана и включена в релиз. Читайте, пробуйте, творите! Среди других изменений:

- переписана C часть, теперь INSTEAD стал модульным;
- в исходный код включен пример минимального интерпретатора (100 строк);
- графические возможности расширены за счет подсистемы pixels;
- звуковые возможности расширены за счет возможности генерировать звук из кода;
- исправлено множество ошибок.

Бинарные сборки будут появляться по мере их готовности.

Кроме того, в этот раз одновременно с выходом INSTEAD 3 выходят несколько новых игр, которые написаны с помощью нового движка! Встречайте:

- ПРОВОДНИК: http://instead-games.ru/game.php?ID=247
- ИНСТЕДОЗ 5: http://instead-games.ru/game.php?ID=252
- ИНЖЕНЕР: http://instead-games.ru/game.php?ID=248

И это еще не все! Журнал ПРИНТЕД поменял свой формат, и теперь доступен здесь: http://printed.syscall.ru

Вы думали новости закончились? Нет! Добро пожаловать в только что открывшийся: КЛУБ INSTEAD: http://club.syscall.ru

Спасибо и до новых встреч! :)

Нам нужен instead-ng 3.0.0! :)

При обсуждении идей игр на INSTEAD, часто затрагиваются вопросы вариативности/свободы в подобных играх. В том плане, что если запрограммировать NPC, дать больше свободы игроку, то может получиться что-то интересное... На мой взгляд эти вопросы тесно связаны с более общим вопросом: принципиальной возможности машинного творчества (возможности создания такой иллюзии). Решил описать некоторые мысленные эксперименты, о которых думал раньше. :)

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

Так вот, мне не интересны шахматы сами по себе, мне всегда интересен сам диалог. В книге и в классическом квесте - это диалог с автором. Даже если он кому-то не заметен, он есть. Поэтому в данном тексте, я рассматриваю возможность симулировать творчество машиной. Можно ли написать такую игру, в которую даже самому автору будет интересно играть, но это будут не шахматы (не просто свод правил)?

Представим себе, что мы хотим написать программу -- художника. Которая нарисует нам пару новых шедевров и мы с удовольствием рассмотрим их. :)

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

Я могу написать формулу фрактала, и программа нарисует мне картинку. Но я уже нарисовал ее, введя формулу фрактала. Я просто получаю то, что ожидал увидеть (как автор программы). Это не творчество. Хотя тут есть возможнось использования компьютера, как инструмента для творчества. Но это несколько другая тема.

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

Итак, размер холста: 1x1. Хорошая новость: программа способна нарисовать все возможные картины и таковых картин будет две. Черная точка и белая точка. Правда, сказать что такая картина "красива" или нет мы не очень то можем -- обе слишком примитивны. С другой стороны, просто точка -- это тоже концептуально. А отсутствие точки, можно сказать -- отсутствие картины. :) Итого -- из 2х картин одна может считаться "нормальной".

Хорошо, перейдем на 2x2. Тут будет уже 16 картин. Часть из которых, условно интересные. Например, "уголок", диагональ, квадрат. Часть картин повторяют друг друга -- просто они симметрично отражены, например. Или повернуты.

Повышая размер холста, скажем, до 8x8 -- мы можем сказать, что программа способна создать все возможные картины на этом холсте, простым перебором. Таких "картин" будет 2 ^ 64.

8x8 это уже тот размер, в котором будут прикольные монохромные иконки, и, скажем, полный алфавит русских букв. :) Да вообще, много чего там будет! Все, что сможем уместить в 8x8.

Но мы замечаем, что с ростом размера холста, доля "интересных" картин сокращается. Если на холсте 2x2 мы сразу можем выбрать "интересные" нано-картинки, то на холсте 8x8 нам и жизни не хватит, чтобы выбрать "интересные" вещи. Кроме того, сам перебор на больших холстах, также начинает съедать время и объем диска (на хранение картинок).

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

"Функция красоты" -- такая функция, которая отбраковывает плохие, неинтересные картинки, и оставляет хорошие, создавая иллюзию творчества. Очевидно, что функция красоты должна быть антропной -- то-есть в ней должны быть заложены функции субъекта и понятия о красоте.

Интересно, что на маленьких разрешениях функция красоты может быть довольно простой, и придерживаться простых правил: например, учитывать симметрию, пропорции, целостность изображения. Возможно, искать принципы само-подобия. Но с ростом степеней свободы, функция красоты начинает стремительно приобретать качества человека, по сути вырождаясь в ИИ. :)

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

В качестве практического примера, я писал игру на SDL, где все персонажи генерировались похожим образом. Монстрики и прочие существа, конструировались из сгенерированных фрагментов, с попыткой использования принципов симметрии. Получалось забавно, но только на небольших разрешениях. Еще один пример "практического" использования -- генерация лабиринтов, в которых есть симметрия и некоторые другие категории "красоты".

Конечно, все что я написал -- самоочевидные вещи, я решил написать эти соображения чтобы показать следующее:

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

Простите за словоблудие. :)

Да всё правильно написали, это очень сложная или скорее объемная задача. Поэтому не надо пытаться генерировать литературу машиной, надо поверх некого общего сюжета и продуманных персонажей впихнуть хорошую вариативность, которая таки будет сильно ограничена степенями свободы сюжета и прочих вещей. Такой подход уже опробован в различных играх и он оправдывает себя. В какой то мере можно привести тот же Fallout, там вроде открытый мир, но мы всё равно в лапах сюжета. Мне лишь хотелось бы чтобы с персонажами можно было более подробно общаться, а то они часто вообще не знают где находятся, даже дорогу не спросить (такая ситуация была в игре "Трудно быть богом").

Хотя вы так смачно описали генерацию сюжета, что и это интересно было бы попробовать. Я бы не сказал, что существующие в репозитории игры (кроме портированных) сильно разнообразны сюжетами. Учитывая что для определённого жанра игр не требуется красочное литературное описание, быть может "электронный распорядитель игр" сможет внести в досуг много интересных загогулин, генерируя разные части сюжета и персонажи к ним. Сочинение произведения - это творчество, но ведь оно обязано подчиняться определённым законам и требованиям, 3-4 актная структура и т.п. :-) Если иерархически представить себе конструкцию из мельчайших действий до целых актов "экспозиция", "завязка", "поворот", "кульминация", "развязка" и т.п. то высокая вариативность может быть перерастёт в качество. Это не будет роман, сочинённый машиной, это будет игра, в которую можно играть то так то этак. Конечно это сложнее того, что я первоначально описывал. Думается начать надо с внедрения "вариативных персонажей" в более менее стабильный сюжет. Для примера берём "квантового кота" и реализуем все действия на основе честного добровольного выбора действий, расширяем набор возможностей, глубину персонажей. С каждым проигрышем игрок будет находить что то новое, какой то новый слой, который он до этого не видел. Ну в общем свой "Мир дикого запада" с блекджеком и прочими :-)

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

Вопрос в том, чего хочется от игры/книги. Например.

Есть просто литература. Есть книги-игры. (Фактически -- литература, написанная так, чтобы она могла склеиваться из кусочков)
Я никогда не променяю хорошую книгу -- на книгу-игру. Это абсолютно разное воздействие и разные жанры.

Так что, вероятно, то, что для тебя недостаток -- для меня достоинство. Мне нравятся рельсы в квестах. :) Да, это одноразовые игры. Как и одноразовые книги :) Хотя, хорошие книги можно перечитывать. Отсутутвие рельс переводит игру в другой жанр, который мне уже не так интересен.Это детали, которые никак не углубляют само произведение. Мне интересны загадки в том виде, в каком их придумал автор. Мне нравится что сюжет конкретен как в книге... Когда я пробую песочницу на прочность, все-таки, это уже нечто другое. Фактически, это становится игрой -- исследуй законы, которые создал автор. Это тоже интересная игра, конечно, но это ближе к стратегии. К шахматам. Некий другой жанр.

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

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

Но повторюсь, пишу просто в рамках обмена мнением. Не более.

XSet> Хотя вы так смачно описали генерацию сюжета, что и это интересно было бы попробовать. Я бы не сказал, что существующие в репозитории игры (кроме портированных) сильно разнообразны сюжетами.

Ну, пиши, посмотрим что выйдет. :)

Да. Синтез вышел бы забавный. Пошёл спасать кота, а в итоге выбрался из туалета :-)

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

А я думаю у неё такой функции и нет, чтобы улучшать сюжет и литературность или что то делать с рельсами, я думаю это просто другой жанр. Точно также как игры не являются книгами, а интерактивная литература не является аркадами, стрелялками и т.п. - игры с симуляцией - это особый вид искусства причём междисциплинарного, тут и литература и программирование и инженерия знаний. Думается и для них должна быть ниша. Кому то нравится жёсткий но хорошо прописанный сюжет, а кто то хочет наоборот повышенной интерактивности мира даже ценой утери его литературной составляющей. Пробовать песочницы - это тоже интересно. Не надо ничего "променивать", пускай расцветают тысячи цветов, нельзя же силой все усадить писать игры в одном жанре в одном стиле и т.п. Лично меня необычность Карантина потрясла, это было что то новое, как бы рассказ "Стой кто идёт" в интерактивной форме. Было бы скучно, если бы игр и кино не было, а был бы один исходный рассказ.

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

XSet> А я думаю у неё такой функции и нет, чтобы улучшать сюжет и литературность или что то делать с рельсами, я думаю это просто другой жанр.

Согласен. Можно так сказать. Вот, кстати, еще пример: http://www.storyteller-game.com/

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

Спасибо. Вообще если говорить о генерации сюжетов прямо с нуля, то на ум в первую очередь лезет Пропп с "Морфологией волшебной сказки", вот уж где по полочкам всё размазано.

Я наконец добрался до последних версий своего кода системы вывода и планировщика на старом компе, вроде выглядит неплохо, тут же куча написанных мной же исследовательских текстов по аспектам генерирования сюжетов. Это я написал когда меня накрыло в прошлый раз. Выглядит неплохо, надо интегрировать в Instead, а то я писал под внешнюю Lua IDE. По крайней мере целеориентированная парадигма ИИ с операторами и эффектами GOAP (применяется в когнитивных архитектурах Act-R, SOAR) понятно как работает и она концептуально проста, к тому же совместима со всеми подходами к логическому выводу, хотя как такового вывода не требует.

Задаём операторы (действия) которые создают некий эффект на состояние мира, например если персонаж поест, то он станет сытым, его вес увеличится и т.д., или если дверь закрыта и есть ключ то можно выполнить "открыть". Если дверь открыта, то можно пройти в локацию за ней. Таким образом попасть в локацию за дверью можно только найдя ключ. Планировщик может построить цепочку действий с минимальной стоимостью для достижения цели или провести верификацию какого то утверждения, таким образом для обычных игр Instead мы могли бы проводить верификацию проходимости ещё до запуска игры, а идеале этот же движок и должен реализовывать проверки,а не ручной код. Производительность труда для создания обычных игр должна существенно повыситься, т.к. это даже не конечный автомат, не система вывода вроде Пролога или CLIPS, а следующий уровень - планировщик, который позволяет связывать довольно общие определения, паршивенькая но модель левого полушария мозга :-)

Кстати вот ещё практический подход, офигенская книга от создателя IBM Watson, я даже нашёл ранние версии кода:
Daydreaming in Humans and Machines: A Computer Model of the Stream of Thought

Попытка научить компьютер фантазировать и порождать сюжеты.

Если кому интересно:
DAYDREAMER is a cognitive architecture that models the human stream of thought and its triggering and direction by emotions, as in human daydreaming. DAYDREAMER includes: daydreaming goals: strategies for what to think about; emotional control of thought: triggering and direction of processing by emotions; hierarchical planning: achieving a goal by breaking it down into subgoals; analogical planning (chunking): storing successful plans and adapting them to future problems; episode indexing and retrieval: mechanisms for indexing and retrieval of cases; serendipity detection and application: a mechanism for recognizing and exploiting accidental relationships among problems; and action mutation: a strategy for generating new possibilities when the system is stuck. DAYDREAMER is implemented as 12,000 lines of Lisp code.

Автор: крутой перец - Erik T. Mueller - на его логическом движке пашет IBM Watson. Судя по всему при должном масштабе этот подход работает.

А ссылку на источник можно? На этот дэйдример.

https://github.com/eriktmueller/daydreamer
https://books.google.ru/books?id=mS3U4lMtCX8C&printsec=frontcover&hl=ru#v=onepage&q&f=false
Вроде оно.

Да. Но хреновина не простая и заточена под странные вещи, поэтому напрямую использовать нельзя, но ознакомиться с подходом ИМХО полезно.

К вопросу о машинном творчестве, кстати. Были статьи про написание музыки компьютером. А ещё нейросеть имитирует стиль художников.
Там тоже есть функция красоты, в музыке гармонии, для картин примеры работ. Хотя все согласны, что что-то тут всё равно не так :)
https://geektimes.ru/post/272430/
https://habrahabr.ru/post/185154/

Про каракули в произведение -- все-таки тут человек участвует. :)
А музыка звучит просто жутко. Слепое мертвое чудовище (с) создает эту музыку, бррр.... Но интересно, конечно, как эксперимент.

В общем я на вашей стороне. На этом этапе покушаться прямо на генерацию сюжетов - это самоубийство и никогда не будет сделано (кроме концептов генераторов сказок). Я долгое время ковырял лингвистику, это адова задача, хотя у меня накоплен немалый задел (в плане материала), в том числе большие тезаурусы с претензией на охват ВСЕГО. :-)

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

Сегодня говорил с true-grue и пришел к такому выводу:

Идея хорошо может сработать в ситуации, когда модель становится "объектом", а не "субъектом". Грубо говоря -- боты не могут быть выше создателя, но могут стать "детьми". Чтобы совсем уж не уходить в философию, примеры таких рабочих ситуаций:

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

2) игра в которой надо предотвратить убийство или самоубийство, путем воздействия на "ботов" в коллективе или индивидуального "бота" (не сторонник таких игр -- но тем не менее -- идея рабочая);

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

Для себя лично я сделал еще некоторые выводы.

Творчество -- это всегда общение. Общение не возможно без "я - ты" (субъектов). Вся наша жизнь -- это творчество. Новое (творчество) и жизнь -- нераздельные вещи.

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

Возник такой вопрос.
К примеру, у нас есть таймер, установленный по timer:set(5)
и вот такой код:

game.timer = stead.hook(game.timer, function(f, s, cmd, ...)
if vn.processing then
return;
end
if not vn.on then
return f(s, cmd, ...);
end
vn.processing = true;
local result = code_that_can_take_more_than_5ms_to_complete();
vn.processing = false;
return result;
end)

Собственно, вопрос: нужно ли вообще это извращение с vn.processing? Или в таймере всё синхронно и новый вызов гарантированно не произойдёт, пока старый не завершён?
А если там реально всё асинхронно, и таймер стреляет с той частотой, что ему указали, будет ли такой код потокобезопасным (в Java я бы точно сказал, что нет, vn.processing нельзя модифицировать без синхронизации, мьютекса итп.)
Ну и вообще, как разрулить такую ситуацию? В идеале хочется, чтобы новый вызов кода по таймеру НЕ происходил, пока старый не отработал.

Antokolos> Возник такой вопрос.
P.S.: Вопрос по STEAD2, но, думаю, в STEAD3 всё примерно так же.

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

P.S. для вставки кода юзай такую запись

ПРИВЕТ МОНОШИРИЙНЫЙ МИР

Peter> Таймер всегда синхронный -- он не прерывает команду инстеда, он обрабатывается между командами и сам может генерировать команду. Насколько я помню -- game.timer это уже производное событие -- которое обрабатывается как обычная команда своим чередом.
Ясно, спасибо! Ну, тогда код упростится :)

В таймере новый вызов происходит, емнип, через timer:set(n) после отработки старого вызова. Т.е. отработал вызов, ждёт n, новый вызов. Во время n происходят другие события.

Kerbal> В таймере новый вызов происходит, емнип, через timer:set(n) после отработки старого вызова. Т.е. отработал вызов, ждёт n, новый вызов. Во время n происходят другие события.
Вообще, изначально у меня было так:
в самом начале длительного метода timer:stop(), чтобы точно уже не пришёл новый тик.
в самом конце длительного метода timer:set(n), чтобы вновь запустить таймер.
Однако, это по каким-то причинам иногда стало приводить к тормозам (сейчас делаю Варвара под Андроид, и на слабом планшете это очень чувствуется).
Была даже гипотеза, что какие-то проблемы с освобождением памяти, но нет, это не подтвердилось.
Сейчас у меня timer:set(n) только в функции init(), timer:stop() вообще не используется, т.е. таймер бесконечно молотит.
В результате становится возможным реализовать, к примеру, onmouseover для спрайта.
Единственно вот беспокоил вопрос, не может ли так выйти, что таймер запустится снова, не дождавшись отработки предыдущего вызова.

onmouseover для спрайта хотеть! Покажешь потом как сделал? Я, когда делал панорамы и дёргал функцию отрисовки в таймере, обрамлял рассчёт каждой линии рендера вызовом stead.busy() чтобы не залипал курсор. Этот же трюк использовал в шахматах. Там тоже на планшете медленно ходы обдумывает. Посмотри, может пригодится где-нить.
https://yadi.sk/d/pmvrIvW5xiXbZ
http://instead-games.ru/game.php?ID=225

kerber> onmouseover для спрайта хотеть! Покажешь потом как сделал? Я, когда делал панорамы и дёргал функцию отрисовки в таймере, обрамлял рассчёт каждой линии рендера вызовом stead.busy() чтобы не залипал курсор. Этот же трюк использовал в шахматах. Там тоже на планшете медленно ходы обдумывает. Посмотри, может пригодится где-нить.
kerber> https://yadi.sk/d/pmvrIvW5xiXbZ
kerber> http://instead-games.ru/game.php?ID=225

Спасибо, погляжу!
Ну, а по поводу onmouseover идея простая. Постоянный таймер + stead.mouse_pos() даёт координаты, и есть два спрайта, обычный и при наведённой мыши. С помощью модуля vn в нужный момент показывается нужный спрайт.
Более подробно можно в Варваре посмотреть, только там страшный код, конечно :)
Ну или вот есть более простой пример:
https://yadi.sk/d/bj-eEC403DszoC
Только модуль там староват, я его постоянно обрабатываю напильником.
Последние версии смотреть здесь:
https://github.com/Antokolos/NLB/blob/master/NLBL/src/main/resources/vnstead/modules/vn.lua

Очень мне хочется, чтоб вы пощупали новые спрайты. В stead3. Ибо там они автоматом освобождаются. И мало кто их тестил. ;) У самого пока руки никак не дойдут до творчества...

Peter> Очень мне хочется, чтоб вы пощупали новые спрайты. В stead3. Ибо там они автоматом освобождаются. И мало кто их тестил. ;) У самого пока руки никак не дойдут до творчества...
Пощупаем-пощупаем :) В планах перевод конструктора на stead3, заодно и генерируемый код надо причесать.
А кстати, sprite.free() осталась, но теперь ничего не делает?

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

Сегодня удалось собрать сабж. С минимальными изменениями. Игры работают, и работают быстро! В том числе те, что со спрайтами. Fps в аркадах 60 fps. :)

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

Проблемы:
1.Переделать фейдинг
2.Музыка ogg (звуки уже работают)
3.Поддержка трекерной музыки
4.Поддержка iconv
5.Сохранения (сейчас они не переживают сессии)

Из всего этого, не знаю как решить 5. Может быть, поможет technix. Остальное, вроде понятно как делать.

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

Отличные новости!
Интересно, в чём была проблема прошлой Emscripten-версии, которая подтормаживала?
А сборочный скрипт для Emscripten будет прямо в основном репозитории Инстеда?

> Отличные новости!
> Интересно, в чём была проблема прошлой Emscripten-версии, которая подтормаживала?
> сборочный скрипт для Emscripten будет прямо в основном репозитории Инстеда?

Там проблемы были в цикле обработке, в реализации таймера в SDL emscripten, в сборке SDL_mixer...

В основном репозитории думаю что как закончу все, что то положу точно. Или readme, или скрипты... А код уже пушаю по тихоньку.

Ну и вот, для первого тестирования прототипа (пока не оптимизированно по скорости, но по моему и так хорошо шпилит):
http://instead.syscall.ru/downloads/instead-em/project.html

Известные проблемы:
1) не всегда грузятся ogg шки
2) иногда исключение на рестарте
3) save пропадают

Новая информация по emscripten сборке.
1) Все желающие с Linux могут попробовать собрать себе instead-em сами. Вот скрипт, который у меня собирает все зависимости и сам инстед:
https://github.com/instead-hub/instead/blob/master/contrib/instead-em-build.sh
Конечно, могут быть какие-то косяки, но в целом -- смотря внутрь скрипта не сложно разобраться что происходит.

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

3) С сохранениями не разбирался, но нашел такую статью: http://www.alternativegames.net/blog/porting-to-emscripten/ где это вроде описывается.

4) Есть проблема -- почему то на андроиде не пашет мышка. Такое чувство, что canvas не получает фокуса или что то такое.

Я сейчас хочу прерваться. На самом деле, нужно понять зачем нам это все нужно.
Плюсы -- инстед прям как "настоящий". Аркады можно гонять, и они работают быстро! :)

Минусы -- нужна поддержка webgl, нестабильная музыка.

В целом, мне нравится, но нужно дальше развивать проект. Я пока делаю перерыв. Если есть желающие помочь/поэкспериментировать -- буду рад!

Еще дополнение. На chromium у меня не упало даже с музыкой. Перезалил обновленную версию. Добавил несколько игр:
http://instead.syscall.ru/downloads/instead-em/project.html

В браузере должен быть включен webgl.

Еще хорошие новости.
Заработала трекерная музыка в полном объеме!
Обновил версию:

http://instead.syscall.ru/downloads/instead-em/project.html

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

Обновил.
Сохранение настроек. Добавил игру про кота. :) В целом, все работает.
В git пушнуты изменения (скрипт сборки).

http://instead.syscall.ru/downloads/instead-em/project.html

Исправил работу с конфигурационным файлом:

http://instead.syscall.ru/downloads/instead-em/project.html

INSTEAD-EM близок к релизу!

Почти все мои игры в веб варианте здесь:

http://syscall.ru/games/

Если что, все есть в git :)

Версия обновлена. Теперь и на мобилках. Но дизайн не адаптирован. В самом инстеде поиграйтесь с настройками разрешения, если будет мелко...

http://syscall.ru/games/

Собрал INSTEAD-EM ещё раз после нашего вчерашнего разговора в чате.
Демо Варвара без музыки (~40MB)
http://nlbproject.com/instead-em/instead-em.html?barbarian_caves_demo_nosound.zip
Демо Варвара с музыкой (~60MB)
http://nlbproject.com/instead-em/instead-em.html?barbarian_caves_demo.zip

Версия с форума в конечном итоге упала с ООМ, поэтому в своём варианте я заменил
-s ALLOW_MEMORY_GROWTH=0
на
-s NO_EXIT_RUNTIME=1 -s ALLOW_MEMORY_GROWTH=1

Падение произошло во время игры в кубики. Попробуйте её найти, это хороший стресс-тест для INSTEAD-EM :)

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

Интересно:
1) Куда реально попадают сохранения? Это же где-то в браузере должно храниться?
2) Какие именно изменения сделаны в "пропатченном Emscripten"? Критично ли это для конечного результата?

> Интересно:
> 1) Куда реально попадают сохранения? Это же где-то в браузере должно храниться?

В local storage

> 2) Какие именно изменения сделаны в "пропатченном Emscripten"? Критично ли это для конечного результата?

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