Dúvidas: Java para jogos e mineração?

Bom, vou responder pelo menos uma:
Vocês jogariam um game feito em java?

Isso pra quem joga é totalmente irrelevante. O cara não ta nem aí se foi feito em java, pascal ou assembly, ele quer é se divertir…

Existem vários frameworks para jogos em java, mas a linguagem mais utilizada pra isso ainda é o C/C++.

c/c++ ainda realmente eh amsi utilizada
em florianópolis tem ums empresa que está lançando um jogo o taikodon um jogo online (massive multiplayer)
e está sendo desenvolvido em java, não chegaram ao mesmo desempenho de um C/C++ mas chegaram cerca de mais de 85%, ou seja sim é possível desenvolver e desenvolver jogos bons em java.

Tem certeza que o Taikodom é feito em Java? Acho que não hein. Lembro de alguns anos atrás algum funcionário de lá estava trollando em um forum de como C++ era a sétima maravilha do mundo e Java era tudo de ruim…

Se fazem jogos até em Flash, por que não? Existem alguns que foram lançados para PC, como o Puzzle Pirates. Mas é muito pouco. Nem o C# é utilizado ainda, e olha que a Microsoft empurra essa jossa em tudo o que pode.

Verdade. Até porque, é a única linguagem suportada em todos os video-games. Nenhum deles tem VMs próprias reconhecidas pelos fabricantes e, por serem hardwares muito específicos, acho realmente difícil que tenham. Até porque, a industria de consoles não tem o menor interesse em ter multiplataforma. Primeiro, porque é uma industria onde o hardware diferenciado é o grande motto. Segundo, porque títulos exclusivos são um grande apelo para as vendas. Basta ver a reação da indústria quando a EA falou no assunto.

Não está sendo lançando. Já lançaram.

Sim, está sendo feito em Java. O curso de Desenvolvimento de Jogos da Universidade Positivo (que, inclusive, está com matriculas abertas), onde cursei e hoje dou aula, tem como um de seus professores o game designer da hoplon. Uma das minhas colegas era testadora lá também. O jogo é feito em Java, muito código que inicialmente era em C++ foi portado para Java.

Do contrário que o Marcos falou, o desempenho atualmente é melhor do que tinham em C++. É bom lembrar que hoje os grandes gargalos do jogo não estão na linguagem de programação utilizada. Pense no MMO. É muito mais provável que você vá ter problemas com lag da rede, do que com processamento do seu computador. Ainda assim, se tiver, será provavelmente com o hardware de vídeo, não com a lógica do jogo. E, bindings como a JOGL acessam o vídeo diretamente, representando um impacto insignificante sobre a performance. No caso do Taikodom, tiveram grande ganho de performance ao remover a Havoc (em C++) e substituir por uma engine de física mais simples e adequada ao jogo, feita em Java pela própria empresa. Um exemplo de que uma decisão incorreta sobre que tipo de estruturas e engines usar, pode ter muito mais impacto do que a linguagem utilizada em si.

Aliás, quem ainda não conhece, dê uma olhada nos benchmarks de um quake feito em java, onde a performance também supera a da versão original em C.
http://bytonic.de/html/benchmarks.html

O interessante é que o Quake era extremamente otimizado, com código fonte em assembly em alguns pontos críticos. Pena que o benchmark não traz dados sobre uso de memória.

Agora, respondendo as perguntas do Runehart. Para a produção de jogos comerciais e AAA, não é viável o uso de Java. Por várias razões, sendo a última delas a performance: Não é suportado em vários consoles, não possui excelentes APIs complementares (como a SpeedTree ou a Havoc, por exemplo), não é determinística, etc. É bom lembrar, em jogos AAA, pode-se sim chegar ao grau em que a linguagem venha a ser um limitante. No caso do Java, creio que o garbage collection não determinístico deva ser um problema maior do que velocidade em si. Principalmente em consoles mais limitados, como o PSP, onde você deve expremer até o último fio de memória e processamento do bichinho. É por isso que a EA e outros grandes estúdios usam C++. Estou falando aqui de jogos grandes mesmo, dos titãs da indústria.

