[Dúvida - Debate] Matemática e física nos jogos.

Cara, são muitas as aplicações.
Vou te explicar uma, que servirá de base para você.

Primeiro, observe onde se localiza: L e X.

Suponha que o ângulo da direita tenha 45º.
Suponha que L seja 100.

Quanto vale X?

Código:

X=lengthdir_x(100, 45)

Qual é a altura do triângulo formado?

Código:

Y=lengthdir_y(100, 45)

Teria como calcular na base do seno e do cosseno:

Código:

X=L*cos(degtorad(45));

Código:

Y=L*sin(degtorad(45));

O degtorad só é preciso porque o game maker só trabalha com radianos.

Edit:
Aplicando num jogo de top down, olha o que dá para fazer:

Código:

if (keyboard_check_pressed(vk_space)) {
 instance_create(x+lengthdir_x(16, image_angle),y+lengthdir_y(16, image_angle), obj_bala);
}

Isso faz com que se crie uma bala fora do player. De acordo com image_angle.

E só para complementar:
Se o ângulo for 0, então o x será exatamente o numero colocado.
Se o ângulo for 90 ou 270, então o x será 0.
Se for 180, então o x será o numero colocado com o sinal trocado.


Até mais!

Pedro Henrique escreveu:Cara, são muitas as aplicações.
Vou te explicar uma, que servirá de base para você.

Primeiro, observe onde se localiza: L e X.

Suponha que o ângulo da direita tenha 45º.
Suponha que L seja 100.

Quanto vale X?

Código:

X=lengthdir_x(100, 45)

Qual é a altura do triângulo formado?

Código:

Y=lengthdir_y(100, 45)

Teria como calcular na base do seno e do cosseno:

Código:

X=L*cos(degtorad(45));

Código:

Y=L*sin(degtorad(45));

O degtorad só é preciso porque o game maker só trabalha com radianos.

Até mais!

Certo, mais em um jogo como posso aplicar isso, to viajando legal.

Eu editei minha mensagem enquanto você postava.
Olhe ela novamente que tem um exemplo.

Até mais!

Beleza mais se for observar esse tipo de aplicação e totalmente desnecessária, não sei se sou eu que ainda não captei direito, mais ainda não vejo uma aplicação prática, de tais funções do gm, e mais uma coisa será que pode-se afirmar que possui matemática avançada na programação, ou somente matemática básica.

Não tenho muito tempo agora, mas sugiro que veja uma engine que eu fiz:
https://gmbr.forumeiros.com/t15335-acertar-alvo-com-tiro-parabolico

É uma aplicação da fisica.
Embora apresente um bug, eu já consertei, mas não atualizei o link.
Se gostar, eu mando uma debugada.

Até mais!

O tópico já tem uns dias, mas não muitos, então vou postar, já que é um tema interessante.

1 - Gravidade/Aceleração
O GM tem a variável gravity. Mas se você quiser ter de algum jeito mais controle sobre a gravidade, você pode fazer a sua própria. Porém, não é tão simplérrimo quanto alguns podem pensar.
Um exemplo de motivo para se querer ter mais controle sobre a gravidade: O gravity do GM trabalha com h/vspeed. Se você preferir fazer o movimento por {x += n; y += n}, o gravity já não serve.

Como eu disse, não é tão simples assim: Diferente do que muitos pensariam, isso não produz uma gravidade correta:

Código:

velocidade_vertical += gravidade;
y += velocidade_vertical;

O correto é utilizar a equação física da posição com aceleração constante (conhecida por alguns como "sorvetão"):
Δs = v*t + a*t/2
Que pode ser aplicada considerando que o tempo é sempre 1 step, resultando nisso:

Código:

y += velocidade_vertical*1 + gravidade*1/2
velocidade_vertical += gravidade;

É assim que funciona a gravidade embutida no GM (do modo correto).

Um exemplo "vivo" é o jogo que eu fiz para o CQ #004, Labirinto de Gravidade, um jogo em que você tem que levar uma bola por um "labirinto" até o objetivo, usando a gravidade (a bola é atraída na direção do mouse). Está incompleto, vez ou outra dá um bug, mas isso não vem ao caso.
A questão é que eu não usei o sistema de colisão do GM. Eu fiz uma codaralhada de mais de 150 linhas para o sistema de gravidade e colisão. Daí você me pergunta: "WT...??? PRA QUÊ ISSO?". Eu respondo: ou melhor, desenho:

A - Imagine comigo a situação no seguinte desenho:

