Quando devo usar um mecanismo de física? [fechadas]

12

Desde que descobri o Box2D , estou usando-o para qualquer tipo de aplicativo semelhante ao jogo que tento escrever, desde protótipos muito pequenos ou programas pequenos para testar algo a projetos reais.

Graças a isso, é muito fácil lidar com qualquer coisa, desde colisões até a física real.

Às vezes, porém, tenho algumas dúvidas: se eu apenas tiver que lidar com círculos ou AABB e não precisar de ferramentas físicas avançadas (juntas ou coisas assim), acho que um mecanismo de física poderia adicionar algo grande, sobrecarga desnecessária.

Para retomar minha pergunta: você usaria o Box2D (ou outros mecanismos de física) em um jogo em que a física é realmente simples (como Super Mario, digamos)? E se não, por que?

physics peoro
fonte
2
Faça o que parece certo. Você acha que seu jogo precisa de um mecanismo de física? Você acha que Mario se beneficiaria com o Box2D? O Mario mais novo certamente tem uma sensação agradável com a física agradável, mas não parece nada parecido com o que eu já vi construído no Box2D.
Jeff
@ Jeff: Isso depende se a pergunta "Quando devo usar o Box2D?" ou "Quando devo usar um mecanismo de física?". O novo Mario certamente contém um mecanismo de física.
1
@ Joe Wreschnig: Sim, mas há sempre um caso em que um mecanismo de física não é usado? Só o tempo em que consigo pensar seria uma aventura de texto ou aponte e clique. Eu acho que isso depende de como geral, você quer fazer a sua definição de motor de física
Jeff
@ Jeff: Poucos jogos de quebra-cabeça (não-físicos) precisam de um, por exemplo, Tetris, Bejeweled. Nos jogos de ação, eu poderia argumentar que a maioria dos shmups 2D não se beneficia de um mecanismo de física, pois geralmente precisam apenas de verificações de sobreposição AABB / círculo, sem resposta de colisão, caminhos de movimento absolutamente fixos e velocidade constante. Platformers, no entanto, são todos sobre física.

Respostas:

8

Se a memória, o espaço em disco, o esforço de desenvolvimento ou o tempo do processador usado para o Box2D forem muito altos para seus objetivos, não o utilize. Caso contrário, não há razão para evitá-lo se você achar útil.

Gregory Avery-Weir
fonte
2
Isso é tudo o que realmente se resume. Se isso facilita a sua vida e não o bloqueia das plataformas que você deseja, é uma vitória, mesmo que você não use partes dela.
1
Ou, em outras palavras - "A única razão para reinventar a roda é aprender a reinventar a roda".
Exilyth 29/11
4

Algo tão fácil quanto o Super Mario não, pois ele realmente não tem muita física. (Mario não afeta a física de outro objeto com seu salto)

se você estiver usando física no sentido de vários itens (mais de um) usando física para afetar o resultado de outros objetos, eu usaria um mecanismo.

Assustadores
fonte
Por outro lado, Mario tem momento, aceleração, tamanho variável e colisão direcional, todos os quais você obtém "de graça" com um mecanismo de física e não são apenas simples verificações de sobreposição delimitadoras.
Eu concordo - acho que na maioria das vezes um mecanismo de física fornecerá muitas coisas que seriam uma perda de tempo para você se implementar.
Christopher Horenstein
3
É verdade que é sempre melhor não inventar a roda, só acho que, se eu quiser apenas uma roda, não vou tomar uma planta para um carro. Além disso, você saberá mais sobre o seu jogo como um todo e mais fácil de alterar / alterar a física.
Spooks
1
Essa é uma analogia realmente horrível. É mais assim: você quer uma roda e eixos e talvez uma coluna de direção e um motor, mas talvez não o painel ou as janelas de potência.
3
quem não gostaria de janelas elétricas?
Spooks
2

Minha resposta é sim, use absolutamente um mecanismo de física como o Box2D para coisas simples, porque você não deve gastar tempo desnecessário de desenvolvimento implementando alguns dos recursos que obtém rapidamente de um mecanismo de física. Por exemplo, defina um corpo estático e solte um corpo dinâmico, e aplique força ao seu corpo dinâmico para entrada direcional, e você terá um jogo de plataformas em alguns minutos. Não acho que um mecanismo adicione sobrecarga suficiente para fazer com que isso não valha a pena.

