> http://obsd.gk11.ru/games
А симпатично.

Ну я наоборот уже устал от поддержки ресурсов. Если найдется человек, который сделает "портал инстед", я буду только рад.
Я тогда просто еще сокращу http://instead.syscall.ru и буду сосредоточен только на движке и играх. :)

Класс объектов

Конструкторы объектов широко использовались в STEAD2. В STEAD3 obj/dlg/room реализованы как классы объектов. Класс объектов удобно создавать для тех случаев, когда поведение создаваемого объекта не укладывается в стандартные объекты obj/room/dlg и вы хотите поменять методы класса. Изменив метод класса, например, вы можете вообще изменить то, как выглядит предмет в сцене. В качестве примера, рассмотрим создание класса "контейнер". Контейнер может хранить в себе другие объекты, быть закрытым и открытым.

-- create own class container
cont = std.class({ -- создаем класс cont
    display = function(s) -- переопределяем метод показа предмета
	local d = std.obj.display(s)
	if s:closed() or #s.obj == 0 then
	    return d
	end
	local c = s.cont or 'Внутри: ' -- описатель содержимого
	local empty = true
	for i = 1, #s.obj do
	    local o = s.obj[i]
	    if o:visible() then
		empty = false
		if i > 1 then c = c .. ', ' end
		c = c..'{'..std.nameof(o)..'|'..std.dispof(o)..'}'
	    end
	end
	if empty then
	    return d
	end
	c = c .. '.'
	return std.par(std.space_delim, d, c)
    end;
}, std.obj) -- мы наследуемся от стандартного объекта

После этого, вы можете создавать контейнеры так:

cont {
    nam = 'ящик';
    dsc = [[Тут есть {ящик}.]];
    cont = 'В ящике: ';
}: with {
    'яблоко', 'груша';
}

Когда контейнер будет открыт, вы увидите описание ящика, а также содержимое ящика в виде строки ссылок: В ящике: яблоко, груша. dsc объектов яблоко и груша будут скрыты.

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

Решил наполнять FAQ пока здесь --- в клубе. Под топиком: ## FAQ ##.

Частый вопрос, это -- как делать переводы строк в конце dsc/decor и прочих методов?
В STEAD3 все начальные и конечные переводы строк (^) -- режутся принудительно. Так как в 99% случаях, наличие дополнительных ^ это ошибка. Например, pn() в конце обработчика. Если вам действительно нужно контролировать вывод настолько глубоко, вы можете:

1) Написать в init() функции std.strip_call = false и тем самым отключить механизм вырезания лишних ^.
2) Использовать подстановки $, например, таким образом:

obj {
   nam = '$',
   act = function(s, w)
      return w
   end,
}

obj {
    nam = 'a';
    dsc = '- 1{$|^}';
}

obj {
    nam = 'b';
    dsc = '- 2{$|^}';
}

obj {
    nam = 'c';
    dsc = '- 3{$|^}';
}

room {
   nam = 'main';
   obj = { 'a', 'b', 'c' };
}

Ссылка на постоянно растущий FAQ будет здесь: http://club.syscall.ru/_faq
Я буду добавлять в него интересные сообщения.

Из документации:

Основное отличие атрибутов от обработчиков событий состоит в том, что обработчики событий могут менять состояние игрового мира, а атрибуты нет. Поэтому, если вы оформляете атрибут (например, 'dsc') в виде функции, помните, что задача атрибута это возврат значения, а не изменение состояния игры! Дело в том, что движок обращается к атрибутам в те моменты времени, которые обычно четко не определены, и не связаны явно с какими-то игровыми процессами!

Если при входе в комнату нужно выполнить какой-то код, оформи его в виде enter или onenter обработчика.

room {
    onenter = function()
        A = 10
    end;
    dsc = ....
}

В документации эти обработчики описаны тут: https://github.com/instead-hub/instead/blob/master/doc/stead3.md#Переходы-между-сценами

Начал писать здесь: https://github.com/gl00my/stead3/blob/master/doc/modules3.md
Можно следить за тем, как она наполняется и задавать вопросы. :)

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

