एक मोबाइल गेम के लिए वास्तु समाधान। भाग 2: कमान और उनकी कतारें

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

एक मोबाइल गेम के लिए वास्तु समाधान। भाग 1: मॉडल
एक मोबाइल गेम के लिए वास्तु समाधान। भाग 3: जेट जोर पर देखें

क्यों कमान?

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

परिणाम की भविष्यवाणी और नेटवर्क पर आदेशों का सत्यापन

इस मामले में, विशिष्ट कोड विचार से कम महत्वपूर्ण नहीं है। और यहाँ का विचार है:

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

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

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

पहला लाभ:

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

एक नुकसान जो किसी कारण से व्यवस्थित रूप से कम करके आंका गया है:

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

विस्तृत डिबगिंग जानकारी

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

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

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

लिखने की आज्ञा की सुविधा और सहजता

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

namespace HexKingdoms { public class FCSetSideCostCommand : HexKingdomsCommand { //              protected override bool DetaliedLog { get { return true; } } public FCMatchModel match; public int newCost; protected override void HexApply(HexKingdomsRoot root) { match.sideCost = newCost; match.CalculateAssignments(); match.CalculateNextUnassignedPlayer(); } } } 

और यहां लॉग है कि यह कमांड खुद के बाद छोड़ देता है, अगर यह लॉग इसके लिए अक्षम नहीं है।

 [FCSetSideCostCommand id=1 match=FCMatchModel[0] newCost=260] Execute:00:00:00.0027546 Apply:00:00:00.0008689 { "LOCAL_PERSISTENTS":{ "@changed":{ "0":{"SIDE_COST":260}, "1":{"POSSIBLE_COST":260}, "2":{"POSSIBLE_COST":260}}}} 

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

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

अब एक बड़ी टीम का एक उदाहरण देखते हैं

 namespace HexKingdoms { public class FCSetUnitForPlayerCommand : HexKingdomsCommand { //            protected override bool DetaliedLog { get { return true; } } public FCSelectArmyScreenModel screen; public string unit; public int count; protected override void HexApply(HexKingdomsRoot root) { if (count == 0 && screen.player.units.ContainsKey(unit)) { screen.player.units.Remove(unit); screen.selectedUnits.Remove(unit); } else if (count != 0) { if (screen.player.units.ContainsKey(unit)) { screen.player.units[unit] = count; screen.selectedUnits[unit].count = count; } else { screen.player.units.Add(unit, count); screen.selectedUnits[unit] = new ReferenceUnitModel() { type = unit, count = count }; } } screen.SetSelectedReferenceUnits(); screen.player.CalculateUnitsCost(); var side = screen.match.sides[screen.side]; screen.match.CalculatePlayerAssignmentsAcceptablity(side); screen.match.CalculateNextUnassignedPlayer(screen.player); } } } 

और यहां टीम द्वारा लॉग छोड़ा गया है:

 [FCSetUnitForPlayerCommand id=3 screen=/UI_SCREENS[main] unit=militia count=1] Execute:00:00:00.0065625 Apply:00:00:00.0004573 { "LOCAL_PERSISTENTS":{ "@changed":{ "2":{ "UNITS":{ "@set":{"militia":1}}, "ASSIGNED":7}}}, "UI_SCREENS":{ "@changed":{ "main":{ "SELECTED_UNITS":{ "@set":{ "militia":{"@new":null, "TYPE":"militia", "REMARK":null, "COUNT":1, "SELECTED":false, "DISABLED":false, "HIGHLIGHT_GREEN":false, "HIGHLIGHT_RED":false, "BUTTON_ENABLED":false}}}}}}} 

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

इंटरफ़ेस के लिए सूचना मॉडल।

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

इस सामान्य दृष्टिकोण के बजाय, हम मॉडल को छोड़कर किसी को भी मना करते हैं जिसमें इंटरफ़ेस की स्थिति के बारे में जानकारी होती है। यह हमेशा की तरह, फायदे और नुकसान हैं, जिनसे जूझना पड़ता है।

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

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

 public EDictionary<string, UIStateModel> uiScreens { get { return UI_SCREENS.Get(this); } } public static PDictionaryModel<string, UIStateModel> UI_SCREENS = new PDictionaryModel<string, UIStateModel>() { notServerVerified = true }; 

मॉडल का यह हिस्सा और इसके नीचे का सब कुछ ग्राहक के लिए विशेष रूप से संबंधित होगा।

यदि आपको अभी भी याद है, तो आपको क्या निर्यात करने की आवश्यकता है और इस तरह क्या नहीं दिखता है:

 [Flags] public enum ExportMode { all = 0x0, changes = 0x1, serverVerified = 0x2 } 

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

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

 public partial class Command { /** <summary>    ,      </summary> */ public virtual void Apply(ModelRoot root) {} /** <summary>         </summary> */ public virtual void ApplyClientSide(ModelRoot root) {} } 

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

पहला तरीका

हम अपने मॉडल की शांत विशेषताओं का उपयोग करते हैं:

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

यह निश्चित रूप से डरावना लग रहा है, लेकिन वास्तव में यह 7 लाइनें है, क्योंकि ऐसा करने वाले कार्य सभी हैं (दूसरे पैराग्राफ से पेड़ को हटाने के अलावा) हम तैयार हैं। और चूंकि यह स्वागत है, इसलिए हम खुद को आशावादी नहीं होने दे सकते हैं।

दूसरा तरीका

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

