दगाबाज़: एक नई शुरुआत

यह अपनी हवा के साथ चलने के लिए दक्षिण और उत्तर की ओर, गोल चक्कर, चक्कर लगाता है
और इसके सर्किट के अनुसार हवा लौटती है;
सभी नदियाँ समुद्र में बहती हैं - और समुद्र नहीं बहता,
जिस स्थान पर नदियाँ चलती हैं, वहाँ - वहाँ वे चलते रहते हैं;

सनकी की किताब

1998 में, अपने समय के लिए एक पूरी तरह से अद्वितीय, अनुप्रयोग विकसित किया गया था जो आपको एक छोटे पाठ विवरण की भाषा के लिए एक अमूर्त बोर्ड गेम (या पहेली) के विकास की प्रक्रिया को कम करने की अनुमति देता है, लिस्प की अस्पष्ट याद ताजा करती है। इस परियोजना को Zillions of Games कहा जाता था। इसने बोर्ड गेम्स के प्रशंसकों में रोष पैदा कर दिया। वर्तमान में, इस तकनीक का उपयोग करके 2,000 से अधिक एप्लिकेशन बनाए गए हैं।

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

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

मेरा लक्ष्य अमूर्त बोर्ड गेम के निर्माण के लिए एक अधिक बहुमुखी और उपयोगकर्ता के अनुकूल "इंजन" का विकास है। लगभग एक साल से मैं ZoG और Axiom की संभावना का अध्ययन कर रहा हूं और उनकी सीमाओं के बारे में बहुत कुछ सीखा है। मुझे लगता है कि मैं एक अधिक सार्वभौमिक और क्रॉस-प्लेटफ़ॉर्म समाधान बनाकर उनकी समस्याओं को हल कर सकता हूं। इस परियोजना पर काम की प्रगति पर मैं रिपोर्ट करूंगा।

खुलापन और प्रतिरूपकता

शायद ZoG का मुख्य दोष इसका बंद होना है। उत्पाद को एक ही प्लेटफॉर्म - विंडोज के तहत "एक बार और हमेशा के लिए" इकट्ठा किया गया था। क्या यह ओपन-सोर्स कोड था, कोई इसे लिनक्स, एंड्रॉइड, आईओएस के तहत पोर्ट करने की कोशिश कर सकता है ... एक और समस्या इसकी अखंडता है।

ZoG में मॉड्यूलरिटी की शुरुआत होती है, जिससे गेम DLL से संबंध बनाने की अनुमति मिलती है, जिसमें AI के कस्टम कार्यान्वयन भी शामिल हैं। Axiom थोड़ा आगे जाता है, जिससे आप ZoG कर्नेल का उपयोग किए बिना मोड ऑटोप्ले में एप्लिकेशन चला सकते हैं। इस समाधान की गंभीर सीमा के बावजूद (केवल दो खिलाड़ियों के लिए आवेदन का समर्थन), यह उदाहरण दर्शाता है कि मॉड्यूलरिटी कैसे सहायक होगी! दो बॉट (विभिन्न एआई सेटिंग्स का उपयोग करके) के साथ एक गेम को व्यवस्थित करने और बड़ी संख्या में गेम पर आंकड़े एकत्र करने के अवसर को समाप्त नहीं किया जा सकता है। लेकिन कितना बेहतर होगा अगर उत्पाद पूरी तरह से मॉड्यूलर हो गया है!

• पीढ़ी मॉड्यूल ले जाएँ
• निष्पादन मॉड्यूल ले जाएँ
• नियंत्रण मॉड्यूल
• एआई मॉड्यूल
• विज़ुअलाइज़ेशन मॉड्यूल

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