А так, смотри сам. При вставке кода используй 4 символа =, примерно так:

l = std.par(std.scene_delim, reaction or false, av or false, l or false, pv or false) or ’’
заменить на:
l = std.par(std.scene_delim,  l or false, av or false, reaction or false, pv or false) or ’’

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

Подумай вот о чем.
Мы берем яблоко.
Яблоко пропадает со сцены.
Описание сцены -- ситуация.
В твоем варианте, мы прочитаем сначала описание новой ситуации (без яблока), а только потом, узнаем что мы взяли яблоко.

Типа:

На столе больше нет яблока.
Вы взяли яблоко.

Разве это не настораживает? ;)

Еще пример. Допустим, есть волк. С методом life. Он убивает гг. При этом идет переход на сцену конец игры.

И вот мы видим:

Конец игры.
Волк бросается на вас.

Вместо: Волк бросается на вас.
Конец игры.

Таких примеров можно еще привести. Вот попытался пояснить мысль. :)

Ну и для полноты картины. При входе в комнату вызывается событие onenter. Пусть в нем будет что то вроде: мы вошли в зал.

В твоем варианте будет:

Вы оказались в большом зале!
Вы вошли в зал.

Ты все еще думаешь, что смена display хорошая идея? :)

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

То есть, логика стандартного поведения:
Что ты сделал -> что получилось

Если нужна другая логика, надо ее сначала продумать. Просто смена вывода не поможет. Нужна концепция. В самом твоем вопросе есть подмена. Реакция не добавляется. Каждый новый экран -- это абсолютно новый такт времени.

В качестве компромиссного решения можно назвать такое.
dsc
Реакция
decor/объекты

Такое поведение было в stead2. Оно имеет противоречия, но если условиться что dsc не меняется, можно его сделать. Если это нужно, могу помочь. Надо look вызов в display разбить на два.

Конечно можно. Если я правильно понял вопрос.
Ты можешь класть/убирать любые объекты из/в любые другие объекты/комнаты просто кодом.
Если нужно это, то смотри "Другие функции стандартной библиотеки" и там тебе: place() например.
Ну или на примере кода задай вопрос, чтоб конкретней ответить.
Еще можно явно манипулировать списками obj и way: описано в "Атрибуты-списки". Например objs "лес":zap() -- убил все объекты

Ну а делать это можно, например, в onenter/enter/exit/onexit.
Код игры на stead3 -- это проводник и инстедоз 5. Можешь для примера изучать эти игры.

Проще, все таки в инстед стиле:

obj {
    nam = 'домик';
    burned = false;
    dsc = function(s)
         if s.burned then
             p [[Вы видите, как дымится {дом}.]]
             return
         end
         p [[Вы видите уютный {домик}.]]
    end
}

Ну и все. Теперь в комнате:

room {
    nam = 'Поляна';
    obj = { 'домик' };
}

По-моему, так проще.

> Аааа. Прошу прощеня, забыл очевидную вещь)))) если убрать return, но отобразятся сразу оба состояния. А return вернет нас просто в room, где об'ект фигурирует.
Дело в том, что есть такое понятие как метод,
Вот dsc - это метод. Когда движку нужно описание, он вызывает метод dsc у всех объектов комнаты. return тут это не возврат в комнату, а выход из функции. Например (это не инстед, просто lua):

function test()
   return 10
end
print(test()) -- выведет 10

function test2()
   return
end
print() -- выведет пустоту

А в инстеде p -- это просто накопление текста, например:

p "hello"

это то же самое, что return "hello"

Или так:

p "hello"
p "world"

то же самое, что и return "hello world"

Теперь про пример:

if s.burned then
   p "сгорел"
end
p "не сгорел"

будет "сгорел не сгорел"

а так:

if s.burned then
   p "сгорел"
   return  -- мы вышли из функции
end
p "не сгорел"

только одно состояние

Еще вариант:

if s.burned then
   p "сгорел"
