वेब सेवाएँ पोकर खेलें

हेलो, हैबर।

मैं खेल प्रोग्रामिंग के लिए बहुत आकर्षित हूं, और मुझे पोकर भी पसंद है। इसलिए मैंने पोकर बॉट टूर्नामेंट शुरू करके एक पत्थर से दो पक्षियों को मारने का फैसला किया।

इसी तरह की अन्य घटनाओं के विपरीत, प्रतिभागी के कार्यक्रम को एक वेब सेवा के रूप में लागू किया जा सकता है जिसके साथ croupier HTTP के माध्यम से संवाद करेगा।

परियोजना का प्रारंभिक विचार मेरे मित्र का है (वह हैबर से नहीं है)। पहली बार यह कुछ इस तरह लग रहा था:

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

मुझे याद नहीं कि मैंने क्या उत्तर दिया था। इस तरह की सेवा करना मेरे लिए अधिक दिलचस्प था। चुनौती स्वीकार;)

स्लाइडर

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

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

इस तरह के कार्यान्वयन से बॉट के विकास / परीक्षण (जिसे मैं एसडीके कहता हूं) के विकास के दौरान पोकर रूम के अंदर और उपयोगकर्ता के कंप्यूटर पर एक ही इंजन का उपयोग करना संभव बनाता है। यह सुनिश्चित करता है कि बॉट उपयोगकर्ता की परीक्षण प्रयोगशाला में और एक वास्तविक टूर्नामेंट गेम के दौरान समान परिस्थितियों में होगा, साथ ही कोड दोहराव को कम करेगा।

इंजन का स्रोत कोड Github (MIT लाइसेंस) पर प्रकाशित किया गया है। विंडोज के तहत एसडीके के रूप में उपयोग करने के लिए, एक एक्साई फ़ाइल ( py2exe का उपयोग करके) अजगर इंटरप्रेटर से सक्षम है। लिनक्स और मैक के लिए, एसडीके को स्रोत कोड में आपूर्ति की जाती है और ऑपरेटिंग सिस्टम में स्थापित इंटरप्रेटर का उपयोग करता है।

मौजूदा कार्यान्वयन में, इंजन केवल एक संस्करण पोकर का समर्थन करता है - निश्चित दरों के साथ टेक्सास होल्डम। विकिपीडिया द्वारा देखते हुए, यह दुनिया के सबसे लोकप्रिय पोकर खेलों में से एक है।

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

स्टैटिस्टिक एपीआई के लिए धन्यवाद लिखने के लिए परीक्षण स्वयं आसान और सुखद हैं।

एपीआई

यदि मेरे पास कोई विकल्प है, तो मैं लगभग हमेशा एक स्टेटलेस एपीआई बनाता हूं। इस मामले में, यह पसंद इतनी स्पष्ट नहीं थी, क्योंकि प्रत्येक मोड़ पर पूरे वितरण इतिहास को बॉट को पास करना आवश्यक है (यह निर्णय लेने के लिए न्यूनतम आवश्यक जानकारी है)।

वर्तमान में, यह जानकारी (मैं इसे "वितरण का राज्य" कहता हूं) HTTP POST अनुरोध का उपयोग करके XML प्रारूप में बॉट को प्रेषित की जाती है। सबसे खराब स्थिति में, यह XML 4KB तक का वजन कर सकता है। यह आपको तय करना है कि यह बहुत कम है या थोड़ा है, लेकिन यह वह कीमत है जो मैं बॉट विकसित करने की प्रक्रिया को सरल बनाने और नए प्रतिभागियों के लिए प्रवेश सीमा को कम करने के लिए भुगतान करने के लिए तैयार हूं।

विकास वास्तव में काफी सरल है - प्रतिभागी को बस एक प्रोग्राम लिखने की ज़रूरत है जो कुछ XML को पार्स करता है, इसमें वर्णित स्थिति का विश्लेषण करता है और एक निश्चित निर्णय (पास, समर्थन, वृद्धि, सभी में जाना, आदि) करता है।

XML दस्तावेज़ स्कीमा को स्वतंत्र रूप से विकसित किया जाना था।

उदाहरण