चाल निष्पादन मॉड्यूल खेल राज्य का संरक्षक है। वर्तमान गेम स्थिति की जानकारी मांग पर अन्य सभी मॉड्यूल को स्थानांतरित कर दी जाती है। उन कारणों के लिए जो मैं नीचे दूंगा, निष्पादन प्रगति को पीढ़ी के मॉड्यूल से गुजरना होगा, जिसका कार्य मॉड्यूल निष्पादन के संदर्भ में एक कमांड का गठन है। साथ ही, मूव जनरेशन मॉड्यूल का कार्य गेम स्पेस का प्राथमिक कॉन्फ़िगरेशन है, जो गेम के विवरण के आधार पर होता है।

नियंत्रण मॉड्यूल, वास्तव में, आवेदन ही है। यह संभावित चालों की सूची के लिए चाल पीढ़ी मॉड्यूल को पूछता है और खेल राज्य को बदलता है, चालित निष्पादन मॉड्यूल के लिए चयनित चाल को पारित करता है। नियंत्रण मॉड्यूल को एक या अधिक एआई बॉट खेलने के लिए जोड़ा जा सकता है। जितने की आवश्यकता है (और संभवतः भिन्न)! नियंत्रण इकाई का प्रकार कार्यों के विभाजन द्वारा निर्धारित किया जाता है। यह गेम के आँकड़े, गेम सर्वर को इकट्ठा करने के लिए ऑटोप्ले हो सकता है (यह कई राज्य स्टोरों को नियंत्रित कर सकता है, जिससे बड़ी संख्या में गेमिंग सत्र हो सकते हैं) या ऑफ़लाइन खेलने के लिए व्यक्तिगत अनुप्रयोग।

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

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


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

खेल का स्थान

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


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


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


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

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

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

 {board 5 18 {grid} {variable} WhitePieces {variable} BlackPieces board} 

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



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


संक्षेप में, मैं कह सकता हूं कि, अपने खेल ढांचे के लिए, मैंने ZoG, Axiom, और Ludi में जो सबसे अच्छा सोचा गया था, उसे लेने का फैसला किया और जो कुछ भी, मेरी राय में, उनमें कमी है।

पीढ़ी को आगे बढ़ाएं

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

 (piece (name Bishop) (image White "images\Chess\SHaag\wbishop.bmp" "images\Chess\wbishop.bmp" Black "images\Chess\SHaag\bbishop.bmp" "images\Chess\bbishop.bmp") (moves (slide ne) (slide nw) (slide se) (slide sw) ) ) 

एक पैरामीटर के रूप में, एक मैक्रो बोर्ड पर आंदोलन की दिशा पारित किया जाता है। यदि आप बोर्ड पर नए टुकड़े स्थापित करने की संभावना पर विचार नहीं करते हैं, तो एक चाल की पीढ़ी सरल दिखती है। बोर्ड पर प्रत्येक टुकड़े के लिए, नियमों के अनुसार सभी संभव चाल की गणना की जाती है। फिर शुरू होता है जादू ...

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

 (define slide ( $1 (while empty? add $1 ) (verify not-friend?) add )) 

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

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

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

 (define slide ( (verify friend?) $1 (while empty? add $1 ) (verify not-friend?) add )) 

महत्वपूर्ण कई "आंशिक" चालों से मिलकर एक चाल प्रदर्शन करने की क्षमता है। ड्राफ्ट के कार्यान्वयन में, इस क्षमता का उपयोग "चेन" कैप्चर करने के लिए किया जाता है:

 (define checker-jump ($1 (verify enemy?) capture $1 (verify empty?) (if (not-in-zone? promotion-zone) (add-partial jumptype) else (add-partial King jumptype) ) ) ) 

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


नियमों के विवरण की ऐसी प्रणाली बहुत लचीली है, लेकिन कभी-कभी अधिक जटिल तर्क की आवश्यकता होती है। उदाहरण के लिए, यदि टुकड़ा, "आंशिक" प्रगति के दौरान पहले से ट्रैवर्स किए गए फ़ील्ड के माध्यम से फिर से पास नहीं होना चाहिए, तो बोर्ड पर पदों से जुड़े झंडे का उपयोग करना तर्कसंगत है। एक स्थान का दौरा करने के बाद, हमने एक ध्वज निर्धारित किया है, इसलिए बाद में इस स्थान पर दोबारा नहीं जाना चाहिए:

 (verify (not-position-flag? my-flag)) (set-position-flag my-flag true) 

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