else
   p "не сгорел"
end

Надеюсь, помог.

Вот законченный пример (main3.lua). Он работает. :) Просто скопируй все в main3.lua и запусти. Если есть вопросы, оформляй в виде примеров - я исправлю.

xact.walkout = walkout -- сделали свою xact функцию walkout

room {
	nam = 'main';
        dsc = [[Я тут стою.]];
	way = { 'pribor' };
}

room {
	nam = 'pribor';
	dsc = '10:20';
	decor = [[{@ walkout|назад}]];
}

Я могу назвать только свои любимые игры. Но они совсем разные и по механике, и по сюжету.
Я вообще, не могу сказать что мне так уж важна форма. Но я не люблю обычно COYA игры. А так, вот список игр, которые я так или иначе помню.

- Лифтер 1 и 2;
- Лидия, Переход;
- Материк (добротно сделано, но сюжет не пошел. игра в steam);
- Инстедоз 3;
- Инстедоз 5;
- Кайлет;
- Славный город Лудд (но очень маленькая);
- Зараженные (как пример просто добротной игры, хотя сюжет не особо близкий);
- Неизбежные вещи (как пример интересной находки в геймплее);
- Новогодняя сказка (не знаю почему, но нравится!, хоть короткая);

> Пытаюсь не выходить из границ целей создания движка Instead (я читал манифест), с другой стороны мне важно как это будет выглядеть для игрока, ну и себе границы задать.

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

1) если ты вышел за рамки документации -- ты уже НЕ новичок. Начиная с этого момента: no warranty, no support.

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

3) очень часто, люди ломают не потому, что переросли ограничения -- а просто не разобрались с текущим положением вещей. Грубо говоря, в 90% случаях человек делает COYA просто потому, что он ничего больше не видел (не хочет видеть) и потенциал инстеда оказывается невостребованным.

А так, полно примеров. когда люди экспериментировали, и получилось интересно.
МП, прокси-меню, спрайты и так далее - все это результат экспериментов.

Короче мой совет, напиши сначала несложную игру, освойся с инструментом. Почувствуй его. Потом все будет. ;)

Ой рвет. И мозг и душу. :)

> Собственно, да... пора уже переходить к фазе разработки несложной, но законченой игры. Первой игры на Instead.
Удачи! Будем ждать. :)

Но судя по названию темы, ты же этого и хочешь? :)

> То есть вопрос, как вписать в функцию отсылку к ТЕКУЩЕЙ комнате, название которое тоже есть функция?
Если в place() 2й параметр не указан, то это будет текущая комната.
Но если нужна отсылка к этой текущей комнате еще для чегото, есть функция here() -- это и есть указатель на текущую комнату.

Далее, тут не понятно:

used = function(s)
    if s^'выложить' then
    place (s, ???????????);
    remove(s);
end; 

Скорее всего ты хотел написать:

used = function(s, w) -- s -- это и будет кувалда, нас интересует w а не s
    if w^'выложить' then
        place (s); -- в текущую комнату
        remove(s);
    end
end; 

Еще настоятельно рекомендую использовать отступы! Понятней код и самому проще и другим. :)

Да еще. remove(s) тоже не нужен. place сам убирает объект из прошлого место-положения. Это put не удаляет, а place -- перемещает как бы объект в новое место.
Так что в твоем случае и remove не нужен (но я бы еще воткнул признак отсутствия реакции):

used = function(s, w) -- s -- это и будет кувалда, нас интересует w а не s
    if w^'выложить' then
        place (s); -- в текущую комнату
    else
        return false -- даем знать stead3, что ничего не сделали, тогда вызовется game.use
    end 
end

> А почему не используешь drop()?
В принципе, drop() в stead3 практически совпадает с place ;) drop создан для наглядности кода главным образом. А так да -- самое место ему тут быть используемым. :)

Справедливости ради, не только твой текст рвет мои части тела. Игры Ореолека тоже остаются мной не понятыми. Поиграй в Инженера. Может у вас единомыслие ? :)

