Sprites como atores

Não tenho experiência em questões de desenvolvimento de jogos, mas como programador. No idioma Scala, você pode ter várias tarefas escaláveis ​​com atores, muito estáveis, pelo que ouvi. Você pode até ter centenas de milhares deles rodando ao mesmo tempo sem nenhum problema.

Então eu pensei, talvez você possa usá-los como uma classe base para 2D-Sprites, para romper com o ciclo do jogo que requer passar por todos os sprites e movê-los. Eles basicamente se moviam, orientados a eventos.

Isso faria sentido para um jogo? Tendo multitarefa assim? Afinal, ele será executado na JVM, embora isso não deva ser um problema hoje em dia.

EDITAR:

Depois de mexer um pouco, notei que há apenas uma vantagem real nessa idéia: Suporte Multicore. Um loop de jogo simples será executado apenas em um núcleo e funcionará com tudo sequencialmente.

Como os computadores modernos, mesmo em casa, hoje em dia têm dois ou mais núcleos embutidos, acho uma boa idéia permitir que programadores de jogos usem com eficiência os outros núcleos. Afinal, acho que geralmente o jogador terá apenas o jogo rodando em sua máquina de oito núcleos, então por que não?

A outra vantagem que vejo é que, no Scala, você pode ter RemoteActors, que pode ser tratado da mesma maneira, mas executado em outro computador. Portanto, talvez isso possa simplificar também os jogos em rede.

Pretendo incorporar isso no meu mecanismo Scala 2D o mais rápido possível.

Não tentei, mas sou programador do Scala e diria que essa não é a melhor abordagem. Os sprites precisam ser animados de forma síncrona. Os atores não têm garantias de que serão executados de maneira justa - alguns sprites podem ser mais rápidos que outros, o que não é o que você deseja. Você pode querer usar uma barreira para sincronizá-los, mas então - por que usar atores. Se você confiar apenas na passagem de mensagens, implementar esse tipo de sincronização (implementar uma barreira para mais de 1.000 atores) é um exagero.

Outra questão é: para que você usaria a passagem de mensagens? Você precisa de seus sprites para se comunicar? Você pode enviar uma mensagem do ator principal, dizendo a cada sprite para passar para o próximo quadro, mas em termos de desempenho, são magnitudes e magnitudes mais do que invocar métodos diretamente e iterar através de um conjunto de sprites.

Parece-me que o que você precisa aqui é uma espécie de multitarefa muito leve e nenhuma mensagem sendo transmitida. Rolar em sua própria implementação do tipo ator, que garante justiça é provavelmente o melhor caminho a percorrer, se você quiser garantir isso, mas isso é muito trabalho para pouquíssimo ganho. Outra coisa a olhar é a programação reativa funcional e scala.react, acredito que seja uma correspondência melhor para este caso de uso.

Eu implementei um mecanismo de jogo isométrico 2d no Scala. Eu usei apenas um ator global para atualizar sprites visíveis que foram animados.

Você pode implementar sua lógica de jogo usando atores - por exemplo, para distribuir cálculos em diferentes partes do mapa do jogo para diferentes atores, para que eles atualizem o estado do jogo em paralelo - e obtenham um ganho de desempenho. Eu não usaria um único ator por objeto de jogo, e sim um ator por região. Se você for muito refinado, o desempenho será prejudicado.

Ainda assim, se eu fosse você, tentaria, apenas para ver o que acontece.

Então eu pensei, talvez você possa usá-los como uma classe base para 2D-Sprites, para romper com o ciclo do jogo que requer passar por todos os sprites e movê-los. Eles basicamente se moviam, orientados a eventos.

Qual seria o evento que os move?

Seria um evento que você emitisse uma vez por quadro?

E se sim, como isso mudou o sistema de alguma maneira prática?

Ao estudar originalmente a orientação a objetos no contexto de C ++, aprendi que algumas pessoas gostavam de pensar em uma declaração xyz.doThis(x)como o significado 'envie a mensagem doThis para xyz (com carga útil de x) e aguarde uma resposta imediata'. Quando visto neste nível, não há diferença intrínseca entre um sistema baseado em eventos ou mensagens e um procedimento normal.

Essa é uma abordagem interessante para atualizar os objetos do jogo. Não conheço o Scala, mas digo: experimente e veja como fica e, melhor ainda, publique seus resultados!

As principais perguntas que me vêm à mente são: Como você gerencia com que frequência alguns objetos do jogo são atualizados em relação a outros? Você precisará se preocupar com os atores de sprite que executam muitos ciclos, de modo que o sistema de renderização não tenha tempo para desenhar um quadro a cada 1/60º | 30º | 24º de segundo?

Outra coisa a considerar é como isso afetará a resolução das interações entre jogadores e IA que dependem da ordem de uma sequência de eventos muito rápidos. Dependendo do tipo de jogo, este pode não provavelmente não vai importar muito.

Bem, também não sou muito programador, mas não vejo nenhum problema em sua proposta. Eu nem pensei em uma maneira de desenvolver atores.

Pode ser um grande desafio, já que a IA precisa ser muito precisa, para evitar comportamentos inesperados, mas além disso, vejo que é uma proposta muito boa

Se por sprite você quer dizer entidade do jogo , com certeza.

As entidades do jogo nunca devem se desenhar. Eles devem atualizar um identificador gráfico que descreve onde e como eles precisam ser desenhados. O sistema de renderização ou gráfico de cena ou o que quer que seja o desenho real. Existe uma placa gráfica, além disso, a placa gráfica deve ser sincronizada a cada 16ms. Uma configuração como essa simplesmente não funciona bem para processamento assíncrono distribuído.

O sistema de renderização deve ser um ator (ou possivelmente um casal, se você for complicado). Quando as entidades do jogo atualizam o identificador gráfico, ele envia mensagens para o sistema de renderização. O sistema de renderização pode tomar todos os tipos de decisões e / ou otimizações, por exemplo, renderização em lote, oclusão, suavização de tremores físicos, etc.

Não sou desenvolvedor de Scala, mas já fiz bastante com Erlang. Portanto, se parte da minha terminologia Scala estiver incorreta, por favor, perdoe-me.