Share
Puoi fare una dozzina di giochi quest'anno. Sembra impossibile? Non è. Prova questa semplice metodologia di sviluppo del gioco da qualcuno che l'ha tolto e vedi da te che 12-in-12 è un obiettivo ragionevole.
Ho intenzione di condividere con voi la mia metodologia di sviluppo del gioco personale. Non pretendo di aver inventato l'unico sistema al mondo per raggiungere il traguardo, tutt'altro. Questo è semplicemente un libro degli incantesimi, una cassetta degli attrezzi piena di suggerimenti e tecniche personali che uso per combattere i demoni che cercano di impedirmi di lanciare un gioco. Questi demoni includono la caratteristica creep, il design tutto-o-niente e l'ottimismo illimitato. Questi sono trucchi che ho sviluppato nel corso del successo in cui avevo fallito in passato.
Vedete, nel 2012 ho raggiunto l'obiettivo nobile di creare 12 giochi in 12 mesi. Sorprendentemente, non è stato poi così difficile: non ha richiesto molto più lavoro di quanto non avessero avuto i miei molti progetti falliti negli anni precedenti.
Quindi qual è stata la differenza? Un approccio più maturo, più esperto, meno oculato e meno ottimista. Non fraintendermi: non c'è niente di sbagliato nell'ottimismo. In effetti, lo incoraggio! Senza di esso, nessuno di noi sarebbe gamedevs. Senza un certo ottimismo non arriverai mai da nessuna parte. Avevo solo bisogno di affrontare i miei progetti con una mentalità un po 'più umile.
Mi piacerebbe condividere alcuni dei miei trucchi e suggerimenti con voi qui. Ti chiedo di considerare ciascuno di loro, ma sentiti libero di accettarli o rifiutarli come ritieni opportuno. Nessuna tecnica può funzionare per ogni persona, ma se togli una tecnica o una mentalità unica che ti aiuta a raggiungere l'obiettivo di un gioco al mese di 12 partite in un solo anno, allora sarò felice.
Prova a utilizzare questi suggerimenti nel tuo prossimo progetto di gioco. Forse ti aiuteranno anche tu. Forse troverai le tue migliori pratiche che sono diverse o migliori. È fantastico! Come con la maggior parte dei consigli, la chiave è considerare il messaggio, accettare o rifiutare ogni punto come tu ritieni opportuno e adottare (o adattare) quelle pratiche che ti attirano.
Il 90% dei progetti di gioco non vede mai la luce del giorno. La mia esperienza personale lo conferma. Ho realizzato giochi per oltre venti anni e, tra tutti i giochi che ho iniziato, pieno di entusiasmo, di un piano dettagliato e di infinite idee di brainstorms, solo una piccola percentuale è stata mai pubblicata. Questo mi ha causato anni di angoscia. Ero un buon programmatore, potevo produrre opere d'arte accettabili, avevo abbastanza idee per sentirmi sicuro dei miei piani, eppure quello stato meraviglioso in cui il gioco è pronto per il pubblico era un obiettivo sfuggente.
Perché? Perché l'implementazione di tutti questi piani entusiasmanti comportava sempre sfide che non avevo previsto. Inoltre, l'entusiasmo che ho avuto per ogni progetto in genere si attenuava man mano che il traguardo si avvicinava. Il gioco si sarebbe fatto duro, i soldi sarebbero finiti, la data di scadenza sarebbe passata, e il divertimento sarebbe finito. Tutto ciò che rimarrebbe è stato lo slog anche se il tratto finale che molti sviluppatori chiamano il muro.
Il muro è il punto in un progetto di sviluppo software in cui non è più divertente. Tutte le cose facili da implementare sono state codificate, e ciò che rimane è il lavoro intenso: bugfixing, bit di codice complicati, compiti ripetitivi, parti che si basano su cose al di fuori del tuo controllo, quel livello mancante o effetto sonoro, problemi di installazione, utente test, che ha segnalato bug che non è possibile riprodurre e invii di app store.
Finire un gioco potrebbe essere pensato come analogo alla scalata di una montagna. Con un po 'di fortuna, puoi farlo con nient'altro che scarpe da ginnastica e ambizione - ma questo generalmente porta a un fallimento catastrofico. Invece di arrampicare liberamente le mie montagne senza un pensiero o un piano, ho iniziato a portare corde e prese, ho studiato il muro di roccia in anticipo, ho preso nota di sezioni che sarebbero state difficili, e ho pedinato me stesso.
Immagina di dover finire un intero gioco senza un singolo salvataggio. Questo è il modo in cui molti sviluppatori di giochi creano software: tutto o niente, nessuna rete di sicurezza, o lo colpisci al di fuori del parco o si blocca e brucia. Nessuna via di mezzo Non contabilizzare contingenze impreviste. Questo è un modo sicuro per mirare involontariamente al fallimento.
Dopo averlo fatto alcune volte, inizierai a vedere lo schema: i piani ottimistici senza punti di salvataggio lungo la strada sono estremamente rischiosi. Perché non ridurre il rischio e darti più punti di uscita lungo la strada?
Facciamo un tuffo. Userò un gioco che ho scritto in un fine settimana come esempio per illustrare molti di questi punti. Questo esempio del mondo reale dovrebbe aiutare a dimostrare che questo funziona.
Il brainstorming è il migliore. Amo annotare vaste liste di tipi di oggetti, tesori, missioni, nomi di personaggi, idee di livello o elementi costitutivi. È divertente ed è un ottimo modo per iniziare a lavorare su un gioco. Ma c'è una trappola nascosta: i brainstorms sono, per loro stessa natura, circa quantità, non di qualità Mi piace scherzare un acronimo per brainstorm è B.S.
Se si inizia ogni progetto con un enorme brainstorming, ottimo. Ma non iniziare a lavorare sul tuo gioco fino a quando non hai gettato il 99% di ciò che è entrato nella tua lista iniziale nella lista dei desideri di "save it for version two point oh".
Un ottimo modo per ridimensionare il volume imponente, inquietante, eccessivamente ottimistico che è il tipico brainstorm di un gamedev è valutare ogni punto elenco su poche scale, come:
Ordina la tua lista e scarta la maggior parte delle tue idee. Salva la maggior parte di loro (specialmente quelli più difficili) per dopo.
Per ogni oggetto delle tue prime scelte, fai un'ultima domanda: è questo a deve avere o a bello avere? Per il primo prototipo, concentrarsi esclusivamente sulle caratteristiche essenziali, che non potrebbero mai funzionare senza.
In secondo luogo, pensa: quanto sarà difficile implementare ciascun elemento? Richiede molto codice o contenuto? Non vergognarti affatto di pianificare in modo pigro in questo momento: dovrai essere abbastanza disciplinato da mettere molte delle tue più grandi idee a portata di mano semplicemente perché implementarle richiederanno un gran numero di ore di lavoro. Sii pigro: scegli le caratteristiche essenziali che sono facile creare.
Ciò a cui mirate quando attaccate il vostro gigantesco brainstorming è di ridurlo solo all'essenziale. Distilla la tua idea al singolo meccanica di gioco di base che ti piace di più che sarebbe facile da implementare. Fai bene una cosa, non una dozzina di cose a metà cottura.
Questo sarà il tuo MVP: il tuo prodotto minimo vitale.
Una volta che hai descritto l'MVP a te stesso - che significa essere in grado di descrivere l'intero concetto di base del gioco in un paragrafo, con una o due caratteristiche al massimo - è il momento di perfezionarlo.
Fai finta di aver bisogno di convincere un importante editore esecutivo della fattibilità del tuo gioco durante una riunione casuale in un ascensore. Hai dieci secondi. Puoi descrivere il tuo gioco in modo così entusiasmante, così interessante, così talmente intelligente che in quel breve momento potresti ottenere un enorme pagamento di royalty e contratto di pubblicazione?
Scrivi questo passo dell'ascensore. Modificalo. Rendilo più corto. Fai finta che, invece dello scenario precedente, questa sarebbe la copia di testo del retro della scatola del tuo gioco se fosse posizionata sullo scaffale di un negozio. Immagina un giocatore che raccoglie la scatola e la gira. Hanno centinaia di altri giochi tra cui scegliere, ma hanno deciso di darti una decina di secondi del loro tempo per considerare i tuoi. Questo campo vende il gioco?
Se lo leggi per un amico (o anche meglio, per uno sconosciuto) sono incuriositi? Eccitato? Entusiasta? Se riesci a dire di sì a queste domande sai che stai facendo qualcosa di buono.
Solo per divertimento, e per illustrare tutti i miei punti, ho intenzione di mostrarvi il mio work-in-progress per un recente gioco che ho fatto. Il pitch dell'ascensore all'inizio è stato qualcosa del genere:
Sei il cattivo. Due amanti vogliono disperatamente abbracciarsi l'un l'altro. La tua missione è di tenerli separati costruendo muri che li spingono più distanti senza mai renderli impossibili. Un puzzle game strategico a turni basato sul path-finding A-star.
Il prossimo passo, prima di iniziare a scrivere codice o creare vaste librerie di contenuti che possono o meno far parte del tuo gioco finale, è fare un abbozzo del gioco in azione. Non hai bisogno di abilità artistiche: queste possono essere nere e mentre disegnano le miniature delle figure stilizzate. Ciò a cui miri è una rappresentazione visiva dell'intero gioco, dall'inizio alla fine.
Disegna un gruppo di pannelli su un pezzo di carta e inizia con un'approssimazione approssimativa di come apparirà la schermata del titolo o il menu principale. Nel pannello successivo, disegna ciò che succede dopo. Un'introduzione? Livello uno? Continua come se stessi facendo un gioco per gioco del gioco stesso, di momento in momento. Più pannelli hai bisogno di creare per visualizzare completamente il tuo gioco, più lavori ti verranno assegnati. Pertanto, mirare a montare l'intera cosa su una singola pagina. Meno di una dozzina di pannelli è saggio - ma il cielo è il limite.
Ti mostrerò i miei scatti in corso di lavorazione di un puzzle / strategia / gioco di tattiche che ho programmato di recente chiamato Pathos. Per iniziare, ecco lo schizzo approssimativo che ho usato per pianificare rapidamente la meccanica di gioco:
Come puoi vedere, sono un grande fan dei giochi di parole. Ho giocato con tutti i tipi di varianti del titolo del gioco che hanno giocato con l'algoritmo di path-finding di una stella, e ho inserito molte immagini in stile RPG di Dungeons and Dragons, poiché questo è ciò che mi ispira. Adoro le mappe del mondo fantasy e ho pensato che sarebbe stato lo schermo di selezione del livello ideale.
La ragione per cui rendere lo storyboard veloce è importante è che ti fornirà una descrizione più concreta di ciò che accade realmente nel gioco. Moreso, espone le cose visivamente. Quanti pulsanti puoi inserire su uno schermo? Quanto è grande l'avatar? Quale direzione è il movimento? Dov'è il punteggio o la barra della salute? Queste miniature sono un modo meraviglioso per vedere il gioco dal punto di vista di un designer. Ti aiuteranno anche durante la codifica in molti modi. Ad esempio, ora saprai approssimativamente quante icone o immagini di pulsanti devi disegnare, quali saranno i livelli dell'arte e anche come apparirà il gioco - da una prospettiva di layout di base.
Se il tuo fumetto non sembra un gioco divertente ora, ti sarai salvato settimane o mesi di lavoro sapendo già che alcune modifiche dovranno essere apportate. Se il fumetto sembra andare avanti all'infinito, vedrai gli ovvi segnali di avvertimento che il carico di lavoro è troppo grande e devi ridurre la quantità di scene o livelli o elementi del gameplay.
Proprio come un elevator pitch, questo fumetto a fumetti a una pagina è un filtro BS ideale. Mostralo agli amici. Vogliono giocare a questo gioco? Pensano che varrebbe il tuo tempo per trasformarsi in una realtà?
Il prossimo grande consiglio utile per questa sfida è di creare un gioco giocabile nel primo giorno. Nessuna schermata del titolo, solo un livello e solo la meccanica di gioco primaria.
Non sarà fantastico, non sarà finito, e certamente non sarà così bello o divertente. Detto questo, questo passaggio è la tua arma migliore. Sfida te stesso per creare un codebase che compila e gira nelle prime ore. Fai in modo che tu possa accettare input, spostarti, animare qualcosa e attivare alcuni suoni. Questo prototipo, per quanto possa essere un gioco schifoso, sarà il tuo migliore amico.
Prima si può avere un prototipo funzionante in anticipo, più è probabile che tu abbia successo. Sarà il tuo primo "save point" - un altopiano di riposo sulla strada verso la cima della montagna su cui è possibile ricollocare. Rappresenta una visione del gioco di lavoro. Da qui in poi potrai lucidare il tuo gioco per tutto il tempo che vuoi con la consapevolezza di avere qualcosa in mano che "funziona".
Ecco come appariva il primo prototipo. Era un semplice esempio di path-finding in azione, con NO ART - solo rettangoli colorati.
Arrivare a questo stadio ha richiesto molto tempo di programmazione. Stimo che la metà della durata del progetto è stata spesa con il gioco simile all'immagine sopra. L'approccio no-art è ideale per la programmazione: fa risparmiare tempo, ti aiuta a capire i bug e ti costringe a concentrarti sulla "sensazione".
I prototipi no-art hanno anche un altro grande vantaggio: nei giochi precedenti, creavo bellissimi prototipi in Photoshop e raccoglievo centinaia di folletti dall'aspetto adorabile in preparazione al gioco. Dopo lo sviluppo è stato completato, la stragrande maggioranza dell'arte doveva essere sostituita, ridimensionata o buttata fuori. Ho sprecato migliaia di ore a realizzare illustrazioni pronte per il gioco prima della codifica; in questi giorni so che le specifiche tecniche e le meccaniche di gameplay in evoluzione significheranno questo molto di quello che fai all'inizio non lo farà nel gioco finito.
Una volta che la meccanica di gioco con cui stai lavorando inizia a funzionare, puoi farlo iniziare ad aggiungere lucido al tuo prodotto minimo vitale. A questo punto, non dovresti avere un menu principale o una schermata del titolo, ma le regole di movimento e gioco dovrebbero essere in atto per coprire il meccanismo principale.
Ora sei pronto per impegnarti in una particolare dimensione in pixel per i tuoi sprite, decidere i layout e le combinazioni di colori e quante piastrelle vuoi sullo schermo, e iniziare a far cadere l'arte della qualità di gioco nel tuo mondo di gioco. Questo è anche il momento di sperimentare con le prestazioni e affrontare tutti i vincoli tecnologici come mantenere un buon framerate e stare al di sotto della larghezza di banda o della dimensione della trama desiderata.
Tornando al mio progetto di esempio, ecco il primo prototipo funzionante, utilizzando solo un paio di sprite segnaposto. La distanza da una posizione all'altra viene ora misurata e siamo pronti per alcuni livelli effettivi:
Buone notizie: questo è il tuo prossimo "save point"! Hai un gioco che "funziona" nel senso che funziona. Puoi fare clic sullo schermo e succede qualcosa. Non c'è personalità e solo un livello, ma per lo meno è qualcosa che potresti inviare ad un amico e chiedere loro di suonare. Hai qualcosa che compila.
Ciò a cui miriamo qui è la funzionalità: qualcosa, qualsiasi cosa, su cui potresti smettere di lavorare e avere qualcosa da mostrare (e giocare!). Può essere orribilmente poco divertente o brutto come il peccato, ma non è un po 'importante. Per lo meno, avrai un progetto di codice che compila senza errori e produce un deliverable.
Solo una volta raggiunto questo "early playable", sei sicuro di raggiungere il traguardo, perché da ora in avanti potresti spedirlo in modo plausibile.
Con la meccanica del gameplay centrale in mano, il mondo ti si apre. Le possibilità sono infinite e inizia la parte divertente. Forse sceglierai di aggiungere alcuni livelli, scrivere qualche finestra di dialogo, o sviluppare alcuni personaggi nell'abitare il tuo mondo di gioco. Forse pensi che un sistema di particelle di fantasia, musica cool o una lista di punteggi più alti sia essenziale per la tua visione di ciò che il gioco dovrebbe essere. Grande! Gettarsi!
Ricorda solo una cosa: non lavorare su un po 'di questo o quello tutto in una volta. Concentrati su un'attività e finiscila allo stato di base minimo completo prima di andare avanti.
Potresti annoiarti a lavorare su qualcosa e hai bisogno di una pausa. Va bene, ma cerca di essere abbastanza disciplinato per continuare a lavorare sul sistema minimale finché non esiste in uno stato da cui potresti andare via se necessario.
Ad esempio, prima di implementare effetti di combattimento o salute o particelle, concentrati sul movimento dei personaggi e sul rilevamento delle collisioni al punto che puoi dire con sicurezza che il personaggio si muove, urta contro i muri e risponde ai comandi della tastiera, del mouse o del joystick.
Solo poi dovresti passare alle armi, o al movimento avanzato come saltare, o scoprire se il giocatore sta toccando o meno la lava in modo specifico e ha bisogno di ricevere danni.
Lavorando il più linearmente possibile (entro limiti ragionevoli), scoprirai che stai manipolando meno cose contemporaneamente. La tua mente sarà libera di concentrarsi su un singolo compito alla volta, piuttosto che essere sopraffatto da cinquanta diversi bug in cinquanta classi diverse. Questo è essenziale per mantenere la motivazione, la concentrazione e l'entusiasmo. Niente ti fa venir voglia di smettere di più che avere così tanti problemi da risolvere che ti scoraggi.
Proprio come con una diga che perde, un singolo foro è facile da collegare. Se, invece, compaiono contemporaneamente cinquanta diversi fori - se salti da una sfida all'altra senza terminare quella su cui stavi lavorando in precedenza - ti ritroverai presto seduto in un enorme pasticcio di codice bacato che è così complesso e ha ci sono così tanti problemi sparsi che otterrai quella sensazione orribile che deriva dalla consapevolezza che dovrai sventrare tutto per sistemarli tutti.
Nella vita di un gamedev, crei un punto di salvataggio metaforico ogni volta che completi un MVP o un prototipo giocabile o una versione rilasciata di un gioco.
Ricordati di salvare questa versione giocabile del gioco in un punto diverso dalla tua cartella di lavoro. Usa il controllo della versione. Chiudi il gioco e gettalo sulla tua unità di backup. Mandalo per email a un playtester. Qualunque cosa tu faccia, assicurati che se distruggi tutto da questo punto in poi, puoi fare un passo indietro di una versione e spedirla.
Cerca sempre di creare molti strumenti di lavoro, funzionali e eseguibili migliorati in modo iterativo e incrementato in modo incrementale. Se sei passato più di un giorno senza avere una solida versione di backup del tuo gioco che, se necessario, potrebbe essere resa pubblica, dovresti innervosirti.
Naturalmente a volte ci sono lunghi tratti in cui si cacciano insetti per ore e ore. Quando arrivi a un punto in cui il gioco sembra vagamente funzionale e non completamente rotto, salva un backup. Lì - hai creato un altro punto di salvataggio.
Per questo motivo, l'approccio lineare e iterativo descritto sopra vale anche per i tuoi contenuti artistici o livelli di gioco. Lavora per levigare un buon livello alla volta. In questo modo, se esaurisci il tempo, i soldi, la pazienza o l'entusiasmo prima di aver completato tutti i 99 livelli che avresti previsto nel tuo documento di progettazione, i tre o quattro che hai completato sono abbastanza buoni da poter essere comunque orgogliosi di loro.
Per dirla in modo più semplice, cerca sempre di disporre di una versione del gioco che puoi allontanare e mettere in diretta. Questa è una rete di sicurezza. Dopotutto, la vita potrebbe scatenare una crisi inaspettata domani. Malattia, roba di famiglia, un autobus in arrivo - qualunque sia la causa, dormirai sempre meglio con un punto di salvataggio pronto.
Ricorda, puoi sempre tornare ad esso e creare una versione 2.0 notevolmente migliorata ed estesa.
Lo sviluppo iterativo, lineare, passo-passo e univoco alla volta è il segreto del successo 12-in-12.
Se hai raggiunto alcuni punti di salvataggio, il tuo gioco sarà in ottima forma. A un certo punto, deciderete che è ora di chiamarlo fatto. È importante rendersi conto che non aggiungerai mai metà delle funzionalità del tuo originale documento di brainstorming. È probabile che molti altri si siano spostati dalla versione 1.0 alla tua wishlist versione 2.0.
Torniamo al mio gioco di esempio. A questo punto, ho lavorato avanti e indietro per un fine settimana ed ero pronto a spedirlo e andarmene. Avevo cambiato il nome, aggiunto alcune belle illustrazioni, codificato un parser per il formato dei dati usato dal mio editor di livelli e trovato alcuni suoni e musica. E 'stato un gioco. Era giocabile. Ne ero orgoglioso. L'ho chiamato "Pathos" e questo è quello che sembrava. Sentiti libero di cliccare sull'immagine qui sotto per leggere di più e giocare.
Tutti i gamedev sono persone entusiaste e creative. Purtroppo, questo sconfinato entusiasmo e creatività ci possono mettere nei guai. Come ottimisti, nella nostra immaginazione abbiamo una visione grandiosa di ciò che potrebbe essere: quel gioco definitivo che sai solo vendere come hotcakes.
Ogni singola parte di questo grande progetto onirico suona come qualcosa che potresti facilmente fare - e probabilmente è vero! Tuttavia, se sommi ogni attività, la tua ampia capacità non è semplicemente ciò che ti limiterà; è tuo tempo questo è a scarseggiare.
Ricorda che la maggior parte dei giochi su console, ad esempio, ha avuto centinaia di persone che lavorano su di essi, a tempo pieno, per diversi anni. Se sei un solista che cerca di competere con questi tipi di squadre tutto ciò che devi fare è un po 'di matematica per capire che le ore di lavoro umane si sommano a più di una vita di uno sviluppatore indipendente.
Devi semplicemente accettare il fatto che devi mirare più in basso per finire, a meno che tu non voglia passare anni in una singola partita. Considerando che il gioco medio indie buono guadagna qualche migliaio di dollari di profitto, non puoi permetterti di spendere centinaia o migliaia di ore nel tuo gioco a meno che tu non stia scommettendo la fattoria sul lavoro di una vita o su un capolavoro epico. È necessario progettare giochi che richiedono dalle 20 alle 50 ore di lavoro.
Con tutti i mezzi, sognare in grande - ma costruire in modo iterativo. Costruisci un prodotto minimo vitale, e se i playtesters lo adorano, aggiungi un po 'di più e chiama quella versione 2.0. Continua a lavorare in questo modo per tutto il tempo che vuoi!
La perfezione è, per definizione, irraggiungibile. Dovrai ingoiare il tuo orgoglio e accettare l'imperfezione. Trascurare questo è incatenare te stesso al progetto per un'eternità. Ricorda, puoi sempre fare un sequel. Rilasciare il tuo gioco anche se sai che potresti migliorarlo per sempre è una buona cosa. Non solo ti solleverà un peso enorme dalle spalle e ti darà qualcosa di cui essere molto orgoglioso, ma una volta che entrerà nelle mani del tuo giocatore, potranno inventare nuove caratteristiche che non avresti mai considerato.
Quando finisci il tempo, l'energia, i soldi o la motivazione, lancia quello che hai. Se hai aderito alla metodologia di sviluppo del sistema di punti di salvataggio, dovresti avere qualcosa di giocabile in qualsiasi fase del progetto, anche se nella lista dei desideri o nella lista delle cose da fare sono presenti tutti i tipi di funzionalità. Va bene!
Il mantra "rilascia presto, rilascia spesso" viene ripetuto più e più volte dai gamedev di successo per una buona ragione. Hai bisogno di feedback da parte dei giocatori. Hai bisogno di test del mondo reale. Codificare in una scatola nera, nascondersi in un bunker fino al momento del rilascio finale, è un errore. Per uno, stai vedendo il tuo gioco attraverso la tua prospettiva limitata. Probabilmente hai notato dei tempi in cui rilevi le tue e-mail ma gli errori più ovvi del mondo sono passati. Questo perché dopo un po 'di guardare la stessa cosa la tua mente inizia a diventare insensibile all'occhio critico. Una nuova serie di occhi vede le cose sotto una luce diversa.
Potresti scoprire che un determinato meccanico, anche se apparentemente brillante sulla carta, è noioso o frustrante una volta implementato.
Inoltre, i giochi che vengono rilasciati presto e continuano a essere sviluppati sono quelli che ottengono la maggiore visibilità. Generi più informazioni "degne di nota". Costruisci buzz. Attrai seguaci. Puoi convincere la gente a testare il tuo gioco e acquisire preziose conoscenze che influenzeranno i tuoi progetti.
I giocatori potrebbero offrire critiche o complimenti che ti sorprendono. Le caratteristiche che pensavi fossero importanti potrebbero essere soddisfatte con disinteresse, mentre quelle che ritenevi non importanti potrebbero rivelarsi le preferite di tutti. È importante vedere come il pubblico reagisce al tuo gioco e reagire di conseguenza. Questo ti fa risparmiare tempo e angoscia. Ti dà la direzione per le versioni future. Ancora più importante, vi darà nuovi fan, seguaci e una meritata pacca sulla spalla.
Inoltre, la consapevolezza che qualcuno là fuori ha giocato e apprezzato il tuo gioco è d'oro.
Ora che ti hanno dato quel tocco in più di motivazione e uno sguardo alla mia metodologia gamedev personale, ti incoraggio a scendere da Internet e ad immergerti. Pianificare o ricercare per troppo tempo può essere un'energia e una perdita di tempo. A volte tutto ciò che devi davvero fare è creare una nuova cartella, creare un progetto vuoto e iniziare la codifica. Accendi i tuoi motori di gioco e colpisci i postbruciatori.
Se segui questa filosofia di base dello sviluppo del gioco sono fiducioso che raccoglierai molti premi. Il più fondamentale sarà lo stress inferiore. Più divertimento del processo, build più tangibili e giocabili, e più possibilità di ottenere feedback da parte dei giocatori sono anche il vantaggio di questo sistema di salvataggio. Infine, tagliando i progetti in piccole sezioni discrete, sarai sicuro di poter pubblicare un nuovo gioco ogni mese di quest'anno.
Se sei pronto per questo tipo di sfida, ti invito caldamente ad unirti a OneGameAMonth, una sfida di gamedev che è stata accettata da oltre tremila giochi indie proprio come te.
OneGameAMonth è gamedev con aggiunta di gamification: guadagni punti esperienza, livelli e premi per realizzare giochi. Si arriva a connettersi con una comunità molto attiva e attiva di coetanei che è di supporto, di aiuto e di accoglienza. Centinaia di giochi di ogni genere sono stati pubblicati lì adesso. Unisciti a noi!
Buona fortuna con i tuoi futuri progetti di gamedev. Puoi farlo.
Accentsconagua