Durante la prototipazione, come posso esplorare più facilmente il comportamento del gioco?

Costruisco personalmente giochi indie, ma di solito sono senza energia una volta che ho portato un gioco di recente sviluppo a un livello in cui è possibile giocare con il comportamento, quindi mi accontento di raffinamento invece di esplorazione. Con risultati orribili.

^{(foto dal blog interfono )}

Ad esempio, trovo che i cicli di iterazione per l'ottimizzazione del comportamento (ovvero il collegamento e il riavvio di un'applicazione C ++) siano così lunghi da uccidere tutta la creatività. Sto costruendo uno strumento per affrontare questo.

Quali altri modi esistono per esplorare rapidamente il comportamento del gioco? Sono interessato alle metodologie utilizzate dagli sviluppatori indipendenti e dalle grandi aziende.

Come hai notato, quando lavori sulle meccaniche di gioco, la velocità di iterazione è fondamentale. Più è lungo il tempo tra pensare a una modifica e riuscire a testare con tale modifica, meno produttiva sarai e più sarai distratto. Di conseguenza, si desidera sicuramente gestire il tempo di iterazione.

Per me, trovo che la mia produttività inizia davvero a diminuire quando il tempo per testare una semplice modifica supera circa cinque secondi. Quindi, quando stai sperimentando per perfezionare il modo in cui il gioco si sente, uno dei tuoi obiettivi deve essere capire "come posso fare un cambiamento e poi giocare usando quel cambiamento in meno di cinque secondi". Non importa come lo fai, purché tu possa mantenere quel tempo di iterazione fino a quel livello.

Molti grandi motori moderni (Unity, Unreal, ecc.) Tendono a farlo inserendo il loro editor all'interno del motore di gioco, in modo da poter apportare la maggior parte delle modifiche dal vivo, senza mai riavviare il gioco. I motori / i giochi più piccoli in genere concentrano il lavoro nella direzione opposta; fai in modo che il gioco si compili e si avvii così rapidamente che non importa se devi riavviare il gioco per ogni modifica; sarai ancora presente e testerai prima che scadano quei cinque secondi.

Nel mio progetto attuale, ci vogliono circa dieci secondi per fare una piccola ricompilazione, collegare, avviare il gioco e quindi raggiungere il gameplay (la maggior parte di ciò sta generando una geometria del mondo renderizzabile durante il caricamento di un gioco salvato). E questo è troppo lungo. Quindi ho creato modalità di gioco "test" separate che mi consentono di testare diverse parti del gioco senza caricare tutte le risorse di gioco reali, in modo da poter entrare e uscire molto, molto più velocemente; in genere in circa 2-3 secondi. Se voglio provare un po 'di UI, posso farlo senza caricarmi nel gioco reale. Se voglio testare il rendering, ho un'altra modalità in cui posso provarlo, di nuovo senza caricare l'intero sistema di gioco.

Ho visto altre persone che hanno affrontato il problema inserendo la logica di gioco in una DLL e lasciando che l'eseguibile del gioco già in memoria ricarichi la DLL mentre il gioco è in esecuzione, in modo da poter ricostruire la DLL e ricaricarla all'interno di un eseguibile già caricato, quindi non è necessario ricaricare / ricostruire le risorse artistiche del gioco. Mi sembra una follia, ma l'ho visto fatto.

Molto più semplice di quello sarebbe specificare i comportamenti di gioco e / o la configurazione in script o file di dati e fornire un modo per far ricaricare i file del sistema, su richiesta, o forse semplicemente guardarli per le modifiche, senza bisogno di chiudere il gioco si interrompe, ricollegarlo e quindi riavviarlo.

Ci sono molti approcci. Scegli ciò che funziona meglio per te. Ma una delle chiavi per perfezionare con successo la meccanica di gioco è l'iterazione estremamente rapida. Se non lo hai, quasi non importa cos'altro fai.

Per prototipare bene, ridurre il costo delle idee di test.

Il mio flusso di lavoro è ottimizzato per i piccoli giochi, ma ho trovato utili queste cose:

• Tecnologia a prova di prototipo  Ho trovato utile utilizzare un linguaggio di programmazione e un framework dinamici, come Lua ( LÖVE è bello per il 2D), JavaScript o Lisp / Scheme dove ottenere il programma per fare qualcosa richiede sequenze di tasti minime, anche a costo di tutto il resto. Una volta che sai cosa vuoi e vuoi perfezionarlo, ottimizzarlo o portarlo su un altro motore.
• Controllo versione  Conserva i prototipi in un repository controllato con revisione . Ramo presto, ramo spesso. Questo ti fa sentire a tuo agio nel provare le cose senza preoccuparti di perdere o dimenticare qualcosa. ( Git ha il modello di diramazione più economico.)
• Costruisci automazione  Assicurati di dover fare il meno possibile per far funzionare effettivamente la cosa. Secondo me, anche dover premere un pulsante è troppo: di solito ne ho uno Makefilecon un make watchobiettivo che gira inotifywaitin un ciclo, reagendo alle modifiche ai file compilando / eseguendo automaticamente il gioco. In un linguaggio interpretato o compilato da JIT , questo è istantaneo.

