Esistono motori / strutture narrative (o almeno non spaziali)? [chiuso]

EDIT (2): Dal momento che ci sono due risposte e non ne ho accettate nessuna, ho pensato di motivare ciò che considererei una risposta qui: O qualcosa che suggerisce fortemente che un tale approccio sarebbe impossibile / per niente utile o , in alternativa, un riferimento a una ricerca (campo) o esempi di un sistema almeno in qualche modo generale al di là dei giochi di avventura testuale / narrativa interattiva.

Anche se non pretendo di aver fatto un'indagine più approfondita, ho notato che tutti i motori / framework di gioco che ho esaminato sembravano qualcosa di simile a un motore grafico glorificato, nel senso che parlano di forme / entità in due o spazio euclideo tridimensionale con, possibilmente, una qualche forma di modello di concorrenza "nascosto" che consente di specificare una qualche forma di logica collegata a queste "entità".

Le "regole" e la narrativa del gioco vengono quindi scritte in modo un po 'ad hoc (rispetto al motore) in cima a queste primitive.

Ovviamente la descrizione sopra è piuttosto semplificata (prendi motori più specializzati come il motore a infinito che include una qualche forma di sistema di ricerca / narrativa), e mi rendo conto che questo modello può funzionare abbastanza bene (molte persone sembrano averlo usato) .

Mi chiedo, tuttavia, quali tentativi sono stati fatti per creare motori / framework che prendono nozioni come la descrizione (di alto livello) delle regole di gioco / logica o narrativa (o almeno un aspetto non spaziale del gioco) come il loro principale base?

EDIT (4): Questo non significa che il gioco non includerebbe alcun aspetto spaziale / grafico, ma solo che anziché avere entità spaziali a cui associ la logica, hai una nozione di trama (o gameplay o "regole del gioco da tavolo" ) di cui descrivi quindi un'interfaccia grafica a / realizzazione di.

In particolare sarei interessato a qualsiasi approccio dichiarativo che tenti di catturare una sorta di semantica (semi) formale di una classe di giochi ragionevolmente ampia, in un modo utile per l'implementazione effettiva (al contrario, ad esempio, di un framework esclusivamente per analisi qualitativa di giochi / narrativa).

Quello che ho visto sono alcune ricerche sulla modellazione / analisi della narrativa con un modello basato su rete di Petri e alcuni approcci interessanti in lingue per la scrittura di narrativa interattiva .

EDIT (1): Ho pensato di aggiungere un esempio giocattolo per illustrare.

Supponiamo che fossimo interessati a creare avventure in stile punta e clicca (pensa ai giochi SCUMM). Si potrebbero analizzare questi come basati su una nozione di progressione più o meno lineare e discreta da una situazione iniziale a una fine.

Concentrandosi sulla nozione di progressione discreta e tenendo conto di una certa non linearità, si potrebbe scegliere la teoria dei DAG (limitati) come una teoria di base. Specificare un gioco di questo tipo, nella sua forma (relativamente a questa teoria) più astratta corrisponde quindi all'aggiunta di ulteriori assiomi a questa teoria (sia in modo che la teoria specifichi un grafico specifico o semplicemente abbastanza per catturare tutto ciò che si pensa sia necessario per catturare quelli "tracciare").

