Desenvolvimento independente de plataforma cruzada


34

Alguns anos atrás, se você escrevesse em C e algum subconjunto de C ++ e usasse um número suficiente de abstrações de plataforma (via SDL ou qualquer outra coisa), poderia executar em todas as plataformas que um indie pudesse acessar - Linux, Windows, Mac OS de várias versões , coisas obscuras como o BeOS, e os consoles abertos como o GP2X e o Dreamcast pós-morte. Se você tiver um contrato para uma plataforma fechada em algum momento, também poderá portar seu jogo para essa plataforma com alterações "mínimas" no código.

Hoje, os desenvolvedores independentes precisam usar o XNA para acessar o Xbox 360 (e o próximo telefone com Windows); não deve usar o XNA para funcionar em qualquer outro lugar que não seja o Windows; até recentemente, tinha que usar Java no Android; O Flash não funciona em telefones, o HTML5 não funciona no IE. Diferentemente, por exemplo, DirectX vs. OpenGL ou Windows vs. Unix, essas são alterações no idioma principal em que você escreve seu código e não podem ser ocultadas sem, basicamente, escrever um compilador. Você pode mover alguma lógica do jogo para scripts e incluir um intérprete - exceto quando não puder, porque o iPhone SDK não permite e o desempenho é prejudicado porque ninguém permite o JIT.

Então, o que você pode fazer se quiser um jogo portátil realmente multiplataforma, ou mesmo apenas um corpo significativo de mecanismo e código lógico?

Isso não é um problema, porque as plataformas divergem fundamentalmente - não vale a pena tentar segmentar um iPhone e o Xbox 360 com qualquer código compartilhado, porque esse jogo seria ruim? (Acho isso muito improvável. Posso ver facilmente o desejo de compartilhar um jogo entre um telefone Windows Mobile e um Android ou um Xbox 360 e um iPad.) As interfaces estão tão de alto nível agora que o tempo de transferência é insignificante? (Acredito que isso seja para aplicativos de negócios, mas não para jogos com requisitos rígidos de desempenho.)

Isso vai se tornar mais pronunciado no futuro? A divisão será, de certa forma assustadora, ainda abaixo das linhas dos fornecedores? Todos nós confiaremos no middleware de alto nível, como o Flash ou o Unity, para fazer qualquer coisa entre plataformas?

tl; dr - Está portando um problema, será um problema maior no futuro e, em caso afirmativo, como o solucionamos?


2
A Seção 3.3.2 do Contrato de Licença do Programa de Desenvolvedor do iPhone permite a criação de scripts de jogos agora, embora ainda seja um pouco complicado. - "Não obstante o acima exposto, com o consentimento prévio por escrito da Apple, um Aplicativo pode usar código interpretado incorporado de maneira limitada se esse uso for apenas para fornecer recursos ou funcionalidades secundárias que sejam consistentes com o objetivo pretendido e anunciado do Aplicativo".
Bachus

3
A Apple mudou o contrato de licença novamente ontem, e os scripts de jogos agora estão totalmente corretos. - "O código interpretado só pode ser usado em um Aplicativo se todos os scripts, códigos e intérpretes forem empacotados no Aplicativo e não forem baixados. A única exceção ao anterior é os scripts e códigos baixados e executados pela estrutura interna do WebKit da Apple".
Bachus

Eu diria que você juntou um monte de coisas que não pertencem - dispositivos móveis, consoles, PCs e jogos baseados na Web? Consoles e PCs, com certeza, devem poder compartilhar uma base de código com alguns ajustes. Os dispositivos móveis são muito diferentes em capacidade do hardware de computação dedicado (em termos de energia gráfica bruta, armazenamento, encadeamento etc.), e assim você nem seria capaz de usar as mesmas soluções. E jogos na web são, você sabe, páginas da web . O que você quer? A fragmentação aqui é entre paradigmas de dispositivos, não meras arquiteturas de computação.
ChrisE

Na verdade, eu não disse nada sobre jogos na web. Eu acho que é razoável querer executar o mesmo código em todos os dispositivos - mapeamento de entrada ou uma API de gráficos abstratos, ou um sistema de entidades, análise de arquivos, rede - esses são os mesmos paradigmas básicos, independentemente da plataforma. Mas a questão também tem 8 meses e surgiu de preocupações que não se aplicam muito desde que o NDK reuniu mais suporte no Android e a Apple interrompeu suas políticas estúpidas.

