Entità / Sistema Componente e UI "Entità"


14

Sono ancora ecologico nei sistemi di entità / componenti. Trovo che dal momento che ho componenti utili per disegnare sprite (o spritesheets) e gestire input (clic del mouse / touch), voglio naturalmente riutilizzarli per creare componenti dell'interfaccia utente (come pulsanti, ad es. Schermata di selezione del livello).

Questo mi sembra molto strano. Ho sempre compreso entità come "modelli di gioco" come giocatori, nemici, potenziamenti, ecc. D'altra parte, dal punto di vista del riutilizzo del codice, il riutilizzo dei componenti per l'interfaccia utente ha perfettamente senso.

Come (e dove) i problemi di UI / GUI si adattano a un sistema di entità / componente?

(Nota: questa domanda è indipendente dalla piattaforma poiché si applica a più piattaforme / lingue)


3
Penso che sia logico per te solo perché stai realizzando un gioco 2D. Immagina che avresti creato un gioco 3D (con 2d gui) quasi nessuna logica di rendering poteva essere riutilizzata, e i componenti di 2d gui all'interno del mondo 3d non avrebbero molto senso. È necessario compilare la GUI sul sistema componente. Come se il tuo GameplayScreen creasse un mondo di entità con componenti, e uno dei componenti sarà la fotocamera con "tela" su cui disegnerà il tuo renderer. E quella tela diventerà lo sfondo di quello schermo.
Kikaimaru,

1
@Kikaimaru hai un punto sul 2D. Forse sono troppo appassionato di MVC, ma sembra un mix di "modello" (entità di gioco) e vista / controller (componenti dell'interfaccia utente). Funziona, certo, ma è così che dovrebbe funzionare? Ci sono modi migliori? Come lo fanno gli altri?
ashes999,

@ ashes999 il tuo commento e la domanda iniziale provengono dal profondo del mio cuore :)
Narek,

@Armen Non ho mai avuto una risposta soddisfacente a questo.
ashes999,

@ ashes999 me to. Ovunque la gente dice che non dovresti mescolare MVC con ECS, ma perché? Non dovrebbe essere carino? Arma diversa per compiti diversi, non sei d'accordo?
Narek,

Risposte:


4

Dopo aver utilizzato diversi sistemi di componenti di entità, in particolare CraftyJS, ho più o meno ottenuto la risposta alla mia domanda: sì, è possibile riutilizzare i componenti (in particolare sprite o immagini e gestori di clic del mouse nei giochi 2D) per la GUI.

Nella maggior parte dei casi, hai accesso solo all'ECS e non ai sistemi sottostanti (ad es. Sistema di disegno). In questo caso, va bene usare i componenti, poiché non hai altra scelta.

Se hai accesso al sistema sottostante (es. Ruby roguelike con accesso diretto alle Maledizioni), potresti scoprire che il disegno / rendering direttamente su quel sistema è più efficace (meno codice, meno fragile, più naturale) rispetto all'utilizzo di un gruppo di entità e componenti.


Dove metti la logica degli elementi dell'interfaccia utente avanzata? Vale a dire. una barra della salute che deve sapere quando il giocatore viene colpito e quanto può ridurre la barra. Non riesco a capire se ha bisogno di un sistema specifico, o una sceneggiatura o qualcos'altro ...
Emir Lima

@EmirLima per qualcosa del genere, metterei la maggior parte della logica dell'interfaccia utente nella barra della salute (modificando le dimensioni della barra della salute) e fare in modo che il giocatore generi un evento quando viene colpito, indicando quale sia il nuovo / modificato valore di salute. (La barra della salute può catturare questo evento e reagire in modo appropriato.)
ashes999

Ma qual è l'oggetto della barra della salute in quell'architettura? È un'entità con un componente "barra della salute"? Una classe che eredita da Entity? Un oggetto normale con aggiornamento chiama hard coded?
Emir Lima

1
@EmirLima Modellerei la barra della salute come entità e il giocatore come entità. Puoi fare tutto ciò che ha senso per te.
ashes999,

1

In 2D o 3D, un sistema di componenti di entità (ECS) dovrebbe almeno avere accesso al sistema di interfaccia grafica, se non fa parte dello stesso ECS.

Personalmente, non mescolerei i due. La riusabilità del codice per una GUI avviene davvero solo al massimo livello. Risposta al mouse / tastiera, rendering e così via. Le funzioni che assumono pulsanti diversi o le informazioni visualizzate da determinati elenchi non sono in realtà qualcosa che può essere reso abbastanza generico da riutilizzarlo.

Ad esempio, immaginerei che i componenti per le entità della GUI sarebbero qualcosa del genere position , rendere gui. Dove il componente GUI definirebbe il tipo di azione intrapresa dall'entità GUI. Tuttavia, tale azione sarà piuttosto unica e specifica per il contesto. Ciò comporta che il sistema che gestisce i componenti della GUI è molto grande ed essenzialmente progettato per gestire ciascuna delle funzioni della GUI (carica gioco, salva gioco, trova server, ecc.). Sembra disordinato.

Preferirei fare un file di classe standard per ogni "schermata" della GUI. Avere tutte le funzionalità per quella schermata in un unico posto (con riferimenti a una classe di funzionalità comune). È molto più ordinato e più facile da gestire.

Tuttavia, come ho detto, l'ECS dovrebbe avere accesso al sistema di interfaccia grafica. Deve essere in grado di fornire informazioni alla GUI in base alle entità nei suoi sistemi. Ad esempio, passando con il mouse sopra un'unità alleata si aprirà una finestra della GUI con tutte le informazioni su quell'unità. Il passaggio del mouse su un'unità nemica fa apparire una finestra della GUI con informazioni limitate. Probabilmente non vuoi programmare la GUI per conoscere la differenza tra i due, vuoi chiedere all'entità di visualizzare le sue informazioni.

Pertanto, le entità avranno probabilmente un qualche tipo di componente GUI, ma saranno entità "in gioco", non entità GUI. Questo componente utilizzerà il sistema di GUI esterno per creare la sua interfaccia GUI.


Sembra che il sistema che ho sia abbastanza diverso da quello che hai descritto. Ho classi di entità come quelle TouchButtonche sono composte da un foglio di calcolo e da un listener touch-click. Per il popup dell'unità, probabilmente lo implementerei come una combinazione di componente sprite + componente listener del mouse. Hmm.
ashes999,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.