Bir oyun döngüsü sabit veya değişken zaman adımlarına mı dayanmalı? Biri her zaman üstün mü, yoksa doğru seçim oyuna göre değişiyor mu?

Değişken zaman aşaması

Fizik güncellemeleri "son güncellemeden bu yana geçen bir argüman" argümanından geçirilir ve dolayısıyla kare hızına bağlıdır. Bu, hesaplama yapmak anlamına gelebilir position += distancePerSecond * timeElapsed.

Artıları : pürüzsüz, kodlanması kolay
Eksileri : deterministik değil, çok küçük veya büyük adımlarla tahmin edilemez

deWiTTERS örneği:

while( game_is_running ) {
    prev_frame_tick = curr_frame_tick;
    curr_frame_tick = GetTickCount();
    update( curr_frame_tick - prev_frame_tick );
    render();
}

Sabit zaman adımı

Güncellemeler, her güncellemenin belirli bir süre için olduğunu varsaydığı için, "geçen süreyi" bile kabul etmeyebilir. Hesaplamalar olarak yapılabilir position += distancePerUpdate. Örnek, oluşturma sırasında bir enterpolasyonu içerir.

Artıları : tahmin edilebilir, deterministik (ağ senkronizasyonu kolay mı?), Daha net hesaplama kodu
Eksileri : v-sync'i izlemek için senkronize edilmez (enterpolasyon yapmazsanız jittery grafiklere neden olur), sınırlı maksimum kare hızını (enterpolasyon yapmazsanız), çerçevelerde çalışmak zor değişken zaman adımlarını varsayalım ( Pyglet veya Flixel gibi )

deWiTTERS örneği:

while( game_is_running ) {
    while( GetTickCount() > next_game_tick ) {
        update();
        next_game_tick += SKIP_TICKS;
    }
    interpolation = float( GetTickCount() + SKIP_TICKS - next_game_tick )
                    / float( SKIP_TICKS );
    render( interpolation );
}

Bazı kaynaklar

• Oyunlarda Gaffer: Zamanınızı düzeltin!
• deWitter oyun döngüsü yazısı
• Quake 3'ün FPS sıçrama fiziğini etkiler - genelde bir neden Doom 3'ün 60 fps'ye kilitli kalması mı?
• Flixel değişken bir zaman aralığı gerektirir (bunun Flash tarafından belirlendiğini düşünüyorum), Flashpunk ise her iki türe de izin verir.
• Box2D'nin El Kitabı § World of Box2D'yi simüle etmek, sürekli zaman adımlarını kullanmasını önerir.

Soruyla ilgili iki konu var.

• Fizik basamak hızı kare hızına bağlı mıdır?
• Fizik sabit deltalarla basamaklandırılmalı mı?

Glen fielder'ın adımındaki adımını "Fiziği Serbest Bırak" diyor. Bu, fizik güncelleme oranınızın kare hızınıza bağlı olmaması gerektiği anlamına gelir .

Örneğin, ekran kare hızı 50fps ise ve simülasyon 100fps'de çalışacak şekilde tasarlandıysa, fiziği senkronize tutmak için her ekran güncellemesinde iki fizik adımı atmamız gerekir.

Erin Catto'nun Box2D'ye verdiği tavsiyelerde, bunu da savunuyor.

Bu yüzden zaman adımını kare hızınıza bağlamayın (gerçekten, gerçekten yapmak zorunda olmadığınız sürece).

Fizik adım oranı kare hızınıza bağlı mıdır? Hayır.

Erin'in sabit adımla ilgili düşünceleri - değişken adımlama:

Box2D, entegratör adı verilen bir hesaplama algoritması kullanır. Bütünleştiriciler, fizik denklemlerini belirli zaman noktalarında simüle eder. ... Ayrıca çok fazla değişecek zaman adımını da sevmiyoruz. Değişken bir zaman adımı, hata ayıklamayı zorlaştıran değişken sonuçlar üretir.

Glen'in sabit ve değişken adım adım üzerine düşünceleri:

Zaman adımınızı düzeltin veya patlatın