Quero dizer, você mencionou HTML5 ... isso é destinado a jogos da web, certo?
ChrisE

Respostas:


14

O mecanismo do Unity oferece a você uma grande parte do caminho até lá. Escreva uma vez e você terá o Mac / Windows Standalone e o webplayer. Ajuste suas entradas e lembre-se de suas chamadas de sorteio e você estará no iOS / Android.


12

Para um pequeno desenvolvedor independente, com recursos / tempo limitados (e talvez um foco maior em 'tornar algo interessante' do que 'tornar lucrativo'), tentar entrar em várias plataformas desde o início pode ser contraproducente. É preciso muito esforço para projetar ferramentas e tecnologia sólidas em várias plataformas (APIs gráficas diferentes, capacidade de suporte, dispositivos de entrada e muito mais) - tempo que poderia ser gasto no lado mais criativo do desenvolvimento de jogos.

Mas você provavelmente quer ter um ótimo jogo que funcione muito bem em uma plataforma antes de se preocupar em colocá-lo no maior número possível de plataformas! Se o jogo é um flop, não faz sentido perder tempo e esforço para torná-lo um flop multiplataforma, existe?

Se você estiver codificando em C / C ++, principalmente do zero, desde que você mantenha o código razoavelmente modular e tome decisões sensatas sobre formatos de dados e middleware / bibliotecas, o suporte a outras plataformas posteriormente não deve ser muito doloroso.

Se as ferramentas / ferramentas de plataforma cruzada de terceiros (por exemplo, Unity) são uma opção para o seu projeto, certamente vale a pena considerar.