Agora, para jogos indie, o Java é uma excelente linguagem. Entre no site do JMonkeyEngine e veja os jogos que tem por lá. É de tirar o fôlego! Já existem diversas e boas APIs de suporte para Java.

Para o mecado de celulares, o Java é a linguagem dominante. Por lá o questionamento costuma ser o inverso: “Vale a pena usar C++ e APIs nativas para celular?”

No caso da Internet, acho que o ActionScript e o Flash são mais práticos e menos estressantes do que o Java. O flash é muitíssimo bem aceito e tem um excelente histórico de compatibilidade. Além disso, jogos casuais, como é o perfil de jogos em browser, não exigem altíssimo conhecimento técnico, viabilizando até que publicitários e designers interessados na área façam ótimo trabalho ou, no mínimo, te ajudem com facilidade.

Se você for investir na sua formação profissional almejando trabalhar na área de jogos AAA, estude C++. E muito. Você até pode brincar no JMonkey com o Java para entender como funciona um SceneManager, por exemplo, mas dificilmente irá encontrar um estúdio sequer pensando em usar isso no futuro.

Já existem quase 40 jogos para IPhone usando C# atravez do mono. Lançaram também um para Wii recentemente também.

Dá uma olhada aqui.

O c# tá bem na fita.

Sobre jogos em java, imagine que tipo de máquina teria que ser para suportar um age of conan em java!?

Referia-me a jogos maiores do que algo casual. A Microsoft tem a faca e o queijo na mão, pois os estúdios usam Visual Studio, e mesmo assim não usam C#. Quando usam é apenas para alguma ferramenta externa.

Sobre jogos em Java, veja Puzzle Pirates que é tipo um MMO. A mesma empresa lançou outros jogos também.

Mais importante do que isso… a Microsoft tem a faca e o queijo na mão porque, além de tudo isso, tem o X-Box.

Thiagosc:

Referia-me a jogos maiores do que algo casual. A Microsoft tem a faca e o queijo na mão, pois os estúdios usam Visual Studio, e mesmo assim não usam C#. Quando usam é apenas para alguma ferramenta externa.

Sobre jogos em Java, veja Puzzle Pirates que é tipo um MMO. A mesma empresa lançou outros jogos também.

Sobre o Puzzle P., parece ser bem legal.

Sim, é possivel criar jogos incriveis em Java!

Thiagosc:

Referia-me a jogos maiores do que algo casual. A Microsoft tem a faca e o queijo na mão, pois os estúdios usam Visual Studio, e mesmo assim não usam C#. Quando usam é apenas para alguma ferramenta externa.

Sobre jogos em Java, veja Puzzle Pirates que é tipo um MMO. A mesma empresa lançou outros jogos também.

Existem jogos AAA feitos usando mono, porém isso não é divulgado, Com um deles sendo lançado em 2009. Não posso divulgar qual é, mas espero que em breve isso aconteça.

Com recursos como age of conan, usando api sobre direct3d e opengl, eu não acredito muito nisso não(sem querer desmerecer nada). Acho que isso não é o foco do java.

Com recursos como age of conan, usando api sobre direct3d e opengl, eu não acredito muito nisso não(sem querer desmerecer nada). Acho que isso não é o foco do java.

Tambem acredito que este não é o foco do java, mas o Taikodom ta ai pra provar que o cmoscoso de fato não esta falando nenhuma mentira.

Com recursos como age of conan, usando api sobre direct3d e opengl, eu não acredito muito nisso não(sem querer desmerecer nada). Acho que isso não é o foco do java.

Tambem acredito que este não é o foco do java, mas o Taikodom ta ai pra provar que o cmoscoso de fato não esta falando nenhuma mentira.

Acredito que se possa criar jogos ótimos sim. O que estou indagando é o hardware que precisará para ser executado.

