Requisiti di progettazione principali

*Questo contenuto è tradotto usando AI (Beta) e potrebbe contenere errori. Per visualizzare questa pagina in inglese, clicca qui.

La seguente lista fornisce un'istantanea dei principali requisiti di progettazione tecnica a cui abbiamo pensato mentre lavoravamo su Il mistero di Duvall Drive.Per maggiori informazioni sul design visivo di questi elementi, vedi il Mystery of Duvall Drive Showcase, che evidenzia le varie funzionalità e strumenti di Studio che abbiamo usato per creare l'Ambienteimmersivo.

Missioni

Ci sono diversi tipi di missioni che i giocatori devono risolvere per progredire attraverso l'esperienza, inclusa la navigazione in una serie di piattaforme rotanti fino a quando i giocatori non sono in grado di recuperare un Articolospeciale, o trovare diversi ingredienti in una panetteria espansa e metterli in pentola bollente.Per organizzare il processo di scripting di creazione e debug delle missioni, abbiamo creato un framework di missione e una versione di debug.

Quadro missione

Per garantire che unifichiamo ogni passo della missione durante l'esperienza, abbiamo progettato un quadro di missione puzzle semplice per ogni missione che consisteva in ganci per l'inizio e la fine del puzzle, un posto per leggere i dati di configurazione e un pulsante per completare il puzzle per finalità di debugging .Per informazioni più dettagliate su questo processo e sui suoi parametri, vedi Logica delle missioni.

Selli e stati di gioco

Quando i giocatori entrarono in stanze specifiche, volevamo che interagissero con oggetti piccoli speciali noti come sigilli per attivare le missioni.Dopo aver risolto la missione, volevamo che prendessero il sigillo e lo posizionassero in una posizione predefinita all'interno del foyer al fine di procedere attraverso l'intero Partita.Dopo aver posizionato il sigillo nella posizione corretta, potrebbero quindi continuare in un'altra stanza all'interno della casa e iniziare la prossima missione facendo clic sull'oggetto speciale di quella stanza.

Abbiamo sviluppato un semplice sistema di presa per tenere un oggetto attaccando l'oggetto al braccio destro del personaggio.
Il foyer in cui i giocatori devono posizionare ciascun sigillo per progredire attraverso l'esperienza.

Per implementarlo, abbiamo creato stati di gioco , che specificerebbero il periodo di tempo in cui i giocatori potrebbero iniziare il processo come:

  • Cercando un sigillo "corrotto" in una stanza per attivare la missione.
  • Raccogli il sigillo "restaurato" quando risolvono la missione.
  • Posiziona il sigillo nel cerchio del foyer.

Gli stati di gioco controllano in gran parte il flusso dell'esperienza e il modo in cui i giocatori interagiscono con la narrativa dell'esperienza narrativa.Per ulteriori informazioni, vedi GameStateManager .

Camere normali e corrotte

Volevamo avere due stati di sei stanze nella casa: uno stato normale e uno stato corrotto.Quando un giocatore tocca un sigillo corrotto in una stanza per attivare lo stato corrotto della stanza, l'ambiente cambia in un'atmosfera più oscura con illuminazione modificata, oggetti ambientali e effetti speciali.I giocatori dovrebbero quindi risolvere la missione per tornare allo stato normale della stanza.

Lo stato normale dello studio
Lo stato corrotto dello studio

Per implementarlo, abbiamo preparato uno spazio speciale nell'esperienza che era molto lontano dalla casa, a circa 6.500 studs di distanza nella direzione X , che poteva ospitare lo stato corrotto di una stanza.Quando un giocatore attiva qualsiasi stato corrotto, lo stato corrotto di quella stanza specifica si clona in quest'area da ServerStorage a TempStorage/Cloned , quindi i giocatori teletrasportarsi in quella stanza.Piccole Parts esistono all'interno di ogni stanza normale e corrotta che servono come punti di spawn per i giocatori quando entrano o escono dalle stanze.Dopo aver risolto la missione, teletrasportiamo simultaneamente i giocatori nel normale stato della stanza e distruggiamo tutti gli oggetti nello stato corrotto della stanza.Per ulteriori informazioni sugli stati di gioco che controllano questo processo di teletrasporto, vedi GameStateManager .

Versione di debug

Per aiutarci a debuggare le missioni periodicamente, abbiamo creato una versione dell'esperienza in cui non dovremmo aspettare nella lobby o per le cutscene.Questa versione aveva trucchi e pulsanti basati sulla tastiera che ci avrebbero permesso di completare automaticamente le missioni in modo da poter testare rapidamente gli aspetti dell'esperienza.Copieremmo e pubblicheremmo periodicamente questa versione nella versione che avevamo previsto di rilasciare che avesse il flusso di gioco appropriato.Per distinguere queste due versioni, abbiamo creato uno script DemoGlobalSettings per controllare l'ID del luogo, vedere se è in esecuzione in Studio e abilitare/disabilitare vari trucchi e pulsanti di gioco.Per ulteriori informazioni, vedi Logica delle missioni e Script di configurazione.

Teletrasporto

