Kısıt optimizasyonuyla Pong'u müzik ritmine senkronize etmek

 (victortao.substack.com)
1 puan yazan GN⁺ 2024-09-04 | 1 yorum | WhatsApp'ta paylaş
  • Pong tarzı müzik görselleştirmesi, topun rakete değdiği anı şarkının ritmiyle eşleştirmek için oyun fiziğini ayarlıyor ve raket konumlarını optimizasyon değişkenleri olarak ele alıyor
  • Top sabit hızla hareket ediyor ve her raket ekranın kendi yarısında istediği yere gidebiliyor; temas noktası yansıma açısını belirliyor ve top üst-alt duvarlardan sekiyor
  • Raketleri merkeze yakın tutmak her türlü zamanlamayı karşılayabiliyor, ancak ekran kullanımı dar kalıyor ve hareket sönükleşiyor; bu da iyi bir görselleştirme üretmeyi zorlaştırıyor
  • Her ritim anındaki raket yatay konumu ile topun yatay hızı belirlenerek, fizik kısıtlarını ve ritmi korurken merkezden uzak raket vuruşlarını en üst düzeye çıkaran bir doğrusal programlama problemi olarak formüle ediliyor
  • Uygulama, CVXPY ile doğrusal kısıtları çözüyor; çözümden elde edilen raket konumları ve top hızlarından yansıma açıları ile dikey konumlar hesaplanıyor, ardından keyframe enterpolasyonu ile animasyon oluşturuluyor

Pong'u müzik ritmine uyduran fizik ayarı

  • Amaç, klasik arcade oyunu Pong'da topun raketten sektiği anları şarkının ritmiyle senkronize ederek, raketlerin müziğe uyumlu hareket ettiği bir görselleştirme üretmek
  • Bunun için oyun fiziğinin bir kısmı değiştiriliyor
    • Top sabit hızla hareket ediyor
    • Her raket ekranın kendi yarısı içinde istediği yere gidebiliyor
  • Klasik Pong'dan korunan kurallar da var
    • Topun rakete değdiği temas noktası, yansıma açısını belirliyor
    • Raketler için hız sınırı yok
    • Top ekranın üst ve alt sınırlarından sekiyor
  • Bu fizik ayarı, topu istenen anlarda raketle buluşturmak için gereken serbestliği sağlıyor

Merkez yerleşimi çözümünün sınırları

  • İki raket ekran merkezine yakın tutulursa her türlü zamanlama gereksinimi karşılanabiliyor
    • Yatay alan küçük olsa da, top üst ve alt duvarlardan sekebildiği için dikey alan pratikte yeterli oluyor
    • İstenen vuruş süresi uzunsa, top daha dikeye yakın vurularak yatay hız düşürülebiliyor
  • Bu yaklaşım, her girdi için bir çözümün var olduğunu gösteriyor, ancak görsel olarak ilgi çekici değil
  • İyi bir görselleştirme için ekran alanının kullanımı önemli
    • Oyun küçük bir bölgeye sıkışırsa boğucu ve zayıf görünüyor
    • İzleyiciler, raketlerin kıl payı yetişip topu karşıladığı daha dinamik hareketleri seviyor
  • Bu nedenle asıl mesele, ritmi ve fizik kurallarını korurken her vuruşta raketin topa ekranı daha geniş kullanacak şekilde nerede vurması gerektiği

