Sincronizando Pong com a batida da música via otimização com restrições

 (victortao.substack.com)
1 pontos por GN⁺ 2024-09-04 | 1 comentários | Compartilhar no WhatsApp
  • Uma visualização musical no estilo Pong ajusta a física do jogo e trata a posição das raquetes como variáveis de otimização para alinhar o momento em que a bola toca a raquete com a batida da música
  • A bola se move em velocidade constante e cada raquete pode se mover para qualquer lugar da sua metade da tela; o ponto de contato define o ângulo de reflexão, e a bola rebate nas paredes superior e inferior
  • Colocar as raquetes perto do centro permite satisfazer qualquer timing, mas usa pouco da tela e deixa o movimento sem graça, o que dificulta criar uma boa visualização
  • Define-se a posição horizontal da raquete em cada instante de batida e a velocidade horizontal da bola, formulando isso como um problema de programação linear que respeita as restrições físicas e o ritmo enquanto maximiza acertos da raquete longe do centro
  • A implementação usa CVXPY para resolver as restrições lineares, calcula ângulos de reflexão e posições verticais a partir das posições das raquetes e da velocidade da bola obtidas na solução, e depois cria a animação com interpolação entre keyframes

Configuração da física para alinhar Pong à batida da música

  • O objetivo é sincronizar, no clássico jogo de arcade Pong, o momento em que a bola rebate na raquete com a batida da música, criando uma visualização em que as raquetes se movem no ritmo
  • Para isso, parte da física do jogo é alterada
    • A bola se move em velocidade constante
    • Cada raquete pode se mover para qualquer lugar da sua própria metade da tela
  • Também há regras mantidas do Pong original
    • O ponto de contato em que a bola toca a raquete determina o ângulo de reflexão
    • As raquetes não têm limite de velocidade
    • A bola rebate nas bordas superior e inferior da tela
  • Essa configuração física fornece graus de liberdade para acertar a bola nos instantes desejados

Limites da solução com posicionamento central

  • Se as duas raquetes forem colocadas perto do centro da tela, é possível satisfazer qualquer exigência de timing
    • O espaço horizontal é pequeno, mas como a bola pode rebater nas paredes superior e inferior, o espaço vertical é, na prática, suficiente
    • Se a duração desejada da jogada for longa, dá para bater na bola com uma trajetória mais próxima da vertical para reduzir a velocidade horizontal
  • Isso mostra que existe solução para qualquer entrada, mas o resultado visual não é interessante
  • Em uma boa visualização, o uso do espaço da tela é importante
    • Se o jogo fica preso a uma área pequena, ele parece apertado e pouco impactante
    • O público gosta do movimento dinâmico de ver as raquetes alcançando bolas no limite
  • Portanto, a questão central é onde cada raquete deve acertar a bola em cada batida para usar melhor a tela, sem violar o ritmo nem as regras físicas

Transformando em otimização com restrições

  • Esse problema pode ser tratado como um problema de otimização com restrições, com função objetivo, variáveis e restrições
    • O objetivo é aumentar o uso da tela
    • As variáveis são as posições em que a bola rebate
    • As restrições são a física do jogo e as batidas da música
  • Ao formular o problema dessa forma, é possível calcular as posições ótimas das raquetes com um solver existente, em vez de projetar um algoritmo manualmente
  • Se a física mudar, basta atualizar as restrições, e também fica fácil testar diferentes funções objetivo
  • Não é necessário modelar o sistema 2D inteiro
    • Como a velocidade total da bola é constante, ao definir a velocidade horizontal a velocidade vertical também fica determinada
    • A posição vertical da bola em qualquer instante pode ser calculada por simulação
    • A posição vertical da raquete precisa coincidir com a da bola para realizar o acerto, com um pequeno delta adicional para obter o ângulo desejado
    • Entre os acertos, a posição da raquete é ligada suavemente por interpolação linear

