Como a câmera / interface do usuário sabe quem é o jogador?

7

Estou com um dilema sobre como certos componentes do mecanismo - como câmera e interface do usuário - sabem quem seguir, cuja saúde e outros atributos devem ser exibidos na tela.

Como você arquiteta um sistema em que ocorre a comunicação entre esses componentes e as entidades? Eu poderia ter uma entidade separada que representa o jogador, mas isso parece um pouco "codificado". E se eu quiser mover a câmera? E se o jogador começar a controlar outra entidade?

Em outras palavras, como abstraio as fontes de dados de componentes como a câmera e a interface do usuário, para que eles não se importem com a entidade que representam?

Um sistema de eventos funciona em muitos casos, mas é mais adequado para propagar informações que mudam ou são geradas 'raramente' (como a morte do jogador). Para algo como integridade e posição da entidade - que precisa ser conhecida em todos os quadros - um sistema de eventos não é adequado.

architecture camera

— Paul Manta
fonte

E a câmera recebe entrada? Ou o personagem do jogador, ou algum controlador abstrato. Então a câmera segue o player, quem é movido pelo controlador cinput?

— Deceleratedcaviar

10

A solução mais simples seria manter um ponteiro de membro para um objeto como Camera.Target ou UI.Subject que aponta para o personagem do jogador, mas pode ser redirecionado para outros objetos (ou definido como NULL) quando necessário.

Se o jogador mudar de personagem, envie um evento para alterar a variável alvo da câmera e o assunto da interface do usuário. Se você deseja deslocar a câmera, substitua o comportamento "alvo" e defina-o para um movimento manual.

— Alex
fonte

+1 Isso é semelhante ao que eu uso. Eu criei uma ITargetinterface que basicamente define variáveis X / Y (meu jogo é 2D). Meus Playerclasse implementa esta interface e atualiza os valores com as suas coordenadas X / Y e, em seguida, o Cameratem uma Targetpropriedade do tipo ITarget. Cada Update, as Cameraverificações, se tiver um Targete-se em conformidade atualizações, caso contrário ele faz outra coisa (no meu caso, é gratuito e se move com base em teclas pressionadas, mas você pode fazer o que quiser).

— Richard Marskell - Drackir

2

Acho que a maneira mais fácil de fazer isso é simplesmente não me restringir a ter apenas uma câmera.

Em vez disso, meus mundos de jogo estão cheios de câmeras, dezenas ou centenas delas. Qualquer personagem potencialmente controlável possui uma câmera, qualquer cena possui uma câmera, geralmente uma única entidade também possui várias câmeras para diferentes atividades do jogador. (movimentos de combate, marcha lenta, corrida, etc). Cada câmera recebe seu alvo quando é criada, e esse alvo (como regra geral) permanece constante durante toda a vida útil da câmera.

O problema agora não é "como a câmera sabe qual personagem está seguindo", mas "como o renderizador sabe qual das câmeras na cena que ele realmente deveria estar usando para renderizar agora". Eu uso uma classe de gerenciador de câmeras para isso, que conhece todas as câmeras da cena e pode se misturar de uma para outra, conforme instruído pelos eventos que recebe da lógica do jogo.

— Trevor Powell
fonte

Soa um pouco exagerado? Você não poderia apenas definir o comportamento com base nos tipos de base? (cutscene, head etc)

— deceleratedcaviar

Não me interpretem mal; as câmeras têm comportamentos padrão. Não estou defendendo implementações separadas para todas as instâncias de uma câmera em cena! Só que ter cada câmera em potencial como uma instância separada na cena é bastante útil para mesclar e simplificar o número de tipos de eventos de câmera que precisam ser tratados pelo restante da base de código.

— Trevor Powell

0

Os jogadores provavelmente são diferentes o suficiente de outros objetos ou entidades para terem sua própria classe. Para muitos jogos, é perfeitamente legítimo ter um objeto de jogador global que pode estar disponível em todo o mecanismo e sempre representa o jogador, e qualquer sistema que precise saber sobre o jogador pode conversar com essa classe. Isso pode ser mais limpo e simples do que passar por um ponteiro em qualquer lugar.

Se o seu jogo for multiplayer em uma rede, isso ainda fará sentido, porque há uma grande diferença entre o jogador local e o remoto. Se você suporta o multiplayer local com dois controladores, precisará de vários objetos de jogador e passagem de ponteiro concomitante.

— Nathan Reed
fonte