Haruskah mesin untuk game berbasis web akhirnya dimulai sebagai layanan web?

Baru-baru ini saya memutuskan untuk mulai menulis mesin untuk permainan kartu. Saya bukan pemain "kartu" besar, tetapi seorang teman memperkenalkan saya ke permainan (itu adalah putaran pada permainan Denmark), dan saya jatuh cinta.

Saya ingin mengembangkan game dalam 3 segmen:

1. Mesin dasar, menangani kartu / deck / gamestate, dll.
2. Antarmuka pengguna (dalam bentuk aplikasi web seluler / desktop.)
3. Kecerdasan buatan dengan berbagai strategi / kesulitan, dll.

Ini adalah proyek yang sangat berbeda, dalam pikiran saya ... dan saya berjuang untuk melihat bagaimana mereka semua akan cocok bersama dalam jangka panjang. Pada awalnya, saya bahkan tidak ingin bisa "memainkan" permainan menggunakan mesin. Mesin terutama akan diuji oleh unit test-nya. Pengujian bermain tidak akan mulai sampai klien ada. Jadi ada sesuatu hubungan klien-server di sini.

Mesinnya adalah potongan puzzle yang sangat besar. Yang ingin saya ketahui adalah: bagaimana Anda mengembangkan "API publik" untuk mesin ini?

Saya berpikir mesin itu bisa menjadi layanan web yang sangat mendasar, yang mengembalikan statusnya melalui permintaan ke RESTful API, tetapi saya khawatir bahwa mengembangkan mesin itu sendiri sebagai aplikasi web dapat menyebabkan keputusan pemrograman yang buruk. (Misalnya, jika saya memilih kerangka kerja MVC, well, API ini tidak akan benar-benar memiliki pandangan ... itu hanya mengembalikan objek berseri melalui JSON, atau sesuatu seperti itu. Apakah buruk menggunakan MVC untuk layanan seperti ini?)

Gagasan saya yang lain adalah bahwa mesin itu hanya akan menjadi aplikasi konsol, dan saya kemudian akan menulis semacam jembatan untuk menyalurkan data antara itu dan aplikasi web. (Jembatan benar-benar bisa apa saja. Maksudku, server web dan mesin gim dapat menganggur di server IRC dan berbagi statusnya dalam saluran.)

Pendekatan apa yang akan Anda ambil (kembangkan sebagai layanan web, atau kembangkan sebagai aplikasi mandiri dan jembatankan nanti), dan mengapa?

Terima kasih, Robbie.

EDIT: Jadi saya rasa ini termasuk dalam Pengembangan Game. Untuk memperjelas, saya akan menulis mesin permainan kartu. Saya mencoba mencari cara terbaik untuk mengekspos API mesin sehingga dapat diintegrasikan di masa depan dengan klien web, dan klien AI.

Saya bahkan tidak punya akun di sini, jadi bagaimana :)

Rute layanan web mungkin yang terbaik dan terukur.

Saya juga melihat sama sekali TIDAK ada masalah menggunakan kerangka kerja MVC untuk mengembalikan JSON (asp.net mvc hebat dalam hal ini). Jika pengendali Anda hanya mengembalikan JSON pada awalnya yang baik-baik saja, Anda dapat menguji unit tanpa tampilan apa pun. Saat Anda siap untuk menambahkan antarmuka game, Anda dapat menambahkan tampilan. Jika html / css atau flash / silverlight, mereka tidak masalah karena, seperti yang telah Anda nyatakan, Anda telah membangun mesin yang mendasarinya.

Saya tidak yakin seperti apa lingkungan pengembangan atau hosting Anda, tetapi saya tidak akan membuatnya berlebihan. Satu set file php sederhana yang mengembalikan JSON mungkin yang Anda butuhkan. Saya tidak terbiasa dengan game yang Anda buat, jadi saya tidak yakin seberapa kompleksnya game ini.

Menurut pendapat saya, jika Anda baru dalam pengembangan game, dan Anda melakukannya sendiri, saya sangat menyarankan Anda mendapatkan sesuatu yang dapat dimainkan sesegera mungkin, karena itu akan membantu Anda termotivasi untuk menyelesaikan game dan memolesnya ke tingkat yang baik.

Tampilan adalah entitas yang mendaftar ke model untuk diberi tahu ketika perubahan terjadi.

Jika model Anda berada di server web, Anda memiliki masalah karena HTTP tidak menerapkan cara eksplisit untuk membiarkan server memulai komunikasi. Anda dapat menggunakan websocket untuk menangani ini tetapi Anda akan mengorbankan beberapa "RESTfulness" Anda ... Saya pikir solusi yang bagus adalah membiarkan URL web Anda untuk mengidentifikasi model dan menggunakan dorongan server HTTP untuk membiarkan pandangan Anda diberitahukan ketika diperlukan.

Katakanlah Anda menjalankan game

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

Anda bisa menggunakan URL

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

untuk memodifikasi model dan

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

menunggu notifikasi.

Memberitahu akan menunggu - untuk beberapa waktu - untuk mendapatkan berita dari model: jika sesuatu yang terjadi pesan akan dikirim (data apa yang diubah atau acara apa yang terjadi atau apa pun).

Klien dapat melakukan permintaan ajax panjang ke / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / beri tahu dan daftarkan callback notifikasi yang akan memperbarui tampilan dan mengirim ulang permintaan notifikasi berikutnya.

Jika game / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / memberitahukan timeout pada klien, permintaan baru dilakukan, jika timeout di server, sumber daya yang dialokasikan dibebaskan.

Anda dapat membangun sistem pemberitahuan yang cukup umum di server Anda dan perpustakaan pemberitahuan di klien Anda sehingga Anda dapat membangun MVC yang konsisten di atas lapisan pemberitahuan transparan.

Jika Anda mencari teknologi, Anda dapat mempertimbangkan untuk membangun mesin game Anda di atas server Couchdb. Couchdb adalah DBMS non-relasional yang menggunakan HTTP sebagai protokol dan JSON sebagai format dokumen. Itu juga dapat PUT dan DAPATKAN file biner atau HTML sebagai lampiran sehingga dimungkinkan untuk menulis webApp lengkap hanya menggunakan DBMS (a couchApp).

Ada perpustakaan javascript yang memungkinkan untuk bereaksi terhadap pembaruan basis data antara lain. CouchdbApp hanyalah sebuah basis data sehingga Anda dapat menyalin aplikasi ke server lain dengan sinkronisasi: klien Anda dapat menyalin aplikasi Anda ke server lokal mereka dan kemudian bermain melalui LAN yang di-offline.