... Bir araba simülasyonunda amortisörler için bir dizi çok sert yay kısıtlaması varsa, dt'deki küçük değişiklikler aslında simülasyonu patlatabilir. ...

Fizik sabit deltalarla basamaklandırılmalı mı? Evet.

Fiziği sabit deltalarla ilerletmenin ve fizik güncelleme hızınızı kare hızına bağlamanın hala bir zaman akümülatörü kullanmaktır. Oyunumda bir adım daha ileri götürüyorum. Gelen zamana bir yumuşatma fonksiyonu uyguluyorum. Bu şekilde büyük FPS çivileri fiziğin çok fazla zıplamasına neden olmaz, bunun yerine bir veya iki kare için daha hızlı bir şekilde simüle edilir.

Sabit bir oranla fiziğin ekranla senkronize edilmeyeceğinden bahsediyorsunuz. Bu, hedef fizik hızı hedef kare hızına yakınsa geçerlidir. Kare hızının fizik oranından daha büyük olması daha kötü. Genel olarak, paranızın karşılığını alabiliyorsanız, hedef FPS'nizin iki katı bir fizik güncelleme oranını hedeflemek daha iyidir.

Büyük bir fizik güncelleme oranını karşılayamıyorsanız, çizilen grafiklerin fiziğin gerçekte olduğundan daha yumuşak hareket etmesini sağlamak için grafiklerin konumlarını kareler arasında birleştirmeyi düşünün.

Bence gerçekten 3 seçenek var, ama onları sadece 2 olarak listeliyorsunuz:

seçenek 1

Hiçbir şey yapma. Belirli bir aralıkta, örneğin saniyede 60 kez güncelleme ve oluşturma girişiminde bulunun. Geride kalırsa, bırak ve endişelenme. CPU oyununa devam edemezse, oyunlar sarsıntılı ağır çekimde yavaşlar. Bu seçenek gerçek zamanlı çok kullanıcılı oyunlar için hiç çalışmaz, ancak tek oyunculu oyunlar için iyidir ve birçok oyunda başarıyla kullanılmıştır.

seçenek 2

Nesnelerin hareketini değiştirmek için her güncelleme arasındaki delta süresini kullanın. Teoride harika, özellikle oyununuzdaki hiçbir şey hızlanmadığında veya yavaşlamadığında, ancak sabit bir hızda hareket ederse. Uygulamada, birçok geliştirici bunu çok kötü uygular ve tutarsız çarpışma tespitine ve fiziğe yol açabilir. Bazı geliştiriciler bu yöntemin olduğundan daha kolay olduğunu düşünüyor. Bu seçeneği kullanmak istiyorsanız, oyununuzu önemli ölçüde arttırmanız ve bazı büyük silah matematik ve algoritmaları ortaya çıkarmanız gerekir, örneğin bir Verlet fizik entegratörü (çoğu insanın kullandığı standart Euler yerine) ve çarpışma tespiti için ışınları kullanma basit Pisagor mesafe kontrolleri yerine. Bir süre önce Stack Overflow hakkında bir soru sordum ve harika cevaplar aldım:

https://stackoverflow.com/questions/153507/calculate-the-position-of-an-accelerating-body-after-a-certain-time

Seçenek 3

Gaffer'ın "zaman adımını düzelt" yaklaşımını kullanın. Oyunu, seçenek 1'deki gibi sabit adımlarla güncelleyin, ancak ne kadar zaman geçtiğine bağlı olarak, oluşturulan kare başına birden çok kez yapın; böylece oyun mantığı, belirli adımlarda kalırken gerçek zamana ayak uydurabilir. Bu şekilde, Euler entegratörleri ve basit çarpışma algılama gibi oyun mantığını uygulamak kolaydır. Ayrıca delta zamanını temel alan grafiksel animasyonları enterpolasyon etme seçeneğiniz de var, ancak bu sadece görsel efektler için ve çekirdek oyun mantığınızı etkileyen hiçbir şey değil. Güncellemeleriniz çok yoğunsa potansiyel olarak başınız belaya girebilir - güncellemeler geride kalıyorsa devam etmek için daha fazlasına ihtiyacınız olacak, bu da potansiyel olarak oyununuzu daha az yanıt verebilir hale getirecektir.

