Pratiche per navigare nell'incertezza nella progettazione del software

2

Sfondo:

Quindi sto cercando di creare il mio primo motore di gioco per scopi di apprendimento. Dopo aver consultato alcuni articoli, sono riuscito a progettare le parti iniziali del mio motore almeno per farmi andare avanti. Il mio progetto finora ha il mio livello "Framework" per il quale tutti gli altri sottosistemi di livello superiore (grafica, input, audio, ecc.) Useranno. Ciò aiuterà la portabilità del codice e mi consentirà di modificare il codice di implementazione sottostante senza dover modificare l'intero codice base (solo il mio codice framework). Questa struttura ha fornito abbastanza di un quadro mentale per farmi andare avanti. Tuttavia, dopo aver programmato alcune cose e aver ottenuto un triangolo sullo schermo e spostato tramite l'input da tastiera, trovo difficile decidere come strutturare ulteriormente i miei diversi sottosistemi (grafica, input, audio, ecc.). Voglio avere un progetto in atto per consentire la comunicazione tra i sottosistemi con il minor numero di sistemi possibile.

Problema:

Il mio problema principale è che trovo difficile progettare ulteriormente il mio motore poiché non so davvero dove andare dopo. Immagino che questo sia un problema tipico per qualsiasi sviluppatore che sta sviluppando qualcosa di nuovo o sconosciuto. Ad esempio, non so veramente quale tipo di funzioni avrò bisogno o chi userà queste funzioni per il mio sistema grafico. I singoli oggetti saranno responsabili del disegno di se stessi? La finestra gestisce la grafica dei disegni? Con l'esperienza precedente, avrei un'idea migliore di queste cose e potrei progettare il mio software di conseguenza ma a questo punto non ne ho.

La mia domanda:

La mia domanda è quali sono alcuni processi di pensiero o pratiche di sviluppo che ti aiutano a provare e ad architettare un codice per il quale non sei sicuro di dove devi andare dopo? Capisco che questo possa essere un argomento importante, quindi cerco solo suggerimenti rapidi per farmi pensare a diverse tecniche possibili. Ho già alcune idee qui sotto, ma volevo ottenere più pensieri dalla comunità.

I miei pensieri su alcune possibili soluzioni:

  1. Disegna alcuni diagrammi per avere un'idea di come le cose andranno a finire: Dopo aver elaborato un'idea progettuale, disegna alcuni diagrammi di classe con le loro interazioni mappate. Questi diagrammi possono aiutarti a individuare eventuali limitazioni nella tua idea di progetto rapidamente e senza alcun codice. Tuttavia, potrebbe essere necessario creare molti diagrammi prima che le limitazioni con l'idea diventino evidenti

  2. Inizia a sperimentare la tua idea nel tuo codice: con un sistema di controllo delle versioni puoi semplicemente diramare il tuo codice base e iniziare a sperimentare con la tua idea. Ciò ti aiuterà a dare un feedback immediato con i limiti del tuo progetto, poiché qualsiasi duplicazione del codice o problemi di compilazione sarà immediatamente evidente dopo l'implementazione. Tuttavia, questo richiederà più tempo e può essere più difficile vedere l'immagine più grande e le ramificazioni del tuo approccio progettuale.

  3. Ripristino di schemi di progettazione consolidati: basta individuare i principali problemi che il sistema deve risolvere e applicare un modello di progettazione corrispondente per risolverlo. Ci sono un sacco di schemi di progettazione comprovati che hanno aiutato a risolvere i problemi per decenni. Puoi semplicemente impostare questi pattern in modo predefinito quando non sai veramente dove andare e chiedi loro di portare avanti il tuo progetto. I problemi qui sono che ci sono così tanti modelli diversi là fuori per problemi diversi che può essere difficile decidere esattamente quale risolvere meglio il tuo problema. Inoltre, l'impostazione predefinita di un modello di progettazione può guidare l'architettura del sistema in una direzione che non si desidera particolarmente andare, ma non la noterà più avanti nel processo.

  4. Qualsiasi altro pensiero ??????

posta Jason 29.12.2016 - 01:49
fonte

1 risposta

8

Non architetti il tuo "quadro".

Puoi utilizzare molte tecniche diverse per determinare che cosa vuoi che il tuo gioco faccia. Quindi inizi a farlo. Mentre procedete decidete se un metodo (o unità di logica) appartiene o meno al framework.

Ad esempio, non dovresti cercare di capire come salvare i formati di file, finché non hai effettivamente una funzione di salvataggio. Quindi puoi guardare i tuoi tipi di dati e vedere cosa hai. Hai solo bisogno di memorizzare le stringhe, quindi un file di testo con le stringhe potrebbe funzionare. Stai cercando di memorizzare i dati binari, quindi dovrebbe essere usata una sorta di libreria di marshalling / codifica.

Lascia i diagrammi delle classi e la pianificazione UML a piccoli segmenti se non del tutto. Non è necessario reinventare la ruota. Ogni lingua che posso pensare ha una sorta di "salva questo blob di dati sul disco rigido".

Il punto è, il tuo all'inizio del gioco. Sai che vuoi che sia a schermo intero. Quindi scrivi i metodi che aprono una finestra in modalità a schermo intero. Quindi sai che vuoi visualizzare un video introduttivo. Quindi scrivi alcuni metodi per visualizzare un video introduttivo. Quindi si desidera una "schermata iniziale", quindi scrivere alcuni metodi per visualizzare una schermata iniziale.

Quindi metti in pausa. dai un'occhiata a ciò che hai scritto. Ci sono alcune classi che potrebbero essere ripulite. Ci sono alcuni metodi che potrebbero essere refactored. Ok, refactoring via.

Quindi, sai che vuoi che il menu diventi "bloop" quando vai alla prossima opzione, quindi scrivi il codice bloop. Non ti preoccupare molto del fatto che piuttosto "bloop" deve usare il metodo sonoro del tuo "framework". Basta fare in modo che la cosa peggiori. Successivamente, refactoring, e noti che "bloop" e "swoosh" sono molto vicini e potrebbero essere uniti in un metodo makeSound.

Infine, non aver paura di usare le librerie. Ad esempio, vai avanti e usa il lettore video lampeggiante per il tuo video introduttivo. È meglio dover scrivere tutto da zero. Dai un'occhiata a Unità o offerte simili.

Se stai provando a fare il prossimo Unity, allora costruisci un gioco ed estrai il tuo motore da esso.

    
risposta data 29.12.2016 - 03:21
fonte