Posso usare il creep a mio vantaggio? [chiuso]

Posso usare il creep a mio vantaggio?

Ogni volta che prototipo un gioco, le funzionalità vengono aggiunte inavvertitamente. Ciò accade sia per coincidenza, sia per essere facile da aggiungere in base al contenuto esistente.

Se conosco il genere del gioco, posso semplicemente iniziare a creare le meccaniche di base e aggiungere funzionalità man mano che diventano evidenti?

Ad esempio, se voglio creare un platform 2d nel corso di 6 mesi, posso semplicemente iniziare a correre, saltare, sparare, ecc. E aggiungere la meccanica di base quando li trovo inavvertitamente? O è troppo rischioso un investimento nel tempo senza un piano predeterminato?

La mia logica è che il design sarà più conveniente. Le scelte progettuali saranno costruite più facilmente attorno a ciò che è facile da fare (in termini di tempo).

In sintesi, c'è qualcosa che non va nella costruzione di un gioco prima di progettarlo?

Questa è una domanda interessante. Soprattutto perché rispondendo aumenta il dilemma del grigio contro il bianco contro il bianco.

c'è qualcosa che non va nella costruzione di un gioco prima di progettarlo?

Se pensi a quella domanda come un tipo sì o no, la risposta può essere solo: sì, c'è. Se la risposta può essere più sfumata, allora cambia. Motivo: non si dovrebbe mai costruire un gioco prima di un po 'di progettazione. Ma puoi sicuramente salvare parti del design per dopo.

Significa che non penso che dovresti vedere il problema a portata di mano come un do o no. Piuttosto, è qualcosa che dovresti pensare in termini di gradi. La caratteristica strisciante forse è la seconda radice di tutto il male per quanto riguarda lo sviluppo del gioco (il primo, come Donald Knuth ci ha criticato, è che "l'ottimizzazione prematura è la radice di tutto il male" ). Tuttavia, nella mia esperienza, non pensare a nessuna delle caratteristiche principali, ovvero non avere almeno un design di base di dove vuoi andare con la tua meccanica di base, non è una buona idea.

Il primo motivo principale è che è utile dal punto di vista delle risorse (incluso il tempo come risorsa) avere un po 'di pianificazione per guidarti nella depressione, perché raggiungere i vicoli ciechi in continuazione a causa di un eccessivo tentativo e errore può essere altrettanto uno spreco di risorse come includere funzionalità impreviste.

La seconda ragione principale, dal punto di vista del design del gioco, è la coerenza. Un buon design del gioco ha coerenza concettuale o coerenza, se lo desideri. Significa che il gioco generale, la storia, l'implementazione, persino la grafica, dovrebbero adattarsi il più agevolmente possibile. È molto improbabile che un game design realizzi qualcosa del genere se le funzionalità principali vengono appena scoperte in movimento. Se non altro, perché in viaggio ha molta casualità: le cose su cui farai passi possono avere impatti molto diversi a seconda di quando nel processo di sviluppo le hai trovate .

Non intendo dire che non dovresti fare affatto quello che hai detto. Sto solo sostenendo che devi trovare un certo equilibrio.

Ad esempio, se voglio creare un platform 2d nel corso di 6 mesi, posso semplicemente iniziare a correre, saltare, sparare, ecc. E aggiungere la meccanica di base quando li trovo inavvertitamente? O è troppo rischioso un investimento nel tempo senza un piano predeterminato?

Vorrei iniziare introducendo una leggera modifica nella frase. Effettuando la corsa, il salto, il tiro e così via stai già implementando la meccanica di base. Ciò che dovresti aggiungere in movimento nel tuo esempio sono le specifiche funzionalità di gioco.

Non è perché sai che il gioco sarà una piattaforma 2D, che correre, saltare o sparare non può variare a seconda del design del gioco. Il tuo giocatore può correre sui muri? Il tuo giocatore può fluttuare in aria quando salta? Anche, il tuo giocatore può sparare mentre corre? Il tuo giocatore spara solo in una direzione lineare o tramite una parabola? Queste decisioni possono dipendere molto dalle caratteristiche del gioco.

Ma vedo il tuo punto: questi meccanici hanno spesso delle parti che variano molto poco. Quindi, se fai un po ' di progettazione del gioco e decidi sulle caratteristiche di base tanto da essere in qualche modo sicuro su come funzioneranno la corsa, il salto, il tiro, ecc., È un inizio. Quindi puoi andare per questi meccanici e continuare a costruire su di essi.