Bunu kısıt optimizasyonuna dönüştürmek

  • Bu problem, amaç fonksiyonu, değişkenler ve kısıtlar içeren bir kısıt optimizasyonu problemi olarak ele alınabiliyor
    • Amaç ekran kullanımını artırmak
    • Değişkenler topun sektiği konumlar
    • Kısıtlar oyun fiziği ve şarkının ritmi
  • Problem kısıt optimizasyonu olarak kurulduğunda, özel bir algoritma tasarlamak yerine mevcut çözücülerle en uygun raket konumları hesaplanabiliyor
  • Fizik değiştirilirse yalnızca kısıtları güncellemek yetiyor; amaç fonksiyonu da kolayca denenebiliyor
  • Tüm 2D sistemi modellemeye gerek yok
    • Topun toplam hızı sabit olduğundan, yatay hız belirlendiğinde dikey hız da belirlenmiş oluyor
    • Simülasyonla herhangi bir andaki topun dikey konumu hesaplanabiliyor
    • Raketin dikey konumu, topa vurması gerektiği için topun dikey konumuyla eşleşiyor ve istenen açı için buna küçük bir delta ekleniyor
    • Vuruşlar arasındaki raket konumları doğrusal enterpolasyonla yumuşak biçimde bağlanıyor

Girdiler ve doğrusal kısıtlar

  • Sabit girdiler ekran genişliği ve top hızı
    • W: ekran genişliği
    • S: topun hızı
  • Ritim zamanları MIDI dosyasından alınıyor
    • T = {t_0, t_1, ..., t_n} topun rakete değmesi gereken her ritim anını ifade ediyor
    • Gelecekte bunu doğrudan sesten daha otomatik biçimde çıkarmanın yolları da araştırılabilir
  • Komşu ritim anları arasındaki fark, her vuruşun süresini veriyor
    • D = {d_0, d_1, ..., d_{n-1}}
    • d_i = t_{i+1} - t_i
  • Optimizasyon değişkenleri yatay konum ve yatay hız
    • P = {p_0, p_1, ..., p_{n-1}}, raketin topa vurduğu anda ekran merkezinden olan yatay uzaklığı ifade ediyor
    • Çift indeksler sol raketi, tek indeksler sağ raketi gösteriyor
    • V = {v_0, v_1, ..., v_{n-1}}, her vuruştan sonra topun yatay hızını ifade ediyor
    • Kısıt kurmayı kolaylaştırmak için, top sola ya da sağa gidiyor olsa da v_i her zaman pozitif tanımlanıyor
  • Fizik kısıtları, raket konumu ve top hızının aralığını belirliyor
    • 0 ≤ p_i ≤ W/2
    • 0 < v_i ≤ S
  • Ritme senkronizasyon kısıtı, topun bir sonraki rakete tam zamanında ulaşmasını sağlıyor
    • p_{i-1} + p_i = d_i v_i
    • Sol taraf, art arda gelen iki raket vuruşu arasındaki toplam yatay mesafe
    • Sağ taraf, vuruş süresi ile topun yatay hızının çarpımı

