क्या एक वेब-सेवा के रूप में अंतिम वेब-आधारित गेम के लिए इंजन शुरू होना चाहिए?

Question

मैंने हाल ही में एक कार्ड गेम के लिए एक इंजन लिखना शुरू करने का फैसला किया है। मैं एक बड़ा "कार्ड" खिलाड़ी नहीं हूं, लेकिन एक दोस्त ने मुझे खेल से परिचित कराया (यह गेम डेनिश पर एक स्पिन है), और मुझे प्यार हो गया।

मैं खेल को 3 खंडों में विकसित करना चाहता हूं:

1. बुनियादी इंजन, कार्ड / डेक / गेमस्टेट इत्यादि को संभालता है।
2. एक उपयोगकर्ता इंटरफ़ेस (मोबाइल / डेस्कटॉप वेब ऐप के रूप में)
3. विभिन्न रणनीतियों / कठिनाइयों आदि के साथ एक कृत्रिम बुद्धिमत्ता।

ये बहुत अलग प्रोजेक्ट हैं, मेरे दिमाग में ... और मैं यह देखने के लिए संघर्ष कर रहा हूं कि वे लंबे समय में एक साथ कैसे फिट होंगे। सबसे पहले, मैं इंजन का उपयोग करके खेल को "खेलना" करने में सक्षम नहीं होना चाहता। इंजन को मुख्य रूप से इसकी इकाई परीक्षणों द्वारा जांचा जाएगा। जब तक कोई क्लाइंट मौजूद नहीं होगा, तब तक प्ले टेस्टिंग शुरू नहीं होगी। तो यहाँ एक क्लाइंट-सर्वर रिलेशनशिप है।

इंजन पहेली का एक बहुत बड़ा टुकड़ा है। जो मैं जानना चाहता हूं वह यह है: आप इस इंजन के लिए "सार्वजनिक एपीआई" को कैसे विकसित करेंगे?

मैं सोच रहा था कि इंजन एक बहुत ही मूल वेब सेवा हो सकती है, जो कि अपने राज्य को प्रश्नों के माध्यम से एक RESTful API पर लौटाती है, लेकिन मुझे चिंता है कि इंजन को वेब ऐप के रूप में विकसित करने से खराब प्रोग्रामिंग निर्णय हो सकते हैं। (उदाहरण के लिए, यदि मैंने एक MVC माइक्रो-फ्रेमवर्क चुना है, तो, इस API में वास्तव में दृश्य नहीं होंगे ... यह सिर्फ JSON के माध्यम से क्रमबद्ध वस्तुओं को वापस कर रहा है, या उस प्रभाव के लिए कुछ है। क्या एमवीसी को किसी सेवा के लिए उपयोग करना बुरा है। इस? )

मेरा दूसरा विचार यह था कि इंजन सिर्फ एक कंसोल ऐप होगा, और मैं बाद में इसके और वेब-ऐप के बीच डेटा को पाइप करने के लिए किसी तरह का एक पुल लिखूंगा। (पुल वास्तव में कुछ भी हो सकता है। मेरा मतलब है, वेब सर्वर और गेम इंजन दोनों एक आईआरसी सर्वर में निष्क्रिय हो सकते हैं और चैनलों में अपने राज्य को साझा कर सकते हैं।)

आप किस दृष्टिकोण को अपनाएंगे (वेब ​​सेवा के रूप में विकसित होते हैं, या स्टैंडअलोन ऐप के रूप में विकसित होते हैं और बाद में पुल होते हैं), और क्यों?

धन्यवाद, रोबी।

संपादित करें: तो मुझे लगता है कि यह खेल विकास में है। स्पष्ट करने के लिए, मैं एक कार्ड गेम इंजन लिखने जा रहा हूं। मैं इंजन के एपीआई को उजागर करने का सबसे अच्छा तरीका जानने की कोशिश कर रहा हूं ताकि इसे भविष्य में वेब क्लाइंट और एआई क्लाइंट के साथ एकीकृत किया जा सके ।

