Nihai bir web tabanlı oyunun motoru bir web hizmeti olarak mı başlamalı?


10

Kısa süre önce bir kart oyunu için motor yazmaya karar verdim. Ben büyük bir "kart" oyuncusu değilim, ama bir arkadaşım beni oyuna tanıttı (bu Danimarka oyununa bir dönüş) ve aşık oldum.

Oyunu 3 segmentte geliştirmek istiyorum:

  1. Temel motor, kartları / desteleri / oyun tablosunu, vb.
  2. Bir kullanıcı arayüzü (mobil / masaüstü web uygulaması şeklinde)
  3. Çeşitli stratejileri / zorlukları olan yapay zeka vb.

Bunlar çok farklı projeler, bence ... ve uzun vadede hepsinin nasıl bir araya geleceğini görmekle uğraşıyorum. İlk başta, motoru kullanarak oyunu "oynamak" bile istemiyorum. Motor öncelikle birim testleri ile test edilecektir. İstemci var olana kadar oyun testi başlamaz. Yani burada bir istemci-sunucu ilişkisi var.

Motor bulmacanın çok büyük bir parçası. Bilmek istediğim şu: Bu motor için "genel API" yı nasıl geliştirirsiniz?

Motorun sorgulama yoluyla durumunu RESTful API'ye döndüren çok temel bir web hizmeti olabileceğini düşünüyordum, ancak motorun kendisini bir web uygulaması olarak geliştirmenin kötü programlama kararlarına yol açabileceğinden endişeliyim. (Örneğin, bir MVC mikro çerçeve seçtiysem, bu API gerçekten görünümlere sahip olmazdı ... sadece JSON aracılığıyla serileştirilmiş nesneleri döndürüyor ya da bu yönde bir şey. MVC kullanmak gibi bir hizmet için kötü bu? )

Diğer fikrim, motorun sadece bir konsol uygulaması olacağıydı ve daha sonra, veriyle web uygulaması arasında veri oluşturmak için bir tür köprü yazacağım. (Köprü gerçekten herhangi bir şey olabilir. Yani, web sunucusu ve oyun motoru bir IRC sunucusunda boşta kalabilir ve durumlarını kanallarda paylaşabilir.)

Hangi yaklaşımı benimseyeceksiniz (bir web hizmeti olarak geliştirebilir veya bağımsız bir uygulama olarak geliştirip daha sonra köprüleyebilirsiniz) ve neden?

Teşekkürler, Robbie.

EDIT: Sanırım bu Oyun Geliştirme aittir. Açıklığa kavuşturmak için bir kart oyunu motoru yazacağım. Gelecekte bir web istemcisi ve bir AI istemcisi ile entegre olabilmesi için motorun API'sını ortaya çıkarmanın en iyi yolunu bulmaya çalışıyorum .

Burada bir hesabım bile yoktu, öyleyse merhaba :)


Motorunuzun kaç eşzamanlı oyunu ele alması gerekir?
Darien

Bu noktada tanımsız, ama ... mükemmel bir dünyada: çok ve çok. Kesinlikle eşzamanlı oyunlar olacak. Proje başlarsa, fikir, kendiniz oynayabileceğiniz (solitaire tarzı) veya bir odaya katılabileceğiniz ve oyunu insanlarla / AI'larla (Pogo'ya benzer şekilde) oynayabileceğiniz çok oyunculu bir uygulama olacağıdır.

Yanıtlar:


5

Web hizmeti yolu muhtemelen en iyi ve en ölçeklenebilir olanıdır.

Ayrıca JSON (asp.net mvc bu harika) dönmek için bir MVC çerçeve kullanarak kesinlikle hiçbir sorun görüyorum . Denetleyicileriniz önce JSON döndürürse sorun olmaz, herhangi bir görünüm olmadan testi test edebilirsiniz. Oyun arayüzünüzü eklemeye hazır olduğunuzda, görünümler ekleyebilirsiniz. Düz html / css veya flash / silverlight ise, önemli değil, çünkü belirttiğiniz gibi, altta yatan motoru zaten oluşturdunuz.

Geliştirme veya barındırma ortamlarınızın nasıl göründüğünden emin değilim ama aşırı mühendislik yapmam. İhtiyacınız olan tek şey JSON döndüren basit bir php dosyaları kümesi. Yaptığınız oyuna aşina değilim, bu yüzden ne kadar karmaşık olacağından emin değilim.