Şahsen, kaçabildiğimde Seçenek 1'i ve gerçek zamanlı olarak senkronize etmem gerektiğinde Seçenek 3'ü severim. Yaptığını bildiğin zaman Seçenek 2'nin iyi bir seçenek olabileceğine saygı duyuyorum, ancak sınırlamalarımı ondan uzak duracak kadar iyi biliyorum.

XNA Framework'ün sabit zaman adımını uygulama şeklini gerçekten seviyorum . Belirli bir beraberlik çağrısı biraz uzun sürerse, "yakalanana" kadar tekrar tekrar güncellemeyi çağırır. Shawn Hargreaves burada açıklar:
http://blogs.msdn.com/b/shawnhar/archive/2007/11/23/game-timing-in-xna-game-studio-2-0.aspx

2.0'da Beraberlik davranışı değişti:

• Güncel saate yetişmek için Güncelleme'yi gerektiği kadar çağırın
• Bir kez Çizim Beraberlik
• Bir sonraki güncellemenin zamanı gelene kadar bekleyin.

Buna göre bence en büyük profesyonel bahsettiniz, tüm oyun kodu hesaplamalarınızı çok daha basit hale getiriyor çünkü o zaman değişkenini her yere dahil etmek zorunda değilsiniz.

not: xna değişken timestep'i de destekler, sadece bir ayardır.

Başka bir seçenek var - decouple Oyun güncelleme ve fizik güncelleme. Fiziksel motorunu oyunun timestep'ine göre uyarlamaya çalışmak, eğer timestep'inizi sabitlerseniz (kontrolden çıkma sorunu varsa, entegrasyon daha fazla timesteps gerektiren daha fazla timesteps gerektirir) ya da değişken ve riskli fizik elde edin.

Çok gördüğüm çözüm, fiziğin belirli bir zaman diliminde, farklı bir yivde (farklı bir çekirdekte) çalışmasını sağlamak. Oyun, alabileceği en yeni iki geçerli kareye göre enterpolasyon yapar veya ekstrapolatlar. İnterpolasyon biraz gecikme ekler, ekstrapolasyon biraz belirsizlik ekler, ancak fizikiniz sabit kalacaktır ve zamanınızı kontrolden çıkarmayacaktır.

Bunun uygulanması önemsiz değildir, ancak gelecekteki kanıtlarını kanıtlayabilir.

Şahsen, değişken zaman-adım değişkenini kullanıyorum (ki bu sanırım sabit ve değişken bir melez tür). Bu zamanlama sistemini çeşitli şekillerde test ettim ve kendimi birçok proje için kullanırken buluyorum. Her şey için tavsiye eder miyim? Muhtemelen değil.