Это знак обновить опенбзд порт! :)

Полный рестарт игры можно сделать: instead.restart(true)

Также можно только состояние мира заресетить. std:reset() -- но эту функцию нужно использовать с осторожностью. Проще instead.restart()

Читаю это и в ужасе.
И эти люди (Рома!) говорят что пройти квантового кота сложно?
Народ, а нет ли НАОБОРОТ очень простых рогаликов, где нет вот этого всего рпгшного, но упор на квесты, разговоры итд,
Кстати, на пальме играл в CalcRogue - нравился!
На телефоне - zaga -33 -- тоже.
Что еще есть из примитива? А то не выдержу и на инстеде напишу. =)

Возможно, твой конек -- это цикл выносящих мозг наноквестов как Хармс писал: https://ru.m.wikiquote.org/wiki/Случаи_(Хармс)

:)

> Может шпаргалку повесить?
А как ты сюда пишешь? У меня прямо под кнопкой отправить целый раздел ПОМОЩЬ.

Ну и снова не правильно.

Так как часто возникают вопросы, а что такое собственно 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/

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

У хармса -- на знаю. Не сойти сума -- уже прошел. :) Твои ненаписанные -- наверное просто. Ты же сложных не любишь.

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

Ладно -- я офф. Надо собираться.

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

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

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

> Пишу ответить (символ повернутой стрелочки) или новое сообщение.
Вот проскроллируй вниз до самого конца. На странице, где пишешь текст. Там подсказка.

> Я тоже, кажется, три раза пытался его пройти и всегда где-то застревал. Так что, по-моему сложно)
Про сложность, вспомнился monkey island (не помню часть), там где курицу на веревку. :) По несколько дней сидели над одной загадкой. :)
Или гоблины 1-е... Или учет веса предметов в старых квестах... Не знаю, сейчас просто жанр выродился, к сожалению. Поэтому непривычно. Кот, все-таки, относительно других игр -- не очень сложен. Средний, скорее...

Про FTL слышал, но попробую наверное сначала нетхак снова или ангабанд на планшете....

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

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

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

Обновил демку модуля finger. Находится демка тут:
https://github.com/gl00my/stead3/tree/master/tests/fingers

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

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

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

> А как добавлять way на сцену?
В way может быть сама комната, и в этом случае можно просто добавить саму эту комнату:

ways():add 'локация'

Но есть и другие способы. Во первых, вместо добавления-удаления, можно делать open/close или disable/enable локации:

room {
    nam = 'дом';
...
}:close() -- закрытый дом

room {
    nam = 'main'
    way = { 'дом' }; -- переход невидим
}
где то в коде:

open 'дом' -- открыли дом -- появился переход

И, наконец, можно использовать path:

way = { path { nam = '#дом', 'В дом', 'дом'}:disable() };  -- выключенный переход

enable 'вдом' -- включили переход.

Можно еще создавать path на лету new и добавлять их... Но это лишнее...

Насчет переменных, не совсем понял вопрос, но вот варианты:

a = path('Выход', 'exit')

И вставляем везде где хотим:

way = { a };

Еще вариант:

exitroom = room {
    nam = 'exit';
....
}

И вставляем где хотим:

way = { exitroom };

В твоем примере с rtt, просто везде в момент загрузки игры в way вставится слово 'локация5', если это то, что тебе нужно - можно и так. Но изменение переменной rtt ничего не изменит в уже созданных комнатах.

Реальность представляется ему под узким углом: он видит лишь изолированные части мира, будь то следствия без причин или причины без следствий. И потому искусство абсурда, которое всегда является реальным искусством, будет всё более и более склоняться к повествовательному нулю и сводиться к описанию реальности по частям, каждая из которых представляет собой начало истории, продолжение которой находится уже вне нашего поля зрения. <…>

Вот цитата характерная, кстати!

> https://en.wikipedia.org/wiki/SunDog:_Frozen_Legacy
Ух ты, интересно. Никтогда не слышал про такое, только starflight как предшественника старконтрола :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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