EDIT (2): Оскільки є дві відповіді, і я не прийняв жодної з них, я вважав, що мотивую те, що вважаю відповідь тут: або щось, що настійно підказує, що такий підхід був би неможливим / зовсім не корисним або Альтернативно, посилання на дослідження (поле) або приклади хоча б дещо загальної такої системи поза текстовими пригодницькими іграми / інтерактивною художньою літературою.
Хоча я не буду робити вигляд, що я робив більш глибоке розслідування, я помітив, що всі ігрові двигуни / рамки, в які я заглянув, здавалися чимось на зразок прославленого графічного двигуна в тому сенсі, що вони говорять про форми / сутності у двох або тривимірний евклідовий простір з, можливо, певною формою моделі одночасності, "підтягнутою", що дозволяє вказати певну форму логіки, приєднану до цих "сутностей".
Гра "правила" та розповідь потім записуються дещо тимчасово (щодо двигуна) поверх цих примітивів.
Очевидно, що вищеописаний опис є досить спрощеним (візьміть більш спеціалізовані двигуни, такі як двигун нескінченності, який включає деяку форму квесту / наративної системи), і я розумію, що ця модель може працювати досить добре (багато людей, здається, використовували її) .
Мені цікаво, що ж було зроблено спроб створити двигуни / рамки, які б сприймали такі поняття, як (високий рівень) опис правил гри / логіки чи розповіді (або принаймні непросторового аспекту гри). основа?
EDIT (4): Це не означає, що гра не буде включати будь-яких просторових / графічних аспектів, просто, а не просторові сутності, до яких ви пов'язуєте логіку, у вас є поняття сюжету (або геймплея, або "правил настільної гри" ), яким ви потім опишете графічний інтерфейс до / реалізації.
Особливо мене зацікавили б будь-які декларативні підходи, які намагаються захопити якусь (напів) формальну семантику якогось досить великого класу ігор, таким чином, корисним для реальної реалізації (на відміну, наприклад, від рамки виключно для якісний аналіз ігор / розповіді).
Що я бачив - це деякі дослідження моделювання / аналізу оповіді за мережевою моделлю Петрі та цікаві підходи в мовах написання інтерактивної художньої літератури .
EDIT (1): я подумав, що я додаю приклад іграшки для ілюстрації.
Скажіть, нам було цікаво створити пригоди в стилі point & click (думайте, ігри SCUMM). Можна проаналізувати, що вони базуються на понятті більш-менш лінійного та дискретного прогресування від стартової ситуації до кінця.
Орієнтуючись на поняття дискретної прогресії та враховуючи деяку нелінійність, можна вибрати теорію (обмежених) DAGs як основну теорію. Визначаючи гру подібного типу, у своїй (відносно даної теорії) найбільш абстрактній формі таким чином відповідає додавання до цієї теорії додаткових аксіом (або так, що теорія задає конкретний графік, або просто достатня для того, щоб зафіксувати все, що думає, що потрібно для фіксації "сюжет").
Перетворення цієї фактичної гри тепер перетворюється на проблему проектування HCI / інтерфейсу щодо вбудовування цієї теорії у щось відтворюване (тобто побудова моделі теорії / знаходження гомо (ізо?) Морфізму графіків із колекції станів інтерфейсу користувача з переходами в DAG "уточнення гри").
У наведеному вище гіпотетичному сценарії я бачу щонайменше три речі, які мають бути можливими для захоплення в бібліотеках. По-перше, потрібні інструменти для перетворення / міркування про DAG-карти або графіки загалом. По-друге, бібліотека користувальницького інтерфейсу достатньо розумна, щоб допомогти переконатися, що наше представлення нашого графіка як граючої гри насправді моделює графік (таким чином, наприклад, принаймні частково / неофіційно, підтверджуючи, що гра не має застряглих станів через умови обмеженості) . Нарешті, може бути надана колекція бібліотек вищого рівня для визначення графіка; наприклад, бібліотека для вираження символів та їх взаємодії та генерування (частин) графіків у такому вигляді.
Навіщо тримати "середню" теорію DAG, а не просто впроваджувати низький рівень з деякими довідковими бібліотеками? Відповідь - всі звичні причини формальної семантики. Зважаючи на те, що ми визначилися з офіційною основою, ми можемо перевірити певні властивості гри, що дозволяє міркувати про такі речі, як оптимізація в бібліотеці інтерфейсів низького рівня (доки вона моделює DAG, ми можемо робити те, що ми хочемо), не маючи необхідності турбуйтеся про невідповідність опису високого рівня (символів / діалогу тощо), оскільки ці описи повинні самі описувати такі структури.
Я жодним чином не натякаю, що зазначений вище підхід конкретно спрацював би, і ідея полягає не в тому, що DAG повинен бути тим, що насправді зберігається в пам'яті (скоріше він формує щось подібне до обчислювального формалізму, наприклад, лямбда-числення), але сподіваюся, що це ілюструє той підхід, який мені цікавий.
Коротше кажучи, я думаю, альтернативним заголовком цього питання могло бути: Як Dijkstra написав комп’ютерні ігри?