Pianificazione del gioco e progettazione del software? Sento che UML non è conveniente

Nella mia università, sottolineano e promuovono sempre il design e le cose di UML, in cui sento che non funzionerà bene con il design della struttura di gioco. Ora, voglio solo un consiglio professionale su come dovrei iniziare a progettare il mio gioco? La storia è che ho una certa abilità nella programmazione e ho fatto molti giochi minori come far funzionare in qualche modo qualche platform 2D. I problemi che ho riscontrato sul mio programma sono il design di scarsa qualità. Dopo aver programmato per un po ', le cose iniziano a guastarsi a causa di una cattiva pianificazione (quando aggiungo una nuova funzionalità, tende a farmi dover ricodificare l'intero programma). Tuttavia, pianificare tutto senza un singolo difetto di progettazione è un po 'troppo ideale. Pertanto, qualche consiglio su come devo pianificare il mio gioco? Come dovrei inserirlo in immagini visibili, in modo che io e i miei amici siamo in grado di dare una panoramica dei disegni?

Ho programmato di iniziare a scrivere un gioco con il mio amico. Questo sarà il mio primo lavoro di squadra, quindi ogni consiglio professionale sarebbe un piacere. Esistono alternative all'UML?

Un'altra domanda è come appare normalmente la "prototipazione"?

Voglio solo un consiglio professionale su come dovrei iniziare a progettare il mio gioco?

Il design del gioco è la specifica del gameplay, delle risorse, dei sistemi di punteggio, ecc. Questi non sono specifici del software. Come tale, UML è lo strumento sbagliato per quell'attività.

Quando si tratta di progettare il codice per implementare questi sistemi, UML è un buon strumento per l'attività, fornendo al team la conoscenza e attenersi ai tipi di diagramma più comuni. Normalmente, quando si tenta di progettare una funzione, si saprà se è necessario utilizzare una descrizione o un diagramma. Se hai bisogno di usare un diagramma, UML ti offre un modo standard di disegnarlo, il che è una buona cosa.

Dopo aver programmato per un po ', le cose iniziano a guastarsi a causa di una cattiva pianificazione (quando aggiungo una nuova funzionalità, tende a farmi dover ricodificare l'intero programma).

Questo è generalmente un problema con il modo in cui programmi, piuttosto che con il modo in cui pianifichi. Un buon software di solito è facile da estendere e riutilizzare. Se segui le buone pratiche di programmazione, questo problema diminuirà. Ma una migliore pianificazione aiuterà anche, e non hai bisogno di diagrammi complessi per questo. Avere un elenco di funzionalità significa che quando si codifica una cosa, si hanno in mente le altre funzioni e si possono considerare come codice.

Pertanto, qualche consiglio su come devo pianificare il mio gioco? Come dovrei inserirlo in immagini visibili, in modo che io e i miei amici siamo in grado di dare una panoramica dei disegni?

Sembra che tu stia mescolando 2 problemi qui, il design del gioco e il design del codice.

Suggerisco innanzitutto di scrivere un design di gioco di base, specificando le caratteristiche di cui hai bisogno, la grafica e i suoni di cui hai bisogno, come il gioco è vinto e perso, ecc. Cerca "documenti di progettazione" se hai bisogno di aiuto lì.

Da lì, avrai un'idea delle funzionalità che devi codificare. Puoi guardare ciascuna funzionalità a sua volta e provare a pensare a come implementarle. I diagrammi possono aiutare a mostrare le relazioni tra le diverse classi e oggetti nel tuo gioco, ma l'abilità di sapere quali oggetti devono esistere è qualcosa che devi imparare attraverso la pratica e / o ulteriori letture.

Inoltre, prova a lavorare su progetti più piccoli e meno ambiziosi. Questo ti abituerà a scrivere un buon codice funzionante, senza bisogno di una pianificazione o riscrittura approfondite.

Non capire qualcosa rende facile respingere. UML è uno strumento di ingegneria utilizzato per comunicare le idee che hai in modo strutturato. Un gioco è un sistema che può essere progettato come un altro. Semmai, la complessità e il dinamismo di un gioco rendono inestimabile una rappresentazione visiva delle sue parti e delle loro interazioni.