As principais 'plataformas de problemas' para indies parecem ser os jogos independentes do Xbox360 (somente C #, acesso limitado à rede etc.) e possivelmente o Android (diferenças enormes no desempenho do dispositivo / tamanho da tela / dispositivos de entrada). Se você estiver determinado a apoiá-los, espere um trabalho de porte mais considerável ou planeje se concentrar neles exclusivamente.


Sim, o Unity3D é ótimo. www.unity3D.com
BerggreenDK

Concordo com o @bluescrn - é melhor saber quase tudo sobre quase nada, do que saber quase nada sobre tudo: Jack de todas as características, mestre de nenhuma.
Rodrigo-silveira

3

Você diz desenvolvimento independente de plataforma cruzada . O maior obstáculo então são os recursos, e isso significa falta de tempo na maioria das vezes, mas também falta de know-how e, possivelmente, de finanças (taxas de licença, compra de dispositivos etc.).

Independente ou não, o maior obstáculo é, na verdade, o design. Como você diz, um jogo que roda no Xbox 360 e no iPad pode funcionar, mas também precisa ser fundamentalmente diferente em termos de design. O 360 tem um controlador, o iPad uma tela de toque. Além disso, o desenvolvimento para o 360 é feito no Windows usando C # como linguagem, o iPad pode ser direcionado apenas em computadores Mac OS e usando C, C ++ ou Objective-C. Ou Javascript, se você preferir. Algumas coisas simplesmente não combinam tão bem o que você faz.

O que você diz sobre as diferentes plataformas é válido hoje. Use C / C ++ e SDL e você poderá escrever seu programa em várias plataformas em máquinas semelhantes a PCs, provavelmente muito mais suavemente do que anos atrás. No entanto, sempre foi um problema e sempre será um problema para portar jogos do PC para o console e para o celular e vice-versa. Ele se tornou mais pronunciado nos últimos anos ao permitir que os desenvolvedores independentes programem consoles (ou desenvolvedores que acessam o site para criar jogos caseiros) e o aumento de dispositivos móveis poderosos o suficiente para rodar jogos.

Portar tem os mesmos problemas que já teve, mas há mais dispositivos para portar. E algumas portas simplesmente não fazem sentido sem redesenhar o núcleo do jogo. Este não é um problema que possa ser resolvido, é um que você deve considerar desde o início, mesmo antes de escrever sua primeira linha de código. Então será administrável, nem mais, nem menos.


Na verdade, eu diria que tempo para portar é algo que um desenvolvedor / grupo independente tem mais chances de ter do que um grande estúdio orientado a editores.

Existem muitos designs de jogos que fazem sentido em todas as plataformas - jogos de tabuleiro virtuais baseados em turnos, por exemplo, são consistentemente um sucesso em todas as plataformas. O mesmo acontece com muitos jogos de quebra-cabeça de blocos caindo / combinando. Eles não podem mais ser "portados" no sentido tradicional - mover um jogo, por exemplo, XBLIG para o iPhone, é uma reescrita garantida de todo o código.

3

Uma estrutura de interface simples, portátil e aberta é realmente necessária, eu acho. Algumas reflexões:

Atualmente, parece haver quatro tipos comuns de métodos de entrada de jogos: teclados, ratos, controladores e superfícies multi-touch. (Vou abordar os problemas de diferentes capacidades entre, por exemplo, gamepads e joysticks por enquanto, embora isso deva ser resolvido.)

Idealmente, nosso desenvolvedor poderia especificar de uma maneira geral algumas UIs diferentes que fazem sentido para o tipo de jogo que está sendo escrito. (Eles podem decidir fornecer uma interface de usuário do teclado e do mouse, uma interface do mouse apenas para mouse e uma interface de toque múltiplo, como exemplo arbitrário.)

A estrutura é responsável por mediar a IO entre a plataforma e o código do jogo, semelhante à maneira como as estruturas da GUI de plataforma cruzada, como QT e GTK, funcionam.

Ter essa estrutura não resolveria o problema de requisitos de idioma incompatíveis, mas pelo menos encapsularia todas as chamadas específicas do sistema por trás de uma API comum, o que tornaria a transferência de linguagem muito mais direta.

Bem, agora que escrevi tudo isso: alguém sabe se uma estrutura como essa já existe?


3

Em projetos como o MonoTouch e o XNATouch, parecia que o XNA poderia levá-lo à maioria das plataformas com um pouco de ajustes. Infelizmente, a Apple meio que torpedeou que, quando eles mudaram seus Termos e Condições para restringir quais idiomas você pode usar. O Unity repassa praticamente tudo agora, embora no XBOX você obtenha XBLA, mas não XBLIG, portanto, não é uma opção para indies menores.

Uma abordagem pode ser criar uma estrutura que use as mesmas convenções em vários idiomas / plataformas; então, é apenas uma questão de ajustar a sintaxe dos jogos de portos. Talvez você queira iniciar seu jogo no Flash, que pode ser desenvolvido rapidamente e atingir um grande público, se for uma porta de sucesso para iPhone, XNA etc. Dessa forma, você sabe que tem um jogo divertido antes de se comprometer demais.


maçã estúpida, que restringe as linguagens de programação! QUEM?!?!
FreshJays

2

Eu acho que isso é um problema econômico, não um problema técnico. Plataformas como o xbox360 têm um forte incentivo para serem excludentes, porque estão tentando fazer com que os usuários escolham sua plataforma em vez de outra plataforma. "Temos esses jogos exclusivos legais" é muito mais interessante do que "também podemos jogar esses jogos que todo mundo tem". O ecossistema é dominado pelos fabricantes de hardware.

Suspeito que isso mude quando a jogabilidade em rede social amadurecer, porque há potencialmente muito mais dinheiro em colocar todos no mesmo sistema de jogos sociais do que em criar outro FPS com gráficos sensuais.


2

Acabei de descobrir Haxe e NME . Ele afirma ser um aplicativo de plataforma cruzada que suporta todos os principais computadores e dispositivos móveis e Flash, a partir de uma base de código. Vale uma olhada.


1

Uma ferramenta de desenvolvimento multiplataforma que é tão nova que eu não recomendo necessariamente é http://www.monkeycoder.co.nz/

Ele atinge todas as plataformas que você mencionou.

Embora seja muito novo para realmente julgar, ele tem um ótimo pedigree: seu criador criou o Blitz3D e o BlitzMax, que eram ótimas ferramentas de desenvolvimento para desenvolvedores independentes de jogos.


0

Tive sorte com o SDK do airplay - pelo menos no x86 e aparentemente direciona bem para o iPhone (embora ainda precise ainda colocar um aplicativo no iPhone).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.