मेरा यहाँ खाता भी नहीं था, इसलिए हॉवी :)

Comments

आपके इंजन को संभालने के लिए कितने समवर्ती खेलों की आवश्यकता है?

— डेरेन

इस बिंदु पर अपरिभाषित है, लेकिन ... एक आदर्श दुनिया में: बहुत सारे और बहुत सारे। निश्चित रूप से समवर्ती खेल होंगे। यदि परियोजना बंद हो जाती है, तो विचार यह है कि यह एक मल्टीप्लेयर ऐप होने जा रहा है, जहाँ आप इसे अपने आप से (सॉलिटेयर स्टाइल) खेल सकते हैं, या एक कमरे में शामिल हो सकते हैं और मनुष्यों / AI के साथ खेल खेल सकते हैं (पोगो, आदि के समान)

Answer 1

वेब सेवा मार्ग शायद सबसे अच्छा और सबसे अधिक स्केलेबल है।

मैं JSON (asp.net mvc इस पर बहुत अच्छा है) को वापस करने के लिए एक MVC फ्रेमवर्क का उपयोग करते हुए बिल्कुल कोई समस्या नहीं देखता । यदि आपके नियंत्रक केवल JSON पहले ही ठीक कर देते हैं, तो आप बिना किसी विचार के इकाई परीक्षण कर सकते हैं। जब आप अपना गेम इंटरफ़ेस जोड़ने के लिए तैयार हों, तो आप विचार जोड़ सकते हैं। यदि उनका सादा html / css या फ़्लैश / सिल्वरलाइट, इससे कोई फर्क नहीं पड़ता, क्योंकि जैसा कि आप बता चुके हैं, आपने पहले ही अंतर्निहित इंजन का निर्माण कर लिया है।

मुझे यकीन नहीं है कि आपका विकास या होस्टिंग वातावरण कैसा दिखता है, लेकिन मैं इसे खत्म नहीं करूंगा। JSON को लौटाने वाली php फ़ाइलों का एक सरल सेट आप सभी की आवश्यकता हो सकती है। मैं आपके द्वारा बनाए जा रहे खेल से परिचित नहीं हूं, इसलिए मुझे यकीन नहीं है कि यह कितना जटिल होगा।

मेरी राय में, यदि आप खेल के विकास में नए हैं, और आप इसे स्वयं कर रहे हैं, तो मैं अत्यधिक अनुशंसा करता हूं कि आपको कुछ ऐसा मिले जो जल्द से जल्द खेलने योग्य हो, क्योंकि यह आपको खेल को पूरा करने और इसे चमकाने के लिए प्रेरित रखने में मदद करेगा। एक अच्छे स्तर पर।

Comments

मैं खेल विकास के लिए नया हूं, और मैं एकमात्र डेवलपर बनूंगा, लेकिन चिंता न करें: कोड मुझे गेम से अधिक दिलचस्पी रखेगा;) मैं रूबरी में लिखे गए हल्के एमवीसी फ्रेम पैड्रिनो का उपयोग करने के बारे में सोच रहा था। क्या अच्छा है यह माउंटेबल ऐप्स है। मैं उनके साथ सुपर परिचित नहीं हूं, लेकिन मुझे लगता है कि मैं इंजन और यूआई ऐप्स को एक ही प्रक्रिया में "माउंट" कर सकता हूं, फिर भी वे अपने संभावित डेटाबेस और स्थिर संसाधनों के साथ अभी भी अलग-अलग ऐप हैं। ।

— रोबी

यह मेरे लिए एक अच्छी योजना की तरह लगता है। यदि कोड आपको दिलचस्पी रखेगा, तो मैं कहता हूं कि इसके लिए जाएं।

— नैट

Answer 2

एक दृश्य एक इकाई है जो बदलाव होने पर एक मॉडल को सूचित करने के लिए पंजीकृत करता है।

