İki ayrı grafik kütüphanesinde aynı oyun mantığı

Hangi kod felsefesi / soyutlama / program tasarımının yapısı, oyun mantığını yeniden kodlamak zorunda kalmadan oyunun hem 2D hem de 3D grafiklerle (ayrı olarak) kullanılmasına izin verir?

Aynı kodu alarak, minimum şeyleri değiştirerek konuşuyoruz (örneğin, 3D varlıklar için dosya adlarıyla 2B varlıkların dosya adlarını değiştirin) ve belki de her bir jenerik / şablon için bir temel sınıfın birkaç uzmanlığını ekliyoruz.

Bunu mantıklı bir yere yerleştirmek için: gerçekten çok iyi oyun donanımlarına sahip oyuncular için bir birinci sınıf, performansa aç 3D istemcinin ve eski için daha mütevazi bir 2D istemcinin olduğu bir LAN çok oyunculu oyun hayal edin birinin tavan arasında bulduğu tozlu kutular. Ama yine de aynı oyun - aynı olaylar kaydedildi (birisi para aldı), aynı Ağ protokolü kullanılıyor, dünyalar orantılı, vb.

Bir MVC bağlamına koymak için: Kontrolörler tamamen aynıdır ("Yukarı" tuşuna basmak oyuncuların ivmesini saniyede 3,5 birim ayarlayacaktır), Görünümler tamamen farklıdır (2B'ye karşı 2D) ve Model aynıdır doğrudan grafiklerle ilgili herhangi bir şey hariç (ortam için bir çarpışma kontrolü her 5 saniyede bir yapılır ve aynı algoritmayı kullanır.Bu, 2D sürümdeki tüm Oyun Nesneleri için bir Z koordinatı olduğu anlamına gelir, ancak sadece göz ardı edilir veya başka bir şekilde kullanıcıya gösterilir; örneğin, oynatıcı havada olduğunda daha solda görüntülenen bir gölge ile).

Bunu bu kadar büyüleyici bir konu yapan şey, geliştiricinin verilerinin nasıl yapılandırıldığı ve kontrolün nasıl aktığı hakkında çok net bir fikre sahip olmasını zorlamasıdır. Bunun SDL, D3DX veya OpenGL gibi bir grafik kütüphanesinden başka bir şey kullanmadığı anlamına gelmez. Oyun motoru yok!

Bu çoğunlukla teorik bir soru olduğundan, programlama dillerini bunun dışında bırakacağım, ancak bir örnek vermek isterseniz, istediğiniz dili kullanabilirsiniz, tüm domuz gitmek istiyorsanız C ++, hatta hissediyorsanız Brainfuck (Herhangi bir somut cevap ve ayrıca soyut cevaplar takdir edilecektir!).

Sanırım tüm (?) Grafik kütüphanenizi saran bir soyutlama katmanı olurdu; kullanacağınız her kitaplık için yeni bir taneye ihtiyacınız olacak ve her birinin aynı harici API'ye sahip olması gerekecektir.

Dizelerin yerelleştirilmesini düşünün: "Envanter" dizesini oyununuza sabit olarak kodlamak yerine, bunun yerine (muhtemelen özel olarak oluşturulmuş) yerelleştirme kitaplığınızı çağırırsınız; oyun.

Aynı şekilde, grafik motoruna tüm çağrılar yapılmış olacağını aracılığıyla etrafında senin sarıcı.

Bunu yaparken, grafik motorunuza verebileceğiniz komutları sınırlandırır / kısıtlarsınız. İşte bazı önemli olanlar:

1. (Konum) konumunda çizim (grafik nesnesi)
2. (Grafik nesnesi) özelliğinin (alfa, döndürme vb.) Özelliğini değiştirme
3. (Grafik nesnesi) öğesini (konuma) taşı
4. Harita oluştur (seviye adı / veri yapısı)

Ve projeniz üzerinde çalışırken bulacağınız bazı diğerleri.

Sıkı Yazılmış Nesne Tabanlı Bir Dil kullanıyorsanız, yukarıdaki komutları, paketleyicilerinizin uygulayacağı arabirimi çağırırsınız . Tercihen, bu olacak tek un korunan / ortak yöntemleri.

Şimdi, grafik kitaplıklarınızın her biri için yeni bir sarmalayıcı oluşturun ve API'yı uygulayın . Size __ 'de __' i çizmek için bir komut verildiğinde, hareketli grafiği veya modeli oluşturmak ve onu ortamınıza çizmek için kod kullanmalısınız. Bu, her bir hareketli grafiğin bir karma içinde saklanması gibi belirli bir sembolle başka bir zamanda yeniden erişilebilir olması gibi bazı hileler gerektirebilir.

Harita oluşturmaya gelince, en verimli yol, her bir grafik motoru için her haritayı önceden önceden oluşturmak ve bir arama yapmak olacaktır. Alternatif olarak haritayı kendi özel veri yapınızda saklayabilir ve daha sonra bu veri yapısından bir harita oluşturmak için sarmalayıcıyı kullanabilirsiniz.

Umarım bu size yardımcı olur =]

