Como os desenvolvedores de jogos têm como alvo várias plataformas (Xbox 360, PS3, PC e Linux)?

Como os desenvolvedores de jogos têm como alvo várias plataformas ao mesmo tempo? Por exemplo, Xbox 360, PS3, PC e Linux. Para jogos 2D, é possível também segmentar o iPhone? Estou interessado nos mecanismos usados ​​(2D / 3D, etc), como o pipeline de compilação é configurado e, geralmente, quanto do "código principal" pode ser centralizado sem a necessidade de escrever ramificações de código específicas da plataforma.

Ou, se geralmente são mantidos troncos de código completamente separados para cada plataforma, como as bibliotecas / códigos são reutilizados (em termos de vinculação e modularização)?

Para o desenvolvimento comercial de jogos de console, a configuração de um sistema de construção para atingir 360, PC e PS3 simultaneamente é irritante, mas não é particularmente difícil. O kit de desenvolvimento 360 é simplesmente um novo alvo para o Visual Studio + algumas ferramentas e usa um compilador muito semelhante ao compilador MSVC ++ padrão do Windows. O PS3 usa um back-end do compilador GCC, mas se conecta facilmente ao front-end do visual studio. Para jogabilidade e código de utilidade geral, geralmente deve ser possível ter um código que seja 99% o mesmo entre as três plataformas. Existem algumas incompatibilidades entre o GCC e o MSVC ++, mas, felizmente, se você resolver isso, o Linux (supondo que você use uma versão do gcc próxima à do PS3) não terá muito mais problemas. O último 1% de código diferente, normalmente você pode corrigir com o kludgy #defines.

Após as etapas básicas de construção, o grande obstáculo serão os sistemas gráficos, bem como quaisquer elementos de alto desempenho do seu jogo. Para esses elementos, você realmente acabará escrevendo o código personalizado da plataforma ou usando um mecanismo existente. A memória será um grande problema, mas isso é para outra questão. Um projeto comercial em que trabalhei foi capaz de obter versões de console de uma fonte original de PC com bastante facilidade, mas fazê-las realmente funcionar bem era um problema completamente diferente.

Se você deseja integrar o iPhone também, pode optar por algum tipo de solução de mecanismo / middleware existente. A configuração do openGL + objetivo C para iPhone não se encaixa muito bem com nenhuma outra plataforma. Essa é uma escolha da parte da Apple, pois desencoraja fortemente o uso de middleware interpretado em qualquer aplicativo do iPhone.

Para a maioria das plataformas, você pode escrever subsistemas que abstraem das APIs específicas usadas para chamar e recuperar informações da plataforma em que você está executando. As APIs de E / S são geralmente as mais fáceis de abstrair - todos os sistemas de arquivos funcionam com algumas suposições bastante básicas sobre abertura, fechamento e leitura de arquivos, mesmo quando você considera as chamadas assíncronas. Então você tem seus sistemas principais, como ler a entrada do controlador, consultar a hora, acessar a memória e as primitivas de encadeamento, a maioria das quais funciona da mesma maneira.

Até os gráficos podem ser abstraídos em grande parte e, de fato, na maioria dos mecanismos bons. Mas você precisa empacotar as coisas 'renderizáveis' em caixas-pretas onde não é permitido saber o que está acontecendo dentro delas. Você sabe que tem uma "coisa" que renderiza em uma posição específica do mundo. Você não sabe como é renderizado, apenas é. E a camada de abstração gráfica cuida de todos os detalhes da exibição na tela. Os pipelines de construção específicos da plataforma empacotam os dados gráficos de forma que possam ser referenciados no mecanismo sem realmente saber como eles são representados internamente.

No entanto, quando tudo se resume a enviar um jogo, há algumas partes que você simplesmente não pode abstrair. Seria ridículo pensar que você poderia enviar o mesmo código no iPhone como faria no 360 ou PS3, já que os mecanismos de entrada, o modo fundamental de operação e os recursos da plataforma são muito diferentes. Você poderia criar um título do tamanho de um iPhone no 360, mas ele teria que limitar seus mecanismos de entrada apenas àqueles que o 360 pode suportar. Portanto, um cursor virtual na tela simula um dedo e, possivelmente, usa o joystick onde a entrada do acelerômetro 3D é usada.

Mais sensatamente, partes do jogo podem ser escritas de maneira reutilizável e módulos de código individuais podem ser portados entre plataformas, mesmo que a maioria do título seja diferente. Por exemplo, se você tem uma máquina de estado de IA, isso realmente não importa se está sendo executado no 360, PC ou iPhone. Seu jogo usará muitos desses componentes, e desde que eles tenham sido projetados bem para receber entradas e saídas bem definidas, o resto do jogo poderá ser envolvido em torno deles, independentemente da plataforma, e evitar a necessidade de reescrevê-los. componentes.

Essa reutilização é a chave para o desenvolvimento de várias plataformas, sem procurar um mecanismo de tamanho único que funcione em todas as plataformas. Mesmo que tal coisa existisse, seria tão prejudicada por ter que trabalhar no menor denominador comum que não seria de muita utilidade fazer jogos.

Uma maneira é usar um mecanismo de múltiplas plataformas, como Torque ou Unity3D . Mas não acho que eles funcionem em todas essas plataformas. Há também outra maneira: desenvolver um mecanismo ...