यदि आपका मॉडल किसी वेब सर्वर पर रहता है, तो आपके पास एक समस्या है क्योंकि HTTP सर्वर को संचार शुरू करने के लिए एक स्पष्ट तरीके को लागू नहीं करता है। इसे संभालने के लिए आप वेबसोकेट का उपयोग कर सकते हैं, लेकिन आप अपने कुछ "रिस्टेबैलिटी" का त्याग करेंगे ... मुझे लगता है कि एक अच्छा समाधान हो सकता है कि आप अपने वेब URL को एक मॉडल की पहचान करने के लिए और अपने विचारों को सूचित करने के लिए HTTP सर्वर पुश का उपयोग करें। जब जरूरत।

कहते हैं कि आप एक चल रहे खेल में है

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

आप URL का उपयोग कर सकते हैं

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

मॉडल को संशोधित करने के लिए और

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

सूचनाओं के लिए प्रतीक्षा करें।

नोटिफ़िकेशन प्रतीक्षा करेगा - कुछ समय के लिए - मॉडल द्वारा समाचार प्राप्त करने के लिए: यदि कोई चीज़ ख़ुशी से संदेश भेजती है (क्या डेटा बदल दिया जाता है या किस तरह की घटना खुश हो जाती है या जो भी हो)।

क्लाइंट / गेम्स / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / नोटिफ़िकेशन के लिए एक लंबा अनुरोध कर सकता है / अधिसूचना कॉलबैक दर्ज कर सकता है जो दोनों दृश्य को अपडेट करेगा और अगले अधिसूचित अनुरोध को फिर से प्रकाशित करेगा।

यदि गेम / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / क्लाइंट पर टाइमआउट अधिसूचित करता है, तो एक नया अनुरोध किया जाता है, यदि यह सर्वर पर टाइमआउट करता है, तो आवंटित संसाधनों को मुक्त किया जाता है।

आप अपने सर्वर पर काफी सामान्य अधिसूचना प्रणाली और अपने ग्राहकों पर एक सूचना पुस्तकालय का निर्माण कर सकते हैं ताकि आप एक पारदर्शी एमआरआई परत पर एक सुसंगत एमवीसी का निर्माण कर सकें।

यदि आप एक प्रौद्योगिकी की तलाश कर रहे हैं, तो आप काउचडब सर्वर पर अपने गेम इंजन का निर्माण करने पर विचार कर सकते हैं। Couchdb एक गैर-संबंधपरक REST DBMS है जो HTTP को प्रोटोकॉल और JSON को दस्तावेज़ स्वरूप के रूप में उपयोग करता है। यह अटैचमेंट्स के रूप में बाइनरी या HTML फाइल्स को भी PUT और GET कर सकता है, इसलिए केवल DBMS (couchApp) का उपयोग करके एक पूर्ण webApp लिखना संभव है।

एक जावास्क्रिप्ट लाइब्रेरी मौजूद है जो अन्य चीजों के बीच डेटाबेस अपडेट पर प्रतिक्रिया करना संभव बनाती है। एक couchdbApp बस एक डेटाबेस है ताकि आप किसी अन्य सर्वर पर सिंक्रोनाइज़ेशन द्वारा किसी एप्लिकेशन को कॉपी कर सकें: आपके क्लाइंट आपके ऐप को अपने स्थानीय सर्वर पर कॉपी कर सकते हैं और फिर एक ऑफलाइन LAN पर खेल सकते हैं।

Comments

कार्ड प्लेसमेंट एक POST होना चाहिए (या एक PUT, अगर यह बेकार है, लेकिन यह संभावना नहीं है और अच्छी तरह से समर्थित नहीं है), GET का URL नहीं।

@Joe Wreschnig आप सही हैं, वह URL केवल उदाहरण के लिए था और मैंने यह उल्लेख नहीं किया कि किस विधि का उपयोग किया जाना चाहिए।

— FxIII