Oyun döngülerim, güncellenecek karelerin miktarını hesaplar (bu F olarak adlandıralım) ve ardından F ayrı mantık güncellemeleri gerçekleştirin. Her mantık güncellemesi sabit bir zaman birimi varsayıyor (bu benim oyunlarımda saniyenin 1 / 100'ünde). Her güncelleme, tüm ayrı ayrı mantık güncellemeleri gerçekleştirilinceye kadar sıra ile gerçekleştirilir.

Mantıksal adımlardaki neden güncellemeler? Devamlı adımlar dener ve kullanırsanız ve aniden fizik sorunlarınız olur, çünkü hesaplanan hız ve mesafeler F değeriyle çarpılır.

Bunun kötü bir uygulaması sadece F = geçerli zaman - son kare zaman güncellemelerini yapar. Ancak hesaplamalar çok geride kalıyorsa (bazen CPU zamanını çalmak gibi başka bir işlem gibi kontrolünüz dışındaki koşullar nedeniyle), hızlı bir şekilde kötü atlama göreceksiniz. Hızla, sağlamaya çalıştığınız bu kararlı FPS SPF olur.

Oyunumda, iki çizim arasında mümkün olması gereken mantık yakalama miktarını sınırlamak için "yumuşak" (çeşit) yavaşlamaya izin veriyorum. Sıkma ile bunu yapıyorum: Genellikle MAX_FRAME_DELTA = 2/100 * s veya 3/100 * s olan F = min (F, MAX_FRAME_DELTA). Bu yüzden oyun mantığının çok gerisinde olan kareleri atlamak yerine, herhangi bir büyük kare kaybını (işleri yavaşlatan) atın, birkaç kareyi kurtarın, çizin ve tekrar deneyin.

Bunu yaparak, oynatıcı kontrollerinin aslında ekranda gösterilenlerle daha yakından eşitlendiğinden emin olun.

Son ürün sözde kodu şunun gibi bir şeydir (delta F daha önce belirtilmiştir):

// Assume timers have 1/100 s resolution
const MAX_FRAME_DELTA = 2
// Calculate frame gap.
var delta = current time - last frame time
// Clamp.
delta = min(delta, MAX_FRAME_RATE)
// Update in discrete steps
for(i = 0; i < delta; i++)
{
    update single step()
}
// Caught up again, draw.
render()

Bu tür bir güncelleme her şey için uygun değildir, ancak arcade tarzı oyunlar için, oyunun yavaşladığını görmeyi tercih ederim çünkü kareleri kaçırmaktan ve oyuncu kontrolünü kaybetmekten ziyade birçok şey oluyor. Bunu ayrıca, çerçeve kaybının neden olduğu yeniden üretilemez sorunlara neden olan diğer değişken zamanlı adım yaklaşımlarına tercih ederim.

Bu çözüm her şey için geçerli değildir, ancak dünyadaki her nesne için değişken timestep'in başka bir seviyesi vardır - değişken timestep.

Bu karmaşık görünüyor ve olabilir, ancak oyununuzu ayrık bir olay simülasyonu olarak modellemek olarak düşünün. Her oyuncu hareketi, hareket başladığında başlayan ve hareket sona erdiğinde biten bir olay olarak gösterilebilir. Olayın bölünmesini gerektiren herhangi bir etkileşim varsa (örneğin bir çarpışma), etkinlik iptal edilir ve olay kuyruğuna (muhtemelen olay bitiş zamanına göre sıralanan öncelikli bir sıradır) başka bir olay bastırılır.

İşleme, olay kuyruğundan tamamen çıkarıldı. Ekran motoru, olay başlangıç ​​/ bitiş zamanları arasındaki noktaları gerektiği gibi enterpolasyonlar yapar ve bu tahminde olması gerektiği kadar doğru veya özensiz olabilir.

Bu modelin karmaşık bir uygulamasını görmek için, EXOFLIGHT uzay simülatörüne bakınız . Geleneksel sabit zaman dilimi modelinden ziyade olaya dayalı bir model olan çoğu uçuş simülatöründen farklı bir yürütme modeli kullanır. Bu tip simülasyonun temel ana döngüsü sözde kodda şöyle görünür:

while (game_is_running)
{
   world.draw_to_screen(); 
   world.get_player_input(); 
   world.consume_events_until(current_time + time_step); 
   current_time += time_step; 
}

Bir boşluk simülatöründe birini kullanmanın asıl nedeni, doğruluk kaybı olmadan keyfi bir hızlanma sağlama gerekliliğidir. EXOFLIGHT'daki bazı görevlerin tamamlanması yıllar alabilir ve 32x hızlanma seçeneği bile yetersiz kalır. Bir zaman dilimi modelinde yapılması zor olan kullanılabilir bir sim için 1.000.000x'in üzerinde ivmeye ihtiyacınız olacak. Olaya dayalı modelde, 1 s = 7 ms'den 1 s = 1 yr'a isteğe bağlı zaman oranları elde ediyoruz.

Zaman oranını değiştirmek, sim'in davranışını değiştirmez, ki bu kritik bir özelliktir. Simülatörü istenen hızda çalıştırmak için yeterli CPU gücü yoksa, olaylar yığılır ve olay sırası temizlenene kadar UI yenilemeyi sınırlayabiliriz. Benzer şekilde, sim'i istediğimiz kadar hızlı ileri sarabiliriz ve CPU'yu boşa harcayamayacağımıza veya hassasiyetten ödün vermeyeceğimize emin olabiliriz.

Özetle: Bir aracı uzun, yavaş bir yörüngede (Runge-Kutta entegrasyonunu kullanarak) ve aynı anda zeminde sıçrayan başka bir aracı modelleyebiliriz.

Eksileri: Bu modeli destekleyen hazır fizik motorlarının karmaşıklığı ve eksikliği :)