Bence, oyun geliştirmede yeniyseniz ve kendiniz gidiyorsanız, en kısa zamanda oynanabilir bir şey almanızı şiddetle tavsiye ederim, çünkü oyunu tamamlamak ve cilalamak için motive olmanıza yardımcı olacaktır. iyi bir seviyeye.


Oyun geliştirmede yeniyim ve tek geliştirici olacağım, ama endişelenmeyin: kod beni oyundan daha fazla ilgilendirecek;) Ruby'de yazılmış hafif bir MVC çerçevesi olan Padrino'yu kullanmayı düşünüyordum. Güzel olan, monte edilebilir uygulamalara sahip olmasıdır. Onlara çok aşina değilim, ancak aynı süreçlerde motoru ve kullanıcı arayüzü uygulamalarını yan yana "bağlayabileceğimi düşünüyorum, ancak yine de kendi veritabanları ve statik kaynakları olan [potansiyel olarak] ayrı uygulamalar. .
Robbie

Bu bana iyi bir plan gibi geliyor. Kod sizi ilgilendirecekse, bunun için git diyorum.
Nate

1

Görünüm, değişiklikler meydana geldiğinde bildirilecek bir modele kaydolan bir varlıktır.

Modeliniz bir web sunucusunda bulunuyorsa, HTTP sunucunun bir iletişimi başlatmasına izin vermek için açık bir yol uygulamadığı için bir sorununuz vardır. Bunu yapmak için websocket kullanabilirsiniz ama "RESTfulness" bazı fedakarlık olacaktır ... Ben iyi bir çözüm web URL'nizin bir modeli tanımlamak izin vermek ve HTTP sunucusu itme görüşlerinizi bildirmek için kullanmak olabilir düşünüyorum ihtiyaç duyulduğunda.

Diyelim ki koşu oyununuz var

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/

URL'yi kullanabilirsiniz

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/playCard?id=3&place=stack 

modeli değiştirmek ve

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify 

bildirimleri beklemek.

Bildir, modele göre haber almak için bir süre bekler: bir şey olursa bir mesaj gönderilir (hangi veriler değiştirilir veya ne tür bir olay olur ya da her neyse).

İstemci / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / uzun bir ajax isteği yapabilir ve hem görünümü güncelleyecek hem de bir sonraki bildirim isteğini yeniden gönderecek bir bildirim geri çağrısı yapabilir.

Games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / istemcideki zaman aşımlarını bildirirse, sunucuda zaman aşımına uğrarsa yeni bir istek yapılır, ayrılan kaynaklar serbest bırakılır.

Saydam bir bildirim katmanı üzerinde tutarlı bir MVC oluşturabilmeniz için sunucunuzda oldukça genel bir bildirim sistemi ve istemcilerinizde bir bildirim kitaplığı oluşturabilirsiniz.

Bir teknoloji arıyorsanız, oyun motorunuzu Couchdb sunucusuna kurmayı düşünebilirsiniz. Couchdb, HTTP'yi protokol olarak ve JSON'u belge biçimi olarak kullanan ilişkisel olmayan bir REST DBMS'dir. Ayrıca, PUT ve GET ikili veya HTML dosyalarını ek olarak alabilir, böylece yalnızca DBMS'yi (couchApp) kullanarak tam bir webApp yazmak mümkündür.

Diğer şeylerin yanı sıra veritabanı güncellemelerine tepki vermeyi mümkün kılan bir javascript kütüphanesi vardır. CouchdbApp basitçe bir veritabanıdır, bu nedenle senkronizasyon yoluyla bir uygulamayı başka bir sunucuya kopyalayabilirsiniz: istemcileriniz uygulamanızı yerel sunucularına kopyalayıp çevrimdışı bir LAN üzerinden oynatabilir.


2
Kart yerleşimi bir POST (veya idempotent ise PUT olmalıdır, ancak bu olası değildir ve iyi desteklenmez), GET URL'si değil.

@Joe Wreschnig haklısınız, bu URL sadece açıklama amaçlıdır ve hangi yöntemin kullanılması gerektiğinden bahsetmedim.
FxIII
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.