Não vai ser muito melhor. A maior parte do processamento dos jogos, como eu já disse, está na placa de vídeo, a GPU. O código que roda na CPU não tem praticamente nenhuma influência. Tanto, que existem jogos 3D impressionantes por aí feitos em Python.

Seria problemático apenas se estivessemos falando de um RTS, ou algum outro jogo fortemente baseado em IA.

Legal, já dá pra fazer jogos então… não sabia que a influência de performance no jogo era tão centrada na GPU…

E sobre a segunda dúvida? Sabem se java tem boa performance em business intelligence?

É só ver o impacto que uma placa de vídeo tem sobre a qualidade do jogo, e facilmente vc comprova essa afirmação. Lógico, no caso de MMOs ou outros jogos de rede, a própria conexão de rede será um dos principais gargalos.

Mas, a menos que seu jogo tenha perfil de um que exija muito processamento de IA (como um RTS), dificilmente sua CPU e a linguagem será um problema.

Quanto a BI, deixo a questão para outros especialistas.

Nossa esse Taikodom parece interessante… eu queria que um jogo nesse estilo fosse open-source.

É só ver o impacto que uma placa de vídeo tem sobre a qualidade do jogo, e facilmente vc comprova essa afirmação. Lógico, no caso de MMOs ou outros jogos de rede, a própria conexão de rede será um dos principais gargalos.

Mas, a menos que seu jogo tenha perfil de um que exija muito processamento de IA (como um RTS), dificilmente sua CPU e a linguagem será um problema.

Quanto a BI, deixo a questão para outros especialistas.

Vini, o problema não é a gpu, mas sim o overhead que um framework causa em cima de outro(java ogre em cima de opengl). A perda de performance é grande. Eu testei o java ogre aqui e não vi muita diferença para sua versão em c++. Mas um teste assim não pode ser comparado com um jogo de mercado ao nível de starcraft2 ou um mmo age of conan.

Não existe perda de performance do ogre em cima de opengl. Pelo contrário, existe ganho.

Primeiro de tudo. Vamos lembrar que, no fundo, existem 2 processadores. A GPU e a CPU. Ambos se comunicam através de memória compartilhada e de um barramento. Essa forma de comunicação é muito lenta, e faze-la de maneira ingênua realmente causa gargalos gigantescos numa aplicação gráfica. E isso sim, é perda de performance.

Também vamos lembrar que a etapa de desenho é muito lenta. A mais lenta que existe num jogo. São milhares de polígonos na tela, transformados, texturizados, iluminados.

Dito tudo isso, é prudente imaginar que o uso de uma GPU também pode ser muito otimizado, já que ela tem caches. Desenhar centenas de vezes o mesmo objeto em sequencia é milhares de vezes mais rápido do que carregar objetos diferentes: mesmo que no final a cena seja a mesma.

Existe também limitações quanto a quantidade de luzes que podem ser ligadas ao mesmo tempo. É mais eficiente desenhar os objetos da frente da cena do que os do fundo primeiro (já que, a placa de vídeo pode evitar totalmente o desenho de objetos eclipsados).

Enquanto um processador está ocupado, o outro pode estar trabalhando. Entretanto, há certas fases que um terá que esperar, pois o trabalho nem sempre pode correr em paralelo. Na maior parte dos jogos, a CPU é o processador que espera. Faz-se todo o desenho, empilha-se os comandos da GPU e espera que tudo seja desenhado.

Para a CPU, todos os comandos de desenho parecem instantaneos. Ele simplesmente os empilha na GPU, que “trava” somente no momento que o comando final de pintura for dado. Como a GPU tem memória, muitas vezes ela empilha 2 ou 3 quadros antes realmente solicitar a CPU que pare.

Enfim… se a CPU está ociosa, podemos dizer que trocar a linguagem lá por uma mais lenta, ou mesmo por uma API inteira, não é um problema. Existe tempo livre lá, e o processador está parado, enquanto o vídeo trabalho. E se usassemos esse tempo para, ao invés de ficarmos parados, implementar toda a otimização que descrevi ali em cima? É o que uma API gráfica, como a Ogre, JMonkeyEngine, a da IDEngine, CryTek fazem. Gasta-se mais CPU, mas poupa-se com isso GPU.