Ovviamente puoi ancora trovare in seguito una nuova funzionalità che richiede di modificare questi meccanismi, indipendentemente da quanto fossero basilari. Ma la chiave qui è la probabilità. La probabilità che ciò accada troppo spesso sarà minore se almeno pensassi alle conseguenze di correre, sparare, saltare ecc. Per le idee di base che hai avuto per il gioco.

Infine, se vuoi seguire questa strada, suggerirei quanto segue. Pensalo come un processo iterativo. Fai un po 'di pensiero progettuale iniziale ad ampio livello. Implementate ciò che sembra fondamentale e più "universale" all'interno del vostro gioco, affinché abbia successo. Quindi fai un po 'più di riflessione sul design, rivaluta ciò che hai implementato e vai per qualche altra implementazione.

Quando realizzi progetti complessi come i giochi, spesso non puoi realizzare tutte le funzionalità che desideri, perché stai esaurendo il tempo / i soldi o perché non si sono rivelati buoni come ti aspettavi. Questo è noto come funzione creep. Ma c'è un rovescio della medaglia in questo; troverai anche funzionalità che non pensavi fossero necessarie, ma man mano che il progetto prende forma, il loro bisogno diventa evidente.

Questo è il motivo per cui le persone costruiscono prototipi : così possono imparare cosa funziona e cosa no, così possono tagliare funzionalità che non funzionano , ma anche trovare nuove funzionalità che sarebbero fantastiche . Se non stai facendo nessuna di quelle cose che non stai imparando , stai sbagliando.

Questo è fondamentalmente il sentimento espresso in un discorso chiamato Advanced Prototyping , di Chris Hecker e Chaim Gingold, che include molti esempi del loro lavoro su Spore, in cui sono stati spesso sorpresi da ciò che ha funzionato e cosa no, fino a ridisegnare il tutto sistemi basati sul feedback del prototipo.

Un altro esempio è il processo di progettazione di Left 4 Dead ; all'inizio il gioco aveva solo zombi di base, ma provando con giocatori esperti, i progettisti hanno scoperto che i giocatori si sono uniti efficacemente e il gioco è stato troppo facile, quindi hanno aggiunto zombi speciali per dividere la squadra e mantenere il gioco eccitante.

Naturalmente, questo non significa che dovresti costruire il tuo gioco senza alcun progetto precedente . Dovresti assicurarti che il nucleo del tuo gioco sia divertente prima di procedere, perché questa è spesso la parte più difficile della creazione di un gioco.

Direi di sì, provaci. Pianifica in anticipo alcune caratteristiche / classi comuni per avere una certa coesione tra ogni nuovo componente.

Unity è noto per il suo approccio componente allo sviluppo del gioco e consentirebbe facilmente questa forma di sviluppo. Se non si utilizza Unity, è possibile replicare un approccio semi-componente. Non ho familiarità con altri motori di gioco.

Gli oggetti di gioco Unity hanno tutti un componente di trasformazione. Questo indica la posizione, la rotazione e la scala dell'oggetto. Quindi crea una classe generica di "trasformazione" per contenere questi valori, più forse un riferimento all'oggetto di gioco reale.

Prendi un componente "Salta", ad esempio. Fai lavorare tutta la logica con la classe di trasformazione di un oggetto gioco per manipolare la posizione. (O il tuo motore avrà già una classe integrata simile.) Potresti associare questa classe 'Jump' a qualsiasi oggetto, e la classe animerà la posizione di trasformazione quando viene attivata un'azione (Jump.PerformJump () o qualsiasi altra cosa). La classe Jump non deve sapere nulla del suo proprietario (o, almeno, informazioni minime).

Ora puoi divertirti a creare una tonnellata di componenti, quindi a collegarli a oggetti di gioco, combinandoli su un oggetto, ecc. Ad esempio: Corri, Salta, Accovacciati, MovingTile, FireWeapon (specifica lo sprite 'bullet' e il comportamento da realizzare un componente generico), ecc.

Rendi ogni componente il più generico possibile per consentire molteplici usi / variazioni. Per FireWeapon, puoi specificare lo sprite del proiettile, la velocità, il danno, ecc. Puoi provare a normalizzare quegli attributi, in modo tale che velocità e danno siano specificati tra 0 e 1. Quindi ridimensionali ai valori massimi del gioco. In questo modo ti preoccupi solo delle differenze relative tra le armi. Inoltre, questo si adatta alle impostazioni globali come difficoltà in cui una difficoltà maggiore ha un danno massimo più elevato, ecc.