Sabit zaman adımı kayan nokta doğruluğunu dikkate alarak ve güncellemeleri tutarlı hale getirirken yararlıdır.

Bu basit bir kod parçasıdır, bu yüzden denemek ve oyununuz için işe yarayıp yaramadığını görmek faydalı olacaktır.

now = currentTime
frameTime = now - lastTimeStamp // time since last render()
while (frameTime > updateTime)
    update(timestep)
    frameTime -= updateTime     // update enough times to catch up
                                // possibly leaving a small remainder
                                // of time for the next frame

lastTimeStamp = now - frameTime // set last timestamp to now but
                                // subtract the remaining frame time
                                // to make sure the game will still
                                // catch up on those remaining few millseconds
render()

Sabit bir zaman adımı kullanmanın asıl sorunu, hızlı bir bilgisayarı olan oyuncuların hızı kullanamayacak olmalarıdır. Oyun sadece 30 fps'de güncellendiğinde 100 fps'de render yapmak, sadece 30 fps'de render yapmakla aynıdır.

Söylendiği gibi, birden fazla sabit zaman adımı kullanmak mümkün olabilir. Önemsiz nesneleri (kullanıcı arayüzü veya animasyonlu sprite gibi) güncellemek için 60fps ve önemsiz olmayan sistemleri (fizik ve gibi) güncellemek için 30fps ve kullanılmayan nesneleri, kaynakları silmek gibi sahneler yönetiminin gerisinde kalan daha yavaş zamanlayıcıları kullanabilirsiniz.

Daha önce belirttiğinizin üstüne, oyununuzun olmasını istediğiniz hissi verebilir. Her zaman sabit bir kare hızına sahip olacağınızı garanti edemezseniz, o zaman bir yerde yavaşlama ihtimaliniz vardır ve sabit ve değişken zaman adımları çok farklı görünecektir. Sabit, oyununuzun bir süreliğine yavaş hareket etmesine neden olacak, bu da bazen amaçlanan etki olabilir (büyük patlamaların bir patronu yenerek yavaşlamaya neden olduğu Ikaruga gibi eski bir okul tarzındaki atıcıya bakın). Değişken timestepsler zamana göre olayları doğru hızda hareket ettireceklerdir ancak pozisyonda ani değişiklikler görebilirsiniz.

Sabit bir zaman adımının ağ üzerinden işleri daha kolaylaştıracağını gerçekten göremiyorum, hepsinin bir makinede başlaması ve yavaşlaması biraz eşzamanlı olmayacaktı, ancak bir başkası işleri eşzamanlı hale getirmeyecekti.

Değişken yaklaşıma kişisel olarak her zaman eğildim ama bu makaleler hakkında düşünülmesi gereken ilginç şeyler var. Yine de, özellikle insanların kare hızının PC’de elde edilebilecek çok yüksek oranlarla karşılaştırıldığında sabit bir 60 fps olduğunu düşündüğü konsollarda hala oldukça yaygın adımlar buldum.

Gaffer'ın "zaman adımını düzelt" yaklaşımını kullanın. Oyunu, seçenek 1'deki gibi sabit adımlarla güncelleyin, ancak ne kadar zaman geçtiğine bağlı olarak, oluşturulan kare başına birden çok kez yapın; böylece oyun mantığı, belirli adımlarda kalırken gerçek zamana ayak uydurabilir. Bu şekilde, Euler entegratörleri ve basit çarpışma algılama gibi oyun mantığını uygulamak kolaydır. Ayrıca delta zamanını temel alan grafiksel animasyonları enterpolasyon etme seçeneğiniz de var, ancak bu sadece görsel efektler için ve çekirdek oyun mantığınızı etkileyen hiçbir şey değil. Güncellemeleriniz çok yoğunsa potansiyel olarak başınız belaya girebilir - güncellemeler geride kalıyorsa devam etmek için daha fazlasına ihtiyacınız olacak, bu da potansiyel olarak oyununuzu daha az yanıt verebilir hale getirecektir.