Valores de entrada e restrições lineares

  • As entradas fixas são a largura da tela e a velocidade da bola
    • W: largura da tela
    • S: velocidade da bola
  • Os tempos das batidas são obtidos de um arquivo MIDI
    • T = {t_0, t_1, ..., t_n} são os instantes de cada batida em que a bola deve tocar a raquete
    • No futuro, também pode ser explorada uma extração mais automatizada diretamente do áudio
  • A diferença entre tempos de batidas adjacentes define a duração de cada jogada
    • D = {d_0, d_1, ..., d_{n-1}}
    • d_i = t_{i+1} - t_i
  • As variáveis de otimização são a posição horizontal e a velocidade horizontal
    • P = {p_0, p_1, ..., p_{n-1}} é a distância horizontal entre o centro da tela e o ponto em que a raquete acerta a bola
    • Índices pares representam a raquete esquerda, e índices ímpares representam a raquete direita
    • V = {v_0, v_1, ..., v_{n-1}} é a velocidade horizontal da bola após cada acerto
    • Para facilitar a criação das restrições, v_i é sempre definido como positivo, independentemente da direção em que a bola se move para a esquerda ou para a direita
  • As restrições físicas definem os limites das posições das raquetes e da velocidade da bola
    • 0 ≤ p_i ≤ W/2
    • 0 < v_i ≤ S
  • As restrições de sincronização com a batida fazem a bola chegar exatamente à próxima raquete no tempo certo
    • p_{i-1} + p_i = d_i v_i
    • O lado esquerdo é a distância horizontal total percorrida entre dois acertos consecutivos das raquetes
    • O lado direito é o produto entre a duração da jogada e a velocidade horizontal da bola

