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?
fonte
Respostas:
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.
fonte
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.
fonte
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.
fonte
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?
fonte
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.
fonte
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.
fonte
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.
fonte
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.
fonte
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).
fonte