Nel caso d'uso è necessario effettuare tutte le attività che l'utente può fare. E poi nel diagramma delle attività ho bisogno di spiegare i casi d'uso, mostra i passi che gestisce.
Ma se è tutto corretto, dove devo mostrare i nemici? Come: Genera path, walk, etc ... Poiché non è controllato dal giocatore, il giocatore non ha quasi nessuna influenza sul nemico.
Mi scuso se questo ti deruba un po '(e porta a qualsiasi confusione), ma il mio suggerimento non è preoccuparsi di UML formale (o di qualsiasi altro strumento di modellazione). Metti insieme qualcosa che ha senso per te, ti permette di cogliere presto i problemi di architettura e ti consente di trasmettere le tue idee agli altri. Naturalmente, è una buona cosa seguire alcuni parvenze di uno strumento di modellazione conosciuto, ma non è la fine del mondo se la tua intera architettura è disegnata a pastello su un tovagliolo (okay, quindi è un po ' di un'esagerazione;)).
Uno dei punti principali dell'utilizzo di questi strumenti è fallire velocemente e fallire a poco (è molto meglio cogliere i problemi di logica / architettura in anticipo e in anticipo piuttosto che quando si è al ginocchio in un codice che richiede una quantità enorme di tempo di refactoring). Se passi più tempo a cercare di capire come dovresti usare questi strumenti invece di svuotare la tua logica, mi sembra un po 'sospetto;)
In oltre dieci anni di esperienza professionale con molte persone molto più intelligenti di me, devo ancora incontrare qualcuno che possa ricordare l'elemento sintattico di UML durante la lavagna (o se lo fa, a chi importa abbastanza da usarlo).
Basta andare a fare le cose. Non preoccuparti tanto dei dettagli formali.
Sono d'accordo con @Demian Brecht.
It is really important to not get caught up in semantics.
What is really important is that you flesh out any design snags that you have yet to encounter.
In altre parole:
Il valore di UML non è solo quello di scrivere un modello preciso in modo che il mondo possa capire il tuo design, ma è uno strumento, in modo che ... puoi capire il tuo design, quindi condividerlo con i tuoi colleghi.
Quindi continua a disegnare. Poni le domande: "Rappresenta esattamente lo stato attuale o lo stato futuro?", "Stiamo lasciando fuori qualcosa?", "Questo supera il test di praticità?".
Con la pratica, è possibile immaginare i diagrammi prima di comprendere appieno il motivo per cui rappresentano gli ordini superiori di complessità. Confrontare qualsiasi diagramma con la realtà può quindi rivelare sviste o ottimizzazioni inattese (frutto nascosto).
In tutti i casi: non importa se la freccia ha un piede di gallina che punta nella direzione giusta oppure no. Ciò che conta è che tu stia estendendo il design attraverso un processo visivo, così come quegli aspetti della sfida del design non sono nascosti alla tua consapevolezza in fase di sviluppo (bomba a tempo).
Per rispondere direttamente alla tua domanda su Activity Diagram: Quello che devi fare è trovare un modo per rendere il tuo diagramma di attività significativo. Se non riesci a vedere un modo per adattare i nemici al prototipo UML che stai guardando, considera come può essere regolato in modo che possano adattarsi. Non sentirti limitato dalla tradizione. L'obiettivo è visualizzare il disegno dei nemici sulla carta.
If it is meaningful, it is valuable - and can be re-used later. If it is meaningless, it is not valuable - ever.
Quindi metti solo quello che sai e inizia ad aggiungerlo. Quando ti rendi conto che qualcosa viene lasciato fuori, scopri come incorporarlo visivamente nel tuo diagramma. Questo ti porterà in nuovi regni di consapevolezza del tuo design che non hai originariamente concepito. Trovare questa consapevolezza è il punto di migliorare i tuoi disegni. Solo allora finisci il diagramma in un modo standard che gli altri possano capire. Solo allora, viene applicato l'aspetto unificato della modellazione. Nel frattempo, spetta a te scoprire ciò che è sconosciuto attraverso il diagramma iterativo.
Spero che ti aiuti.
Solo dagli esempi di coppia che hai fornito (in particolare "genera percorso"), penso che tu stia cercando di definire i tuoi casi d'uso a un livello troppo basso. Le azioni del nemico in un caso d'uso potrebbero essere attacco, inseguimento, ricerca, stand ma "generare percorso" è troppo basso di livello. Inoltre, sta descrivendo "come" e non "cosa" che è anche una cattiva idea IMO. Se usi casi di utilizzo a un livello così basso non verrai mai eseguito.
Torna alla domanda originale .... come mostrare i nemici? Normalmente identificheresti l'evento che innesca i casi d'uso. Potrebbe essere un timer, potrebbe essere il giocatore che si trova a distanza di distanza. È possibile dichiarare il sistema o il timer o qualsiasi altro trigger come attore se ha senso. È persino valido dichiarare il nemico come attore. vale a dire. Il nemico rileva il giocatore e lo fa .... Non devi necessariamente specificare in che modo il nemico individua il giocatore (solo che l'evento si verifica). Ti preoccupi del come nell'implementazione.
Leggi altre domande sui tag game-development uml