Função objetivo e geração da animação

  • Para evitar a solução degenerada em que tudo permanece no centro, o método incentiva as raquetes a se afastarem do centro da tela
  • A função objetivo maximiza a soma das distâncias das raquetes em relação ao centro
    • Maximize Σ p_i
  • Como todas as restrições são lineares, o problema pode ser resolvido com um solver de programação linear (LP)
  • A implementação usa CVXPY
    • O CVXPY resolve problemas de otimização convexa, dos quais LP é um subconjunto
    • Todo o conjunto de recursos não é necessário aqui, mas ele ajuda em experimentos criativos por permitir funções objetivo e restrições mais complexas
  • O solver retorna as posições horizontais em que as raquetes devem acertar a bola e a velocidade horizontal da bola
    • A partir desses valores, é possível calcular os ângulos de reflexão
    • As posições verticais são calculadas por simulação
  • A animação final usa as posições da bola e das raquetes nos instantes de acerto como keyframes
    • Entre os acertos, as posições são interpoladas para criar um movimento suave
  • O código foi publicado como open source: Github Repo

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-04
Comentários do Hacker News

  • Isso me lembrou de um projeto de uns 20 anos atrás em que programei áudio multiplayer para uma exposição de arte
    Quanto mais intensa a partida ficava, mais ficava evidente que os sons da bola/parede estavam tocando música, e a estrutura era tal que os três jogadores na verdade estavam executando uma única composição juntos
    Colocamos 3 gabinetes de arcade virados um para o outro, de modo que cada jogador não podia ver a tela dos outros, e ajustamos levemente a velocidade/direção da bola para que ela batesse na raquete ou na parede nos pontos musicalmente corretos e produzisse o som certo
    O Josh também colocou isso no site dele como referência: https://www.autogena.org/work/ping

    • Que legal. Então havia uma composição fixa, e a jogabilidade era levemente ajustada para se encaixar nela?

  • Como variação dessa ideia, isso me faz imaginar treinar agentes de aprendizado por reforço em jogos de Atari ou Super Mario, mas adicionando recompensas/entradas baseadas em música para criar partidas que pareçam “musicais”
    Não sei o quão interessante isso seria de assistir, nem se valeria a pena

    • Sou iniciante em machine learning, mas a OpenAI já fez uma biblioteca Python para aprendizado por reforço em videogames, e um fork dela ainda é mantido ativamente [1]
      Pelo que lembro de alguns anos atrás, dava para colocar para rodar em um ou dois dias, ou no máximo em um fim de semana. Ela usava o emulador RetroArch e suportava um número enorme de emuladores e consoles
      https://github.com/Farama-Foundation/Gymnasium
      Também há um ótimo vídeo no YouTube do SethBling sobre machine learning com Super Mario World:
      https://www.youtube.com/watch?v=qv6UVOQ0F44
      Recomendo experimentar. No clima atual de hype em torno de IA, videogames parecem um pouco subestimados, e vejo muito potencial em máquinas aprenderem habilidades jogando. Também há grande potencial em escolher ou criar jogos novos para ensinar habilidades específicas. Embora, chegando nesse ponto, talvez seja melhor abandonar áudio e visual e se comunicar com a máquina por texto ou dados puros
      Por outro lado, já vi vídeos de redes neurais convolucionais usando cada pixel da imagem como entrada, então imagino que treinar com dados de som ou pixels de espectrograma também possa gerar resultados positivos. Ver um jogo ser jogado no ritmo da música, ou quase como uma dança alinhada com melodia, harmonia e narrativa, certamente pareceria divertido
      Tudo que os humanos já criaram primeiro existiu na imaginação humana, e você também tem um cérebro assim. Seguir a visão que existe na sua mente e trazê-la para a realidade física é algo belo, e parece um presente para toda a humanidade
    • Crypt of the NecroDancer explora essa ideia ao dar bônus no jogo quando o movimento do personagem acompanha o ritmo
    • Acho que não ficaria muito bom. Mario não tem ritmo suficiente para evocar uma musicalidade forte
      Nos originais isso já acontecia um pouco, porque o som era vinculado à taxa de quadros. Depois, nas versões PAL, essa característica se perdeu porque elas rodavam em uma taxa de quadros mais baixa

  • Isso me lembra as visualizações de polirritmo do YouTube. Um bom exemplo é o LucidRhythms
    https://www.youtube.com/@LucidRhythms
    Seria quase impossível ajustar ao contrário uma música já existente para se encaixar na visualização, mas poderia ficar interessante se barras diferentes representassem notas diferentes e, nos acordes, a bola se dividisse

    • Também seria legal ter N raquetes. Para não ficar fácil demais, você poderia impor um custo quando as raquetes ficassem muito próximas, otimizar qual nota ou tempo cada raquete assumiria e também aplicar um custo para mudanças bruscas de altura; assim, cada raquete poderia se especializar em uma faixa de notas específica

  • Muito legal. Fiquei hipnotizado vendo as raquetes se moverem conforme a batida avançava
    Existem coisas que simplesmente se encaixam só de olhar, e por isso parecem belas; este projeto é um desses casos

  • Antecessor: Eisenfunk - Pong (https://www.youtube.com/watch?v=cNAdtkSjSps)

    • Ainda assim é bem diferente. Nesse exemplo, os bipes saem em velocidade constante, então o vídeo foi sincronizado manualmente com o BPM da música
      Basicamente, está mais para uma visualização artesanal pulando uma batida sim, outra não do bumbo
      Já o trabalho enviado não coloca as notas em um simples tempo de semínimas, e é “animado” automaticamente com base em otimização por restrições. Por isso, a visualização também fica muito mais interessante

  • Muito bom. Só que, sem assinar, não dá para mandar coração, então para mim isso soa meio inadequado

  • Tecnicamente ficou bom, mas há vários momentos em que as raquetes e a bola se movem quase na mesma velocidade, então parece que as raquetes estão empurrando a bola o tempo todo
    Por esse motivo, talvez fosse melhor não permitir p[i] = 0. Quando um d[i] grande é seguido logo por um d[i+1] bem pequeno, isso talvez seja inevitável, mas parece possível evitar quando der

    • Você pode colocar uma penalidade proporcional a d'[i] na função objetivo

  • Isso me faz imaginar ter uma installation no meu espaço, usando junto um MT-80S e um display
    Será que eu conseguiria entender direito esse timing? Não sou exatamente inteligente nessa área, mas tenho interesse
    https://www.matrixsynth.com/2014/07/roland-mt-80s-midi-playe...

  • Muito interessante, mas, estranhamente, meu cérebro odeia muito isso
    Parece mexer com algum tipo de modelo causal dentro de mim, e me dá a sensação de ser difícil de olhar. Estranho

    • O que mais me salta aos olhos é a ausência de dinâmica. Especialmente em passagens rápidas com “ghost notes” entre notas muito mais fortes, parece que falta alguma coisa
      Mesmo assim, de forma estranha, existe uma satisfação visual. Fico curioso se minha experiência tocando vários instrumentos tem relação com essa sensação. Para mim, instrumentos como xilofone ou steelpan parecem bastante próximos disso
    • Continua parecendo estranho porque a bola parece quicar no meio das raquetes, e não na borda. Talvez estejamos vendo o mesmo problema

  • A Atari teve um dispositivo de visualização musical em vídeo no fim dos anos 1970. Foi projetado por um dos desenvolvedores do jogo Pong e foi o primeiro, ou um dos primeiros, produtos de consumo desse tipo
    https://en.wikipedia.org/wiki/Atari_Video_Music
    Se você viu o filme Over the Edge, Claude e Johnny têm um em casa