Prima che tu lo sappia, hai un arsenale di componenti da collegare e ora puoi sviluppare rapidamente per qualsiasi tipo di gioco.

Breve: la maggior parte delle volte non è possibile seguire un'unica fase di progettazione di una singola fase di codifica. Dovrai alternarli. Come regola generale, cerca di rispettare ciò che è già progettato (non ciò che è già codificato).

A proposito di non avere un disegno iniziale (solo uno schizzo o un'immagine mentale): se non hai un disegno non hai un disegno. Devi fare qualcosa per venire con uno. Ma finché inizi a costruirne uno, cerca di rispettarlo, non venire con uno nuovo ogni volta.

Effettuare la sperimentazione e ottenere funzionalità casuali può o meno essere dannoso. Può anche essere utile o inevitabile. Ad esempio: sai che vuoi supportare il salto (molti giochi di ruolo 3D / 2D non consentono di saltare). Come lo sai? Perché hai immaginato una mappa di gioco che richiedesse il salto per ordinare un ostacolo? Quindi l' implementazione del salto è abbastanza buona fintanto che consente al giocatore di risolvere quell'ostacolo o deve rispettare determinate caratteristiche come la massima altitudine raggiungibile, può essere potenziata da oggetti o oggetti di gioco sulla mappa, la fisica deve includere l'accelerazione o il rimbalzo ( quando Mario salta in un nemico, ottiene l'impulso di elevarsi di nuovo e questo è molto importante per il gioco)?

Se sei già in grado di rispondere a queste domande, i tuoi documenti di progettazione (immaginari o reali) sono molto completi. Se non riesci a rispondere a questi, il tuo design è incompleto. In questo caso, dovrai ricominciare a lavorare nella progettazione o fare esperimenti per colmare le lacune. Le opportunità possono essere molto aperte o molto restrittive. Se alcuni dei tuoi livelli di gioco avranno ostacoli e hai solo bisogno di saltare per loro, allora c'è molta libertà per decidere l'altitudine massima raggiungibile o la velocità, forse decidi di far finta che ci sia un motore fisico per iniziare tutto solo per migliora la grafica dell'animazione del salto ma non ti serve per nient'altro. (In molti giochi di ruolo in 2D non puoi saltare quando vuoi, ma fintanto che c'è un singolo foro di tessera in una mappa, provando ad entrare in essa si innesca automaticamente un salto sulla piastrella del pavimento accanto alla tessera del foro)

Capisco che va bene andare al codice senza un design completo purché rispetti ciò che è già stato deciso. Inoltre, può essere inevitabile in alcune situazioni poiché gli universi di gioco possono essere costruiti da una varietà di diversi processi di pensiero. Ad esempio un gioco di carte: so che voglio che le carte abbiano Attacco e Difesa, un certo numero di carte nel tavolo in un dato momento e che il giocatore durante il suo turno possa scegliere con quale carta attaccare quale altra carta. Può sembrare che alcuni abbiano già un design completo, ma poi arriva il bilanciamento del gioco, possibile solo attraverso molte simulazioni. Dopo molte simulazioni, decido che una carta con Attacco 10 è sopraffatta, posso semplicemente eliminarla dal gioco ma mi piace troppo, quindi farò qualcosa di diverso, Creerò una nuova regola che dice che se un giocatore attacca con una carta del genere non può attaccare con altre carte durante quel turno. Ora ho una nuova regola che arricchisce le meccaniche di gioco, ma applicarla a una singola carta sembra strana (come un trucco sporco), mi rendo conto che sembra strana e quindi decido di creare un nuovo set di carte che hanno numeri alti ma il nuova regola di limitazione si applica a loro. Ora ho una meccanica di gioco più complessa, costruita al di sopra di quella originale più semplice, a mio avviso, l'ho sfruttata a mio vantaggio per creare un gioco migliore.

Ora, una cosa sull'ultimo esempio, nell'esempio proposto del gioco di carte, nuove carte può comportare nuove risorse (aumento dei costi, aumento del tempo). Ma penso che sia un buon esempio di come le opportunità che vedi solo quando il codice influenza le tue decisioni di progettazione in modo positivo.

Non credo che la maggior parte dei giochi a cui giochiamo siano stati interamente progettati prima della codifica, sono sicuro che dovevano prendere decisioni difficili per rispettare le scadenze e così via.

Quando qualcun altro paga per tutto: spiega, negozia.