Você poderia me ajudar a esclarecer, por favor, o que exatamente deveria estar contido em um gráfico de cena do jogo? Veja a lista a seguir, por favor:
- Atores de jogos? (obviamente sim, todos os objetos que mudam de estado devem ser o principal ponto de partida do gráfico de cenas)
- Objetos estáticos simples de jogos? (Refiro-me a objetos no fundo que não são animados nem colidem)
- Gatilhos de jogo ?
- Luzes do jogo ?
- Câmeras de jogos ?
- Balas de armas ?
- Explosões de jogos e efeitos especiais?
Os tipos de objetos considerados acima. Agora, para a cobertura do gráfico da cena:
- Um gráfico de cena deve conter todo o mapa do nível do jogo desde o início do nível ou deve conter apenas a parte visível do mapa? Se o segundo for verdadeiro, isso significaria que o gráfico da cena seria atualizado continuamente, adicionando / removendo objetos do jogo, conforme o jogador se move. No entanto, conter apenas os visíveis do mapa obviamente seria muito mais rápido de percorrer e atualizar.
game-design
architecture
scene-graph
Bunkai.Satori
fonte
fonte
Respostas:
Acho que ler um pouco o que outras tecnologias de gráficos de cena estão fazendo traria muitos benefícios para você.
Histórico
Por exemplo, veja a descrição do Ogre3D. É um mecanismo gráfico baseado em gráfico de cena que é de código aberto. Eu sugeriria examinar os tutoriais e ver como os nós de cena estão sendo usados (Nota: não estou dizendo para você aprender a usar o Ogre, mas quais recursos estão presentes nos nós de cenas e nos gerenciadores de cenas do Ogre)
Documentação do SceneNode:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html
Documentação do SceneManager: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html
Outra coisa que vale a pena olhar é o seguinte link:
http://sgl.sourceforge.net/#features
É uma solução de gráfico de cena baseada em OpenGL e a página de recursos mostra todos os nós que ela pode conter.
Seus nós sugeridos
Sou da opinião de que um gráfico de cena deve ser o mais abstrato possível da lógica do jogo, para que você não tenha problemas de dependência. Para cada um dos seus pontos de marcador, eu diria o seguinte:
Atores de jogos,
eu provavelmente diria que não. Semelhante ao Ogre, eu teria uma classe Entity base (que conteria a lógica específica do objeto) e um SceneNode base com um ponteiro de membro Entity para obter as informações apropriadas para renderizar o objeto (Posição, Orientação etc.)
EDIT: Não estou dizendo para não incluir os atores do jogo no gráfico da cena aqui (caso contrário, nada apareceria: P) Estou dizendo para ter um nó de cena com uma referência à classe lógica dos atores do jogo, então você ainda ficou solto o acoplamento da renderização e atualização dos objetos do jogo.
Objetos estáticos simples de jogo
Sim
Gatilhos de jogo?
Não, isso me parece uma lógica específica do jogo.
Luzes do jogo?
sim
Câmeras de jogos?
sim
Balas de armas?
Não estou completamente certo sobre este, mas provavelmente diria que sim, mas você provavelmente desejaria todos os marcadores como filhos em um nó de cena pai "BulletCollection", apenas para que você possa armazenar em cache essa posição e não precisará atravessar o muito gráfico para remover e adicionar marcadores para renderizar.
Explosões de jogos e efeitos especiais?
Não tenho certeza, vou deixar alguém responder isso.
Cobertura do gráfico de cena
Se você possui um nível relativamente pequeno, deve poder armazenar todo o nível em um gráfico de cena e otimizar a visibilidade usando uma Octree (geralmente para ambientes externos) ou uma árvore BSP (geralmente para ambientes internos).
Se você tem um nível muito maior e não deseja carregar nenhum nível, é aqui que o streaming entra em cena, mas isso é outro problema. Eu começaria com um nível pequeno e veria gradualmente o tamanho que você pode aumentar sem afetar adversamente o desempenho.
Conclusão
Para mim, um gráfico de cena é para a parte Render de um loop do jogo. Você não deve acoplar sua renderização e suas atualizações lógicas muito próximas, caso contrário, ocorrerá problemas de dependência irritantes.
fonte
Minha inclinação é sugerir colocar menos coisas em um gráfico de cena. Veja em particular este artigo de Tom Forsyth: " Gráficos de cena - apenas diga não ".
O ponto crucial do artigo de Forsyth é que você não deve tentar colocar um monte de coisas não relacionadas em uma grande estrutura de dados mestre. Isso é muito parecido com as idéias que eu toquei nesta resposta no que diz respeito a derivar tudo no jogo
GameObjecte depois colocar tudo em uma grande lista heterogênea (ou seja, isso é ruim).Relativamente poucos objetos no mundo realmente exibem uma forte relação pai-filho, conforme convém a uma estrutura de árvore. O exemplo canônico de uma xícara de café em uma mesa é geralmente usado aqui - com certeza, você pode considerar que ela é uma "criança" da mesa ... pelo menos até que seja derrubada. Então ainda é realmente um filho da mesa? Isso significa que sua 'árvore' pode acabar bem superficial e meio que se degenerará em uma lista.
Então, eu sugiro que você use várias estruturas de dados para várias coisas, o que faz mais sentido para essas coisas. A geometria estática e as luzes, por exemplo, parecem uma coisa razoável para inserir em um gráfico de cena. Mesmo se os objetos representados não tiverem relações pai-filho naturais, o fato de serem estáticos significa que você pode fornecer a eles relacionamentos pai-filho estruturais sabendo que eles nunca mudam.
Atores de jogos ... Não tenho tanta certeza. Qualquer coisa que tende a se mover, de fato, significa que você geralmente precisa mantê-los perto da raiz do gráfico ou re-parentê-los constantemente (o que é uma tarefa árdua e não é super eficiente).
Marcadores, gatilhos, efeitos especiais e outros objetos transitórios que eu armazenaria em outro lugar. Nada que renderize ou tenha uma representação visual (um gatilho geralmente é um volume delimitador invisível, uma bala geralmente é apenas um raio) deve estar em um gráfico de renderização. Você deve se esforçar para separar as camadas de renderização e lógica .
Pelo que vale a pena, nunca usei um gráfico de cena em forma de árvore em nenhum dos renderizadores que construí para uso não acadêmico (obviamente, eu já criei gráficos de cena em forma de árvore antes, e foi assim que cheguei à conclusão de que agora estou tentando fazer com que você concorde).
Uso métodos de particionamento espacial apropriados ao estilo de jogo (quad-tree, octree, BSP, etc.) para agrupar / selecionar as entidades lógicas no jogo que devem ser (a) processadas nesse quadro e (b) processadas esse quadro. Acabo alimentando o conjunto de objetos da lista (b) em um sistema que mapeia objetos lógicos para renderizar descrições e classifica essas descrições em buckets com base nas propriedades (por exemplo, qualquer coisa que use transparência será empurrada para o bucket por "coisas" isso deve ser processado de trás para frente). Então, eu renderizo todos os buckets em ordem e para cada bucket processamos todas as descrições em ordem. Acho que você pode chamar isso de "árvore", mas não exibe o estado típico / transformar métodos de propagação que os gráficos tradicionais de cenas orientadas para árvores fazem.
fonte