Come sviluppatore che si concentra principalmente sulla prototipazione, ecco alcuni consigli dalla mia esperienza.

1. Utilizzare un motore che consente di apportare modifiche VELOCEMENTE. Ciò include cose come "Non aspettare la compilazione", ma anche "cambiare le cose in fase di esecuzione", "facilità di debug", "disponibilità di risorse di test" ecc. Personalmente adoro Unity3D, ma non è lo strumento migliore in circolazione . Lo strumento migliore dipende dal gioco: ad esempio, Unreal Engine compila il codice molto più lentamente di Unity3D, ma può avviare rapidamente più client connessi. Per un gioco in rete, questo spesso compensa i costi di compilazione. Considera anche la familiarità. Se sei un mago con C ++, anche il miglior motore Javascript non farà molto bene, e viceversa. Non passare il tempo a lottare con tecnologie sconosciute (voglio dire, impara altre lingue / framework, ma non contemporaneamente a realizzare prototipi importanti).
2. Impara a scartare senza pietà le funzioni esistenti. Aggrapparsi a cose che hai già implementato è un anatema per la prototipazione di successo, ma lasciar andare il tuo lavoro è difficile.
3. Se non lavori con un game designer, metti una linea chiara tra "indossare un cappello da programmatore" e "indossare un cappello da designer". L'aggiunta di una nuova interessante funzionalità di gioco sembra molto allettante, ma non farlo quando sei nella posizione di designer. Piuttosto prova a creare un gameplay divertente (preferibilmente più varianti) con quello che hai; fare un elenco di funzionalità che potrebbero essere d'aiuto e quindi implementarle (alcune).
4. La prototipazione rapida implica il bilanciamento tra due opposti. Vuoi fare cose il più velocemente possibile, quindi scrivi un codice errato. Ma vuoi cambiare roba il più possibile, quindi devi scrivere un buon codice! Impara a bilanciare questi due. Scusa, non riesco a pensare a nessun consiglio concreto su come farlo, ma almeno sii consapevole di questo problema (-8

Guarda quanto tempo richiede la tua prototipazione. Nella mia esperienza, vuoi avere una versione giocabile di qualsiasi cosa in due giorni al massimo - a partire da zero; e vuoi testare una o due nuove funzionalità ogni giorno. Se non stai raggiungendo questi obiettivi, cerca modi per essere più veloce.

Si può dividere lo sviluppo del gioco tra queste quattro fasi:

• prototipazione
• perfezionamento del gioco
• sviluppo
• perfezionamento delle prestazioni

Credo che l'esplorazione del gameplay avvenga principalmente nella fase di prototipazione e questi sono alcuni consigli che cerco di seguire:

• Inizia a progettare con un prototipo di carta. Dopo aver avuto un'idea chiara di ciò che potrebbe essere il gioco, inizia a codificarlo in modo da poter effettivamente sentire le interazioni. Forse questo è inutile per i giochi 3D, ma personalmente mi ha aiutato molto in passato.

• Codice sapendo che getterai via il tuo codice dopo aver finito. Questo ti permetterà di essere liberale quando si tratta di quale motore di gioco scegliere.

• I cicli di iterazione rapidi sono importanti (come altri hanno già sottolineato in precedenza). Scegli un motore di gioco in base alla sua capacità di mostrarti rapidamente ciò che hai codificato. Inoltre, in questa fase non devi preoccuparti delle prestazioni o della fedeltà grafica.

• Limita la portata. Se il gameplay reale è in 2D (solito gioco di strategia, JRPG), prototipo in 2D. In questa fase ti preoccupi solo del feedback sul gameplay .

• Non perdere tempo a lucidare o cercare risorse. Scarabocchia qualcosa su un foglio, scatta una foto, taglialo in Photoshop, magari coloralo e usalo come uno sprite. Accendi il microfono e pronuncia "pew pew". Metti insieme due cubi e una sfera e avrai un robot. Ricorda sempre, esplorare le possibilità di gioco è la tua prima e unica priorità.

Dopo aver deciso un prototipo divertente, inizia a perfezionarlo. Non credo ci sia ancora un motivo per cambiare tecnologia, tranne se c'è un elemento di gioco che ne ha bisogno.

Più avanti nella fase di sviluppo, manterrai il prototipo raffinato a portata di mano mentre svilupperai un gioco nuovo, molto più bello, molto più bello, molto più piacevole. Qui devi scegliere il motore di gioco effettivo da utilizzare.

Alla fine, prendi quello che hai e sintonizzalo per usare meno risorse.

La maggior parte di ciò che descrivo sopra è conoscenza comune, ma inserendola in un elenco, compartimentando l'intero processo di sviluppo, mi aiuta a mettere ogni passo in prospettiva. Mi auguro possa aiutare anche te.

Concordo con la risposta di Trevor Powell secondo cui la velocità dell'iterazione è fondamentale per rimanere nello stato d'animo creativo anziché limitarsi a lucidare. Una grande fonte di ispirazione per me è il discorso di Bret Victor, "Inventing on Principle" . Sfortunatamente, è difficile trovare strumenti reali a quel livello. Ho provato a costruirne uno per lo sviluppo di Python che mi consente di eseguire il mio codice Python mentre lo sto scrivendo. Si chiama Live Coding in Python .

Ho creato uno strumento di prototipazione chiamato Trabant che:

• è SOLO 3D e meccanico di gioco (nessuna interfaccia utente, nessun testo, niente);
• richiede estremamente poco codice e non attivi per costruire un prototipo;
• I modelli 3D sono creati in codice usando l'arte ASCII ;
• consente iterazioni seconde;
• ha il supporto per la simulazione di corpi rigidi;
• funziona su Windows, Mac, Linux e iOS;
• utilizza un noto linguaggio generico, Python;
• ha un IDE per Windows e iOS.

Ho costruito 30 prototipi di prova per verificare quanto sopra.

Come sottolineato da Trevor Powell, le iterazioni devono essere <5 secondi e trovo <1s iterazioni quasi cinque volte migliori.:)