Şahsen, kaçabildiğimde Seçenek 1'i ve gerçek zamanlı olarak senkronize etmem gerektiğinde Seçenek 3'ü severim. Yaptığını bildiğin zaman Seçenek 2'nin iyi bir seçenek olabileceğine saygı duyuyorum, ancak sınırlamalarımı bundan uzak durmaya yetecek kadar iyi biliyorum

60 fps ile senkronize edilmiş sabit zaman adımlarının ayna düzleminde animasyon verdiğini buldum. Bu, VR uygulamaları için özellikle önemlidir. Başka bir şey fiziksel olarak mide bulantısıdır.

Değişken timestepsler VR için uygun değildir. Değişken timesteps kullanan bazı Unity VR örneklerine bir göz atın. Bu hoş değil.

Kural, eğer 3D oyununuz VR modunda yumuşaksa, VR olmayan modda mükemmel olacaktır.

Bu ikisini karşılaştırın (Cardboard VR apps)

(Değişken timesteps)

(Sabit timesteps)

Tutarlı zaman aşımı / kare hızı elde etmek için oyununuz çok okuyuculu olmalıdır. Fizik, UI ve oluşturma özel konulara ayrılmalıdır. Bunları senkronize etmek iğrenç PITA'dır, ancak sonuçlar istediğiniz görüntüyü yansıtır (özellikle VR için).

Mobil oyunlar esp. zorlu çünkü gömülü CPU'lar ve GPU'lar sınırlı performansa sahipler. İşlemciden olabildiğince çok iş çıkarmak için GLSL (argo) kullanın. Parametreleri GPU'ya iletmekten çok veri yolu kaynaklarını tükettiğini unutmayın.

Geliştirme sırasında her zaman kare hızınızı göstermeye devam edin. Asıl oyun 60 fps'de sabit tutulması. Bu, çoğu ekran ve aynı zamanda çoğu göz duvarı için yerel senkronizasyon oranıdır.

Kullanmakta olduğunuz çerçeve size bir senkronizasyon isteğini uyarabilir veya bir zamanlayıcı kullanabilmelidir. Bunu başarmak için uyku / bekleme gecikmesi takmayın - küçük değişiklikler bile fark edilir.

Değişken zaman adımları, mümkün olduğunca sık yapılması gereken prosedürler içindir: İşlem döngüleri, olay işleme, ağ işleri vb.

Sabit zaman adımları, öngörülebilir ve kararlı bir şeye ihtiyaç duyduğunuz zaman içindir. Bu, fizik ve çarpışma tespitini içerir, ancak bunlarla sınırlı değildir.

Pratik açıdan, fizik ve çarpışma tespiti, her şeyden, kendi zaman adımında çözülmelidir. Bu gibi prosedürleri küçük bir sabit zaman adımında gerçekleştirmenin nedeni, onları doğru tutmaktır. Darbe büyüklükleri zamana oldukça bağımlıdır ve aralık çok büyürse, simülasyon kararsız hale gelir ve çılgın şeyler zeminde zıplayan bir top aşaması gibi olur ya da hiçbiri istenen oyun dünyasından zıplar.

Geriye kalan her şey değişken bir zaman adımında çalışabilir (profesyonel olarak konuşulmasına rağmen, kilitleme işleminin sabit bir zaman adımına izin vermesi genellikle iyi bir fikirdir). Bir oyun motorunun tepki verebilmesi için, ağ mesajları ve kullanıcı girişi gibi şeyler en kısa sürede ele alınmalıdır; bu, oylama arasındaki aralığın ideal olarak mümkün olduğu kadar kısa olması gerektiği anlamına gelir. Bu genellikle değişken anlamına gelir.

Geriye kalan her şey eşzamansız olarak ele alınabilir ve zamanlamayı önemli bir nokta haline getirir.