Fatti fare vs Solid Software Design?


17

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:


20

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 ... ).


7
+1, un buon consiglio. Non lasciarti catturare dalla famigerata paralisi dell'analisi, perché questo non ti porta da nessuna parte. Considerando che il refactoring è uno strumento potente per correggere i difetti del passato, quindi non aver paura di sbagliare.
Michael Klement,

1
Ahh. Paralisi dell'analisi . Il mio più grande nemico! Dovrei costruire un gioco in cui Analysis Paralysis viene servito come End-Boss. Comincio meglio progettando prima l'architettura di gioco ... Noooo! Scherzi a parte: ottima risposta e bel commento!
Bummzack,

12

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".


8

Questo è vero nella mia mentalità oggi:

  • Pragmatismo sull'ideologia
  • (1) Fallo funzionare (2) quindi fallo correttamente - game over se dimentichi il passaggio 2
  • Rilascialo!
  • Troppo design iniziale sarà una perdita di tempo
  • TDD e Clean Code portano a progetti software più semplici e più stabili

Puoi approfondire lo sviluppo guidato dai test in un ambiente di gioco? A parte qualche logica di base, non ho mai trovato programmi altamente interattivi adatti a questo tipo di cose. Inoltre, stai collegando alla pagina di chiarimento delle
domande

2
@Ranieri Se si traccia una linea tra le parti che si interfacciano con l'hardware grafico e l'input dell'utente, il test è semplice.
Jonathan Fischoff il

@Ranier Grazie, risolto il collegamento. Sono d'accordo che inventare prima i test per simulazioni interattive o giochi client-server può essere complicato. Oltre ai test delle unità, potresti voler avere alcuni test di funzionalità di livello superiore e possibilmente sessioni di riproduzione che si svolgono a determinati intervalli. In ogni caso, pensare prima ai test probabilmente ripagherà in molti scenari. Trova alcune viste interessanti in gamedev.stackexchange.com/questions/1905/…
jmp97

5

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:

  • Interfaccia di input max amichevole per configurare direttive e impostare variabili o dati.
  • Eccezionali eccezioni e gestione degli errori.
  • Online come la funzione di debug ma a livello di ciò che è necessario.
  • Interfaccia di output max amichevole per mostrare o acquisire risultati in tutti i modi possibili e possibili.

vantaggi:

  • È possibile migliorare la crosta RapidPrototype durante l'intero sviluppo.
  • Puoi vedere e configurare il tuo codice in molti modi.
  • Puoi concentrarti solo sulla teoria e sul problema di ciò che devi risolvere.
  • Puoi sviluppare rapidamente qualsiasi nuova parte del progetto e provarla con il resto delle cose finali.
  • Puoi fornire nuovi elementi da utilizzare più rapidamente nel riempimento dei contenuti e finalizzarli in un secondo momento (specialmente nella custodia sandbox)
  • Puoi facilmente descrivere e mostrare principi o soluzioni a chiunque altro. In linea.
  • Il prototipo funzionale e trasparente è la migliore fonte di informazioni per il codice finale (chiunque altro può farlo).

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.


1
Questo è un buon consiglio, anche se consiglierei un tempo o qualche altro tipo di risorsa legata al loop, dopo di che esci (0) e prova un altro prototipo.

@Joe Wreschnig - I piani orari possono essere inclusi in AnalysingResults (), ma penso che puoi usare RapidPrototype per un po 'e finirlo in seguito o metterlo nei piani. Meglio che rimasi bloccato per sempre :). In RapidPrototype È anche possibile simulare la funzionalità. È utile in molti modi.
samboush,

1

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).


2
Non credo che esista una metodologia di sviluppo che non pretenda di "farlo e avere un solido progettista di software".

@Joe Penso che molte metodologie "pesanti" tendano a preferire il CYA a un software solido. In effetti, gran parte della mia esperienza non agile tende ad essere "non ha bisogno di essere giusta, deve essere proprio ora", mentre "agile" mira a dire "deve essere proprio ora, ma fai tutto ciò che puoi fare cose giuste man mano che procedi. "
dash-tom-bang,

Direi che lo sviluppo agile ha una scarsa influenza sul fatto che il codice sia solido o meno. L'essenza di Agile è di dedicare tutto il tuo tempo di sviluppo solo a cose importanti. Il codice può ancora essere un disastro alla consegna, perché la qualità del codice (o la mancanza di debito tecnico) è raramente una misura del successo in una consegna.
Magnus Wolffelt,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.