Através de uma classe chamada Scene Manager, essas APIs são capazes de dizer o que vai ser desenhado, quando e como. E tentam organizar para que isso seja feito da melhor forma possível. Ganha-se com GPU, reduz-se a ociosidade da CPU. Seria muitíssimo difícil (embora certamente possível) obter uma performance melhor usando OpenGL diretamente.

Veja que o overhead que você está falando, seja da linguagem ou da biblioteca, está num processador que estaria parado, esperando pelo vídeo. É o que acontece quando otimizamos o lugar errado. Aumentar a velocidade da linguagem, nesse caso, só faria com que a CPU esperasse o desenho por mais tempo. Numa aplicação, seja ela qual for, temos que atacar o maior gargalo, não coisas que parecem menos eficientes, mas não são o problema.

Cabe aqui uma analogia. Imagine que vc tem 1 pedreiro e um auxiliar. O pedreiro (A GPU) está construindo uma parede. O auxiliar (a CPU) está levando o material para o primeiro. A GPU é lenta, empilha devagar os tijolos. O outro, busca os sacos de cimento e os tijolos e os dispõe numa área comum, entre ambos. Como ele é muito mais rápido, frequentemente essa área comum enche e ele é obrigado a esperar que mais tijolos sejam empilhados. Nessa hora ele senta, toma um café e fica completamente parado.

Se você trocar o um auxiliar por um que corre até o saco de cimento duas vezes mais rápido, só que vai ter é esse sujeito parado por mais tempo. Afinal, a montagem da parede não se acelerará por causa disso e é ali que está nosso problema.

Agora, imagine que você troque por um auxiliar mais inteligente. Ele não traz os sacos mais rapidamente, de fato, ele é até um pouco mais lento. Porém, ele usa seu tempo livre para dispor o material de modo que fique muito mais fácil para o pedreiro que constrói a parede. Ele já deixa os materiais para fazer a massa lado-a-lado, mantém o material de trabalho do pedreiro próximo as mãos dele e evita ao máximo que esse pedreiro perca tempo desnecessário. Por exemplo, ele poderia trazer primeiro todos os tijolos, e só depois todos os azulejos, evitando que o pedreiro tenha que alternar entre as construções de ambos desnecessariamente.

Consequentemente, o sujeito construindo a parede ganha 30% até 40% de rendimento. As pausas para o café do auxiliar ainda existem, mas como o pedreiro é mais rápido, elas agora são muito menos freqüêntes. Entretanto, não só ambos se mantém ocupados, como o trabalho final sai mais rápido e mais bem-feito.

Não quis dizer o ogre nativo. Disse o java ogre. O nativo usa a opengl diretamente. O java usa o framework ogre através de jni, que por sua vez usa opengl. Ae que eu queria saber se vai realmente dar uma grande diferença, prq pequena, já dá.

Mas enfim, vi o quake2 portado para java, e ficou realmente muito bom.

ViniGodoy:

Não existe perda de performance do ogre em cima de opengl. Pelo contrário, existe ganho.

Primeiro de tudo. Vamos lembrar que, no fundo, existem 2 processadores. A GPU e a CPU. Ambos se comunicam através de memória compartilhada e de um barramento. Essa forma de comunicação é muito lenta, e faze-la de maneira ingênua realmente causa gargalos gigantescos numa aplicação gráfica. E isso sim, é perda de performance.

Também vamos lembrar que a etapa de desenho é muito lenta. A mais lenta que existe num jogo. São milhares de polígonos na tela, transformados, texturizados, iluminados.

Dito tudo isso, é prudente imaginar que o uso de uma GPU também pode ser muito otimizado, já que ela tem caches. Desenhar centenas de vezes o mesmo objeto em sequencia é milhares de vezes mais rápido do que carregar objetos diferentes: mesmo que no final a cena seja a mesma.

