Fizik ve oyun mantığını UI kodundan ayırma


12

Basit bir blok tabanlı bulmaca oyunu üzerinde çalışıyorum.

Oyun, oyun alanında hemen hemen hareketli bloklardan oluşuyor, bu yüzden önemsiz bir fizik simülasyonu. Benim uygulama, ancak, bence ideal olmaktan uzak ve bana nasıl daha iyi yapmak için herhangi bir işaret verebilir misiniz merak ediyorum.

Kodu iki alana ayırdım: Oyun mantığı ve UI, birçok bulmaca oyununda yaptığım gibi:

  • Oyun mantığı oyunun genel kurallarından sorumludur (örneğin satrançtaki resmi kural sistemi)
  • Kullanıcı arayüzü oyun alanını ve taşlarını (örn. Satranç tahtası ve taş parçaları) görüntüler ve animasyonlardan (örn. Satranç taşlarının hareketli hareketi) sorumludur.

Oyun mantığı, oyun durumunu mantıksal bir ızgara olarak temsil eder; burada her birim bir hücrenin ızgaradaki genişliği / yüksekliğidir. Böylece, genişlik 6 bir ızgara için, genişlik 2 bir bloğu sınırla çarpışana kadar dört kez taşıyabilirsiniz.

Kullanıcı arabirimi bu ızgarayı alır ve mantıksal boyutları piksel boyutlarına dönüştürerek çizer (yani, sabit ile çarpar). Ancak, oyunun neredeyse hiç oyun mantığı olmadığından, oyun mantığı katmanım [1] çarpışma algılaması dışında yapacak fazla bir şey yok. Şöyle çalışır:

  1. Oyuncu bir parçayı sürüklemeye başlar
  2. Kullanıcı arabirimi, oyunun mantığını o parçanın yasal hareket alanı için sorar ve oynatıcının bu alanda sürüklemesini sağlar
  3. Oyuncu bir parçayı bırakıyor
  4. Kullanıcı arabirimi parçayı ızgaraya bağlar (böylece geçerli bir mantıksal konumda olur)
  5. UI oyun mantığına yeni mantıksal pozisyonu söyler (mutator yöntemleri ile kaçınmak istiyorum)

Bundan pek memnun değilim:

  • Oyun mantığı katmanım için birim testleri yazıyorum, ancak kullanıcı arayüzü değil ve tüm zor kodun kullanıcı arayüzünde olduğu ortaya çıktı: Parçanın başkalarıyla veya sınırla çarpışmasını durdurmak ve ızgaraya yapıştırmak.
  • Kullanıcı arayüzünün oyun mantığına yeni durum hakkında bilgi movePieceLeft()vermesini sevmiyorum, diğer oyunlarda olduğu gibi bir yöntem ya da bunun gibi bir şey demeyi tercih ederim, ama bu yaklaşımdan uzak durmadım, çünkü oyun mantığı, kullanıcı arayüzünde mümkün olan sürükleme ve yakalama hakkında hiçbir şey bilmiyor.

Sanırım yapılacak en iyi şey oyun mantığı katmanımdan kurtulmak ve bunun yerine bir fizik katmanı uygulamak olacaktır. Bununla ilgili birkaç sorum var:

  1. Böyle bir fizik katmanı yaygın mıdır yoksa oyun mantığı katmanının bunu yapması daha mı tipiktir?
  2. Izgara ve parça sürükleme koduna yapışmak kullanıcı arayüzüne mi yoksa fizik katmanına mı ait?
  3. Böyle bir fizik katmanı tipik olarak piksel boyutları veya oyun mantık katmanım gibi bir tür mantıksal birim ile çalışır mı?
  4. Bir kez oyunun kod tabanında olay tabanlı çarpışma algılama gördüm, yani, oyuncu sadece parçayı sürükleyecekti, UI bunu itaatkar bir şekilde işleyecek ve fizik sistemini bilgilendirecek ve fizik sistemi bir onCollision () yöntemini çağıracaktı bir çarpışma algılandığında parça üzerinde. Daha yaygın olan nedir? Bu yaklaşım mı yoksa önce yasal hareket alanını mı istiyorsun?

[1] katman , muhtemelen ne demek istediğim için doğru kelime değil, ancak alt sistem aşırı şişmiş ve sınıf yanlış yönlendiriyor, çünkü her katman birkaç sınıftan oluşabilir.


Cevabım yardımcı oldu mu, daha fazla bilgiye mi ihtiyacınız var?
Marcouiller

Lütfen, böyle bir mimariyi veya bir şeyi uygulamadaki sorunlarınız hakkında yardımcı olduysa veya söylediyse cevabı kaldırın ve kabul edin, ancak daha iyi yardımcı olabilmemiz için durumunuzdan bizi haberdar edin. =)
Marcouiller

Yanıtlar:


3

Ne istediğini anlayabildiğim için bu soruya cevap vermeye çalışacağım, ancak hala öğrenmeye başladığım için fazla oyun geliştirme deneyimim yok.