ठीक करने के लिए एक और चीज चाल के निष्पादन में एक स्पष्ट "जीवन चक्र" की कमी है। कदम शुरू करने से पहले सभी झंडे स्वचालित रूप से रीसेट हो जाते हैं, लेकिन प्रारंभिक चरण को स्पष्ट रूप से पहचानना आसान होगा। मेरी राय में, इस कदम की गणना में, निम्नलिखित चरण होने चाहिए:

1. चर की शुरुआत और समग्र चाल के लिए पूर्व शर्त की जाँच करना
2. चरों की शुरूआत और आंशिक चाल के लिए पूर्व शर्त की जाँच
3. आंशिक चाल की पीढ़ी
4. आंशिक चाल की जाँच पश्चात
5. कम्पोजिट मूव के पोस्टकंडिशन बनाना, पूरा करना और जांचना
6. खेल की समाप्ति की स्थिति के लिए जाँच करना

पूर्ण समग्र चाल में दूसरे से चौथे चरण के समूह को कई बार दोहराया जा सकता है। पूर्व और बाद की स्थितियों का विचार, जिसे मैं आक्रमणकारी कहता हूं, मैंने प्रोजेक्ट लुडी से लिया। मैं आपको बाद में आक्रमणकारियों के उपयोग के बारे में बताता हूं।

संकेतन के महत्व पर

स्थिति से सभी संभावित चालों का सृजन कहानी का केवल आधा हिस्सा है। खेल राज्य को नियंत्रित करने के लिए उत्पन्न चालों की एक कॉम्पैक्ट प्रस्तुति की आवश्यकता होती है। ZoG में, इस उद्देश्य के लिए, ZSG- नोटेशन का उपयोग किया जाता है। यहाँ इस रूप में शतरंज के खेल की संभावित शुरुआत का विवरण दिया गया है:

 1. Pawn e2 - e4 1. Pawn e7 - e5 2. Knight g1 - f3 2. Knight b8 - c6 3. Bishop f1 - c4 3. Knight g8 - f6 4. King e1 - g1 Rook h1 - f1 @ f1 0 0 @ g1 0 0 4. Pawn d7 - d5 5. Pawn e4 x d5 5. Knight f6 x d5 

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


ZSG- नोटेशन में एक कदम की रिकॉर्डिंग में खेल की स्थिति को सही ढंग से बदलने के लिए पूरी जानकारी पर्याप्त होनी चाहिए। यदि इस तरह के रिकॉर्ड के अनुसार गेम में विशेषताओं के बदलाव के बारे में जानकारी खो जाती है, तो एक चाल गलत तरीके से दोहराई जा सकती है (उदाहरण के लिए, खिलाड़ी को फिर से कास्टिंग करने का अवसर होगा)। दुर्भाग्य से, DLL- एक्सटेंशन (जैसे Axiom) में, विस्तारित जानकारी प्रसारित नहीं की जा सकती है।

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

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

 1. White Stone G19 x A19 x B19 x C19 x D19 x E19 x F19 

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

सौभाग्य से, इन सभी समस्याओं से निपटने का एक सरल तरीका है। आइए देखें कि ZRF में टुकड़ों की चाल को कैसे परिभाषित किया जाए:

 (piece (name Pawn) (image White "images\Chess\SHaag\wpawn.bmp" "images\Chess\wpawn.bmp" Black "images\Chess\SHaag\bpawn.bmp" "images\Chess\bpawn.bmp") (moves (Pawn-capture nw) (Pawn-capture ne) (Pawn-move) (En-Passant e) (En-Passant w) ) ) 