Anko ha affermato che l'uso di un linguaggio dinamico è una buona idea, ho scelto Python poiché è uno dei più utilizzati . Per quanto riguarda l'automazione della compilazione, il test in Trabant è rapido quanto premere F5 nell'IDE (o F6 per testarlo sull'iPad) e, poiché non è necessario alcun passaggio di build, non è più istantaneo di questo.

Il codice di lancio era uno degli asporto di Nevermind . Sono totalmente d'accordo, e Trabant lo impone.

Oltre alla velocità di iterazione di Trevor Powell, che è davvero importante, ecco alcune altre considerazioni utili:

È come un buon codice ...

Un sacco di IF lì dentro.

Più solido è il concetto, meno è necessario giocare. Se sai cosa la carne che stai cercando di fare è, la prototipazione diventa - cosa mettere e come organizzare le cose in relazione al pilastro centrale (la tua cosa principale).

Se stai iniziando come molti altri - non sei sicuro di cosa vuoi fare, vai in una direzione ed esplori molto nel modo dell'immagine che hai mostrato.

In ogni caso, l'impegno per una tecnologia è irrilevante se ciò che stai cercando può essere simulato senza molta profondità: prototipalo su tutto ciò che vuoi / puoi.

Non sprecare un solo secondo in più in risorse. Scarica tutto da Internet. Proprietaria o no. Stai cercando di avere un'idea del tuo concetto al lavoro - a meno che la grafica non sia la tua caratteristica principale, nessuno ti farà causa per aver sperimentato i suoni, le trame e tutto il resto degli altri, non lo stai ancora mettendo nello scaffale del negozio. A meno che tu non sia già finanziato - convincere le persone che il concetto è utile è la cosa che ti darà i soldi per ottenere le risorse che desideri. Ho visto persone di game studio presentare concetti di gioco con versioni modificate di giochi proprietari a cui non hanno diritti.

È come se stessi costruendo un modello in scala. È fantastico avere una replica di vita in miniatura di ciò che vuoi. A volte è sufficiente ritagliarlo dalle riviste, creare a mano e incollare i pezzi insieme. Chiunque abbia un pizzico di immaginazione non supporrà che costruirai il grattacielo dallo stesso cartone con cui hai mostrato il modello in scala. E nelle industrie creative - è più preferibile lavorare con persone con un po 'di fantasia. Se non riescono a guardare oltre alcuni problemi di bozza per vedere il potenziale dietro un intero concetto, raramente apprezzeranno un prodotto. Nessun apprezzamento significa che sono meno disposti a impegnarsi e questa è una spirale discendente. È la differenza tra impostare l'atteggiamento di tuo figlio per conquistare il mondo e invece dire "Non puoi nemmeno allacciarti le scarpe nel modo giusto, piccolo tuffo,

Qualunque cosa tu stia facendo, ricorda sempre che l'atteggiamento da solo è più che sufficiente per rovinare qualsiasi cosa, indipendentemente dal suo potenziale tecnologico o economico.

Una volta ho prototipato un gioco usando esclusivamente immagini gif e dando loro qualcosa a che fare con javascript. Non è abbagliante ma ha lo scopo di mostrare ciò che volevo mostrare. Non importa se in seguito lo svilupperai esclusivamente per Xbox.

Se la tua idea è più complessa di un semplice prototipo, allora dovrai mettere la ricerca nella tecnologia che utilizzerai - poiché il prototipo sarà il ponteggio per l'ultima cosa (semplicemente perché molto è investito in e non può essere gettato via leggermente) - se lo ottieni approvato ovviamente.