 public class GameState : Model { public RootModelData data; public RootModelLocal local; } public class RootModel { public bool locked { get; } } 

फिर यह पता चलता है कि प्रत्येक उपप्रकार का अपना ताला है। गेमस्टेट को मॉडल विरासत में मिला है, क्योंकि इसके लिए सभी समान कार्यक्षमता के एक अलग कार्यान्वयन के साथ आना आसान है।

आवश्यक सुधार

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

कार्यान्वयन में मौलिक रूप से कुछ भी जटिल नहीं है। यह सिर्फ इतना है कि मॉडल के प्रत्येक क्षेत्र की संपत्ति में एक और शर्त है, एक पेड़ का चक्कर।

एक और आवश्यक शोधन - आपको पेड़ की जाँच की गई और पेड़ के कुछ हिस्सों की जाँच नहीं करनी होगी और उनके लिए NextFreeId अलग-अलग होगा।

सर्वर द्वारा शुरू की गई कमांड

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

निष्पादित करने की आज्ञा देता है जिसे आपको सर्वर प्रतिक्रिया जानने की आवश्यकता होती है

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

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

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

सर्वर डेटा भंडारण और सर्वर अनुकूलन का मैला विषय

मैं तुरंत स्वीकार करता हूं कि मैं एक ग्राहक हूं, और कभी-कभी मैंने परिचित सर्वर सेवकों से ऐसे विचार और एल्गोरिदम सुने हैं कि वे मेरे दिमाग में भी नहीं आए। अपने सहकर्मियों के साथ संवाद करने से, मैंने किसी तरह एक चित्र विकसित किया कि आदर्श स्थिति में सर्वर आर्किटेक्चर पर कैसे काम करना चाहिए। हालांकि: इसमें मतभेद हैं, विशेषज्ञ सर्वर से परामर्श करना आवश्यक है।

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

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

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

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

टीमों को सर्वर के बीच कैसे विभाजित किया जाता है

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

, : , . . . , . , . — — .

, , - . , . , VR CS, - . , , , 30%.

, — , . , . , , , , , .

, , - , : . , . , 35 . , , . , , , — .
: — 30 . ? №1: . №2: , 3000 .

, — . कुछ इस तरह:

 public interface Command { void Apply(ModelRoot root, long time); } 

, , Unity — . UnixTime , , PTime, PValue<long> , JSON : - . . .

: , , , , . , . , . PTimeOut, . , :

 public class MyModel : Model { public static PTimeOut RESTORE_ENERGY = new PTimeOut() {command = (model, property) => new RestoreEnergyCommand() { model = model}} public long restoreEnergy { get { return RESTORE_ENERGY.Get(this); } set { RESTORE_ENERGY.Set(this, value); }} } 

, . , , . , , , , . , , .

- , . , , , , , . , currentTime, :

 public partial class Model { public void SetCurrentTime(long time); } vs public partial class RootModel { public event Action<long> setCurrentTime; } 

, , , , . , , , - GC.

1, ,

. , - . , , . , , , , callback, . , . , , , , « » , , . , , .

, . , inventory, . , , -, , . , « » , , , . « ». , . , , . :

 public class OpenMisterBox : Command { public BoxItemModel item; public int slot; //        ,  . public override void Apply(GameState state) { state.inventory[item.revardKey] += item.revardCount; } //       . public override void Apply(GameState state) { var cause = state.NewPersistent<WaitForCommand>(); cause.key = item.key; cause.value = item.value; state.ui.delayedInventoryVisualization.Add(cause); state.ui.mysteryBoxScreen.animations.Add(new Animation() {cause = item, slot = slot})); } } public class MysteryBoxView : View { /* ... */ public override void ConnectModel(MysteryBoxScreenModel model, List<Control> c) { model.Get(c, MysteryBoxScreenModel.ANIMATIONS) .Control(c, onAdd = item => animationFactory(item, OnComleteOrAbort => { AsincQueue(new RemoveAnimation() {cause = item.cause, animation = item}) }), onRemove = item => {} ) } } public class InventoryView : View<InventoryItem> { public Text text; public override void ConnectModel(InventoryItem model, List<Control> c) { model.GameState.ui.Get(c, UIModel.DELAYED_INVENTORY_VISUALIZATION). .Where(c, item => item.key == model.key) .Expression(c, onChange = (IList<InventoryItem> list) => { int sum = 0; for (int i = 0; i < list.Count; i++) sum += list[i].value; return sum; }, onAdd = null, onRemove = null ) //      .Join (c, model.GameState.Get(GameState.INVENTORY).ItemByKey(model.key)) .Expression(c, (delay, count) => count - delay) .SetText(c, text); //     ,      ,   ,  ,   ,       ,     : model.inventory.CreateVisibleInventoryItemCount(c, model.key).SetText(c, text); } } public class RemoveDelayedInventoryVisualization : Command { public DelayCauseModel cause; public override void Apply(GameState state) { state.ui.delayedInventoryVisualization.Remove(cause); } } public class RemoveAnimation : RemoveDelayedInventoryVisualization { public Animation animation public override void Apply(GameState state) { base.Apply(state); state.ui.mysteryBoxScreen.animations.Remove(animation); } } 

आखिर में हमारे पास क्या है? View, , , . . GameState , , . , , , .

कुल मिलाकर

- , , , , , , . . , , . , , .
. , , — . .