विंडोज 8 के लिए गेम के क्लाइंट भाग का विकास

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

प्रारंभ में, चार लोग थे, एक सर्वर भाग, कुछ नकदी और एक सार योजना को ध्यान में रखते हुए। विंडोज 8 प्लेटफॉर्म पर हममें से किसी को भी कोई विकास का अनुभव नहीं था, इसलिए हमने जल्दी से इस विषय पर साहित्य पढ़ा: विंडोज 8, सी #, .नेट। दो दिन बाद, हम विकास शुरू करने के लिए तैयार थे, मेट्रो अनुप्रयोगों की संरचना के बारे में पर्याप्त जानकारी प्राप्त करने के बाद, .NET प्रभावित के साथ सामान्य अनुभव। फिर दोनों ने मंच के साथ प्रोटोटाइप और प्रयोगों में संलग्न होना शुरू कर दिया, जिसने भविष्य में जल्द से जल्द सही जवाब दिए। समानांतर में, पहला काम अनुसूची तैयार किया गया था, और अंतिम व्यक्ति लगातार एक डिजाइनर की तलाश में था जो हमारे साथ काम कर सकता है। यह लगभग 13-15 दिनों तक चला, इस दौरान खेल के हिस्सों के मसौदा रेखाचित्रों का संयुक्त रूप से मूल्यांकन किया गया था, उन्होंने हमारी राय में प्रत्येक स्केच के लिए पर्याप्त रूप से भुगतान करने का प्रयास किया। डिजाइनर ने खुद को चुना कि वह क्या और कितने समय तक हमें पेश कर सकता है, इसके लिए उसके पास एक गेम था जो HTML और JS को उसके आधार के रूप में इस्तेमाल करता था। स्केच की लागत 1000 से 2000 रूबल तक थी, कुल 4 स्केच पर विचार किया गया था। नतीजतन, हमने एक लेआउट चुना, सब कुछ बनाने के लिए 2 महीने का समय मिला और पूरे डिजाइन के लिए लगभग 40,000 रूबल की लागत। यह ध्यान दिया जाना चाहिए कि 100,000 रूबल से कीमतों वाले आवेदक थे, जो हमें सूट नहीं करता था। इसके अलावा, संकलित टीके के अनुसार, डिजाइनर ने तत्वों को भेजा, और हमने तय किया कि वे फिट हैं या नहीं। प्रत्येक तत्व को टुकड़ों में काट दिया गया था और डेवलपर्स द्वारा XAML मार्कअप में समायोजित किया गया था, डिजाइनर ने ब्लेंड को छूने के बिना केवल एक ग्राफिकल संपादक का उपयोग किया था।



सर्वर भाग में WCHttpBinding बाइंडिंग का उपयोग करते हुए WCF सेवाओं का एक सेट होता है। Windows 2008 R2 के वातावरण में Windows सेवा के आधार पर सेवाएँ तैनात की जाती हैं। चूंकि क्लाइंट पहले HTML में उपयोग किया गया था, इसलिए प्रमाणीकरण और प्राधिकरण के साथ सभी मुद्दों को MVC .NET अनुप्रयोग द्वारा हल किया गया था, और सेवा ने इसे विश्वसनीय माना। यहां, इस दृष्टिकोण का उपयोग अनावश्यक और जटिल था, क्योंकि मेट्रो एप्लिकेशन सीधे डब्ल्यूसीएफ सेवाओं के साथ बातचीत कर सकते हैं, हालांकि उन्हें प्रमाण पत्र और बेसिकहेटबाइंडिंग के उपयोग की आवश्यकता होती है। परीक्षण प्रमाणपत्र सफलतापूर्वक डेवलपर्स की मशीनों पर स्थापित किया गया था और डब्ल्यूसीएफ द्वारा उपयोग किए जाने वाले पोर्ट से जुड़ा हुआ था, साथ ही प्रकाशन के लिए एक वास्तविक प्रमाण पत्र प्राप्त हुआ था। डेवलपर्स के लिए निम्नलिखित निर्देश निकला:

