डार्क साइड ZRF

जो लोग मेरे लेखों की श्रृंखलाओं को खेल की श्रृंखला पर पढ़ते हैं, उन्हें यह आभास हो सकता है कि मैं इस उत्पाद से पूरी तरह संतुष्ट हूं। बेशक, ऐसा नहीं है। ZoG इस मायने में अनूठा है कि यह आपको लगभग किसी भी तार्किक खेल का एक प्रोटोटाइप विकसित करने के लिए "घुटने पर" जल्दी और व्यावहारिक रूप से अनुमति देता है, लेकिन इसका मतलब यह नहीं है कि यह एकदम सही है। आज, मैं इस बारे में बात करना चाहता हूं कि मुझे इस परियोजना के बारे में क्या पसंद नहीं है।

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



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



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



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



बहुत सरल:



(loss-condition (White Black) (checkmated King))
      
      





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



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



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



इस तर्क को फिर से कर्नेल में वायर्ड किया गया है:



 (option "maximal captures" true)
      
      





इस विकल्प के अलावा, AI ZoG द्वारा उपयोग किए जाने वाले कई अन्य विकल्प हैं:





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



 (option "maximal captures" 2)
      
      





... "अधिकतम कैप्चर" मोड को खाता में ले जाता है।



उपलब्ध कराए गए विकल्पों की सूची में कोई प्रणाली नहीं है। इसके अलावा, एक ही सूची में ऐसे विकल्प हैं जिनका एआई से कोई संबंध नहीं है, उदाहरण के लिए, " चेतन कैप्चर ", " हाइलाइट गोल्स ", " शो मूव्स लिस्ट " ... ... इस तंत्र को शायद ही सार्वभौमिक कहा जा सकता है।