Gördüğüm gibi, GUI kodunu oyun mantığınızdan ve etki alanı nesnelerinden, yani bulmaca parçalarından ayırmanız gerekir. Bunlar gerçekten üç ayrı katman - ve evet, layerbence uygun bir terim. Genellikle bir sistemin her bir nesne seviyesini birbirinden bağımsız alt sistemlere ayırma kavramlarını açıklamak için kullanılır.

Nesneye yönelik programlama ile ilgili olarak, her nesne bir sınıf olmalıdır. Yani, bulmacanızın her parçası kendi başına bir sınıftan ve dolayısıyla oyun tahtasından oluşacaktır. Oyun tahtası , oyuncuya vermek istediğiniz boyutuna ve hareket kapasitesine bağlı olarak X bulmacanın parçalarını içermelidir .

İşte konu hakkındaki düşüncelerim - umarım yardımcı olur:

  1. GUI katmanı: Bu katman, oyunun kendisi ile oyuncu arasındaki etkileşime izin vermek için sadece oyun tahtasında parçaları görüntülemek için yöntemler içermelidir;
  2. Game Controller katmanı: Oyuncunun girdilerinden sorumludur. Bir parçanın farklı yönlerde hareket etmesini söylemesi ve oyun tahtasına hareket üzerine çarpışma olup olmadığını sorması gereken katman budur;
  3. İş katmanı: Bu katman tüm iş sınıflarınızı, yani oyununuzun parçalarını ve bulmaca parçalarını içeren oyun tahtası nesnesini içerecektir.

Bu mimaride, GUI katmanının, oyun halinin oyuncusunu, her bulmacanın parçasını göstermesini sağlayabilirsiniz. GUI katmanı daha sonra oyuncu girişlerini almaktan ve bunu altta yatan Game Controller katmanına aktarmaktan sorumlu olacaktır, bu da çarpışma tespitinden sorumlu olacaktır. Eğer yoksa, o giriş parçasına hareket etmesi için parça sipariş edilebilir. Bunu yapmak için, bu parçayı çağırmanız yeterlidir MoveLeft,MoveRightparçanın hareket etmesini sağlayan yöntemler. Ayrıca oyun tahtasına hangi parçayı hareket ettirmek istediğinizi bildirebilirsiniz ve daha sonra kendi başına parçanın hareketini sipariş eder ve parça istenen yöne doğru hareket eder. Bu mimari, her bir kod parçasını farklı katmanlarda test etmeyi kolaylaştırır ve daha sonra birim testi, entegrasyon testi ve fonksiyonel test için size izin verir.

Bunun görme açısından biraz kafa karıştırıcı görünebileceğini biliyorum ve eğer değilse tanrıya şükürler olsun! Daha fazla ayrıntı ve yardıma ihtiyacınız olursa, lütfen sormaya çekinmeyin, oyun geliştirmeye yeni başlayan biri olsam da elimden gelenin en iyisini yapmaktan memnuniyet duyarım.

Okuduğunuz için teşekkürler! =)


2
Bu da Model View Controller'a çok benziyor.
tenpn

Dürüst olmak gerekirse, altta yatan uygulamadan soyutlama arayüzünün herhangi bir açıklaması Model View Controller gibi görünecektir. Ancak, kullanılan terminoloji ve teknikler aynıdır (uygulama ayrıntılarından soyutlama ve kullanıcı arayüzünü uygulamadan ayırma). Ancak çok basit bir ortam olduğunu varsayar. Burada birden fazla katman var ve her katmanda denetleyiciler var. Görünümü modelden ayırmak burada yeterli değil, ayrıca kullanıcı etkileşimi kontrolünü oyun kontrolünden ayırmanız gerekiyor.
MrCranky

Burada neyin karmaşık olduğunu merak ediyorum, çünkü bir bulmacanın parçalarını sınırlı bir oyun tahtasına taşıyoruz. Kontroller GUI'den alınmıştır, bu aslında iyi bir yoldur ve bir soyutlama katmanına, yani oyun denetleyicisine geçer. Oyun kumandası hareket sırasında çarpışma olup olmadığını kontrol eder, ardından herhangi bir çarpışma tespit edilmezse parçanın hareket etmesini söyler. Yapboz parçası daha sonra istenen yöne doğru doğru hareket eder ve Positionözellik alıcı işlevi aracılığıyla yeni konumunu ortaya çıkarır , böylece oyun denetleyicisi artık GUI'nin bu yeni parçayı bu yeni konuma göstermesini gerektirir.
Marcouiller

heh, birkaç ay önce oyun geliştirmede "MVC" hakkında blog yazdım. Evet, oyun geliştirme ile başlamamış
Joel Martinez

1
Geç kabul ettiğim için özür dilerim, maalesef bir süredir projeden uzaklaştım. Denetleyici yaklaşımını gerçekten seviyorum, benimseyeceğim!
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.