<?xml version="1.0"?> <game> <table button="2"> <player sit="0" name="vbo" stack="80" in_stack="100"/> <player sit="2" name="lenny" stack="80" in_stack="100"/> <player sit="5" name="psycho" stack="90" in_stack="100"/> </table> <posts> <post amount="10" player="psycho" type="small_blind"/> <post amount="20" player="vbo" type="big_blind"/> </posts> <betting> <round name="preflop"> <action amount="20" player="lenny" type="call"/> <action amount="10" player="psycho" type="fold"/> <action amount="20" player="vbo" type="check"/> </round> <round name="flop"> <action amount="0" player="vbo" type="check"/> <action amount="0" player="lenny" type="check"/> </round> <round name="turn"/> <round name="river"/> </betting> <community> <card rank="Q" suit="H"/> <card rank="A" suit="H"/> <card rank="7" suit="S"/> <card rank="T" suit="S"/> </community> </game> 

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

वितरण के आंतरिक प्रतिनिधित्व के लिए, इंजन योजना के एक विस्तारित संस्करण का उपयोग करता है, जहां एक डेक होता है, प्रत्येक बॉट के लिए इसका परिवहन (URL, आदि), पॉकेट कार्ड, आदि इंगित किया जाता है। वितरण की अंतिम स्थिति में एक तसलीम नोड भी शामिल है, जो यह स्पष्ट करता है कि कौन सा खिलाड़ी जीता और उसके पास कौन से कार्ड थे (यदि उसे खोलना था)। वर्तमान कार्यान्वयन में, वितरण की अंतिम स्थिति केवल बॉट के लेखक द्वारा देखी जाती है जब वह पोकर रूम की साइट पर गेम के आंकड़ों को देखता है।

अन्य सभी जानकारी POST अनुरोध के अलग-अलग क्षेत्रों में (HTTP परिवहन के मामले में) प्रेषित की जाती है। ऐसा इसलिए किया जाता है ताकि आप बिना XML के एक साधारण बॉट लिख सकें। इसके अलावा, ऐसा कार्यान्वयन लेखन परीक्षणों को और अधिक सुविधाजनक बनाता है - एक परीक्षण बॉट XML को बिल्कुल भी पार्स नहीं कर सकता है और उदाहरण के लिए, बेतरतीब ढंग से या सरलतम एल्गोरिथ्म का अनुसरण कर सकता है ("चेक / कॉल किसी की भी भावना" या "शर्त / अच्छे कार्ड बढ़ाएं")।

यह अंत करने के लिए, "क्रुपियर" भी बॉट को उन कार्यों की एक सूची देता है जो आम तौर पर इस स्थिति में किए जा सकते हैं। यदि बॉट एक क्रिया करता है जो इस सूची में नहीं है, तो इसकी प्रतिक्रिया को गुना के रूप में माना जाता है, और प्रतिक्रिया पाठ (आमतौर पर स्टैक ट्रेस अपवाद) पोकर कमरे के किनारे पर लॉग को लिखा जाता है। फिलहाल, मैं खुद इन लॉग्स को पढ़ता हूं और बॉट के टूटने पर प्रतिभागी को ईमेल लिखता हूं। बेशक, बहुत निकट भविष्य में, यह प्रक्रिया स्वचालित होगी;)

टूर्नामेंट

खेल प्रोग्रामिंग प्रतियोगिताओं में, मैं हमेशा निम्नलिखित के बारे में बहुत परेशान हूं:

• वे समय पर शुरू नहीं करते हैं।
  उदाहरण के लिए, काम पर एक बड़ी परियोजना शुरू करने से पहले अंतिम सप्ताहांत।
• वे सबसे दिलचस्प क्षण पर समाप्त होते हैं।
  उदाहरण के लिए, जब मैं एक शानदार विचार के साथ आया, जो मेरे कार्यक्रम को अच्छी तरह से बना देगा, बिल्कुल आश्चर्यजनक।

इसलिए, शुरू से ही मैंने मुख्य प्रतियोगिता को "अंतहीन" बनाने का फैसला किया। लोगों के लिए एक वास्तविक ऑनलाइन पोकर क्लब की कल्पना करें। आप किसी भी समय वहां आ सकते हैं, कुछ पैसे फेंक सकते हैं, मेज पर बैठ सकते हैं और बहुत अच्छा समय दे सकते हैं। आप अपने कौशल में सुधार कर सकते हैं और उच्च दांव के साथ तालिकाओं पर बैठ सकते हैं, या आप अपने खाली समय में "कैंडी रैपर" खेलने का मज़ा ले सकते हैं।

बेशक, मैंने अभी कुछ ऐसा ही नहीं किया है, केवल रोबोट के लिए - यह बहुत निराशाजनक होगा, उदाहरण के लिए, छह महीने के विकास के बाद यह महसूस करने के लिए कि सेवा में प्रवेश की सीमा बहुत अधिक है और मैं वहां शानदार अलगाव में खेलता हूं।

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