एक व्यवस्थित दृष्टिकोण का एक समान अभाव पूरे ZRF "लाल धागे" से चलता है। उदाहरण के लिए, "पंक्ति में 3" प्रकार के पदों को निर्धारित करने के लिए एक सुविधाजनक सापेक्ष-विन्यास कमांड है। यहां बताया गया है कि इसका उपयोग टिक-टैक-टो में कैसे किया जाता है:



 (win-condition (XO) (or (relative-config man n man n man) (relative-config man e man e man) (relative-config man ne man ne man) (relative-config man nw man nw man) )
      
      





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



तीन-कहानी की जांच
 (define Check-for-3 (set-flag first? false) (set-flag second? false) (set-flag third? false) (set-flag fourth? false) a1 (while (and (on-board? next)(not-flag? fourth?)) (if friend? (if (not-flag? first?) (set-flag first? true) else (if (not-flag? second?) (set-flag second? true) else (if (not-flag? third?) (set-flag third? true) else (set-flag fourth? true) ) ) ) ) next ) (verify (not-flag? fourth?)) (if (am-Black?) (change-type Jumping z0) ;set permanent flag else (change-type Jumping z1) ;set permanent flag ) )
      
      







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



एक और अत्यंत उपयोगी विशेषता नेस्टिंग के स्तर को सीमित किए बिना मार्क / बैक कमांड का कार्यान्वयन होगा। मार्क कमांड चाल की गणना करने की प्रक्रिया में वर्तमान स्थिति को याद करता है, और वापस आपको इसे वापस करने की अनुमति देता है। ऐसा लगता है कि पदों को बनाए रखने के लिए स्टैक का उपयोग करने से अधिक प्राकृतिक क्या हो सकता है? लेकिन नहीं, मार्क नेस्टेड कॉल समर्थित नहीं हैं! यह एक दया होगी कि यह सुविधाजनक होगा ...



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



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



और यह ऐड कमांड की एकमात्र (और सबसे महत्वपूर्ण भी नहीं) समस्या नहीं है! ZRF में, पारिवारिक आदेशों को जोड़ने पर दो कार्य होते हैं:



  1. उस क्षेत्र का संकेत, जिस पर उस टुकड़े ने चाल प्रदर्शन किया है
  2. पाठ्यक्रम के एक प्रकार (या भाग) के गठन का समापन


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



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



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



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





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



मानक ZoG में ऐसी कोई विशेषताएं नहीं हैं, लेकिन उन्हें Axiom डेवलपमेंट किट में लागू किया गया है। यह अधिक विस्तार से बताने योग्य है। तथ्य यह है कि ZoG आपको उन एक्सटेंशनों का उपयोग करने की अनुमति देता है जिन्हें विकसित किया जा सकता है, उदाहरण के लिए, C ++ का उपयोग करके। ऐसे एक्सटेंशन का उपयोग करने का शुल्क बिल्ट-इन AI ZoG के उपयोग की पूर्ण अस्वीकृति है। वास्तव में, एक्सटेंशन ZoG का उपयोग केवल दृश्य चाल के साधन के रूप में करता है। इस तरह के विस्तार को विकसित करते समय, आपको स्वयं एआई का ध्यान रखना होगा।



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



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



Engine.h
 // Engine.h // // Copyright 1998-2000 Zillions Development // // Header file for plug-in DLL engine to Zillions #include "EngineDLL.h" DLL_Result FAR PASCAL DLL_Search(long lSearchTime, long lDepthLimit, long lVariety, Search_Status *pSearchStatus, LPSTR bestMove, LPSTR currentMove, long *plNodes, long *plScore, long *plDepth); DLL_Result FAR PASCAL DLL_MakeAMove(LPCSTR move); DLL_Result FAR PASCAL DLL_StartNewGame(LPCSTR variant); DLL_Result FAR PASCAL DLL_CleanUp(); DLL_Result FAR PASCAL DLL_IsGameOver(long *lResult, LPSTR zcomment); DLL_Result FAR PASCAL DLL_GenerateMoves(LPCSTR moveBuffer);
      
      







EngineDLL.h
 // EngineDLL.h // // Copyright 1998-2000 Zillions Development // // Shared DLL plug-in for DLL engine and Zillions #include "windows.h" typedef enum { kKEEPSEARCHING = 0, kSTOPSOON = 1, kSTOPNOW = 2 } Search_Status; typedef enum { DLL_OK = 0, DLL_OK_DONT_SEND_SETUP = 1, // only supported in 1.0.2 and higher! DLL_GENERIC_ERROR = -1, DLL_OUT_OF_MEMORY_ERROR = -2, DLL_UNKNOWN_VARIANT_ERROR = -3, DLL_UNKNOWN_PLAYER_ERROR = -4, DLL_UNKNOWN_PIECE_ERROR = -5, DLL_WRONG_SIDE_TO_MOVE_ERROR = -6, DLL_INVALID_POSITION_ERROR = -7, DLL_NO_MOVES = -8 } DLL_Result; enum { UNKNOWN_SCORE = -2140000000L, LOSS_SCORE = -2130000000L, DRAW_SCORE = 0, WIN_SCORE = 2130000000L }; // ***** REQUIRED ROUTINES // DLL_Search // // The DLL should search from the current position. If it returns DLL_OK it should // also return the best move found in str; however, it should not make the move // internally. A separate call to MakeAMove() will follow to make the move the // engine returns. // // -> lSearchTime: Target search time in milliseconds // -> lDepthLimit: Maximum moves deep the engine should search // -> lVariety: Variety setting for engine. 0 = no variety, 10 = most variety // -> pSearchStatus: Pointer to variable where Zillions will report search status // -> bestMove: Pointer to a string where engine can report the best move found so far // -> currentMove: Pointer to a string where engine can report the move being searched // -> plNodes: Pointer to a long where engine can report # of positions searched so far // -> plScore: Pointer to a long where engine can report current best score in search // -> plDepth: Pointer to a long where engine can report current search depth // // Returns DLL_OK or a negative error code typedef DLL_Result (FAR PASCAL *SEARCH)(long lSearchTime, long lDepthLimit, long lVariety, const Search_Status *pSearchStatus, LPSTR bestMove, LPSTR currentMove, long *plNodes, long *plScore, long *plDepth); // DLL_MakeAMove // // The DLL should try to make the given move internally. // // -> move: notation for the move that the engine should make // // Returns DLL_OK or a negative error code typedef DLL_Result (FAR PASCAL *MAKEAMOVE)(LPCSTR move); // DLL_StartNewGame // // The DLL should reset the board for a new game. // // -> variant: The variant to be played as it appears in the variant menu // // Returns DLL_OK, DLL_OK_DONT_SEND_SETUP, DLL_OUT_OF_MEMORY_ERROR, or // DLL_GENERIC_ERROR typedef DLL_Result (FAR PASCAL *STARTNEWGAME)(LPCSTR variant); // DLL_CleanUp // // The DLL should free memory and prepare to be unloaded. // // Returns DLL_OK, DLL_OUT_OF_MEMORY_ERROR, or DLL_GENERIC_ERROR typedef DLL_Result (FAR PASCAL *CLEANUP)(void); // ***** OPTIONAL ROUTINES // DLL_IsGameOver // // This optional function is called by Zillions to see if a game is over. If // not present, Zillions uses the goal in the ZRF to decide the winner. // // -> lResult: Pointer to the game result which the DLL should fill in when // called. If the game is over the routine should fill in WIN_SCORE, // DRAW_SCORE, or LOSS_SCORE. Otherwise the routine should fill in // UNKNOWN_SCORE. // -> zcomment: Pointer to a 500-char string in Zillions which the DLL can optionally // fill in, to make an announcement about why the game is over, such // as "Draw by third repetition". The DLL should not modify this // string if there is nothing to report. // // Returns DLL_OK or a negative error code typedef DLL_Result (FAR PASCAL *ISGAMEOVER)(long *lResult, LPSTR zcomment); // DLL_GenerateMoves // // You can use GenerateMoves in your DLL to tell Zillions the legal moves for // any position in the game. // // -> moveBuffer: Pointer to a 1024-char sting which the DLL should fill in when // called. Initial call should be with moveBuffer set to "". Each call // to GenerateMoves should fill in the next available move from the // current position, with a final "" when no more moves are available. // All moves must be in valid Zillions move string format. // // Returns DLL_OK or a negative error code typedef DLL_Result (FAR PASCAL *GENERATEMOVES)(LPCSTR moveBuffer);
      
      







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



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



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



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



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



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




All Articles