Sono circa un migliaio di righe di codice per creare il mio gioco spaziale 2D, che crea reti di sistemi stellari generati casualmente e li popola con una selezione casuale di pianeti, stazioni, navi e armi.

Potrebbero esserci centinaia di diverse stazioni / navi / ecc. Che il gioco dovrà usare - quindi ecco cosa mi chiedevo. Dovrei dedicare del tempo alla creazione di un caricatore di dati "softcoded", che memorizzerebbe tutte queste informazioni in (ad esempio) file XML e sarebbe quindi un po 'più facile da modificare in seguito, o dovrei semplicemente andare con quello che ho sto facendo proprio ora - codificare tutti gli oggetti nel motore principale del gioco.

Sono l'unica persona del progetto e, come ho già detto, è solo una cosa di hobby che sto facendo nel tempo libero lontano dall'università. Ma la comunità consiglierebbe di investire nella creazione di un intero sistema aggiuntivo di archiviazione dei dati in file aggiuntivi?

Quali sono i vantaggi dei dati di softcoding in questo modo, rispetto alla semplice codifica di tutto tramite i costruttori? C'è un vantaggio a lungo termine nell'avere file esterni che possono essere modificati - se non sto cercando il gioco con "mod", è necessario avere file esterni? Se è solo una cosa da hobbista a cui potrei rinunciare in poche settimane o mesi, dovrei perdere tempo su questo?

Sì. È necessario implementare un sistema per caricare contenuti all'esterno del motore principale.

Intestazioni per risposte sintetiche.

No. Non richiede troppo tempo.

Penso che la questione se si tratti di un'assegnazione valida del tuo tempo limitato è controversa; anche se solo per il fatto che sarà una piccola parte del tempo totale del progetto.

Trascorrerai centinaia (migliaia) di ore in un progetto di gioco che completerai. Forse non su un clone di Pong, ma sicuramente per il tuo complesso gioco spaziale. Confrontalo con un lettore di file di configurazione. L'implementazione di un sistema per convogliare XML nel tuo costruttore principale, e successivamente riavviare il processo di gioco, richiederà forse 10 o 20 ore. Anche se impieghi 50 o 100, sarà una piccola frazione del tempo totale del progetto.

Risparmierai tempo

Non è una spesa in termini di tempo; è un investimento di tempo. E pagherà.

Il flusso di lavoro è importante e disporre di un caricatore di configurazione renderà il tuo flusso di lavoro migliore. Creando un sistema che ti consente di modificare le configurazioni al volo, risparmierai innumerevoli ricostruzioni. Puoi guardare il gioco mentre è in esecuzione, modificare XML e ricontrollare in pochi secondi. Oppure puoi guardare il codice, trovare una riga di codice (tra le migliaia), modificarne i valori con estrema attenzione (sei nel tuo motore principale, dopotutto), ricostruire, eseguire, riportare il gioco allo stato di test, provare a ricorda com'era prima della modifica e vedi se la modifica ha avuto l'effetto che volevi. Supponendo che nulla si rompa nel tuo motore, il tuo treno di è sicuramente interrotto.

Da una prospettiva comp-sci più fondamentale, prova a ricordare che la parte più lunga del software di scrittura non sta avendo qualche tasto in più o spazi bianchi. È a caccia di insetti. E se passi un po 'di tempo in più per rendere le cose più chiare scrivendo un codice più dettagliato, risparmierai molto più tempo in seguito. Nel tuo caso, scrivere un importatore di contenuti comporta un codice più pulito che sarà più facile da leggere. Invece di miglia e miglia di valori codificati, la tua sorgente presenterà un semplice caricamento di file. Allo stesso modo, puoi leggere il file di configurazione senza passare attraverso il codice del motore di gioco. Entrambe le parti diventano più gestibili e più facili da eseguire il debug.

Le squadre a un membro ne traggono il massimo beneficio

Se hai assunto un artista per generare parte di quel contenuto, dovrai creare degli strumenti con cui lavorare. Devono apportare modifiche ai pixel e vedere rapidamente gli effetti. Non oseresti costringerli a ricostruire il codice per vedere ogni cambiamento. Il loro tempo è costoso e non vuoi sprecarlo.

Ora immagina che l'artista sia molto abile e lento (artista programmatore) e abbia molte altre cose di cui preoccuparsi perché sono anche il programmatore principale e il musicista. Non vorrai assolutamente perdere tempo, altrimenti il ​​progetto non finirà mai. E quell'artista schifoso odierà l'addestramento per diventare un artista migliore, perché trascorrono tutto il loro tempo a rinominare le stringhe di risorse in codice.

Non farlo da solo. Crea gli strumenti e avrai più tempo per creare un gioco.

Questa è una buona domanda e la migliore risposta che posso dare è che solo l'esperienza può davvero dirti quando è una buona idea prendere la strada che è più difficile / che richiede tempo. Se qualcuno ti dice che dovresti SEMPRE farlo nel modo "corretto", allora hanno semplicemente torto.

Capisci già che è un compromesso. Da un lato, l'hardcoding è così allettante perché è facile e veloce iniziare, ma a lungo andare l'aggiunta di funzionalità e il debug diventeranno da incubo. D'altra parte, scrivere un sistema grande, flessibile ed espandibile richiede un grande investimento iniziale, ma rende la vita molto più facile a lungo termine.

L'obiettivo è quello di finire qualcosa, e se vieni impantanato nel creare un ottimo sistema, l'obiettivo si allontanerà ulteriormente e perderai la motivazione. In alcuni casi le cose con codifica rigida vanno bene, ma devi capire le conseguenze di farlo. Ecco alcuni dei motivi per cui hardcoding è una cattiva idea:

• Potresti pensare che il tuo progetto sia piccolo, ma è possibile che cresca quando decidi di aggiungere più funzionalità. Se inizi il hardcoding, arriverà un momento in cui l'energia necessaria per mantenerlo (aggiornandolo con nuove cose e risolvendo la miriade di inevitabili bug) inizierà a superare seriamente i guadagni iniziali.

• I contenuti hard-coding sono per definizione specifici del progetto corrente. Per il prossimo progetto, dovrai ricominciare da capo, possibilmente ricodificando le cose (perché è quello con cui ti sentirai a tuo agio). Se avessi messo il tempo in un sistema di caricamento decente, potresti saltare quel lavoro e il mal di testa per tutti i progetti futuri.

• Al momento potresti lavorare da solo, ma potrebbe venire un momento in cui desideri coinvolgere qualcun altro nel progetto. Ti prenderai il tempo per spiegare il tuo disgustoso sistema parrocchiale e scrivere la documentazione per questo?

• L'hard-coding comporta spesso la necessità di sapere cosa significano determinati numeri magici o complicate dipendenze di classe. Potresti essere in grado di tenere tutto a mente ora, ma aspetta solo di essere stato lontano dal codice per un po '. Anche con ampi commenti, una struttura mal progettata è un inferno a cui tornare.

Direi che dovresti sentirti libero di scrivere codice solo nei minimi dettagli. Se hai anche la minima idea dell'elemento su cui stai lavorando per essere utilizzato da qualcun altro, crescere molto più grande o essere utilizzato in un altro progetto, allora prenditi il ​​tempo per farlo bene, ora.

D'altra parte, prototipo come un pazzo e codificare certe cose è semplice e veloce e ti lascia libero di concentrarti sulla sperimentazione. Dipende dal tuo stile di lavoro.

Quello di cui stai parlando è una programmazione basata sui dati .

Per i piccoli progetti, potrebbe non valere la pena investire tempo, poiché spesso ci sono caratteristiche molto più importanti che potresti migliorare.

Tuttavia, la programmazione basata sui dati può essere MOLTO facile da implementare. Se sei serio, dovresti probabilmente usare XML, JSON o YAML, ma puoi anche usare file di testo semplice.

Programmazione basata sui dati

Professionisti

1. Consente ai progettisti di accedere e modificare i dati di gioco senza conoscenze di programmazione
2. Puoi apportare modifiche al gioco senza dover ricompilare . Questo non dovrebbe essere sottovalutato, in quanto è possibile sviluppare un gioco molto più rapidamente in questo modo. I buoni giochi arrivano dopo molte iterazioni.

Contro

1. Ci vuole tempo e fatica per implementare.
2. Potrebbe aumentare la complessità del programma.