Amaç fonksiyonu ve animasyon üretimi

  • Merkezde kalan dejeneratif çözümden kaçınmak için raketlerin ekran merkezinden uzaklaşması teşvik ediliyor
  • Amaç fonksiyonu, raketlerin merkezden uzaklıklarının toplamını en büyüklemeyi hedefliyor
    • Maximize Σ p_i
  • Tüm kısıtlar doğrusal olduğundan, problem bir doğrusal programlama (LP) çözücüsüyle çözülebiliyor
  • Uygulamada CVXPY kullanılıyor
    • CVXPY dışbükey optimizasyon problemlerini çözüyor ve LP bunun bir alt kümesi
    • Bu iş için tüm yetenekleri gerekmese de, daha karmaşık amaç fonksiyonları ve kısıtları desteklediği için yaratıcı denemeler açısından avantaj sağlıyor
  • Çözücü, raketlerin topa vurması gereken yatay konumları ve topun yatay hızlarını döndürüyor
    • Bu değerlerden yansıma açıları hesaplanabiliyor
    • Dikey konumlar simülasyonla hesaplanıyor
  • Nihai animasyon, top ve raketlerin vuruş anlarındaki konumlarını keyframe olarak kullanıyor
    • Vuruşlar arasında konumlar enterpole edilerek akıcı hareket elde ediliyor
  • Kod açık kaynak olarak yayımlanmış: Github Repo

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-04
Hacker News yorumları

  • Yaklaşık 20 yıl önce bir sanat sergisi için birden fazla kişinin aynı anda oynadığı sesli bir proje kodladığımı hatırlattı.
    Oyun kızıştıkça top/duvar seslerinin müzik çaldığı ortaya çıkıyordu; üç oyuncu aslında birlikte tek bir parçayı çalıyordu.
    Üç arcade kabinini birbirine bakacak şekilde yerleştirmiştik; böylece her oyuncu diğerlerinin ekranını göremiyordu. Topun hızını/yönünü hafifçe ayarlayarak müzikal olarak doğru noktalarda rakete ya da duvara çarpmasını ve doğru sesi çıkarmasını sağlıyorduk.
    Josh’un kendi sitesine referans olarak koyduğu bir şey de var: https://www.autogena.org/work/ping

    • Harika. Yani sabit bir beste vardı ve oynanışı ona uyacak şekilde hafifçe ayarlamış mı oldunuz?

  • Bu fikrin bir varyasyonu olarak, Atari oyunlarında ya da Super Mario’da pekiştirmeli öğrenme ajanları eğitip müzik tabanlı ödül/girdi ekleyerek “müzikal” görünen bir oynanış üretilebileceğini hayal ettim.
    Ne kadar iyi görüneceğinden ya da buna değip değmeyeceğinden pek emin değilim.

    • Makine öğrenmesinde acemiyim ama OpenAI bir zamanlar video oyunlarıyla pekiştirmeli öğrenme için bir Python kütüphanesi yapmıştı; onun bir fork’u hâlâ aktif olarak sürdürülüyor [1].
      Birkaç yıl öncesinden hatırladığım kadarıyla bir-iki günde, en fazla bir hafta sonunda çalışır hâle getirilebiliyordu. RetroArch emülatörünü kullanıyordu ve çok sayıda emülatör ile konsolu destekliyordu.
      https://github.com/Farama-Foundation/Gymnasium
      SethBling’in Super Mario World ile makine öğrenmesini ele alan harika bir YouTube videosu da var:
      https://www.youtube.com/watch?v=qv6UVOQ0F44
      Kendin denemeni öneririm. Bugünkü yapay zeka abartısı içinde video oyunları biraz hafife alınıyor gibi geliyor; makinelerin oyun oynayarak beceri öğrenmesinde büyük potansiyel olduğunu düşünüyorum. Belirli becerileri öğretmek için oyun seçme ya da yeni oyun yapma ihtimali de büyük. Ama o noktada ses ve görselleri bırakıp makineyle metin ya da saf veri üzerinden iletişim kurmak daha iyi olabilir.
      Öte yandan, görüntüdeki her pikseli girdi olarak alan evrişimli sinir ağı videoları görmüştüm; bu yüzden ses verisiyle ya da spektrogram pikselleriyle eğitmenin de olumlu sonuçlar verebileceğini düşünüyorum. Müziğe göre oyun oynamak ya da melodiye, armoniye ve hikâyeye göre dans eder gibi oynamak kesinlikle eğlenceli olurdu.
      İnsanların yaptığı her şey önce insanın hayalinde vardı; sende de böyle bir beyin var. Zihnindeki vizyonun peşinden gidip onu fiziksel gerçekliğe çekmek güzel bir şey ve tüm insanlığa verilmiş bir hediye gibi görünüyor.
    • Crypt of the NecroDancer, karakter hareketlerini ritme uydurunca oyun içinde bonus vererek bu fikri inceliyor.
    • Pek iyi olmayabilir. Mario’da güçlü bir müzikalite çağrıştıracak kadar ritim yok.
      Orijinaldeki sesler kare hızına bağlıydı, bu yüzden temelde buna benzer bir şey zaten oluyordu. Daha sonraki PAL portları daha yavaş kare hızında çalışınca bu özellik bozuldu.

  • YouTube’daki poliritim görselleştirmelerini hatırlattı. İyi örnekler için LucidRhythms’e bakılabilir.
    https://www.youtube.com/@LucidRhythms
    Önceden yazılmış bir parçayı geriye dönük olarak görselleştirmeye uydurmak neredeyse imkânsız olurdu; ama farklı çubuklar farklı notaları temsil etse ve akorlarda top bölünse eğlenceli olabilir.

    • N tane raket koymak da güzel olurdu. Çok kolaylaşmaması için raketler fazla yaklaştığında bir maliyet verip, her raketin hangi notayı ya da vuruşu üstleneceğini optimize ederek ve ani perde değişimlerine de maliyet uygulayarak her raketin belirli bir ses aralığında uzmanlaşmasını sağlayabilirsiniz.

  • Gerçekten harika. Vuruş ilerledikçe raketlerin hareket edişini izlerken dalıp gittim.
    Sadece bakınca bile yerine oturan şeyler vardır ve bu yüzden güzel hissettirirler; bu proje de öyle.

  • Önceki çalışma: Eisenfunk - Pong (https://www.youtube.com/watch?v=cNAdtkSjSps)

    • Yine de epey farklı. O örnekte bip sesi sabit hızda çıktığı için video parçanın BPM’ine manuel olarak senkronlanmış.
      Temelde bir kick drum’ın her diğer vuruşu için elle yapılmış bir görselleştirmeye yakın.
      Buna karşılık gönderilen çalışma, notalar basit dörtlük nota temposunda olmadığı hâlde kısıt optimizasyonuna dayanarak otomatik “animasyon” üretiyor. Bu yüzden görselleştirme de çok daha ilginç hâle geliyor.

  • Gerçekten güzel. Ancak abone olmadan kalp gönderilememesi bana pek uymadı.

  • Teknik olarak iyi ama raket ve top neredeyse aynı hızda hareket ettiği için raketin sürekli topu itiyormuş gibi göründüğü birkaç durum var.
    Bu nedenle p[i] = 0’a izin vermemek daha iyi olur. Büyük bir d[i]’nin hemen ardından çok küçük bir d[i+1] gelirse kaçınılmaz olur; ama mümkün olan durumlarda bundan kaçınacak şekilde yapılabilir gibi.

    • Amaç fonksiyonuna d'[i] ile orantılı bir ceza eklenebilir.

  • Kendi alanıma bir installation koyup MT-80S ve bir ekranla birlikte kullanmayı hayal ettirdi.
    Bu zamanlamayı gerçekten anlayabilir miyim? Bu konuda çok zeki değilim ama ilgimi çekiyor.
    https://www.matrixsynth.com/2014/07/roland-mt-80s-midi-playe...

  • Gerçekten ilginç ama tuhaf biçimde beynim bundan çok hoşlanmıyor.
    İçimdeki nedensellik modeli gibi bir şeye dokunuyor sanki ve izlemesi zor geliyor. Garip.

    • Bana en belirgin eksik gelen şey vurgu/şiddet. Özellikle hızlı pasajlarda çok daha yüksek notaların arasında “ghost note”lar olduğunda bir şey eksikmiş gibi hissediliyor.
      Yine de tuhaf şekilde izlemesi tatmin edici. Birkaç enstrüman çalmış olmamın bu hisle ilgisi var mı merak ediyorum. Bana ksilofon ya da steelpan gibi enstrümanlar buna oldukça benzer hissettiriyor.
    • Top, raketin kenarından değil de ortasından sekiyormuş gibi göründüğü için sürekli tuhaf duruyor. Belki de aynı sorunu görüyoruzdur.

  • Atari’nin 1970’lerin sonunda bir video müzik görselleştirme cihazı vardı. Pong oyununun geliştiricilerinden biri tasarlamıştı ve bu tür tüketici ürünlerinin ilki ya da ilklerinden biriydi.
    https://en.wikipedia.org/wiki/Atari_Video_Music
    Over the Edge filmini izlediyseniz, Claude ve Johnny’nin evinde bunlardan biri var.