A bola está se movendo com uma velocidade consideravelmente grande. Tudo o que o sistema de colisão do GM poderia fazer é inverter a direção após bater. Além disso, observe a linha vermelha: nesse movimento, a bola colidiria com a coluna da esquerda, mas o GM não captaria essa colisão.
B - Agora, esta outra situação:

Passo 1 - A bola se move 32px para a direita e para baixo. Como pode-se ver, a bola entra na parede. (A direção aqui é 45º, mas poderia ser qualquer outra)
Passo 2 - A bola é trazida de volta pelo mesmo caminho, pixel por pixel. Isso é possível utilizando o seno e cosseno (que quem não sabe como funcionam pode substituir pelas funções lenghtdir_x() e lenghtdir_y()).
Passo 3 - A direção é devidamente alterada, e os pixels que foram desfeitos são refeitos na nova direção. Aqui acaba o step.
Passo 4 - Novamente, a bola vai se mover, 32px para a esquerda e para baixo.
Passo 5 - É feito o mesmo que no passo 2.
Passo 6 - É feito o mesmo que no passo 3. Porém, dessa vez, a bola entrará novamente na parede. Então, os passos 2 e 3 são repetidos até terminar o movimento todo.

Com o sistema de colisão do GM, apenas, isso não é possível.
Ainda nesse meu jogo, para testar se a bola colidiu com uma barra, que pode estar na diagonal (direção diferente de 0, 90, 180 e 270 graus), eu tenho que, nos códigos, subtrair a direção da barra dela mesma e da bola, para conseguir calcular sem problemas com os eixos x e y em que parte que houve colisão e, assim, qual deve ser a nova direção. Tudo usando seno e cosseno.

Mesmo com tudo o que eu fiz, o movimento não é fisicamente perfeito: mesmo dentro da variação de 1 step, a direção da gravidade no início do step é diferente da no final do step, pois ela é direcionada para o mouse. Para isso, já seria necessário mais física do que está dentro de meus conhecimentos. Só sei que há fórmulas para movimentos circulares perfeitos, que sempre possuem uma mesma aceleração, direcionada para um só ponto (o centro do círculo).

2 - Direção
Tanto em jogos top-down quanto tridimensionais, a posição e movimento do personagem e de outros elementos é definida usando o seno e cosseno. Às vezes, eles são "escondidos" pelas funções do GM, mas não deixam de estar lá.

3 - Rotação de imagens
É tão simples virar uma imagem, é só colocar algum valor na rotação, ou no image_angle e pronto, não é? No GM, sim. Se você for ver o que está por trás do tão simples image_angle, o que vai achar? Matemática!

4 - Efeitos
Esse efeito que eu fiz com primitivas e texturas no GM, mais uma vez, usa seno e cosseno:


5 - Movimentos
Quando você quer fazer movimentos "suaves", que começam devagar e terminam devagar, o mais eficiente é usar seno/cosseno.

6 - 3D
É verdade que "nós" não lidamos com isso, mas a matemática e física devem ser abusadas para se fazer uma projeção 3D.

7 - Funções embutidas do GM
Há várias coisas que usam o seno e cosseno, como: gravity, lenght_dirx/y, rotação.
O gravity e fricction trabalham com aceleração.
O point_distance(), em outas palavras, é o Teorema de Pitágoras (hip² = cat² + cat²).
Para a opção "Smooth curve" dos paths, certamente é usada alguma fórmula matemática.
Com certeza há mais funções comumente usadas que precisam de coisas assim.

Pensando mais, acredito que dá para achar utilidade também para diversas outras coisas. É que essas coisas mais complicadas da matemática e física, ou são desnecessárias pela simplicidade dos jogos com que costumamos mexer ou são escondidas pela facilidade do GM.

Eu criei alguns scripts, que estão nesse link:
https://gmbr.forumeiros.com/t17425-scripts-matematicos

Tem a simulação de point_distance, point_direction, raiz quadrada, entre outros dez scripts.

Até mais!

Estes dias eu estava pensando sobre isso, estou com um projeto que comecei ontem de um jogo em que você é um canhão e deve destruir os outros canhões, e nesse jogo queria fazer um movimento realístico, então pensei: Qual formula física usar? Eu sei que o movimento seria um movimento uniformemente variado (ou MUV), então pensei posso usar o "sorvetão" (Δs = v*t + a*t/2 ou S = S₀+v*t + a*t/2) para descobrir a posição final, mas ai vai uma dúvida que fiquei, o que é o "S" e "S₀" em física? Seria uma razão de X e Y ou somente o X pois vou usar a gravidade em "a"(aceleração) fazendo com que eu não precise me preocupar com o Y pois a gravidade irá controlar. Ai quando vi este tópico dizendo que "Δs" é igual a Y, mas como? Alguém poderia me responder o que equivale a "S" e "S₀" no GM? Eu acho que deve ser meio besta a pergunta, mas é que sou burro.
Agradeço desde já!

