Architettura del gioco - collegamento di diverse parti del gioco

In realtà ho scritto una guida di gioco su larga scala che implementa (tra molte altre cose) proprio quelle azioni di cui stai parlando. Il modo in cui ha funzionato è che il gui era completamente separato dalla logica del gioco, quindi in teoria potevi giocare senza il gui, o creare due guis sullo stesso gamelogic. Nessuno ci ha mai provato, ma era teoricamente possibile, e il fatto che fosse possibile rivela una caratteristica importante del design:

The gui must know the gamelogic.

The gamelogic should know absolutely nothing about the gui.

Il modo in cui questo viene realizzato è rendere tutto osservabile in gamelogic e fare in modo che la GUI registri vari osservatori per ricevere notifiche dal gamelogic.

Quindi, quando l'utente fa clic sul pulsante, il pulsante dice alla gamelogic di eseguire l'azione corrispondente.

L'azione fa tutto ciò che deve fare, quindi imposta il proprio time-to-sbloccare al 100%. Poiché lo stato dell'oggetto azione è ora cambiato, emette una notifica in tal senso.

La GUI si è registrata con il gamelogic per ricevere eventi sull'azione, quindi riceve questa notifica, recupera il nuovo stato dell'azione e dipinge il pulsante come completamente disabilitato.

Quindi al prossimo tick (la successiva iterazione del ciclo principale del gioco) l'azione riduce il time-to-sbloccare, diciamo, al 95%, e rilascia un altro evento su quel cambiamento.

Il gui riceve questo evento e ripete il pulsante per mostrarlo parzialmente disabilitato. E così via, e così via.

Come Stephen ha suggerito nel suo commento , puoi usare il pattern Observer per connettere le diverse parti della tua applicazione.

Tuttavia, questo è un approccio piuttosto statico, e dovrai implementare interfacce ovunque e le dipendenze sono ancora forti. Poiché questo è un gioco, la tua struttura, la logica e il gameplay potrebbero cambieranno nel tempo.

Consiglierei di utilizzare un approccio basato sugli eventi. Funziona in modo simile all'Observer, con la differenza che né il mittente né il destinatario si conoscono l'un l'altro (nessuna "notifica" esplicita).

Sparerebbe semplicemente un evento "HealthChanged" e ogni componente interessato agirà di conseguenza. Puoi ottenerlo utilizzando un bus eventi .

Se vuoi rendere il programma davvero disgiunto e flessibile, potresti prendere in considerazione l'utilizzo della meccanica degli eventi insieme a un sistema Entity

È un approccio basato sui componenti: invece di avere un attributo di salute nella classe del giocatore, il giocatore sarebbe definito dai suoi componenti : salute, attacco e posizione (o qualsiasi altra cosa).

Dal momento che non sono sicuro che questo potrebbe essere troppo oneroso per un progetto a tempo libero come il tuo, non entrerò nei dettagli qui. Ma puoi controllare il link qui sopra e maggiori dettagli qui

Obviously I want to separate the UI code from the functionality code.

A mio parere, i giochi sono una categoria in cui è assolutamente da dimenticare abbandonare questo requisito e accoppiare semplicemente la logica di gioco all'interfaccia utente a meno che non si stia mirando al tipo di gioco in cui tale disaccoppiamento è vantaggioso, come uno che potrebbe funzionare in un modo completamente diverso Ambiente GUI con un set di grafica completamente diverso e forse anche un set di controlli completamente diverso.

Detto questo, se vuoi tenerlo disaccoppiato, puoi semplicemente "mappare / associare" il codice GUI a un determinato tipo di abilità, come "StunWidget" a "typeof (StunAbility)", in questo modo:

MapWidget (typeof (StunAbility), StunWidget)

Il widget mappato ottiene automaticamente l'istanza dell'abilità quando è costruita per un determinato tipo di abilità.

Quindi, quando hai selezionato un'unità, puoi scorrere le abilità disponibili usando qualcosa come la riflessione per quell'unità e creare / inserire / visualizzare i controlli della GUI associati (data la sua abilità type come chiave per trovare il tipo di abilità associato widget) per ogni abilità. Quindi il widget diventa responsabile dell'attivazione dell'abilità, bersagliandolo se richiede il targeting, visualizzando il cooldown, ecc., Magari con una visualizzazione a matrice come in Starcraft che mostra cosa puoi fare con l'unità:

Adoro il design a matrice 3x3 per la GUI in Starcraft 1, senza mai presentare più di 9 controlli hotkeyable all'utente. Penso che sia uno dei flussi di lavoro più ottimali per un gioco che consente di selezionare più unità, come un RTS o un gioco di ruolo in cui si hanno più membri del partito che è possibile selezionare singolarmente (compresi i TRPG). Penso che l'efficacia di un tale progetto si manifesti attraverso i giocatori che possono eseguire centinaia di azioni al minuto in un tale flusso di lavoro.