Existe também limitações quanto a quantidade de luzes que podem ser ligadas ao mesmo tempo. É mais eficiente desenhar os objetos da frente da cena do que os do fundo primeiro (já que, a placa de vídeo pode evitar totalmente o desenho de objetos eclipsados).

Enquanto um processador está ocupado, o outro pode estar trabalhando. Entretanto, há certas fases que um terá que esperar, pois o trabalho nem sempre pode correr em paralelo. Na maior parte dos jogos, a CPU é o processador que espera. Faz-se todo o desenho, empilha-se os comandos da GPU e espera que tudo seja desenhado.

Para a CPU, todos os comandos de desenho parecem instantaneos. Ele simplesmente os empilha na GPU, que “trava” somente no momento que o comando final de pintura for dado. Como a GPU tem memória, muitas vezes ela empilha 2 ou 3 quadros antes realmente solicitar a CPU que pare.

Enfim… se a CPU está ociosa, podemos dizer que trocar a linguagem lá por uma mais lenta, ou mesmo por uma API inteira, não é um problema. Existe tempo livre lá, e o processador está parado, enquanto o vídeo trabalho. E se usassemos esse tempo para, ao invés de ficarmos parados, implementar toda a otimização que descrevi ali em cima? É o que uma API gráfica, como a Ogre, JMonkeyEngine, a da IDEngine, CryTek fazem. Gasta-se mais CPU, mas poupa-se com isso GPU.

Através de uma classe chamada Scene Manager, essas APIs são capazes de dizer o que vai ser desenhado, quando e como. E tentam organizar para que isso seja feito da melhor forma possível. Ganha-se com GPU, reduz-se a ociosidade da CPU. Seria muitíssimo difícil (embora certamente possível) obter uma performance melhor usando OpenGL diretamente.

Veja que o overhead que você está falando, seja da linguagem ou da biblioteca, está num processador que estaria parado, esperando pelo vídeo. É o que acontece quando otimizamos o lugar errado. Aumentar a velocidade da linguagem, nesse caso, só faria com que a CPU esperasse o desenho por mais tempo. Numa aplicação, seja ela qual for, temos que atacar o maior gargalo, não coisas que parecem menos eficientes, mas não são o problema.

Cabe aqui uma analogia. Imagine que vc tem 1 pedreiro e um auxiliar. O pedreiro (A GPU) está construindo uma parede. O auxiliar (a CPU) está levando o material para o primeiro. A GPU é lenta, empilha devagar os tijolos. O outro, busca os sacos de cimento e os tijolos e os dispõe numa área comum, entre ambos. Como ele é muito mais rápido, frequentemente essa área comum enche e ele é obrigado a esperar que mais tijolos sejam empilhados. Nessa hora ele senta, toma um café e fica completamente parado.

Se você trocar o um auxiliar por um que corre até o saco de cimento duas vezes mais rápido, só que vai ter é esse sujeito parado por mais tempo. Afinal, a montagem da parede não se acelerará por causa disso e é ali que está nosso problema.

Agora, imagine que você troque por um auxiliar mais inteligente. Ele não traz os sacos mais rapidamente, de fato, ele é até um pouco mais lento. Porém, ele usa seu tempo livre para dispor o material de modo que fique muito mais fácil para o pedreiro que constrói a parede. Ele já deixa os materiais para fazer a massa lado-a-lado, mantém o material de trabalho do pedreiro próximo as mãos dele e evita ao máximo que esse pedreiro perca tempo desnecessário. Por exemplo, ele poderia trazer primeiro todos os tijolos, e só depois todos os azulejos, evitando que o pedreiro tenha que alternar entre as construções de ambos desnecessariamente.

Consequentemente, o sujeito construindo a parede ganha 30% até 40% de rendimento. As pausas para o café do auxiliar ainda existem, mas como o pedreiro é mais rápido, elas agora são muito menos freqüêntes. Entretanto, não só ambos se mantém ocupados, como o trabalho final sai mais rápido e mais bem-feito.

clap clap clap :shock: