Sistema de entidade / componente e UI "Entidades"

Ainda sou verde para os sistemas de entidade / componente. Acho que, como tenho componentes úteis para desenhar sprites (ou planilhas) e manipular as entradas (cliques do mouse / toque), naturalmente quero reutilizá-las para criar componentes da interface do usuário (como botões, por exemplo, tela de seleção de nível).

Isso me parece muito estranho. Eu sempre entendi as entidades como "modelo de jogo", como jogadores, inimigos, power-ups, etc. Por outro lado, de uma perspectiva de reutilização de código, reutilizar componentes para a interface do usuário faz todo o sentido.

Como (e onde) as preocupações de interface do usuário / GUI se encaixam em um sistema de entidade / componente?

(Nota: esta pergunta é independente de plataforma, pois se aplica a várias plataformas / idiomas)

2d component-based gui

— ashes999
fonte

Eu acho que parece lógico para você apenas porque você está fazendo um jogo 2D. Imagine que você faria um jogo 3D (com 2d gui) quase nenhuma lógica de renderização poderia ser reutilizada, e os componentes 2d gui no mundo 3d não fariam muito sentido. Você deve criar a GUI sobre o sistema de componentes. Assim como sua GameplayScreen crie o mundo da entidade com componentes, e um dos componentes será a câmera com "tela" que seu renderizador chamará. E essa tela se tornará o fundo dessa tela.

— Kikaimaru

@Kikaimaru, você tem uma opinião sobre 2D. Talvez eu goste muito do MVC, mas parece uma mistura de "modelo" (entidades do jogo) e visão / controlador (componentes da interface do usuário). Funciona, claro, mas é assim que deve funcionar? Existem maneiras melhores? Como os outros fazem isso?

— ashes999

@ ashes999 o seu comentário e pergunta inicial é de profundo dentro do meu coração :)

— Narek

@ Armmen Eu nunca recebi uma resposta satisfatória para isso.

— precisa saber é o seguinte

@ ashes999 me para. Em todo lugar, as pessoas dizem que você não deve misturar MVC com ECS, mas por quê? Não seria legal? Arma diferente para tarefas diferentes, você não concorda?

— Narek

Respostas:

Depois de usar vários sistemas de componentes de entidades, especialmente o CraftyJS, obtive mais ou menos a resposta para minha pergunta: sim, você pode reutilizar componentes (especialmente sprites ou imagens e manipuladores de cliques do mouse em jogos 2D) para a GUI.

Na maioria das vezes, você só tem acesso ao ECS, e não aos sistemas subjacentes (por exemplo, sistema de desenho). Nesse caso, não há problema em usar componentes, pois você não tem outra escolha.

Se você tiver acesso ao sistema subjacente (por exemplo, Ruby roguelike com acesso direto a Curses), poderá achar que desenhar / renderizar diretamente nesse sistema é mais eficaz (menos código, menos frágil, mais natural) do que usar vários entidades e componentes.

— ashes999
fonte

Onde você coloca a lógica dos elementos avançados da interface do usuário? Ou seja. uma barra de saúde que precisa saber quando o jogador é atingido e quanto diminuir a barra. Eu não consigo perceber se ele precisa de um sistema específico, ou um script ou qualquer outra coisa ...

— Emir Lima

@EmirLima para algo assim, eu colocaria a maior parte da lógica da interface do usuário na barra de saúde (alterando o tamanho da barra de saúde) e faria o jogador gerar um evento quando fosse atingido, indicando qual é o novo / alterado valor de saúde. (A barra de saúde pode capturar este evento e reagir adequadamente.)

— ashes999

Mas qual é o objeto de barra de integridade nessa arquitetura? É uma entidade com um componente "barra de integridade"? Uma classe que herda de Entity? Um objeto normal com atualização chama codificado?

— Emir Lima

@EmirLima Eu modelaria a barra de integridade como uma entidade e o jogador como uma entidade. Você pode fazer o que fizer sentido para você.

— precisa saber é

Em 2D ou 3D, um sistema de componente de entidade (ECS) deve ter pelo menos acesso ao sistema da GUI, se não fizer parte do mesmo ECS.

Pessoalmente, eu não misturaria os dois. A reutilização do código para uma GUI realmente acontece apenas no nível superior. Respondendo ao mouse / teclado, renderização e assim por diante. As funções que diferentes botões executam ou as informações exibidas por determinadas listas não são realmente algo que possa ser tornado genérico o suficiente para ser reutilizado.

Por exemplo, eu imaginaria que os componentes para entidades da GUI seriam algo como position, rendere gui. Onde o componente da GUI definiria o tipo de ação que a entidade da GUI executa. No entanto, essa ação será única e específica ao contexto. Isso resulta no sistema que lida com os componentes da GUI ser muito grande e essencialmente projetado para lidar com cada uma das funções da GUI (carregar o jogo, salvar o jogo, encontrar o servidor, etc.). Parece bagunçado.

Eu preferiria criar um arquivo de classe padrão para cada "tela" da GUI. Tenha todas as funcionalidades dessa tela em um só lugar (com referências a uma classe de funcionalidade comum). É muito mais limpo e fácil de gerenciar.

No entanto, como eu disse, o ECS deve ter acesso ao sistema GUI. Ele precisa fornecer informações à GUI com base nas entidades em seus sistemas. Por exemplo, passar o mouse sobre uma unidade aliada abriria uma janela da GUI com todas as informações sobre essa unidade. Onde pairar sobre uma unidade inimiga apareceria uma janela da GUI com informações limitadas. Você provavelmente não deseja programar a GUI para saber a diferença entre os dois; você deseja solicitar à entidade que exiba suas informações.

Portanto, é provável que as entidades ainda tenham algum tipo de componente da GUI, mas estarão entidades "em jogo", não entidades da GUI. Este componente usará o sistema GUI externo para criar sua interface GUI.

— MichaelHouse
fonte

Parece que o sistema que eu tenho é bem diferente daquele que você descreveu. Eu tenho classes de entidade como as TouchButtonque são compostas por uma planilha e um ouvinte de toque e clique. Para o pop-up da unidade, eu provavelmente implementaria isso como uma combinação de componente sprite + componente ouvinte do mouse. Hmm.

— ashes999