Come sono modellate le missioni di gioco (ad esempio Oblivion)?

Question

Ho appena iniziato a suonare Elder Scrolls IV: Oblivion alcuni giorni fa, e una cosa che non posso fare a meno di chiedermi è come viene gestito il sistema di ricerca in modo programmatico?

In particolare, ci sono molte dozzine (centinaia?) Di missioni e anche missioni secondarie nel gioco, che si riflettono nell'ambiente del gioco in molti modi: dagli eventi programmati che accadono nel gioco in momenti specifici/posti tra persone specifiche (supponendo che siano ancora vivi), a oggetti di quest correlati (alcuni dei quali sono associati a particolari NPC e stati della missione), a vari dialoghi con diversi NPC (di nuovo, con un albero complesso che può essere modificato da dialogo con altri NPC & stato generale della ricerca).

Inoltre, è possibile scambiare le missioni attive/inattive in qualsiasi punto, in modo che questi complessi comportamenti dinamici che influenzano radicalmente l'ambiente circostante siano un ulteriore passo avanti essendo completamente intercambiabili.

Sembra un incubo logico, e sto attraversando un periodo difficile per capire come qualcosa di così profondo e ricco possa essere definito a livello di codice, così apparentemente in modo impeccabile.

C'è qualcuno con esperienza in questo genere di cose che può spiegare (in senso lato) cosa succede in questo tipo di sistemi?

Answer 1

Sto solo indovinando qui. Non ho fatto questo tipo di programmazione, ma ho pensato molto a come lo stavano facendo mentre giocavano RuneScape.

Probabilmente ci sono un sacco di flag e variabili associate al tuo account, e mentre avanzi in una missione, i loro valori cambiano. All'inizio, il carattere X è contrassegnato come vivo e in Posizione Y. Successivamente, viene contrassegnato come nella Posizione Z. Quindi, è morta. Quindi, quando entri in Location Y, controlla la variabile per vedere se è lì e mette lì il suo oggetto, oppure no. Nel frattempo, un altro giocatore che non ha iniziato la missione può trovarsi nella stessa area e vedere qualcos'altro interamente.

Answer 2

Non sono un designer di gioco, ma posso vedere qualcosa che può essere al lavoro qui ...

Object Oriented Programming permette per questo tipo di complessità e dinamicità incapsulando i dati e la logica ordinatamente all'interno di molti oggetti. Questi oggetti possono interagire "verbalmente", usando la messaggistica tra oggetti per delegare le attività l'una all'altra. Il mittente del messaggio non deve sapere come il ricevente interpreterà il messaggio, lasciando il metodo di azione interamente al destinatario. Proprio come nel mondo reale, la delega consente alle cose di funzionare più agevolmente.

Ad esempio, quando ordinate un risotto ai funghi da Del Posto a New York City, ordinate tornando in cucina e parlando direttamente con lo chef? Ti metti un grembiule e prepari da solo il risotto? Guidi verso la fattoria dei funghi più vicina e scegli i tuoi funghi? No, non lo fai. È sufficiente delegare queste attività al cameriere, al team di chef e al fornitore di prodotti, rispettivamente. Per ottenere il risotto ai funghi, tutto quello che devi fare è dire al cameriere che lo vuoi. Il resto viene fatto automaticamente, attraverso una catena di delega. Questo stesso tipo di delega probabilmente esiste nel tuo gioco.

Ora, torniamo agli oggetti. Alcuni oggetti ereditano dati e logica da oggetti padre e, in questo modo, possono avere una grande quantità di dati/logiche in comune; chiamiamoli fratelli e sorelle Nell'esempio della ricerca di gioco, ogni missione è probabilmente il suo 'oggetto di ricerca', con dati di base e logica ereditata dal genitore di ricerca genitore. I fratelli di quest possono essere differenziati tra loro attaccando dati/logie extra che riguardano le specifiche missioni.

In base alle tue azioni nel gioco (e alle tue selezioni nel menu del gioco, forse), l'oggetto del gioco può scambiare un oggetto di ricerca attivo per uno dei suoi fratelli. Spesso, questo può essere fatto con un comando molto semplice (in pseudo-codice, non è modellato su un particolare linguaggio di programmazione):

gameObject.activeQuest -> getCurrentObject(); 
//returns the object containing all of the data/logic of the current active quest: 
Gibbons_GoldenArtifacts 
//Let's say the quest description is "Scour the Catacombs of Gibbon for a 
mysterious treasure" 

gameObject.activeQuest -> setCurrentObject(Gibbon_DefeatGhost) 
//sets the activeQuest object (note that QUEST OBJECT contains baseline data/logic) 
//assuming, say, Gibbon_DefeatGhost is an object like so: 

Gibbon_DefeatGhost={QUEST OBJECT}; 
Gibbon_DefeatGhost.extend(
    description="Defeat Gibbon's ghost to retrieve his golden artifacts"; 
    objective="Defeat Gibbon's ghost"; 
    questNPC="Gibbon's ghost"; 
    questLocation="Gibbon's Inner Sanctum" 
    questTriggers[1]="When PLAYER enters Gibbon's Inner Sanction: Release Gibbon's ghost"; 
    questTriggers[2]="When Gibbon is slain: Drop Gibbon's golden artifacts" 
) 

Da quel momento in poi, l'oggetto gioco stesso sarà probabilmente interagire con la ricerca attiva obiettare come sempre, ma l'oggetto di ricerca attivo può percepire quelle interazioni in modi diversi dai modi di oggetti di quest fratelli, dando come risultato un'esperienza di gioco diversa.

Spero di non essere del tutto fudging il clown su questo ...

Answer 3

A finite-state machine (FSM) or finite-state automaton (plural: automata), or simply a state machine, is a behavioral model used to design computer programs. It is composed of a finite number of states associated to transitions. A transition is a set of actions that starts from one state and ends in another (or the same) state. A transition is started by a trigger, and a trigger can be an event or a condition.