Assim você precisaria do tempo.
Usando essa fórmula, onde u é a velocidade inicial:

Código:

v²=u²+2g(S-So)

Como a velocidade final será 0:

Código:

0=u²+2g(S-So)

Supondo que a gravidade seja 1:

Código:

0=u²+2*(S-So)
(-u²)/2=S-So
S=(-u²)/2+So


Só que como S será relativo a posição x, So é 0:

Código:

S=(-sqr(u))/2

Então, ao atirar, basta definir u. Será achado a distância entre o fim e o começo.

Até mais!

Valeu Pedro Henrique! Funcionou perfeitamente!

Só esclarecendo:

LuanMaia escreveu:Ai quando vi este tópico dizendo que "Δs" é igual a Y, mas como?

Δs = variação da posição
y += ...
Ou seja, variação do y.

E quanto ao tempo, normalmente, é 1 step, então dá pra usar aquela fórmula.

Hmmm... Entendi, valeu pela ajuda ai pessoal. Com isso "abriu" um pouco minha mente pra física em jogos.

bom, fiquei animado com esse negócio de matemática, então resolvi interagir um pouco a matemática do colégio no GM, bom não deu muito certo, não sei no que eu errei, aos meus olhos está certo, como ninguém sabe de tudo...
Estava tentando repetir a fórmula quadrícula da matemática no Game Maker, a fórmula quadricula é:

x = -b +√b² - 4ac
2a

Sendo
a=1
b=5
c=6

Eu fiz no Game Maker:

<gml>var a, b, c, r;
a=1
b=5
c=6
r = -b + sqrt(sqr(b) - 4*a*c) / 2*a
draw_text(x,y,r)</gml>
Porém o resultado da fórmula quadricula que eu calculei, deu r=-2, já o código GML quando desenha aparece r=-4,50

Eu li, re-li e li mais vezes e não consegui achar erros, eu interpretei correto no Game Maker, e porque o resultado é diferente ??

O resultado disso aí é -12. E também não faz muito sentido, porque você elevou o b ao quadrado e tirou a raiz, é a mesma coisa. Experimenta assim:

Código:

a=1
b=5
c=6
r = -b + sqrt(power(b,2) - 4*a*c / 2*a
draw_text(x,y,r)

Acho que entendi o erro:

r = -b + sqrt(sqr(b) - 4*a*c) / 2*a

Contas de divisão são feitas primeiro, mas no caso, o certo seria:

Código:

r = (-b + sqrt(sqr(b) - 4*a*c)) / 2*a

Até mais!

Agora consegui entender, como não pensei antes, ele dividia primeiro, para depois calcular a raiz quadrada não é isso ? Agora quando posto entre parênteses, ele da uma certa prioridade ao numerador. O resultado foi exatamente igual ao da fórmula quadrícula, -2.

@The Games Never Finish
O resultado é -2 mesmo cara.

É isso mesmo. Parenteses são resolvidos primeiro.
Como isso é um debate, vou colocar uma equação interessante.

Se você tiver que atirar (em um jogo de plataforma) em um alvo que se move horizontalmente, você teria que calcular a velocidade ou o ângulo de disparo (dependendo dos dados que tem). Se você tiver o ângulo, é simples calcular a velocidade que o canhão deve ter para alcançar o alvo em movimento.

Código:

v=(-u+sqrt(sqr(alvo.hspeed)+2*abs(other.x-x)*gravidade/tan(degtorad(angulo))))/(2*cos(degtorad(angulo)));

Dados:
u = velocidade horizontal do alvo
sqrt = raiz quadrada
angulo = angulo de disparo do canhão (coloque 45º para a velocidade ser a menor possivel)
degtorad = converte graus para radianos, porque o game maker só trabalha com essa unidade; não seria necessário fazer isso na escola, por exemplo.

Eu ainda não testei, mas parece que dá certo. Eu fiz e refiz no papel, não tem porque dar erro.

Até mais!

:S Eu me compliquei aqui. Eu pensava que os problemas eram na multiplicação, mas lembrei que tinha a raiz quadrada, que ele calculava primeiro, malz ae.
E também tem os parenteses, que junta tudo para não ser calculado um fora do outro.