Ağ entegrasyonu nedeniyle kendi fizik motorumu yazmalı mıyım?

Şu anda yukarıdan aşağıya, gerçek zamanlı bir zombi atıcısı geliştiriyorum. Bunu Java'da kodluyorum, fizik motorum olarak JBox2D kullanıyorum. Bu hafta ağları kodluyorum ve şimdi fizik senkronizasyonuna bağlıyım.

Sunucu daha sonra onayladığı sürece, istemcinin taşımak için ücretsiz olduğu tahmini istemci / yetkili sunucu modelini kullanmayı planlıyorum. Bu, istemcinin sunucuya hareket verileri içeren paketleri göndermesini ve sunucunun gecikmeyi hesaplamasını ve dünyayı eski bir durumdan yeniden simüle etmesini içerir.

Benim sorunum şu anki fizik motorum JBox2D (temelde Box2D'nin bir limanı), dünyayı geri almayı desteklemiyor ve görünüşe göre dünya verilerinin serileştirilmesi o kadar kolay değil. 2 çözümüm var, mevcut fizik motorumu değiştirebilir / genişletebilir veya kendim yazabilirim.

Kendi fizik motorumu yazmanın nedenleri -

• Gereksiz özellikleri kaldırabilirim. Yukarıdan aşağıya bir oyunda sadece çarpışma mekaniğine ve taşıma kuvvetlerine ihtiyacım var. Hiçbir yerçekimi söz konusu değildir.
• Kodu daha iyi anlayabilirim ve [büyük olasılıkla] geri alma işlevlerini uygulamak daha kolay olurdu

JBox2D'yi genişletme / değiştirme nedenleri

• Kendi fizik motorumu yazmak, hantal olabilen önemli miktarda çalışma olurdu.
• JBox2D, geliştiricime yardımcı olabilecek çok destekleyici bir topluluğa sahip
• JBox2D, çarpışma tespiti gibi şeyler için belirli optimizasyonlara sahiptir.
• Bazıları bu konuda zaten yapılmış gibi çalışıyor, ancak çok az kod paylaşıldı

Peki düşüncelerin neler? Bu benim ilk oyunum ve profesyonel bir oyun geliştiricisi değilim. Herkes bölgede zaten yapılan iş için bazı bağlantılar sağlayabilir (tercihen JBox2D / Box2D / Java kullanarak).

2D'de çarpışma tespiti o kadar basit ki, ilk etapta neden bir fizik motoru kullanmayı bile rahatsız edeceğinizi bilmiyorum. Ve tüm taşıma kuvvetleri doğrudan ileri veya eğri olduğu için (düşme, teşhis değiştirme vb.) Şahsen benim için seçmeniz gereken bir beyin yok. Kendi yapmak basittir. Çarpışma:

2 dikdörtgende meydana gelebilecek 3 olası çarpışmayı hesaba katın:

1. Kenardan kenara: Oldukça basit, tek bir kenarın eksenini ve diğerini alıyorsunuz ve aynı alanı mı yoksa yeterince yakın mı işgal edeceklerine siz karar veriyorsunuz.
2. Köşeden köşeye: Dönen şekilleriniz varsa, bu en yaygın olanı olacaktır. Neyse ki, uygulanması da oldukça basit.
3. Köşeden köşeye: Bu çok nadiren gerçekleşecek ve uygulamaya bile değmeyecek. Bunun nedeni, 2 şeyin aynı kesin eksende tam olarak ters yönde hareket ettirilmesi gerektiğidir. Şimdi, eğer her şey 45 veya 90 derece dönerse, bu MAYIS (yine de muhtemelen değil) dahil etmeye değer

EDIT: Yorum olarak, ben bu konuda çok daha az aşina ve mermi / mermi çarpışma hakkında danışılmamalıdır.

2B alanda mermilerle çalıştığımda, fizik motorunu (sıfırdan yapmadığım) kullanarak mermiyi fırlatacağım ve standart çarpışma kullanacağım, hem düz çizgide çalışan hem de kavisli bir yol kullandım.

Bunu sıfırdan bina hakkında yorumlarda okuyun.

EDIT: * Güven bana, * hangisi olursa olsun, mermiler ve herhangi bir zamanda kaç mermi ekranda olabilir çünkü oyun motorunuzda bir tür ölü hesaplaşma gerekir. KESİNLİKLE verilen konumda ekrandaki her bir madde işaretini çerçeve başına güncellemek istemezsiniz. Ama oyunu oynanamaz bir şekilde yavaşlatmanın harika bir yolu: D! Sadece bunları güncellemelisiniz:

• Bir mermi atıldı
• Atıldığı yön
• Kavisli olup olmadığı
  • Ve eğer öyleyse, eğrinin işlevi nedir
• Ne mermi (Bu grafik, efektler, hasar, her şeyi açıklar)

Şimdi motordaki verileri, her bir lanet mermi için sunucu yerine bu verilere göre güncelleyin ve her mermi için paket verileri gönderin. (Bunu ekranda sadece 2 makineli tüfekle yaptığınızı düşünün! İsa!)