प्रत्येक दिन की शुरुआत में, पोकर रूम टूर्नामेंट के प्रतिभागियों की रेटिंग बनाता है, जो पिछले दिन के लिए जीतने के लिए (या हारना था) "धन" के आधार पर। उसके बाद, प्रत्येक उपयोगकर्ता का संतुलन शून्य पर सेट होता है और प्रतियोगिता शुरू से शुरू होती है। प्रतियोगिता के भाग के रूप में, पोकर रूम यह सुनिश्चित करने की कोशिश कर रहा है कि सभी बॉट लगातार खेलते हैं, और यदि संभव हो तो विभिन्न विरोधियों के साथ। वर्तमान कार्यान्वयन में, इसके लिए निम्नलिखित नियमों का उपयोग किया जाता है:

• यदि बॉट स्वतंत्र है, तो यह तुरंत पहली मेज पर बैठता है। उसी समय, प्राथमिकता उन तालिकाओं को दी जाती है, जिन पर बॉट लंबे समय तक नहीं बैठे (या कभी नहीं) और कम से कम खिलाड़ियों की संख्या वाले टेबल।
• बॉट खो जाने के साथ ही टेबल से उठ जाता है या उस पर N वितरण से अधिक खेलता है। अंतिम नियम लागू किया जाता है ताकि समान प्रतिद्वंद्वी एक-दूसरे के साथ अनिश्चित काल तक न खेलें।
• पोकर रूम खुली तालिकाओं की "इष्टतम" संख्या का समर्थन करता है - ताकि सभी के लिए पर्याप्त हो और अभी भी ऐसी जगहें हैं जहां आप फ़ेक के बाद सीटें बदल सकते हैं। यह संख्या रैखिक सक्रिय खिलाड़ियों की संख्या पर निर्भर करती है।

इन नियमों को लागू करने वाले एल्गोरिदम (आरेख में यह "टूर्नामेंट कार्यकर्ता" है) समानांतर, अतुल्यकालिक और पूरी तरह से स्वतंत्र रूप से काम करते हैं। यह मशीन पर एक समान भार और प्रति यूनिट समय पर वितरण की संख्या की स्थिरता सुनिश्चित करता है। साथ ही, यह आर्किटेक्चर सिस्टम को और अधिक स्केलेबल बनाता है।

श्रमिक, साइट की तरह, PHP में कार्यान्वित किए जाते हैं (मेरे पास अजगर की तुलना में यहां अधिक अनुभव है) और PostgfSQL डेटाबेस के साथ काम करते हैं। तालिका कतार के समानांतर प्रसंस्करण सुनिश्चित करने के लिए, उम्मीदवारों का चयन करते समय pg_try_advisory_lock का उपयोग किया जाता है। मैं यह गारंटी नहीं दे सकता कि यह विधि सबसे सही है, incl। मुझे टिप्पणियों में इस मुद्दे पर चर्चा करने में खुशी होगी।

योजनाओं

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

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

परियोजना "सिर्फ मनोरंजन के लिए", incl की जाती है। इन सभी "गायों" के कार्यान्वयन के लिए समय सीमा प्रकाशित करना बेकार है। गिट लॉग से देखते हुए, मैंने फरवरी की शुरुआत में वर्तमान कार्यान्वयन करना शुरू कर दिया। इससे हम अपनी गति के बारे में निष्कर्ष निकाल सकते हैं।

यदि पाठक को खेलने में रुचि है, तो पोकर रूम का बीटा संस्करण यहां काम करता है । और यूट्यूब पर आप पीएचपी में एक साधारण बॉट बनाने के तरीके पर एक छोटा वीडियो देख सकते हैं, इसका परीक्षण कर सकते हैं और टूर्नामेंट में पंजीकृत कर सकते हैं।

यूपीडी [०५/३१/२०१३] परियोजना पोस्ट के प्रकाशन के कुछ महीने बाद जमी थी। कारण यह है कि समुदाय से सकारात्मक प्रतिक्रिया के बावजूद, सेवा के केवल कुछ दर्जन वास्तविक उपयोगकर्ता थे, और यहां तक ​​कि बहुत जल्दी उन्होंने अपने समाधान को अपडेट करना बंद कर दिया। यदि आप इस परियोजना को फिर से शुरू करने के लिए इच्छुक हैं, तो मुझे पीएम पर लिखें, मुझे इसे अच्छे हाथों में पारित करने में खुशी होगी।