ZoG मैक्रोज़ में परिभाषित चाल के नाम, चाल के एक जनरेटर के रूप में दुर्गम हैं। लेकिन क्या हमें मैक्रोज़ को छोड़ देने और उनके नाम के साथ चालों का वर्णन करने से रोकता है? यहां बताया गया है कि शतरंज खेल के लिए रिकॉर्ड कैसा होगा:

 1. e2 - e4 Pawn-move 1. e7 - e5 Pawn-move 2. g1 - f3 leap2 n nw 2. b8 - c6 leap2 n ne 3. f1 - c4 slide nw 3. g8 - f6 leap2 n nw 4. e1 - g1 OO 4. d7 - d5 Pawn-move 5. e4 x d5 Pawn-capture nw 5. f6 x d5 leap2 w nw 

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

 1. G19 drop-to-empty White Stone 

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

एक और संभावना, जिसे किसी को समर्थन देना चाहिए, "आंशिक" चाल की कार्यक्षमता में प्रकट होता है। यहाँ " रूसी चेकर्स " से एक उदाहरण है:

 1. Checker g3 - f4 1. Checker f6 - g5 2. Checker e3 - d4 2. partial 2 Checker g5 - e3 = XChecker on f4 2. Checker e3 - c5 = XChecker on d4 x d4 x f4 

यहां अश्वेत अपनी दूसरी चाल पर, d4 और f4 पर दो टुकड़े लेते हैं। XChecker के लिए इन टुकड़ों का एक प्रारंभिक "परिवर्तन" इस कार्यान्वयन की एक विशेषता है और एक ही चाल पर "पराजित" टुकड़ों को फिर से लेने से रोकने के लिए कार्य करता है। वाक्यांश "आंशिक 2" "समग्र" पाठ्यक्रम की शुरुआत का वर्णन करता है, जिसमें दो "आंशिक" चाल शामिल हैं। विवरण का यह रूप असुविधाजनक है, क्योंकि पहली चाल की पीढ़ी के समय, "आंशिक" चाल के अनुक्रम की लंबाई ज्ञात नहीं हो सकती है। यहाँ यह विवरण एक नए प्रारूप में दिखेगा:

 1. g3 - f4 checker-shift nw 1. f6 - g5 checker-shift ne 2. e3 - d4 checker-shift nw 2. + g5 - e3 checker-jump nw 2. + e3 - c5 checker-jump sw 2. + 

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

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

खेल का जीवन चक्र

बोर्ड पर टुकड़े रखने के बारे में जानकारी के अलावा, मोड़ों का क्रम खेल राज्य का एक अनिवार्य हिस्सा है, खेल प्रक्रिया में एक चर है। इस जानकारी को संग्रहीत करने के लिए सबसे सरल (और सबसे आम) मामले में, एक बिट पर्याप्त होगा, लेकिन ZoG अधिक जटिल मामलों को लागू करने के लिए कुछ और अवसर प्रदान करता है। यहाँ कैसे चाल के एक अनुक्रम का वर्णन खेल स्प्लिट के लिए देख सकता है ! :

 (players South West North East) (turn-order South West West repeat North North North East East East South South South West West West ) 

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


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

 (players White Black) (turn-order (White normal-move) (White capture-move) (Black normal-move) (Black capture-move) ) 

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

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