Christopher Horenstein
fonte
3
no entanto, pode-se dizer que descobrir como implementar e usar o Box2D levaria mais tempo do que criar uma física simples. (embora eu acho que isso depende da extensão do uso da física)
Spooks
1
@ Spooks: Não consigo imaginar nada "mais fácil" do que o Box2D que ainda seja útil.
Estou de pleno acordo com Joe aqui; simplesmente não há substituto simples para a utilidade que acompanha o uso do Box2D. Não consigo imaginar codificar algo que atenda às necessidades de alguém mais rapidamente do que aprender a criar alguns equipamentos e definir a gravidade com o Box2D.
Christopher Horenstein
1

Se a "física" em um jogo é simples, não há necessidade de importar um mecanismo de física.

Uso o termo física livremente, já que há uma diferença entre modelar física e simular phyiscs. Uma coisa muito importante para diferenciar.

Por exemplo, em Mario Bros. quando você corre e para, desliza um pouco. Pense em como você pode implementar isso.

Você pode modelá-lo definindo todas as variáveis ​​necessárias: por exemplo. massa, gravidade, coeficiente de atrito, empuxo etc. e depois calcular sua nova velocidade, aceleração etc.

Mas vale a pena? Você pode simular o mesmo efeito, diminuindo a velocidade dos jogadores enquanto eles não estão em movimento ...

Algo como:

if( pressing movement key ) { 
 speed = 5; 
} else { 
 if(speed) speed--; // slide!
}

A diferença é que uma é física e a outra não. Há prós e contras para ambos. Mas como regra geral para jogos simples, é muito mais fácil falsificá-lo.

aaronfarr
fonte
1
Esse tipo de física é nojento. Se você pretende falsificá-lo, pode torná-lo agradável. atrito = 0,9 ou algum número abaixo de 1. speedX * = atrito; speedY * = atrito;
AttackingHobo
2
É claro que, no final do projeto, ele se transforma em "if (pressionando a tecla de movimento e não se movendo e no gelo e não debaixo d'água e você tem esse poder especial e não está andando de bota e ...)".
@ AttackingHobo: O objetivo do post não é criar um bom algoritmo de deslizamento. É para ilustrar a diferença entre uma simulação e um modelo.
aaronfarr
@ Joe: Essas são apenas modificações na sua variável de atrito .. talvez você e o @AttackingHobo devam conversar: P Com um mecanismo de física, você precisa definir propriedades para cada objeto no jogo. Meu argumento é que a conexão de um mecanismo de física para jogos simples não deve ser automática. É situacional.
Aaronfarr #
1
@aaronfarr: Não há diferença entre uma simulação e um modelo; para esses fins, são sinônimos. Tudo o que você mostrou é que uma parte isolada de um modelo / simulação de brinquedo é menos código que a totalidade do Box2D.
0

Você deve decidir de acordo com a situação

Profissionais usando seu mecanismo personalizado

  • Software sob controle (nenhuma alteração devido a nova versão)
  • Adequado para o seu jogo (apenas os recursos necessários para o jogo, da maneira que você precisa)
  • Flexibilidade (qualquer dinâmica louca que você quiser pode ser codificada, qualquer recurso futuro não dependeria do mecanismo)
  • Experiência de aprendizado (talvez um dia você precise aprimorar um mecanismo e criar um)
  • Menos estudo e programação de recursos simples (às vezes, fazer algo com um mecanismo pode exigir a compreensão profunda de sua estrutura. E pode não ser digno)
  • Maior desempenho para recursos simples (para recursos específicos simples, você pode obter um desempenho superior ao de um mecanismo de uso geral)
  • Menos memória (o objeto e o código podem ocupar muito menos espaço e memória quando apenas os recursos necessários são usados)

Profissionais do mecanismo físico de prateleira:

  • Pode se adaptar ao novo hardware e novo sistema operacional sem muito esforço
  • Menos esforço de estudo e programação para recursos complexos
  • Maior desempenho para recursos complexos
Dimitri Ognibene
fonte