Devo usar Lua para lógica de jogo em dispositivos móveis?


33

Como acima, realmente,

Estou escrevendo um jogo baseado no Android no meu tempo livre (Android porque é gratuito e não tenho nenhuma aspiração real de fazer nada comercial).

A lógica do jogo vem de um modelo baseado em componentes muito típico, no qual as entidades existem e têm componentes anexados a elas e as mensagens são enviadas para lá e para cá, a fim de fazer as coisas acontecerem.

Obviamente, a camada para executar realmente é fina e, se eu escrevesse uma versão para iPhone deste aplicativo, teria que reescrever o renderizador e o driver principal (deste sistema baseado em componentes) no Objetivo C.

As entidades são apenas arquivos simples que determinam os nomes dos componentes a serem adicionados e os componentes são objetos simples e de propósito único que contêm a lógica da entidade.

Agora, se eu escrever toda a lógica desses componentes em Java, teria que reescrevê-los no Objective C se decidisse fazer uma porta para o iPhone. Como a maior parte da lógica do aplicativo está contida nesses componentes, eles seriam, em um mundo ideal, escritos em alguma linguagem / script / DSL independente de plataforma que poderia ser carregada no aplicativo em qualquer plataforma.

No entanto, fui levado a acreditar que este não é um mundo ideal e que o desempenho de Lua etc. em dispositivos móveis ainda não está preparado, que a sobrecarga é excessiva e que eu teria problemas mais tarde se eu foi por esse caminho?

Este é realmente o caso? Obviamente, essa é apenas uma pergunta hipotética. Fico feliz em escrevê-las todas em Java, pois é simples e fácil fazer as coisas acontecerem, mas digo que realmente gosto de fazer esse jogo (improvável, dado o quanto atualmente não gosto de ter que lidar com todos esses dispositivos móveis diferentes) e eu queria criar um jogo comercialmente viável - eu usaria Lua ou aceitaria o sucesso quando se tratasse de portar e apenas reescrever todo o código?

Respostas:


17

No que diz respeito às linguagens de script, Lua é muito rápido, mas, como qualquer coisa, varia dependendo do processador. Por exemplo, Lua não seria ótimo em uma plataforma de console porque tende a ser muito ramificada, e algumas plataformas de console ramificam muito lentamente. Para melhor responder sua pergunta, sugiro executar alguns benchmarks. Veja a rapidez com que Lua executa vários algoritmos no dispositivo. Eu suspeito que você ficaria bem, desde que você não faça nenhuma matemática ou iteração pesada no seu código de script. (Você não deveria fazer isso de qualquer maneira. São scripts. Faça cálculos no mecanismo.)

Dito isto, o script não é uma bala de prata para a independência da plataforma. Pode ser necessário reescrever o Obj-C de qualquer maneira, se você portar para o iPhone devido às restrições da Apple na execução de código dinâmico. Não tenho um link de improviso, mas pode valer a pena ler. Apple mal permite código gerenciado (você precisa de permissão especial para executar uma distribuição especial). Eles certamente não permitirão uma implementação de Lua na loja de aplicativos.

Aparentemente, eu estava enganado sobre a coisa Lua no iphone. Dê uma olhada nos comentários abaixo.


9
Lua é amplamente usada em aplicativos para iPhone e foram feitas alterações nos termos que o permitem. Veja aqui: appleoutsider.com/2010/06/10/hello-lua
Colin Gislason

5
Muitos aplicativos de console realmente usam LUA. Sim, é ramificado - mas isso não importa se você controla a lógica de alto nível. Apenas não o chame do seu loop de renderização;) Até onde eu sei, a LUA para jogos está bem com as recentes alterações no contrato do desenvolvedor - há muitos jogos que são movidos pela LUA. Mas, como em qualquer desenvolvimento em uma plataforma fechada, solicite respostas definitivas ao proprietário da plataforma (por exemplo, Apple). Além disso, não há necessidade de Obj-C - o iPhone permite C / C ++ muito bem. (Eu recomendo que você faça UIKit nada em Obj-C, embora reduzido fator de dor.)
Rachel Blum

7
Vá vá caixa de sabão mágico. Lua é um substantivo, não um acrônimo, você nunca escreveria JAVA. Lua significa lua. Você não escreveria LUA. obrigado - o nazista lau.
Deft_code 20/08/10

2
Infelizmente, conheço muitas pessoas que escrevem "JAVA".

1
Eu usei lua pesadamente no NDS (que é muito menos poderoso que um iPhone) e funcionou muito rápido. Rápido o suficiente para fazermos mais da metade da lógica de um jogo diretamente na lua.
Klaim

7

A implementação C de Lua foi projetada especificamente para ser executada em dispositivos incorporados. É pequeno e rápido (para uma linguagem de script). Eu teria pensado que era bom para pelo menos tarefas leves.


4

Certo. É muito improvável que a lógica de script seja seu gargalo (você realmente criará um perfil com Shark ou Instruments, certo?). Eu trabalhei na versão para iPhone do Marooned, que usava muito Lua para a lógica do jogo. Eu fiz muitos ajustes de desempenho, e basicamente Lua foi de 0%.

(Lua era uma área cinzenta quando lançamos o Marooned, mas desde então foi oficialmente abençoada pelo desenvolvimento do iOS.)



1

Depende um pouco de quanto da lógica do seu jogo está incorporada nos scripts. Em geral, o LUA é usado como cola de alto nível, mas muito do trabalho pesado ocorre através de C (++). Sim, o LUA é rápido no que diz respeito às linguagens de script - você ainda está olhando para uma desaceleração em comparação com os idiomas nativos de cerca de 30 a 50 vezes, por isso depende realmente de quanto está acontecendo no LUA.


0

Você pode escrever todo o jogo em Lua e evitar Java / ObjectiveC / C / C ++ completamente.

Para o desenvolvimento de plataforma cruzada, use Corona . É gratuito para uso até que você planeje enviar para a App Store ou Android Marketplace.

Se você deseja segmentar o iPhone / Pad / Touch, dê uma olhada na cera .

Como nota lateral @Sean Edwards: estive envolvido no envio de cinco títulos para Nintendo DS, Wii, Sony PSP e Xbox360, que usavam o mesmo mecanismo e foram roteirizados em Lua. É amplamente utilizado em consoles e celulares.

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.