I diagrammi UML sono diverse viste di un modello del sistema in discussione. Comincio con casi d'uso per una persona seduta davanti al mio programma e avviandolo. Nel caso di un gioco ci sono due tipi di utenti: designer e giocatori. Scrivo un caso d'uso per ciascuna delle cose che posso vederle fare. Quindi realizzo alcune carte CRC per capire quali servizi devo fornire. Quindi faccio un diagramma di classe per le interfacce che forniranno questi servizi e le loro relazioni. Questo si basa sulle schede CRC. Poi arrivano diagrammi dinamici per eventi come l'inizializzazione che richiedono pianificazione e orchestrazione. Quindi diagrammi statici più dettagliati che mostrano le classi che implementano le interfacce.

Nel frattempo sto scrivendo codice e prototipazione e lo sto evolvendo nella direzione di fornire i servizi di supporto per soddisfare i requisiti del mio gioco. Non viene creato nulla che non supporti l'utente attraverso i casi d'uso. Scrivo alcuni elementi del diagramma inutili, ma tra la codifica dell'interfaccia e il diagramma scrivo pochissimo codice inutile. Il diagramma mi dà la certezza di comprendere il modo in cui la classe che sto scrivendo si adatta all'intero sistema.

Il punto che sto cercando di sottolineare è che un programma banale può essere scritto senza piani, ma un gioco è tutt'altro che banale. Qualche tempo fa, quando OOP era nuovo, ci furono molte sperimentazioni e alcune buone pratiche vennero alla ribalta. La comunità di sviluppo software ha convenuto che avevamo bisogno di una lingua per scrivere e analizzare i progetti software. UML è il linguaggio che abbiamo sviluppato. Lo sappiamo tutti e lo capiamo, quindi se vuoi usare le soluzioni di altre persone ai tuoi problemi (libri, discussioni online, articoli, cataloghi di schemi, ecc.) E non reinventare la ruota, devi imparare a leggere la notazione standard. Come bonus, quando ti forzi a pensare al tuo sistema in un'altra lingua, impari cose inaspettate.

Esistono molte metodologie diverse, ma tutte identificano il problema e descrivono una soluzione in modo sistematico. Questo è ingegneria. UML è enorme e complesso, ma nessun modello utilizza ogni costrutto. È come un coltellino svizzero. Devi conoscerlo e capire come usarlo per supportare il tuo processo di ingegneria. L'importante non è quale processo o metodologia, ma che tu ne abbia uno. Altrimenti affogherai nella complessità.

Sto anche lavorando ad alcuni progetti di gioco indipendenti con un amico (team di 2 persone). Come qualcuno in una situazione simile alla tua, posso offrire alcune cose che ho trovato utili.

1. Se le tue idee sono difficili, prova a implementarle una alla volta in progetti di prototipazione super piccoli. Ad esempio, sto realizzando un gioco con piattaforma 2D e ottenere il salto del giocatore giusto è estremamente importante per me. Quindi, ho realizzato un nuovo progetto in cui le uniche 2 cose che accadono sono a) Disegnare il giocatore sullo schermo eb) Rilevare l'input e ridisegnare il salto [il personaggio non può nemmeno muoversi a sinistra oa destra]
2. Alcune persone potrebbero disapprovare questo consiglio, ma prima pensa a scrivere il manuale del gioco (per spiegare concetti, controlli, obiettivi). Questo può fare 2 cose per te: generare un documento molto necessario, ma anche delineare i sottosistemi del tuo gioco e tutti i dettagli necessari per il giocatore. Se sai in anticipo cosa deve sapere il giocatore, allora sai in anticipo cosa devi fare.
3. Scrivi il codice in blocchi abbastanza piccoli (detti anche modularizzati ) in modo che i pezzi fattorizzati possano essere spostati o meglio organizzati senza avere la sensazione di provare a rimuovere tutti i pezzi di spaghetti di medie dimensioni da un piatto di pasta.

Spero che tu abbia trovato almeno un'informazione utile e buona fortuna!