Trasformare questo in un gioco reale ora si trasforma nel problema di progettazione HCI / Interface di incorporare questa teoria in qualcosa di giocabile (ovvero costruire un modello della teoria / trovare un morfismo homo (iso?) Di grafici dalla raccolta di stati dell'interfaccia utente con transizioni nel DAG "specificando il gioco").

Nello scenario ipotetico sopra riportato vedo almeno tre cose che dovrebbero essere possibili da acquisire nelle librerie. Innanzitutto sono necessari strumenti per trasformare / ragionare su DAG o grafici in generale. In secondo luogo una libreria di interfaccia utente abbastanza intelligente da aiutare a verificare che la nostra rappresentazione del nostro grafico come gioco giocabile modella effettivamente il grafico (quindi, ad esempio, almeno parzialmente / informalmente, dimostrando che il gioco non ha stati bloccati, a causa della condizione di limitatezza) . Infine, potrebbe essere fornita una raccolta di librerie di livello superiore per specificare il grafico; come una libreria per esprimere i personaggi e la loro interazione e generare (parti di) grafici in termini di questo.

Perché mantenere la teoria "intermedia" dei DAG, anziché limitarsi all'implementazione di basso livello con alcune librerie di aiuto in cima? La risposta è tutte le solite ragioni per una semantica formale. Dato che abbiamo deciso su una base formale, possiamo verificare alcune proprietà del gioco permettendoci di ragionare su cose come l'ottimizzazione nella libreria di interfaccia di basso livello (fintanto che modella il DAG possiamo fare ciò che vogliamo), senza dover preoccuparsi dell'incomparabilità con la descrizione di alto livello (di personaggi / dialoghi ecc.), poiché tali descrizioni devono esse stesse descrivere tali strutture.

Non intendo in alcun modo che l'approccio di cui sopra in particolare funzionerebbe, e l'idea non è che un DAG debba essere ciò che viene effettivamente tenuto in memoria (piuttosto forma qualcosa di simile a un formalismo computazionale come un calcolo lambda), ma spero che questo illustri il tipo di approccio di cui sono curioso.

In breve, immagino che un titolo alternativo a questa domanda potesse essere: come avrebbe fatto Dijkstra a scrivere giochi per computer?

Una breve nota sulla narrativa e le regole del gioco: nella narrativa interattiva si può sostenere che il gioco è quello di attraversare un grafico della narrativa ramificata, ma alla fine la narrazione vive al di fuori della meccanica del gioco - potresti sostituire tutte le parole con qualcosa di illeggibile e tuttavia i passaggi per completare il gioco (o perderlo durante il gioco) sarebbero esattamente gli stessi. Questo a sua volta implica che la narrazione è irrilevante per il gameplay, tranne nel caso in cui uno sviluppatore scelga di cambiarne uno per adattarsi all'altro. Nei giochi, la narrazione è essenzialmente una facciata sulla meccanica che può rendere la meccanica più avvincente per un giocatore a cui piace quella narrativa, ma questo è tutto. Ci sono alcuni giochi (anche se alcuni non li chiamano giochi) in cui la narrazione è la forma principale di intrattenimento e le meccaniche di gioco sono per lo più superficiali,Caro Esther , ma gli sviluppatori non hanno bisogno di un metodo formale per raccontare storie più di quanto non facciano gli scrittori di narrativa, quindi non prenderò in considerazione ulteriormente la narrativa. In generale, qualsiasi gioco che assomiglia a "narrativa giocabile" è un albero o un grafico di eventi di gioco che possono esistere e essere discussi in modo significativo senza la narrazione.

Ho notato che tutti i motori / framework di gioco che ho esaminato sembravano qualcosa di simile a un motore grafico glorificato, nel senso che parlano di forme / entità in uno spazio euclideo bidimensionale [...]

Sì, la maggior parte dei "motori di gioco" sono ovviamente "motori di videogiochi" e la loro principale responsabilità nel tempo è stata quella di facilitare il lato dell'ingegneria del software di un videogioco, non quello del gioco. Probabilmente questo ha senso perché è l'ingegneria del software che è l'aspetto più nuovo, più costoso e quindi più rischioso. In confronto, il design del gioco in senso astratto è stato fatto a mano per migliaia di anni senza l'ausilio di strumenti, il che può spiegare in qualche modo perché ciò continui ad essere il caso.

quali tentativi sono stati fatti per creare motori / framework che considerino come base primaria una descrizione (di alto livello) delle regole / logica o narrativa del gioco (o almeno un aspetto non spaziale del gioco)?

Ci sono stati alcuni tentativi seri, nessuno riuscito, per quanto ne so.

Storytron è uno. "A differenza della narrativa interattiva tradizionale, uno Storyworld è più interessato a modellare le azioni e le reazioni degli attori e le loro emozioni e inclinazioni piuttosto che la geografia del mondo di gioco o gli oggetti banali che lo popolano." Segue uno sforzo precedente chiamato Erasmatron, che non è riuscito davvero, e Storytron non sembra nemmeno riuscire. Il seguente articolo è una buona lettura su questo: Chasing the Dragon

A un livello meno ambizioso, ci sono molte persone che hanno escogitato modi semplici per rappresentare giochi semplici. Uno dei tanti è questo: Multigioco: un linguaggio di altissimo livello per la descrizione dei giochi da tavolo (il link è dietro un login, ma potresti essere in grado di cercarlo) ma tutto ciò che hai alla fine è un set leggibile da computer di possibili stati, transizioni di stato e condizioni di vittoria o funzioni di mantenimento del punteggio - va bene per giochi da tavolo discreti come gli scacchi o giochi di carte come il poker, ma non si generalizzano ai giochi con grandi quantità di stato continuo o quelli con semantica che sono più come simulazioni (es. giochi sparatutto) o sport (es. giochi di corse). Tali giochi non possono essere adeguatamente rappresentati attraverso un semplice albero di stati di gioco.

Un modo per avvicinarsi alla comprensione di questi sistemi più complessi è cercare di classificare ogni meccanico esistente in una delle diverse forme di base, e quindi capire come combinare le forme di base per formare un gameplay più complesso, partendo dal presupposto che tutto il gameplay può essere composto da queste unità fondamentali o loro combinazioni. Dan Cook ha un articolo intitolato " What Are Game Mechanics ?" e un seguito " The Chemistry of Game Design"che tentano di documentare questo approccio compositivo alla progettazione del gioco. In teoria potrebbe essere possibile costruire un sistema dichiarativo in aggiunta a ciò, ma in pratica la meccanica costituisce solo una piccola parte del gioco e quindi l'output risultante sarebbe presumibilmente limitato all'interno di un framework di presentazione che non sarebbe abbastanza flessibile da catturare l'attenzione della maggior parte dei giocatori.

Altri tentativi di formalizzare i concetti di progettazione del gioco sono spesso chiamati "grammatica del gioco" - uno di questi articoli è chiamato " Atomi di gioco multiplayer ", ma fa riferimento a vari lavori precedenti.

Supponiamo che fossimo interessati a creare avventure in stile punta e clicca (pensa ai giochi SCUMM). [...] si potrebbe scegliere la teoria dei DAG (limitati) come una teoria di base. [...] Innanzitutto sono necessari strumenti per trasformare / ragionare su DAG o grafici in generale. In secondo luogo una libreria di interfaccia utente abbastanza intelligente da aiutare a verificare che la nostra rappresentazione del nostro grafico come gioco giocabile modella effettivamente il grafico (quindi, ad esempio, almeno parzialmente / informalmente, dimostrando che il gioco non ha stati bloccati, a causa della condizione di limitatezza) . Infine, potrebbe essere fornita una raccolta di librerie di livello superiore per specificare il grafico; come una libreria per esprimere i personaggi e la loro interazione e generare (parti di) grafici in termini di questo.

Il problema qui è che il computer non aggiunge molto al processo. I progettisti di giochi come questo spesso elaboreranno esattamente questo, un grafico in forma digitale o fisica, che mostra il flusso attraverso il gioco. È banale vedere se il gioco può teoricamente essere completato o meno. Anche codificare le varie regole per avanzare in un'avventura punta e clicca è banale. La parte difficile è far sì che segua una narrazione interessante, inserendola in un mondo dall'aspetto avvincente, creando l'arte e le risorse sonore per ritrarre correttamente il gioco e l'interfaccia e le varie attività di ingegneria del software che lo tengono insieme. Il grafico diretto degli stati significativi attraverso il gioco è di solito relativamente banale; è tutto ciò che lo circonda che è il problema. Ed è per questo che non c'è molto interesse in ciò,

Personalmente sto attualmente lavorando con un team su un prodotto chiamato Storybricksche tenta di consentire la costruzione di un gameplay interessante specificando varie regole, e queste regole possono indicare lo stato iniziale di una persona, i suoi bisogni e così via. È facile prendere queste regole e verificare se le esigenze di una persona possono essere soddisfatte e, in tal caso, come, e quindi creare attività dichiarative che devono essere completate nel gioco. Tuttavia, questo di per sé non crea intrinsecamente un gameplay interessante, perché una volta astratte le cose fino al livello di "X ha bisogno di Y - prendilo per loro" i giocatori iniziano a individuare il modello e cessano di goderselo. (Ad esempio: le persone si sono stancate rapidamente delle missioni generate automaticamente in Skyrim, perché potevano vedere che non vi era alcun significato intrinseco in una missione generata proceduralmente, rispetto a quelle create dai progettisti. ) Quindi il nostro compito sarà utilizzare i metodi di intelligenza artificiale per rendere queste situazioni più interessanti, ed è qualcosa su cui stiamo ancora lavorando. (Storybricks è ancora in una fase alfa molto precoce). Ma la nostra ricerca indica che poche persone stanno tentando qualcosa di simile e che è un problema molto difficile.

Un altro problema con l'approccio dichiarativo è che non è molto utilizzabile. Agli scienziati piace perché è facile da elaborare, ad esempio per dimostrare che una situazione è risolvibile o che un insieme di regole logiche è coerente. Ma nel mondo reale, né i programmatori di giochi per computer né gli utenti finali sono generalmente a proprio agio con una rappresentazione dichiarativa che si concentra sui risultati come lo sono con una rappresentazione imperativa che dice loro come agire affinché i risultati accadano. Gli attuali 10 principali linguaggi di programmazione sono tutti imperativi e le istruzioni del mondo reale sono anche generalmente in forma imperativa, sia che si tratti di come preparare una torta che di come costruire mobili. Questa mancanza di entusiasmo da entrambe le estremità dello spettro significa che non vi è alcun incentivo commerciale a produrre specifiche formali per i giochi moderni, e questo sembra improbabile che cambi nel prossimo futuro.

Ho pensato a come rispondere per un po 'e non sono sicuro di come metterlo.

È una buona domanda Sfortunatamente il tipo di risposta si riduce al fatto che o non ha senso programmare nulla per non parlare di un motore di gioco in questo modo, o che è già così che vanno le cose.

Sembra esserci questa enfasi sulla grafica, perché deve esserci un modo per definire l'esistenza fisica degli oggetti. Questo è un po 'il punto in cui le cose iniziano a diventare esistenziali perché quello di cui stiamo veramente parlando è una rappresentazione della dimensione, ma per ora ignoriamo questo. Il punto principale è che questo è qualcosa che è davvero abbastanza coinvolto. Consentire la rappresentazione dello spazio sarà qualcosa che intrinsecamente occupa molto della programmazione di un motore di gioco. E se i designer vogliono realizzare delle belle scene, avranno bisogno di molto controllo su come vengono posizionate le cose. Quindi vedrai molte cose sulla grafica.

Quindi, questo è il lato di basso livello delle cose. Qualcuno deve riflettere molto profondamente su tutti questi piccoli problemi tecnici.

Per quanto riguarda le regole narrative e di gioco? Questo è al di fuori di ciò che un motore di gioco dovrebbe fare. Questa è la parte in cui entra in gioco il gruppo di sviluppo.

Inoltre, non è che si sia pensato molto a come rappresentare le idee attraverso la programmazione. Questo è davvero quello che la storia della scienza informatica è . Ed è per questo che i motori di gioco hanno spesso interfacce per linguaggi di alto livello. È più facile rappresentare i pensieri attraverso di loro.

Quindi, tenuto conto di ciò, si potrebbe creare un linguaggio specifico per i giochi con un'enfasi narrativa? Direi che probabilmente no. Anche in questo caso tutto si riduce alla rappresentazione. La lingua deve essere in grado di descrivere i dettagli in modo tale che il computer sappia cosa farne. Se lo scopo è quello di creare un linguaggio specifico per la creazione del gioco, qualsiasi decisione progettuale dovrebbe essere centrata su quello.

E ancora, ci sono molte scelte di lingue così come sono. E più persone rispetto a quelle del settore dei giochi li hanno sviluppati. In genere ha senso usare uno di quelli.

In sintesi, hai posto una domanda interessante, ma molto difficile. E non sono del tutto sicuro di cosa sia, o se ho effettivamente risposto.

* modifica: col senno di poi, mi rendo conto che stavo prendendo in considerazione solo i motori di gioco 3D, come se fossero i soli che esistono. Alcuni giochi non hanno affatto una persona che agisce in uno spazio fisico. Anche se in questi casi non sono sicuro che un motore di gioco possa contribuire molto.

All'inizio della storia dell'informatica per hobby (ovvero gli anni '80) c'erano alcuni kit di sviluppo commerciale disponibili per giochi basati sia su testo che su sprite. Quelli basati su sprite erano molto simili agli attuali "motori grafici".

L'altro tipo includeva cose come i parser di linguaggio naturale. Questo tipo sembra sopravvivere nei moderni "editor di livelli". La maggior parte di questi sembra includere il supporto per qualcosa come Lua o lo scripting Python. Vorrei anche notare che non vedo molta attività nell'editing di livello open source, ma ciò è dovuto al fatto che queste cose sono solitamente strettamente legate alle specifiche del gioco in questione. Sto pensando a qualcosa come i set di costruzione Elder Scrolls.

Kinect può riportare il parser. Come fan del vecchio gioco di avventura basato su testo, sono entusiasta della direzione di Bethesda anche qui. Sicuramente è proprietario, ma forse qualche giovane genio ...