Modelli architettonici per un gioco

Naviga le tue risposte
4

Quindi ho una soluzione che contiene alcuni grandi progetti, che sto cercando di suddividere in progetti più piccoli con responsabilità più isolate. Questo è un gioco con cui sto armeggiando - Sono principalmente uno sviluppatore LOB e penso che i principi siano universali, quindi spero di imparare qualcosa qui.

Le dipendenze di alcuni oggetti sono un po 'troppo strettamente intrecciate, e spero in qualche aiuto su come districarle. O forse una sorta di pattern o astrazione che potrebbe renderli più gestibili.

Ares.Core.World contiene classi come Creature, Elementi, ecc. Tutte ereditano dall'Entità, che è a conoscenza di quale cella sulla mappa esiste. Ciò si ottiene tenendo un riferimento ad Ares.Core.UI.MapControls.MapCell ... E puoi vedere che i fili si stanno già incrociando.

Ares.Core.UI.MapControls contiene Map e MapCell, ognuno dei quali contiene elenchi di creature e oggetti che essi contengono. MapCell eredita anche da Ares.Core.World.Entity dal momento che ha risolto alcuni problemi iniziali in modo molto elegante - ad esempio, tutte le Entità hanno inventario.

Mi piacerebbe trovare un modo per dividere l'interfaccia utente e il mondo in progetti separati ( Ares.World e Ares.UI ) dal momento che l'interfaccia utente e il mondo globale dovrebbero probabilmente essere preoccupazioni separate. Ma come puoi vedere, il modo in cui ora i due progetti dovrebbero fare riferimento l'un l'altro, e i riferimenti circolari non sono consentiti.

Mi chiedo se ci siano schemi architettonici là fuori che potrebbero aiutare in questa situazione. Grazie!

    
posta Brian MacKay 19.05.2011 - 23:29
fonte

3 risposte

1

Penso che lo schema architettonico che stai cercando sia MVC . Attualmente sembra che World sia tutto un modello, ma l'interfaccia utente mischia modello, visualizzazione e controllo.

    
risposta data 20.05.2011 - 15:39
fonte
0

Penso che quello che stai cercando sia iniezione di dipendenza . Esiste anche un modo più disaccoppiato di DI e questo è con un contenitore (es. Dipendenza Contenitore di iniezione o DIC in breve).

    
risposta data 20.05.2011 - 01:38
fonte
0

Perché stai cercando di separare il mondo dai partecipanti?

Derivando la cella e i partecipanti dall'entità, presumo che tu volessi un modello composito per le azioni ad effetto area. È un'applicazione abbastanza buona considerando lo scenario. Detto questo, in teoria si potrebbe avere un progetto di base con la classe entità e gli oggetti Mappa e avere tutte le impostazioni composite delle relazioni. Il progetto figlio può implementare le creature / attori ecc. Che possono dipendere dalla libreria di base del progetto, fornendoti una delineazione minore. Inoltre non sono necessarie dipendenze circolari tra i progetti se si mantengono i riferimenti inversi nella classe Entity stessa. Ma senza una visione approfondita dell'intero progetto, sarebbe difficile consigliare un cambiamento architettonico.

Alcuni progetti sono intrinsecamente grandi - inutile cercare di dividerli, a meno che tu non stia bene con la ripetizione del codice, ecc. Dovresti davvero valutare ciò che otterrai da questo.

    
risposta data 20.05.2011 - 08:54
fonte

Leggi altre domande sui tag

È possibile distribuire script Perl o Python nello stesso modo degli script PHP? Utilizzare un oggetto valore personalizzato o un Guid come identificatore di entità in un sistema distribuito?