" बाओ स्वाहिली " एक जटिल जीवन चक्र के साथ एक खेल का एक अच्छा उदाहरण है। इस खेल में, दो चरणों में निष्पादन के लिए नियम हैं जो काफी भिन्न हैं। खेल की शुरुआत में, पत्थरों का हिस्सा "हाथ में है। प्रत्येक खिलाड़ी का "। हालांकि अभी भी पत्थर" हाथ में हैं, पत्थर को कुओं में डाल दिया जाता है, एक समय में एक पत्थर। जब पत्थर "हाथ में" बाहर निकलते हैं, तो खेल का दूसरा चरण सम्मिलित वितरण के साथ शुरू होता है पत्थर। कोई यह नहीं कह सकता है कि इस गेम का वर्णन ZRF (ZoG की विवरण भाषा) में नहीं किया जा सकता है, लेकिन ZoG की सीमाओं के कारण, यह कार्यान्वयन बेहद भ्रामक होगा (जो निश्चित रूप से AI कार्य की गुणवत्ता के लिए सर्वोत्तम नहीं है)। आइए देखें कि "आदर्श दुनिया" में इस तरह के खेल का वर्णन कैसा होगा:

 (players South North) (turn-order (turn-order (South pi-move) (North pi-move) ) (label phase-ii) (turn-order (South p-ii-move) (North p-ii-move) ) ) 

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

 (players South North) (turn-order (turn-order (South pi-move) (North pi-move) ) (turn-order (labels - phase-ii) (South p-ii-move) (labels phase-ii -) (North p-ii-move) ) ) 

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


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

 (players South North) (turn-order (label repeat) South (label repeat) North ) 

लेबल रिपीट में कूदने वाला खेल, खिलाड़ी फिर से अपनी बारी खेलेगा (घुमावों की सूची में वर्तमान स्थिति के निकटतम लेबल प्रभावी होगा)। मुझे इसकी अंतर्निहित परिभाषाओं में पर्ल का दृष्टिकोण पसंद है। नियंत्रण संरचनाओं की निहित पीढ़ी खेल के विवरण को सरल बना सकती है। बार-बार चाल के रूप में Inasmuch का उपयोग कई खेलों में किया जा सकता है, लेबल दोहराते हैं, किसी भी मोड़ की संभावित पुनरावृत्ति का अनुमान लगा सकते हैं:

 (players South North) (turn-order South North ) 

इसके अलावा, चूंकि घुमावों का क्रम खिलाड़ियों के निर्माण में खिलाड़ियों के लिखित आदेश के साथ पूरी तरह से सुसंगत है, आप स्वचालित रूप से पूरे टर्न-ऑर्डर उत्पन्न कर सकते हैं:

 (players South North) 

विवरण लिखना जितना आसान है, उतना ही अच्छा है।

टूटने वाला अदृश्य

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


सामान्य शोगी से , यह खेल केवल खिलाड़ियों की संख्या में भिन्न होता है। दुर्भाग्य से, यह अंतर चेकमेट (और इस "जादू" शब्द से जुड़ी सभी चीज़ों) को निर्धारित करने के काम को गलत बनाने के लिए पर्याप्त है। जाँच में जा रहा है केवल एक खिलाड़ी के संबंध में किया जाता है। नतीजतन, राजा पर हमला हो सकता है और खाया जा सकता है [विरोधियों के संयोजन से "चेक" में नहीं रहने पर भी बदल जाता है]! यह इष्टतम नहीं है जो एआई के काम में परिलक्षित होगा।

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


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

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