Oyununuzun mimarisini, ekran kodunun tamamen soyutlanmasına izin verecek kadar MVC'ye yakın bir paradigma ile inşa etmek, büyük projeler için oldukça zor olacaktır. Ancak, hem 2D hem de 3D istemciyi destekleyen bir oyun yaratmanın en büyük engeli, her iki istemcinin de eşit derecede yetenekli olduğu bir oyun tasarlamak olacaktır.

İki istemciyi oluşturmak ve desteklemek amacıyla oyununuzun tasarımına başlamak gerekli olacaktır ve muhtemelen tüm oyun işlevlerini 2D istemcisi için anlamlı olanla sınırlamak en güvenli olacaktır.

Örnek bir tuzak olarak, sınırlı bir işlevsellik seti tasarlamıyorsanız, önemli bilgilerin veya nesnelerin yalnızca belirli açılardan görülebildiği seviyeler oluşturabilirsiniz. 2B istemciniz bu önemli nesnelerin her birinde görünürlüğü olan bir görüş açısını açıkça desteklemediği sürece 360 ​​derece görüntüleme özgürlüğüne sahip 3B istemciler için iyi olsa da, istemcinin kullanıcılarını bozarsınız.

2B istemci (8 veya 16 veya benzeri) için belirli sayıda görüntüleme açısı belirlemek ve tüm içeriği bu kısıtlamalara uyacak şekilde geliştirmek en iyisidir. Ne yazık ki, yalnızca belirli bir açı kümesinden görüntülenebilecek şekilde tasarlanmış düzeyleriniz ve nesneleriniz varsa, bir 3D istemciden oldukça garip görünebilir.

Bence, eşit yeteneklere sahip olması amaçlanan 2D ve 3D istemcilere izin veren bir oyun tasarımı girişimi kötü bir seçim olacaktır. Asimetrik oyun seçenekleri tasarlamak ve her müşterinin güçlü yönlerini oynamasına izin vermek için kaynakların daha iyi kullanılması olacağını düşünüyorum. Örneğin, 2B istemci öncelikle oyun dünyasında stratejik düzeyde bir perspektife odaklanmışsa ve 3B istemci taktik düzeyde oyun için kullanılıyorsa.

Sanırım kendi sorunuzu hemen hemen cevapladınız:

Bir MVC bağlamına koymak için: Kontrolörler tamamen aynıdır ("Yukarı" Tuşuna basmak oyuncuların hızlanmasını 3,5 birim / saniye olarak ayarlayacaktır), Görünümler tamamen farklıdır (2D'ye karşı 3D) ve Model aynıdır grafiklerle doğrudan ilgili olan her şey hariç.

Böylece, girdi, oyun mantığı, vb. Ve grafikler arasında yeterli bir soyutlama sağlayarak sorunu çözmüş olacaksınız.

Bu, temel olarak MVC modelinin noktasıdır, özellikle masaüstü ve web uygulamalarıyla ilgilidir: aynı verilere erişen ve işleyen birden fazla istemci olabilir (örneğin, bir web arayüzü, mobil istemci ve e-posta için masaüstü istemcisi).

Basit istiyorsanız basit tutun: - Nesneleri taşımak için oyun mantığını yazın. Üzerinde oluşturma ile ilgili herhangi bir veri saklamayın. - Oyun verilerinin durumuna bakma ve çizme şansı verilen oluşturucular yazın.

Bunun için az çok karmaşık programlama tekniklerini kullanabilirsiniz. İhtiyacınız olan tek şey, her oyun nesnesi için oluşturmanız gereken "ekstra" verilere ulaşmanın bir yoludur. En basit yol sıfır ekstra veriye sahip olmaktır! Oyun nesnesi bir "Sihirbaz" ise, bir Sihirbaz çizin.

Daha karmaşık yöntemlere ihtiyacınız varsa, polimorfizm, hatıra kalıbı, hash tabloları, boşluk * işaretçileri vb. Göz önünde bulundurun.