Quanto è corretto questo piccolo design di gioco senza rimuovere il suo schema di progettazione?

Question

Quanto è corretto questo piccolo design di gioco senza rimuovere il suo schema di progettazione?

#1 da (6 voti)
#2 da (4 voti)
#3 da (2 voti)

2

Given è un design di un videogioco in cui un giocatore ha diverse possibilità di adattare il suo personaggio:

I game designer hanno capito che è insensato essere un elemento elementale di fuoco e acqua allo stesso tempo. È possibile creare un personaggio del genere con il design attuale? Se sì, è possibile evitarlo senza rimuovere / distruggere il modello attuale di progettazione? O forse non funzionerà affatto?

Penso che sia possibile creare un personaggio che sia fire-elemental e water-elemental allo stesso tempo senza rimuovere il suo pattern perché se lo vedo correttamente qui abbiamo solo il pattern di progettazione 'composite'.

Ma non sono sicuro di come dovrebbe essere cambiato perché la parola insensata di cui sopra mi confonde, vuol dire che non è necessario essere un elemento elementale di fuoco e acqua allo stesso tempo perché entrambi sprecano mana come risorsa d'attacco? O è piuttosto che è illogico e quindi dovrebbe essere impedito di essere un elementale di fuoco e acqua contemporaneamente? Forse lo sai meglio perché questo mi confonde molto? : /

object-oriented design design-patterns object-oriented-design

posta kathelk 01.12.2018 - 19:07

fonte

3 risposte

Leggi altre domande sui tag object-oriented design design-patterns object-oriented-design

Memorizza la password nel progetto open source Test di unità e realtà [chiuso]

score 6 · Answer 1

La struttura del tuo programma interno dovrebbe non riflettere le regole del tuo gioco. Dovrebbero riflettere come funziona il tuo programma.

Le regole del tuo gioco dovrebbero essere codificate altrove, probabilmente nei file di dati.

Perché? Perché le tue regole di gioco non sono conformi alla logica di programmazione. Mentre all'inizio sembra semplice, più diventa complesso meno felice sarà il fatto che tu abbia associato la logica di gioco e la logica del programma insieme.

Esempio: hai una classe Character . Wizard e Warrior derivano da quello. Un personaggio può brandire un IWeapon . Ma i guerrieri possono impugnare qualsiasi arma, solo maghi Dagger s. Whoops, ha violato il principio di sostituzione di Liskov proprio lì e tu sei solo alla regola n. 2 di un gioco molto complesso.

Lettura obbligatoria su questo argomento: Wizards and Warriors (tutti e cinque parti).

score 4 · Answer 2

Questo diagramma, assumendo UML, mostra sia l'aggregazione che la generalizzazione / specializzazione.

Con la generalizzazione / specializzazione, si dice che ciascuno di Sinceratore, Elementale di Fuoco, Elementale di Acqua e berserker sono specializzazioni di una nozione più generale di carattere. Questa è la relazione "è-a": un incantatore è un personaggio e così via anche per gli altri.

Inoltre, si afferma che ogni tipo di personaggio si aggrega con ciascun carattere di Sinceratore, personaggio elementale di fuoco, personaggio elementale di acqua e personaggio di berserker.

È quasi come se ci fosse un gruppo di personaggi, una squadra, se stanno lavorando insieme, o un gruppo di avversari se stanno lavorando contro.

Questo potrebbe essere esattamente ciò che è inteso dal particolare gioco; tuttavia, senza sapere altro, sono sospettoso. L'aggregazione è insolitamente specifica: la semplice aggregazione di un personaggio con carattere avrebbe permesso la creazione di una squadra. (Per non parlare di una squadra o di una serie di avversari potrebbero essere creati anche altri modi.)

Is it possible to create such a character (fire-elemental & water-elemental) with the current design?

Se il linguaggio di programmazione ha ereditarietà multipla, e le classi non sono definitive, un programmatore può aggiungere una classe che specializza sia il carattere elementale di fuoco che il carattere elementare dell'acqua, questa nuova classe consentirebbe a una singola istanza di essere sia una carattere elementale di fuoco e un carattere elementale di acqua.

Se stai chiedendo se è possibile avere un carattere elementale di fuoco e un carattere elementare dell'acqua in aggregazione tra loro, allora sì questo è permesso dal diagramma.

Se stai pensando che l'elementale del fuoco e l'elementale dell'acqua sono in qualche modo meramente attributi, proprietà o qualità di carattere che possono essere aggregati, non lo sono: sono ognuno il loro (tipo di) carattere .

score 2 · Answer 3

Berserk, stregone, elementale del fuoco e elementale dell'acqua sono troppo specifici.

In effetti, un Mage , MagicEntity e Warrior sarebbero molto più facili da riutilizzare. Inoltre, ha molto senso usare questo modello, in quanto potresti essere un guerriero, un mago e un elementale (ed essere un po 'sopraffatto!). Questo è il motivo per cui essere un elementale del fuoco e un elementale dell'acqua è insensato, perché alla fine il personaggio è solo un elementale, quindi non acquisisce più potere.

Inoltre, l'attacco ha l'aspetto di un'azione che fa qualcosa, ma sta semplicemente cambiando lo stato dell'oggetto corrente che sta ingannando. Non dovrebbe accettare un parametro Character per attaccarlo? Come ora, sembra molto più simile a un metodo getAttackPoints .