• प्रमाण पत्र प्राप्त करें और इसे आयात करें;
• Cmd चलाएं और असाइन किए गए प्रमाणपत्रों के साथ बंदरगाहों को देखें: netsh http शो sslcert, जांचें कि प्रमाणपत्र सही पते पर निर्दिष्ट नहीं है, हमें 8734 पोर्ट की आवश्यकता है रिकॉर्ड: 0.0.0.0:8734;
• पहले चरण में आयात किए गए प्रमाण पत्र के मापदंडों के साथ एक प्रविष्टि जोड़ें: netsh http sslcert i900 = 0.0.0.0: 8734 प्रमाण पत्र = प्रमाण पत्र प्रमाणपत्र मूल्य appid = {GUID} जोड़ें। टैग हैश मान "रचना" टैब पर प्रमाण पत्र के "फ़िंगरप्रिंट" फ़ील्ड से लिया गया है, बिना रिक्त स्थान के दर्ज किया गया है। अगला, आपको दूसरे पैराग्राफ को दोहराकर रिकॉर्ड की उपलब्धता की जांच करने की आवश्यकता है।

प्रमाणीकरण समस्या को UserNamePasswordValidator से वारिस को कार्यान्वित करके और Windows Live ID का उपयोग करके हल किया गया था। परिणामी सत्यापनकर्ता app.config सेवाओं में जोड़ा गया था।

<behaviors> <serviceBehaviors> <behavior name="Security"> <serviceCredentials> <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="Thisislogic.XGame.Service.Common.SecurityManager, Thisislogic.XGame.Service.Common" /> </serviceCredentials> </behavior> </serviceBehaviors> </behaviors> 

सत्यापनकर्ता लाइव आईडी सेवा की गुप्त कुंजी का उपयोग करके समझता है, उपयोगकर्ता पहचानकर्ता और यह निष्कर्ष देता है कि सेवा की अनुमति है या नहीं।

 public class SecurityValidator : UserNamePasswordValidator { private const string LiveSecretClientKey = "My_Secret_Key"; public override void Validate(string userName, string password) { try { if (string.IsNullOrEmpty(userName) || string.IsNullOrEmpty(password)) { throw new Exception("User or Password not set"); } var d = new Dictionary<int, string>(); d.Add(0, LiveSecretClientKey); var jwt = new JsonWebToken(password, d); var jwtUserName = jwt.Claims.UserId; if (jwtUserName != userName) { throw new Exception("Manipulated Username"); } } catch (Exception e) { var fe = new FaultException("Unknown Username or Incorrect Password \n" + e.ToString()); throw fe; } } } 

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

 private string GetHardwareId() { var token = HardwareIdentification.GetPackageSpecificToken(null); var hardwareId = token.Id; var dataReader = DataReader.FromBuffer(hardwareId); var bytes = new byte[hardwareId.Length]; dataReader.ReadBytes(bytes); return BitConverter.ToString(bytes); } 

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


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

 [MagicAttribute] public abstract class PropertyChangedBase : INotifyPropertyChanged { protected virtual void RaisePropertyChanged(string propName) { var e = PropertyChanged; if (e != null) { SmartDispatcher.BeginInvoke(() => e(this, new PropertyChangedEventArgs(propName))); } } [MethodImpl(MethodImplOptions.NoInlining)] protected static void Raise() { } public event PropertyChangedEventHandler PropertyChanged; } 

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

परिणामस्वरूप, परिणामों की एक सारांश तालिका:

गतिविधि	समय	पैसा
ट्रेनिंग	7 दिन	10000
परिसर और तकनीकी लागतों का किराया	3 महीने	35000
डिज़ाइन	3 महीने	40000
प्रारंभिक रेखाचित्र	15 दिन	6500
वेतन	2 महीने	50000
कुल मिलाकर		141,500

कुल खर्च लगभग 141,500 रूबल और 3 महीने का काम है।