A Cd Project Red assinou um contrato de parceria com a EPIC. OS motivos poderão ser os problemas com o seu motor proprietário.
Após um Cyberpunk 2077 catastrófico, a CD Project Red parece disposta a abandonar o seu motor, o REDEngine. Aparentemente os problemas deste motor serão tão profundos, que a empresa não lhes ver uma solução para breve, preterindo assim do uso futuro do mesmo. E nesse sentido, optou por uma parceria estratégica com a EPIC para o uso do Unreal Engine 5 no seu próximo jogo da série The Witcher (que não é The Witcher 4, segundo a CDPR).
A estratégia inclui colaboração no sentido de desenvolver e melhorar o Unreal Engine 5, não se limitando a um simples licenciamento para uso.
Não foram divulgados mais dados, mas Bart Wronski, que já trabalhou na CDProjectRed refere que tal é uma excelente escolha. Segundo ele o RedEngine tem problemas sérios que levaram a que a cada novo jogo criado ele fosse re-escrito de raiz para resolver problemas. Mas essa solução a cada nova alteração só criava ainda mais problemas, ao ponto de tal levar a enormes constrangimentos no desenvolvimento e à pouca existência de ferramentas adicionais funcionais. Nesse sentido esta escolha permite ultrapassar todos esses problemas e efetivamente permitir que a CDPR se foque naquilo que realmente importa que é o jogo.
Every game they dropped the whole engine, rewrote it from scratch hoping this time it will be better and work, but then due to crunch hacked the hell out of it with it not being maintainable or usable at all.
— Bart Wronski 🇺🇦 (@BartWronsk) March 22, 2022
From a perspective of someone who worked on those engines – excellent choice.
— Bart Wronski 🇺🇦 (@BartWronsk) March 22, 2022
Yes, *all* of the ones you list were scrapped between W2 and W3. And W3 and CP77. Even streaming, script system, literally everything (ok, some parts of renderer funnily actually stayed). Though often one by one.
Art worked on W3 DLCs.— Bart Wronski 🇺🇦 (@BartWronsk) March 22, 2022
Há muito tempo se sabe que, usar motores gráficos proprietários tendem a ser muito trabalhoso e problemático (frosbyte, cryengine e etc.) O problema passa a ser que, ao usar o motor de terceiros além de problemas comuns passa a ter que lidar com soluções comuns, logo a inovação vai para o fim da fila das prioridades…
Quando se usa um motor próprio a empresa além de ter todos os problemas também acaba por desenvolver tecnologia. Não a a esperar por soluções.
É uma faca de dois gumes:
Ainda esses dias estava a jogar Uncharted na velha PS3 e bom lá está o motor da Nauthdog a simular as colisões de seu personagem e o realismo que isso faz é simplesmente fantástico, pois diga o que quiser quais outros motores gráficos e de física tentaram aí ao menos uma solução parecida… Podes dizer que é mero detalhe mas ali temos o esforço genuíno de resolver uma falha que existe na maioria dos jogos… Mas lá daqui a 5 anos com a Epic a nadar rios de dinheiro alguém vai pensar, olha isto está errado.. E conhecendo a dona do Unreal ela vai dizer “Isto vira primeiro no Fortnite”.
na verdade o que parece é que eles simplesmente desistiram…
ao que parece desde sempre eles tentaram fazer a propria engine, nunca deu certo e finalmente jogaram a toalha.
É bem por aí. Sem dúvidas é bom por contar com mais mão de obra especializada e acostumada com uma engine, mas perde em investimento e inovação de técnicas e a possibilidade até de surpreender. Mas eles devem ter tido muita dor de cabeça com Cyberpunk e resolveram se focar no mais importante que é o jogo.
Exato, Cyberpunk e Halo Infinite são dois exemplos onde CD Projekt Red e 343 ficaram tempo excessivo reescrevendo engines, e com isso faltou tempo para focar mais nos requisitos do jogo, vide promessas ainda não cumpridas em ambos os jogos.
Em Halo me lembro de ler que a engine da Bungie chegou a ter tanto débito técnico que a situação chegou em technical bankruptcy (https://www.bloomberg.com/news/articles/2021-12-08/how-microsoft-s-halo-infinite-went-from-disaster-to-triumph?srnd=premium). Essa foi a motivação da 343 ter abandonado a engine antiga e começado a fazer outra do zero. Talvez poderiam ter escolhido a UE4 para Halo Infinite, e com a nova geração migrado para a UE5.
Halo não poderia ser feito na Unreal Engine 4 da forma como eles queriam. De acordo com conversas de fóruns técnicos, a UE4 é bastante complicada em jogos que tem grandes áreas abertas e bastante NPCs, e isso é exatamente o que tem em Halo Infinite. O distancia de visualização é muito alta, o jogo praticamente não tem fog e é possível observar NPCs aliados e adversários em batalhas ocorrendo a distância e participar delas. Além disso, toda a interação com objetos do cenário, movimentação de veículos e IA de Halo são muito difíceis de reproduzir em um motor comercial, onde teriam muito trabalho para reproduzir. Então eles preferiram criar sua própria solução, que ainda mantém uma base de código legado do motor original da Bungie, o que tambem acontece no Destiny até hoje. É um motor muito acertado para esse tipo de jogo, é uma troca, os visuais não podem evoluir tanto pois o motor é pesado, mas os recursos que funcionam para o estilo FPS não existem nem no Frostbite.
A Coalition tambem reescreveu todo o renderizador do Unreal Engine 4 para fazer o Gears 5, e já colabora com a Epic no UE5 também.
Seu exemplo de Uncharted foi cirúrgico. É exatamente isso.
Unreal já entregou excelentes jogos. A UE5 então com Lumen e Nanite promete um grande avanço. Mas fica aquela impressão de que quem quer “algo a mais” vai desenvolver a sua própria engine, já que nesse caso existe uma total liberdade de desenvolvimento.
Interessante que essa situação nos mostra como deve ser complexo implementar do zero um novo render, usando técnicas como a Nanite que foi implementada na UE5. Então não é só uma questão de manter a arquitetura x86.. a Red Engine usada em The Witcher 3 foi reescrita para Cyberpunk porque naturalmente são dois jogos muito diferentes. Mas para The Witcher 4 também precisaria ser reescrita em virtude de suportar o que essa nova geração é capaz de fazer (e como os micropolígonos de Nanite mostraram).
Talvez seja por isso que embora cada um dos principais estúdios da Sony possuem sua respectiva engine, nós já vemos de certa forma um destaque sobre a Decima Engine, sendo cedida para outros estúdios como Kojima, Supermassive, dentre outros. Talvez estúdios menores não podem esperar até desenvolver uma nova engine para depois entregar jogos. Precisa de ser prático.
pelo que o sujeito ai ex DEV falou, finalmente viram que não iriam conseguir fazer uma engine direito e desistiram.
meu chute é que os pobres coitados que tiveram que fazer as outras engines saíram fora da empresa depois das M do cyberpunk e ninguém mais quer trabalhar pra eles… Deve estar falando mão de obra para fazerem ou refazerem a própria engine.
outra que devia estar em uma parceria parecida é a From Software.
e para finalizar 😛
alex bokeke mostrando o tanto que ele entende de fazer jogos…
Só tá triste pq agora sim que não vai mais existir chance de outro cyberpunk pra ele conseguir botar um “jogo de PC” no top 1 gráficos nem que seja 1x a cada 10 anos
off:
tinha dito aqui que o DLSS era meio lixo, muito caro, e a Nvidia só fez ele pq ela unifica as GPUs Servidores e para jogos; pessoal com 3080 pagando a conta de desenvolvimento de GPU para servidor.
que DLSS é um “aproveitamento” de algo que a Nvidia fez para servidores
FSR 2.0 da AMD entregando praticamente o mesmos sem precisar e silicio dedicado.
quem sabe? talvez para os proximos 10 ou 15 anos seja isso mesmo, silicio dedicado e a Nvidia esteja se antecipando… RDNA 4 vai ser o 3 com chips dedicados, mas por hora, Checkboarding, FSR 2 > DLSS.
Vi a análise dele ontem de Ghostwire Tokyo (https://www.youtube.com/watch?v=FbFMafKzJyY), e parece que o TSR (Temporal Super Resolution) feito para a UE5 já está disponível também na UE4 e está entregando resultados muito bons, bem superiores aos do FSR 1.0, e melhores até que TAAU.
O problema do TSR, pelo menos como apontado pela Coalition no estudo de caso da demo da Unreal Engine 5, é que apesar de ter qualidade de imagem bem melhor que a reconstrução padrão da UE4, é custosa no desempenho. Pelo menos nos testes deles com o Series X, eles chegaram a conclusão de que seriam necessários otimizações tanto do lado da engine, quanto coisas que eles identificaram do próprio renderizador do devkit do Xbox.
Concordo com a engine da From (pelo menos considerando os games antigos, pois ainda não experimentei nem Elden, nem Sekiro), outra engine que espero que mude é a de Fallout e Elders, mas talvez já tenha mudado tendo em vista Starfield que não tem lembrado os outros da Bethesda.
Agora, muito cuidado com as comparações técnicas de upscale, vamos ter paciência pra esperar o futuro se apresentar. Sem dúvidas o FSR 2 parece algo muito bom, se os resultados forem semelhantes, ou mesmo melhores que o DLSS, indiscutivelmente é um grande avanço da AMD rumo a liderança do mercado.
Por isso que eu escrevi o último parágrafo :p
Por hora é isso aí…. Talvez o normal seria silício dedicado daqui 10 anos?
NVidia montada na grana e monopolizando o mercado praticamente resolveu pular e adiantar esses 10 anos?
Primeiro era up por software e depois hardware dedicado, caminho da AMD?, mas aí a NVidia resolveu pular a etapa de software e foi direta para silício dedicado ao upscalling?
Mais suposições.
Acho que Silício dedicado é para quando chegar as placas de video MCM, a Nvidia que adiantou o silicio dedicado em DIE monolítico.
Pensei agora é acho q deve ser isso mesmo
Claramente se observa na indústria uma necessidade de buscar caminho alternativos já que a escalada de potência não condiz com a porporcionalidade direta de crescimento de performance e resultado prático obtido.
O que hoje a AMD tem provado (e eu estava descrente), se tudo se confirmar, é que ainda não há necessidade de IA para oferecer resultados praticamente equivalentes. Mas não há dúvidas de que o DLSS é bom, e é bom que ele exista pra termos caminhos diferentes na evolução da indústria, independente do motivo que levou a Nvidia a escolher processamento dedicado, se pra facilitar o desenvolvimento ou reduzir custos evitando diversificar linha de produção, se por marketing, ou não.
É importante que haja concorrência pra haver melhora, embora não seja o ideal um duopólio (ou oligopólio), sobretudo no ramo de tecnologia e pesquisa.
Eu acredito que atualmente os tensor cores são bastante subutilizados no mundo de games, se restringindo basicamente a um único tipo de aplicação que é a reconstrução de pixels.
Existem diversas implementações interessantes para Deep Learning (inclusive no mundo dos games), que pode fazer uso dos tensor cores e aliviar bastante os shaders. Essa breve apresentação da NVIDIA ilustra bem alguns cenários: https://twitter.com/CarlosEduardoCD/status/1300853353153519619?s=20&t=JqCod_Oc1Bw8fMOofYSnfg
Mas eu acredito que embora iremos ver gradativamente essa expansão de Machine ou Deep Learning em games, creio que será usado em larga escala e para diversas aplicações apenas na próxima geração, pois os consoles ainda não possuem hardware dedicado para tal e consumiria bastante dos shaders. Mesmo o rapid packed math apresentado para Xbox Series X|S faz uso dos shaders.
Interessante que conhecemos SSD há vários anos, mas só nessa geração que os jogos estão sendo desenvolvidos diretamente para a latência dele. Machine Learning/Deep Learning sobre hardware dedicado (tensor cores) também é algo que já conhecemos, mas acredito que será algo padrão apenas na próxima geração, quando possivelmente a AMD ou a Intel possuírem silício para tal.
O ruim dessa notícia, para o próximo The Witcher em si, é que muito provavelmente este será um game 4k@30 reconstruido nos consoles de nova geração, se nada mudar muito na Unreal 5.
Não que eu esteja reclamando por antecipação, pois não sou um radical dos 60fps, muito pelo contrário, optei por 4k@30 tanto em Ratchet quanto HFW, estou apenas conjecturando sobre o futuro do jogo nos consoles.
Os 4K reconstruídos do UE5 é só com o Nanite, e com o Lumen, sendo que o pesado é o Lumen. O UE 5 não tem só essa possibilidade nem para RT, nem para o grafismo. Para além do mais, desde a demo do Matrix que o Lumem se encontra alterado e agora suporta aceleração hardware no RT.
Mas é o que queremos pra The Witcher, Mário, um mundo aberto com o Nanite e o Lumem, aos moldes de Matrix! Olha e te confesso que a Guerrilla chegou perto da perfeição com HFW sem o Unreal.
Pow, mas aí você tá se embasando em que? Em duas demos que nem foram otimizadas e feitas em pouquíssimo tempo? A geração mal começou e o software muito a evoluir, inclusive a própria U5.
Meu desejo, assim como o seu é de que saia melhor, mas só posso me basear no apresentado e o que vimos até agora é algo maravilhoso, mas a 30fps no PS5. E não muito diferente em PCs de topo. Mas sim, tudo pode mudar!
Mas isso foi explicado. Foi tudo a 30 por ser mais rápido de entregar e também mais cinematográfico na apresentação. Um R&C da vida já é maravilhoso visualmente e roda em 4k/40 e com Ray Tracing. Isso aí tende a evoluir e como o Carlos disse uma vez, um Spider 2 pode ser que veremos maior fidelidade visual, RT em reflexos e iluminação global, sendo uma evolução do que foi R&C
Ah, eu acho que cabe aqui, já que falamos de Unreal 5. Tô curioso pra ver como esse motor vai se comportar na questão de vegetação. Pq cidade, asfalto, iluminação, etc, já vemos que tá 10/10.
Existe um motivo pelo qual atualmente a EPIC só faz a Unreal Engine e dá suporte em um jogo com visuais tão rústicos quanto o Fortnite, e estúdios que trabalham com engines proprietárias tem tido problemas com determinados jogos, geralmente games de mundo aberto. Desenvolver sua própria engine ficou muito caro e complicado. Fora a Rockstar que é gigante, a maioria dos estúdios só tem sucesso com suas próprias tecnologias ao criar jogos lineares, ou sandbox com poucas interações. De acordo com alguns desenvolvedores, a Unreal Engine 4 não era muito boa em jogos de mundo aberto e precisava de muitas modificações, então provavelmente a EPIC corrigiu esse problema, como a própria demo do Matrix sugere, e fora algumas otimizações com motores de física, essa engine atualmente deve ser adequada para quase todos os estilos de jogos. A CD Project não deve ser a única empresa a fazer esse caminho.
Penso que é tudo uma questão de gerir recursos e fazer escolhas. Provavelmente, companhias não tão grandes ou com engines problemáticas (como se enquadra perfeitamente a CDPR) optarão por engines de 3os como opção, tanto por contar com mão de obra farta e especializada, como pra cortar custos (hoje, quase todo programador de games se inicia por Unity ou Unreal).
Mas não vejo as grandes a indústria a optar por uma solução de engine completa de terceiros.
Acho que fora da Rockstar e de estúdios que já possuem desenvolvimento ocorrendo à algum tempo, ou necessidades muito específicas, creio que todos aqueles estúdios com motores que ainda não estão preparados para a nova geração tendem a ir para a UE5. Sabe-se por exemplo que a Bioware não vai mais usar a Frostbite por causa dos problemas que tiveram com Anthem e Mass Effect Andromeda, e escolheram a Unreal Engine. A maioria dos estúdios da MS estão com o Unreal Engine. Provavelmente estúdios da Sony não devem ir por esse caminho por desenvolverem a própria tecnologia a anos, trabalharem em compartilhamento técnico, e por geralmente estarem fazendo jogos relativamente parecidos, terceira pessoa, lineares, semi abertos, não tanta necessidade de interações etc…
Deve ser complexo para um dev que queira o nível de mundo aberto de um RDR2 criar a própria solução. A Rockstar trabalhou por 8 anos em RDR2, e eles tiveram milhares de desenvolvedores, acho que nunca vi créditos tão longos ao final de um jogo como aquele. A CD project não conseguiu deixar Cyberpunk nem igual GTA 5, que é um jogo de PS3/X360 e nesses anos recebeu só upgrade gráfico.
E também tem muita tecnologia específica para nova geração nesse momento que necessitam de reformulação de motores. Exemplos, a utilização ideal de VRS precisa de implentação desde a concepção do mecanismo, Mesh Shaders necessitam que todo o pipeline de renderização seja reconstruído, sample feedback stream necessita que uma API específica seja incluída desde o início de desenvolvimento. A implementação ideal de Ray Tracing necessita de DXR 1.1, que poucos motores estão utilizando, o caso que me lembro melhor atualmente é com Metro Exodus onde a 4A reformulou a engine. Tudo isso estará no PC nos próximos anos, e para estúdios que não são um grande conglomerado, é melhor utilizar uma solução pronta que atenda às necessidades e precise de poucas adequações, do que perder muito tempo criando sua tecnologia.
Certamente, mas me surpreende um pouco a EA estar a deixar em segundo plano suas engines pela Unreal, assim como a MS (salvo a Coalition pelo histórico com a Epic), porque recursos essas empresas têm. Não teria objeções quanto a algumas engines da indústria, mas a Frostbite, por exemplo, fez dos gráficos mais belos da indústria em alguns momentos (lembro de ver os trailers de SW Battlefronts admirado) e provavelmente os jogos que você citou talvez tenham sido mais prejudicados pelo planejamento deles próprios que pela engine “defeituosa”, mas não podemos negar sempre a possível dificuldade de se obter um bom resultado se a engine não é “fácil”.
Penso que a indústria perde em desenvolvimento quando todos preferem usar recursos padronizados, mas enfim, são empresas gerindo recursos.
Pelos movimentos da Microsoft, indo em direção ao PC e deixando o console mais secundário não entendo vc se surpreender! Os caras simplesmente colocaram o l Xbox junto com pc no mesmo kit de desenvolvimento, sendo o PC a plataforma mais genérica.
A MS é dona de diversas tecnologias, e a menos que ela pense em comprar a Epic, que é uma possibilidade remota, pois não é algo crível, não vejo sentido em optar por um motor externo. Ela tem diversos motores bons, como os da ID e Playgrounds, é dona do Havok e de muitas outras tecnologias e em teoria não tem porque optar por Unreal, exceto para dar liberdade aos novos estúdios ou estúdios com jogos pequenos, mas sim, na gestão do Phil Spencer, tudo é possível. A minha surpresa é no sentido de decepção, pois as diferenças podem trazer saltos, todos na mesma marcha já torna tudo muito igual.
Não tem porque optar por unreal, mas já vem optando. Kkkkk Hellblade 2 fizeram um Carnaval pq seria na unreal. A da id eu concordo, pois é a engine mais escalável da indústria hj. Tá bem óbvio que ela quer generalizar do que optar por um desenvolvimento mais fechado, como é o caso da Sony. Um desenvolvimento mais fechado precisa de muita gente capacitada e trabalhar tudo em cima disso. Microsoft usa directx e nem prioriza mais seu console, não tem sentido algum vc ficar gastando um monte de dinheiro em algo específico e o resultado ser praticamente igual do que algo que já tem no mercado e é acessível.
O problema do motor da ID é que ele funciona bem em em ambientes fechados. Mas não tens exemplos de uso em mundos abertos, e ele pode não se dar muito bem com isso.
E não se dá, é só olhar o jogo The evil within 2 que é um mundo semi aberto e o jogo não tem um bom desempenho.
Rage é outro exemplo de como o motor não se deu muito bem em um ambiente aberto e a ação do jogo geralmente ocorria em locais do tipo masmorras ou muito mais fechados.
Leia minha outra resposta à você. O directx no Xbox não é como no PC, se não engano o próprio dev da ID falou isso uma vez, muito antes de serem comprados quando ele defendia que os devs deveriam ir para o Vulkan e não DX12 pois mesmo o Xbox não utilizava o DX12 padrão.
E como disseram, um motor pode ser muito bom para fazer uma coisa, mas ruim para situações genéricas. A unreal engine costumava ser o motor do Gears of War e sofreu um pouco em alguns jogos que não eram shooters lineares. Todos os jogos de mundo aberto da UE foram feitos com base em fortes modificações do core da engine uma vez que o código é aberto. É mais fácil pegar uma engine genérica mas de código aberto como a unreal e customizar com o que você precisa, do que pegar uma engine específica e ter que incluir coisas para o qual ela não foi feita. Como EPIC evoluiu e melhorou demais com a UE5, atualmente não compensa mais o trabalho com a engine proprietária. É mais fácil pegar um realease da UE5 e modificar com o que você quer por que o ponto de partida já é excelente, do que pegar a engine da geração passada e reformular totalmente.
O dev da ID Software defendia o uso de Vulkan porque dentre as APIs populares de PC, é a mais “closer to metal” que existe. E como Doom é um game com requisitos extremos de escalabilidade, quanto mais “closer to metal”, maior a liberdade de se optimizar performance.
O próprio Billy Khan (tech lead da ID) confirma isso a partir dos 7:58 dessa entrevista: https://www.youtube.com/watch?v=Zw0QEgOLhDs&t=478s
Embora o texto acima possua lógica, eu não faria essa generalização. Não é simples como parece abrir o código pronto da UE5 e já sair customizando para as necessidades específicas do estúdio. A curva de aprendizagem pode ser gigantesca, e certas customizações podem ser tão custosas quanto fazer outro sistema do zero. E embora a engine da geração passada demande reformulações, se trata de um código já “desbravado” pelo time de desenvolvimento.
Esse raciocínio seria similar a falar algo do tipo: “pra que fazer um novo sistema de vendas do zero? Basta pegar um pronto do mercado e customizar”. Os requisitos podem ser radicalmente diferentes.
Em um motor genérico destinado ao mercado em geral onde o fabricante ja se preocupou com a maioria dos requisitos para ser eficiente em todos os tipos de jogos, que tipo de otimizações voce acredita que seriam mais dificeis do que fazer algo do nada?!
A Unreal Engine 5 é o estado da arte para o mercado, e creio que não vai ter concorrência a não ser que o Unity tenha evoluído a ponto de ser uma boa alternativa AAA. Coitada da Crytek e da Cryengine.
Em relação do dev da ID, ele mencionou o Vulkan sem comparar com Directx 12, mas elas são iguais, inclusive com funções muito parecidas. Em outras discussões, ele clamou pelo vulkan pelo fato de ser multiplataforma e estar disponível em diversos sistemas operacionais incluindo Windows 7, o Directx 12 é uma coisa do Windows 10 e Windows 11, e ele não disse ver significado para os devs utilizarem,e quando questionado se era por compatibilidade com o Xbox, ele defendeu que o DX12 do Xbox é diferente do do PC, pelo menos se os devs quiserem acesso a todo o desempenho.
A UE5 de fato é uma engine bastante competitiva no que tange ao propósito geral. Mas não acho razoável colocar como se compensasse para todo estúdio migrar para trabalhar com uma UE5 customizada. A 4A acabou de entregar uma solução de RIGI bastante competitiva em Metro Exodus Enhanced, a Turn10 tem trabalhado fortemente na reformulação da Ftech. Então essa generalização não me soa apropriada, embora faça sentido para alguns estúdios.
Sobre o dev da ID, ele já comparou sim:
Vulkan Ray Tracing é o caminho a seguir. Para realmente progredir, precisamos adotar APIs abertas, colaborativas e multiplataforma. Vulkan é a melhor API para renderização em tempo real.
https://twitter.com/billykhan/status/1240149555301298176?s=20&t=bV6aJ1lJVA89BFH8erkISQ
Não estou a falar que Vulkan é melhor ou pior que DX12. É uma questão de requisitos, e a ID via dessa forma. Na entrevista que escrevi no comentário anterior, o Billy fala que vai sempre trabalhar com a API mais “baixo nível” (ou closer to metal) que o SKU permitir. Querem enxugar até a última gota de performance, para o Doom alcançar até os 1000fps como já fizeram em um teste.
Acho que jogos de corrida certamente não serão um local onde a unreal estará indo bem e representa uma característica específica. A 4A também é outro estúdio que gosta de construir sua tecnologia, embora seja visível que muitas coisas da engine deles lembram um game AA. Veja como o gameplay de Stalker 2 já parece um pouco acima do Metro Exodus e o estúdio provavelmente é menor.
“To truly make progress, we need to embrace open, collaborative, cross-platform APIs.”
O Billy Khan é um entusiasta de open source e multiplataforma. Eu até acho que dificilmente os jogos da ID serão exclusivos por que isso provavelmente chatearia bastante o estudio e não é interessante perder talentos. Mas eu creio que a comparação que ele faz é muito mais focada sobre a parte multiplataforma do que desempenho no geral. Dá uma olhada nesse estudo de caso de comparação de desempenho do RT:
https://tellusim.com/rt-perf/
Os testes estão comparando as APIs de RT do DX12 e do Vulkan, e também comparando com o desempenho do ray tracing utilizando os shaders de computação. Os números de VK e DX12 são muito parecidos, com pequenas diferenças entre NVIDIA e AMD que devem ser coisas relacionadas ao driver. E além da clara compreensão de que o hardware RT é mais performático na Nvidia e que o RT acelerado é muito mais rápido, me parece que as duas APIs são bastante equivalentes e a diferença é muito mais um suporte de driver já que na Nvidia o vulkan é um sopro de vento mais rápido, e na AMD o DX12 costuma ser mais rápido, do que capacidade da API.
Os estudios da MS não fazem jogos muito parecidos. Gears é muito diferente de Halo, embora seja shooter, Forza é muito diferente desses dois jogos, Sea of Thieves é muito diferente de todos os outros, Fable vai ser outra coisa nada a ver com os outros games citados. Talvez Hellblade seja algo que fosse mais relacionado a um jogo linear em terceira pessoa orientado por narrativa, mas a Ninja é um estúdio que já tem o histórico com a Unreal, não faz sentido ir para outro motor, tem uma curva de aprendizagem interna. A ID tem seu motor feito para o seu tipo de jogo que é igual ao da Machine Games.
No playstation é mais fácil, fora algumas alterações de temáticas, e um ou outro jogo, todo mundo ta desenvolvendo seu jogo em terceira pessoa orientado por narrativa, e eles tem direção de arte muito parecidas. Provavelmente o núcleo de todos os motores tem a mesma origem, a equipe ICE da Naughty Dog.
Não necessariamente. Um jogo como Spiderman possui requisitos de engine muito diferentes de um Uncharted por exemplo. Não dá para colocar como “parecidos”. Basta você assistir por exemplo a apresentação da Insomniac no GDC (https://www.youtube.com/watch?v=KDhKyIZd3O8), e reparar como os requisitos de streaming de assets são muito extremos, já que o Spiderman se movimenta a até 72 mph (ou 115 km/h). Além disso, em um jogo você tem liberdade total de movimentação sobre uma cidade viva, e o outro é linear, embora em certas situações se tem alguns espaços abertos para exploração. O fato de ambos serem em terceira pessoa e possuírem cutscenes diz muito pouco sobre requisitos de engine.
E do lado do Xbox, dos jogos que tu citou, Sea of Thieves e Gears usam a UE4, Hellblade 2 que usa a UE5. Não vejo muita diferença de citar a variedade de Sackboy, Destruction Allstars e Days Gone, três jogos que usam a UE4.
O motor da Insomniac vem de antes da compra pela Sony, mas Guerrilla, Santa Monica, Sucker Punch e Naughty Dog tem coisas muito parecidas nos seus jogos.
E como vc mesmo disse, os outros jogos usam a Unreal Engine, um motor de mercado definido para funcionar com qualquer cenário, por isso jogos lineares e de mundo aberto, embora fica bem claro que existe uma diferença absurda de qualidade gráfica entre os jogos lineares e de mundo aberto da UE4, que a demo do Matrix mostrou que eles resolveram na UE5. Days Gone é um belo exemplo de um dos maiores dowgrades da geração passada tem video comparando a revelação em 2016 e o resultado final e é muito nítido. Mesmo os locais de mundo semi aberto do Gears 5 tem uma perceptivel redução de qualidade.
A Insomniac foi só um exemplo. Ghost of Tsushima também é um jogo de exploração, e com requisitos bem diferentes de Uncharted. O fato do Jim Sakai não se movimentar com o cavalo a 110 km/h não faz da exploração um requisito parecido ao de cenários mais fechados de Uncharted. Aloy tem todo um mundo subaquático e voa em aves no Horizon Forbidden West, o que já te entrega requisitos razoavelmente diferentes de se implementar em engine.
Não, para desenvolver no Xbox o desenvolvedor precisa do GDKX que tem os recursos do XBox. O que a MS fez foi unificar o devkit, mas ela fez isso lá no Xbox One com o XDK e mesmo assim o desenvolvimento não é o mesmo. O Directx no Xbox não é idêntico ao do PC, tem vários recursos exclusivos e específicos. O que a MS auxilia é com um wrapper para deixar as coisas mais simples e não haver perda de tempo em conversões, mas mesmo assim, alguns jogos simplesmente são muito custosos no PC, como o Halo Infinite, mostrando como o Directx do Xbox é muito mais otimizado e direto no console. O próprio Gears of War e o Forza rodando no Xbox One básico como rodam mostram o quanto a API é mais otimizada no console muito mais fraco.
Se você pesquisar, vai econtrar exemplos de códigos do Devkit do Xbox no github da Microsoft, e poderá comparar com o código de PC, caso você tenha alguma familiaridade com desenvolvimento, inclusive pegar alguns insights interessantes como o fato do Xbox One ter tiudo 2 APIs de baixo nível durante sua vida, o D3D11.X e D3D12.X, algumas diferenças com o DX do PC. No GDK você verá que no Xbox Series eles atualizaram a API para D3D12.XS e modificaram o wrapper para mapear a biblioteca correta se um jogo for executado no Series, ou no One.
https://github.com/microsoft/Xbox-ATG-Samples
https://github.com/microsoft/GDK
https://github.com/microsoft/Xbox-GDK-Samples
No XDK não existe unificação com PC. Esse SDK é dedicado à plataforma Xbox, primeiramente com o Xbox 360 e por último com o Xbox One. O XDK tem uma customização própria do DirectX para o Xbox.
O GDK sim unifica Xbox Series e PC no mesmo pipeline, todos fazendo uso do DirectX 12 ultimate. Não tem como o código-fonte ser idêntico entre todos os SKUs porque cada um terá seu respectivo profile. Mas por estarem dentro do mesmo pipeline, compartilham de bibliotecas comuns, não existe uma customização diferente do DX12U para cada SKU.
https://www.reddit.com/r/XboxSeriesX/comments/jwxtb6/in_relation_to_the_xbox_general_development_kit/
Há situações específicas para a consola, isto apesar de a base ser a mesma. São livrarias específicas.
Sim, de fato o XDK nao tem o desenvolvimento do PC usei o X no local errado, é o GDK que unifica tudo, mas ele foi incluído no Xbox One em 2019 não começou com o Xbox Series. O GDK é a sigla de Gamecore Dev Kit, veio antes do Xbox Series e os atuais jogos do Xbox One são desenvolvidos com ele.
E embora as funcionalidades sejam as mesmas do DX12U em jogos nativos do Series, a forma como funcionam não é a mesma entre o PC e o console. A API é muito mais direta no console e usa bibliotecas específicas para o console. Da uma fuçada no link do github da MS, abre os arquivos C++ e da uma olhada nas partes comentadas dos códigos. O que a MS fez foi criar um wrapper pra tornar o desenvolvimento mais direto. É uma abordagem usada pela Sony tbm, confirmado indiretamente pelo dev do God of War em uma das entrevistas técnicas sobre o fato de terem portado para DX11 pra não ter de reescrever tudo já que a linguagem de alto nivel era parecida, e só nao tinham as extensões específicas de console. Inclusive o motivo de exigirem GPU mais poderosas era pela necessidade ter pelo menos 4GB de VRAM por causa das coisas específicas do console, mas já era muito mais potência do que o necessário.
Apesar do que dizes é verdade, oque se passa não é muito diferente de teres suporte diferente para GPUs diferentes. Há sim otimizações para a XBox, mas o API é o mesmíssimo, e base, o Core, é o mesmo.
Basicamente o que se passa é que a Microsoft pega nas partes em que a Xbox possui hardware que se revela diferente do usado no, e cria extensões para esse núcleo.
Isto é uma otimização pontual, que não toma em conta a génese. Basicamente ao partilhares o core, estás a permitir que a conceção do jogo seja igualmente partilhada, o que vai limitar o uso do hardware adicional da consola que vai servir apenas para refinamentos.
No fundo acabas como se tivesses numa situação cross gen, mas algo diferente pois aqui as capacidades dos sistemas são radicalmente diferentes, e apesar dos refinamentos da consola, a base partilhada tem muito mais poder bruto no PC.
É algo que no fundo se pode tornar bastante complexo de ser gerido.
Concordo que a core é o mesmo, mas na verdade foi o PC que se tornou mais parecido com os consoles nos últimos anos do que o contrário. O Directx 12, igual o Vulkan, entregou aos desenvolvedores o controle sobre o hardware que já era comum nos consoles mas eram tratados pelos drivers nas versões anteriores do DX e no OpenGL. O que sobrou de diferenças foi exatamente o que você descreveu, as características específicas dos consoles e coisas de arquitetura como coerência de memória. Nós nunca mais estaremos em situações onde o PC precisa ter o dobro de potencia do console como na era PS3/X360. Na verdade o DX11 já tinha reduzido muito esse gap e desde o inicio o PC já estava igualando ou superando com certa facilidade o X1 e PS4. Em jogos verdadeiramente otimizados para APIs de baixo nivel no PC, as diferenças já são bem menores. Exemplos, Doom Eternal com o Vulkan, e Gears 5 com o DX12. São dois jogos de alta qualidade técnica e que rodam muito bem em PCs até modestos, apesar que também brilham com o desempenho em consoles.
E também temos exemplos onde estão melhores no console como Elden Ring e Halo Infinite, embora nesses dois eu ache que foi muito mais uma questão de engine muito focada em consoles e devs acostumados com DX11.
É irrelevante se o PC precisa do Dobro ou de 20% mais. Otimização é otimização, e otimizar desde a conceção ainda faz muita diferença. O PC ao partilhar a base cria aqui uma situação em tudo comparável o cross gen.
Se no Cross gen, estás limitado pala performance da consola mais fraca, aqui a coisa ainda é mais complexa, pois o PC tem um poder bruto que as consolas não tem, e as consolas tem otimizações que o PC não tem. Logo, na conceção tens de seguir um caminho de compromisso.
A questão é que as thirds sempre tiveram no PC a plataforma de eleição para o desenvolvimento, pelo que havendo esta situação, à partida será sempre para o lado da consola que cai o machado. Mas tambem pode acontecer o contrário.
Nota que estamos a falar de limitações na conceção!