Con appena il tempo a nostra disposizione per completare i giochi che creiamo, come puoi trovare un buon equilibrio tra una solida architettura software e fare buoni progressi per fare tutto?
La mia sfida personale: che ne dici di essere efficace oggi e pensare a lungo termine allo stesso tempo? Inoltre, mentre lo stai facendo, potresti voler imparare nuove cose sulla strada invece di ricorrere agli stessi schemi ripetitivi che hai usato negli ultimi 5 anni?
Risposte:
Meno esperienza hai, più tempo perdi con il design frontale. Fare buoni progetti è qualcosa che imparerai facendolo e poi vedendo / valutando come risulta. Alcune decisioni hanno implicazioni di vasta portata ma oscure. Dopo alcuni giochi probabilmente sarai in grado di rendere il progetto iniziale abbastanza solido e ti ripagherà investendo ancora un po 'di tempo in questa fase.
Il mio motto: fare le cose in primo luogo, ma usare il buon senso per rilevare quali componenti sono più critici di altri e progettarli abbastanza bene, entro il limite di tempo. Ad esempio, se l'IA è fondamentale per il tuo gioco, assicurati di poterlo estendere / modificare facilmente in un secondo momento. Oppure, se hai intenzione di scrivere un componente che utilizzerai in ogni gioco, progettalo per la riusabilità. Tieni traccia del tuo tempo e non scatenarti nella progettazione. Stabilisci una scadenza per il design e, successivamente, inizia a modificare tutto per ottenere la scadenza per il rilascio. Ma assicurati di annotare quali punti necessitano di refactoring / riprogettazione in seguito e calcola in un po 'di tempo prima di iniziare il gioco successivo per migliorare quelle cose, in modo che non possano morderti!
Un buon consiglio: se devi scegliere tra due opzioni, non soffermarti troppo sui dettagli. Molto spesso, non esiste "buono" o "cattivo". In alcune situazioni, A sarà migliore, in alcune, B sarà, e nel complesso, la differenza tra entrambi potrebbe non valere sempre la pena.
C'è molta esperienza da guadagnare nella progettazione di software o giochi, quindi assicurati di dedicare un po 'del tuo tempo alla ricerca (ad esempio, leggere un libro sul design, leggere l'esperienza di altri, parlare con gli altri programmatori dei tuoi progetti, ecc ... ).
Le persone sono terribili nel predire il futuro. Ciò è particolarmente vero per i giochi, in cui i requisiti possono cambiare su base giornaliera.
C'è un principio chiamato YAGNI , noto anche come "Non ne avrai bisogno", che sostanzialmente dice che non dovresti implementare qualcosa finché non sai che ne avrai bisogno.
Ho visto così tanti sistemi impantanarsi con rigidità architettonica che in realtà non ne usava nulla dato che le funzionalità che le persone pensavano che avrebbero avuto bisogno non sarebbero mai state utilizzate per essere utilizzate.
La mia filosofia personale è fare la cosa più semplice che potrebbe eventualmente funzionare . Detto questo, c'è una differenza tra Getting It Done e Hacking Shit Together. Scrivere codice con uno scopo non dovrebbe implicare fare cose che generano "odori di codice" come rendere tutto pubblico, avere classi blob che fanno tutto, o una qualsiasi di quelle dozzine di altre cose che significano codice "cattivo".
Questo è vero nella mia mentalità oggi:
Sono amico del software di prototipazione rapida. Soprattutto durante lo sviluppo del gioco. È utile per l'apprendimento rapido, i test e l'uso delle cose. Per vicino alla programmazione hardware o algoritmi complicati è il metodo migliore per me.
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();La mia versione di Rapid Prototype deve avere una crosta prototipo adeguata:
vantaggi:
Se lo fai bene, puoi avere una vera versione di debug / apprendimento del tuo prodotto alla fine.
Lo stiamo usando nel nostro progetto e ne siamo felici.
Dai un'occhiata allo sviluppo software agile . Sebbene non sia un proiettile d'argento, mira a fare entrambe le cose (farlo e avere una solida progettazione software).