Penso che ci siano alcuni oggetti da asporto preziosi da UML che non puoi negare. d'altra parte, tieni presente che UML è stato creato per i processi aziendali , sai, modellando sistemi che hanno un sacco di persone che interagiscono con esso, il tutto con diversi desideri, bisogni e desideri. UML cerca di assicurarsi di non lasciare nulla fuori o di essere sopraffatto dai dettagli.

UML è "un modo standard per visualizzare l'architettura di un sistema"

UML descrive

• attività
• attori
• processi di business
• schemi di database
• componenti (logici)
• dichiarazioni del linguaggio di programmazione
• componenti software riutilizzabili

Ma se stai realizzando un gioco semplice, devi davvero modellare tutto questo?

• Attori: il giocatore.

Quanto aiuta?

Modellare alcune delle altre cose, tuttavia, è molto utile. Ad esempio, se stai realizzando un piccolo MMO, vuoi sicuramente schemi di basi di dati ben progettati.

Quindi, mentre i take away di UML sono eccellenti (sapere cosa stai facendo, annotare i requisiti e disegnare diagrammi di diagrammi di flusso ovunque sia necessario), e elementi di esso sono molto utili, tendo a ritenere che l'intero processo UML sia un po 'di un foro rotondo con piolo quadrato per i giochi.

UML non è una cosa, è una raccolta di cose che alcune hanno un valore, altre non così tanto. lo stile precedente utilizza Casi (almeno quelli che chiamiamo casi d'uso) che dichiarano

• nome
• requisiti
• precondizioni
• trigger
• Azioni
• azioni alternative
• eccezioni

può essere abbastanza utile. sebbene ciò che trovi per "Usa casi" se fai una ricerca sul web (le immagini) sono più per software generale.

Darei anche un po 'di credito al diagramma di classe. questo dimostra che sei in grado di mostrare la relazione tra tutti i tuoi oggetti e che conosci il layout della tua architettura.

ciò che ne consegue è che il tuo set di funzionalità dovrebbe essere pianificato e bloccato int (assegnato in una necessità / configurazione) prima della modellazione e persino l'avvio del diagramma. questi dovrebbero essere tutti nel tuo Breve / Trattamento / Script (a volte indicato come intonazione, documento di caratteristiche e storia). poi da lì faresti il ​​tuo materiale tecnico che ha i tuoi modelli e diagrammi.

ci sono aziende che usano UML, ma di solito sono aziende che hanno team di progettazione e implementazione separati. le aziende che creeranno tutta la loro documentazione e la consegneranno a un team di scimmie-codice per creare un prototipo / alfa. si dice che se riesci a modellare il tuo gioco con precisione dovresti essere in grado di darlo a una squadra completamente diversa e fargli programmarlo anche se questo è più un sogno irrealizzabile che un'accuratezza.

Ti insegneranno UML nella tua università per aiutarti a comunicare le tue idee con il resto del tuo team e mostreranno ai docenti che hai una buona conoscenza pratica dei principi di base dell'ingegneria del software.

Come ogni discussione sul linguaggio, sugli strumenti o sul design, di solito dipende da come lo usi. Scegli lo strumento / la lingua / il design migliore per il lavoro e fai il backup della tua scelta con una forte motivazione. Devo ammettere che UML non è così flessibile per la produzione di giochi, anche se posso dire che l'abbiamo usato in modo efficace per modellare le funzionalità del motore come comunicazioni e tempistiche di rete, gestione delle attività parallele e casi d'uso. Non c'è niente di peggio che spiegare la stessa cosa a 5 diversi membri del team 10 volte diverse perché non riescono a capirlo. Ecco la documentazione, leggila.

A seconda di quanto siano solidi i tuoi progetti e di quanto sia disciplinato il tuo team, può essere abbastanza produttivo essere in grado di modellare i tuoi costrutti attorno a quelli che non sono ancora stati ancora avviati, e tuttavia sapere esattamente come funzioneranno a causa del documentazione.

Nonostante ciò, probabilmente sentirai (e realizzerai duramente) che si tratta di DOCUMENTI VIVENTI e, a meno che non vengano rivisti e aggiornati regolarmente, diventeranno rapidamente obsoleti ed effettivamente inutili.