जाहिर है, किसी को राजा के चेक में गिरने से गेम के सत्यापन के तर्क को जांच में अलग करना होगा, जो कि एक अचूक नियम है जिसे प्रत्येक मोड़ के बाद जांचा जाता है। नियम का उल्लंघन चाल को निष्पादित करना असंभव बनाता है (चाल को उपलब्ध चाल की सूची से हटा दिया जाता है)। एक राजा के लिए जाँच में (सरलीकृत) परीक्षण "Tamerlane शतरंज" के लिए इस तरह लग सकता है:

 (verify (or (> (count (pieces my? (is-piece? King))) 1) (= (count (pieces my? (is-piece? King) is-attacked?)) 0) ) ) 

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

 (loss-condition (and (= (count moves) 0) (= (count (pieces my? (is-piece? King)) 1) (> (count (pieces my? (is-piece? King) is-attacked?)) 0) ) ) 

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


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

 (option "maximal captures" true) 

यह सेटिंग " अंतर्राष्ट्रीय चेकर्स " के लिए उपयुक्त है, लेकिन " इतालवी चेकर्स " में बहुमत नियम अलग तरीके से तैयार किया गया है। खेल के इस संस्करण में, यदि समान संख्या में कैप्चर के लिए कई विकल्प हैं, तो आपको एक विकल्प चुनना होगा जो बड़ी संख्या में रूपांतरित चेकर्स (राजाओं) को पकड़ता है। ZoG के डेवलपर्स ने इसे प्रदान किया है। आप निम्न सेटिंग दर्ज करें:

 (option "maximal captures" 2) 

इस सेटिंग में, न केवल पकड़े गए टुकड़ों की संख्या, बल्कि उनके प्रकार भी गिना जाता है। दुर्भाग्य से, सब कुछ पूर्वाभास नहीं हो सकता है। यहां बताया गया है कि "पुराने फ्रांसीसी चेकर्स" में "बहुमत नियम" किस प्रकार तैयार किया गया है:

यदि कैद की एक श्रृंखला द्वारा एक साधारण आदमी के साथ या एक राजा के साथ समान चेकर्स को पकड़ना संभव है, तो खिलाड़ी को राजा का उपयोग करना चाहिए। हालाँकि, अगर दोनों मामलों में चेकर्स की संख्या समान है, लेकिन एक में एक दुश्मन राजा है (या अधिक हैं), खिलाड़ी को इस विकल्प को चुनना होगा, भले ही कैप्चरिंग फिर साधारण चेकर का उपयोग करके की गई हो, और नहीं राजा का उपयोग करना।

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

 (verify (>= capturing-count max-capturing-count) ) (if (> capturing-count max-capturing-count) (let max-capturing-count capturing-count) (let max-capturing-sum capturing-sum) (let max-attacking-value attacking-value) ) (verify (>= capturing-sum max-capturing-sum) ) (if (> capturing-sum max-capturing-sum) (let max-capturing-sum capturing-sum) (let max-attacking-value attacking-value) ) (verify (>= attacking-value max-attacking-value) ) (let max-attacking-value attacking-value) 

यहाँ, हम मानते हैं कि कैप्चर जेनरेशन के नियम सही तरह से [निम्नलिखित] स्थानीय चर भरते हैं:

• कैप्चर-काउंटिंग - कुल टुकड़ों पर कब्जा
• कब्जा-राशि - पकड़े गए राजाओं की संख्या
• हमलावर मूल्य - टुकड़ा कैप्चरिंग का मूल्य

इनमें से प्रत्येक चर के साथ संबद्ध एक मूल्य-संचायक है, जो उपसर्ग अधिकतम के साथ एक चर में संग्रहीत है। तीन चेक को सिलसिलेवार तरीके से अंजाम दिया जाता है। किसी भी सत्यापित स्थिति का उल्लंघन तुरंत अगले मोड़ विकल्प की पीढ़ी को बाधित करता है (कब्जा संभव मोड़ की सूची में संग्रहीत नहीं है)। चूँकि किए गए चेक चर मानों से जुड़े हैं, इसलिए यह पर्याप्त नहीं है [केवल वर्तमान नए कैप्चर विकल्प का परीक्षण करने के लिए]। प्रत्येक परीक्षण उत्पन्न कैप्चर [जो संचित अधिकतम मूल्य को संशोधित कर सकता है] से संबंधित एक "बेंडेबल नियम" उत्पन्न करता है। किसी भी संचायक में प्रत्येक परिवर्तन के बाद, सभी संबंधित नियमों को फिर से [सूची में हर विकल्प के लिए] जाँच की जानी चाहिए। यदि पहले से तैयार विकल्प के लिए किसी भी स्थिति का उल्लंघन किया जाता है, तो उस विकल्प को संभव मोड़ विकल्पों की सूची से हटा दिया जाना चाहिए।

निष्कर्ष

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