Ci sono tre tipi di teletrasporto che si verificano all'interno dell'esperienza:

  1. Teletrasportare i giocatori dalla semplice lobby all'area principale di gioco in un server riservato.
  2. Teletrasportare i giocatori dallo stato normale di una stanza allo stato corrotto, quindi di nuovo mentre mostri una cutscene.
  3. Teletrasportare i giocatori all'interno di alcuni puzzle, o quando riappaiono dopo essere caduti dall'area di gioco.

Server riservati

Abbiamo deciso di raggruppare i giocatori in gruppi di cinque in una semplice lobby prima di teletrasportarli su un server riservato per l'area principale di gioco della casa.La lobby ha fornito tempo per i giocatori aggiuntivi per unirsi e giocare insieme e i server riservati hanno impedito ai giocatori aggiuntivi di mancare gli aspetti del gameplay e della narrativa della esperienza a tarda notte.Questa teletrasportazione avviene solo una volta.

Scene di taglio

Volevamo essere in grado di trasportare i giocatori durante il gioco ogni volta che completavano determinati compiti, come toccare una balena o completare una missione.Per implementarlo, abbiamo sviluppato una versione semplice di uno strumento basato su script chiamato EventManager che ha controllato diverse proprietà e attributi, eseguito script e audio/suonoe eseguito scuoti della fotocamera per un periodo di tempo.Ciò ci ha permesso di spostare sia i giocatori che lo streaming in e fuori diverse stanze mentre nascondiamo questo processo al giocatore utilizzando effetti speciali.Per ulteriori informazioni, vedi Gestore eventi.

Respawn giocatori

Il terzo tipo di teletrasporto che volevamo implementare era un breve teletrasporto con solo un cambio di coordinata del giocatore CFrame all'interno di alcuni puzzle e quando i giocatori cadono e respawn.A differenza dei due precedenti tipi di teletrasporto, questo tipo non richiede esplicitamente lo streaming asincrono.

Script della giocabilità

La programmazione ci ha permesso di eseguire su elementi specifici del gameplay, come elementi di interfaccia fading, di creare volumi di trigger per eventi chiave e di evidenziare gli oggetti quando sono stati in primo piano con il cursore del Giocatore.Molti di questi sistemi hanno fatto affidamento sulla marcatura degli oggetti per eseguire un comportamento personalizzato, quindi utilizzando una varietà di script client o server per contenere flussi di lavoro specifici a seconda di quale azione doveva accadere a punti specifici nell'esperienza.Per maggiori informazioni su come abbiamo implementato questi sistemi, vedi Sistemi di gioco di base e Sistemi di supporto.

Comportamento personalizzato con tag

Volevamo un modo per aggiungere un comportamento personalizzato per gli oggetti, come il blocco delle porte in modo che i giocatori dovessero rimanere nella stanza fino a quando non avessero completato la missione attiva.Per implementarlo, abbiamo deciso di utilizzare i tag per oggetti specifici, quindi abbiamo utilizzato CollectionService per trovare questi oggetti e connettere qualsiasi corrispondente Scripts per aggiungere un comportamento personalizzato.Avevamo uno Script per ogni categoria di tag che ha agito come manager per gestire tutti gli oggetti contrassegnati con quella categoria in modo che potessimo mantenere il Script in un'unica posizione piuttosto che essere copiati molte volte in DataModel .Per ulteriori informazioni, vedi DoorManager , MasterAnimator , DrawerManager , KillVolumes , PlayerMissionRespawn e PianoManager.

Il "gestore" Script utilizza una funzione Init per trovare tutti gli oggetti contrassegnati quando l'esperienza inizia e connettere un comportamento personalizzato ad essi.Ad esempio, DoorManager trova qualsiasi oggetto contrassegnato con Porta , quindi attribisce il comportamento corretto agli oggetti della porta (movimenta la porta quando viene cliccata, riproduce un effetto sonoro di scuotimento della porta, ecc.).Tuttavia, qualsiasi oggetto aggiunto o rimosso durante l'Tempo esecuzione, come qualsiasi oggetto aggiunto a una stanza corrotta dopo che un giocatore interagisce con un sigillo corrotto, perde questa chiamata iniziale e non ottiene mai il comportamento previsto.Per risolvere questo, usiamo CollectionService.GetInstanceAddedSignal e CollectionService.GetInstanceRemovedSignal per concedere lo stesso comportamento a nuovi oggetti che sono contrassegnati e non contrassegnati, rispettivamente.

Script cliente e server

Volevamo ridurre la larghezza di banda per diversi aspetti del gameplay che sarebbero stati costosi in termini di Prestazione.Abbiamo deciso che quando la funzionalità dell'oggetto può influenzare la simulazione per altri giocatori, come la movimentazione dell'oggetto attraverso la collisione, avremmo eseguito questo sul server , ma se qualcosa è più correlato al design dell'ambiente, come le luci, le animazioni ambientali che non influiscono sul Partita, gli effetti speciali e l'audio/suono, lo eseguiremmo sui client >.Ciò ridurrebbe la larghezza di banda e mantenere più lisce le modifiche sia del movimento che dell'ambiente sugli dispositivi dell'utente.