Goblin Wars II.NET - स्क्रैच से C # में एक नेटवर्क गेम बनाने की कहानी है

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

प्रागितिहास

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


गेमप्ले


वह है

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

क्या आप एक महान जादूगर बन सकते हैं?

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

गोबलिन वार्स II.Net

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

एक नई रोशनी में

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



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

खेल वास्तुकला: सामान्य अवलोकन

मैं सबसे पहले ध्यान देना चाहूंगा - खेल मॉड्यूलर है। बहुत मॉड्यूलर है। इस अर्थ में कि खेल के सभी सबसिस्टम अलग-अलग dll हैं, जिनमें से अधिकांश किसी भी तरह से एक दूसरे से जुड़े हुए नहीं हैं, और जो जुड़े हुए हैं वे केवल इंटरफेस के बारे में जानते हैं। इससे सिस्टम के एक हिस्से को फेंकना और दूसरे को बदलना आसान हो जाता है। UDP नेटवर्क, lindgren नेटवर्क पसंद नहीं है? कृपया एक dll, Network.dll लें, और अपना खुद का लिखें, इंटरफेस के कार्यान्वयन के बारे में नहीं भूलकर, INetworkClient, INetworkServer। उदाहरण के लिए, किसी एकल खिलाड़ी को लागू करने के लिए, तथाकथित शून्य-नेटवर्क को लागू किया गया था, जो क्लाइंट और सर्वर के लिए बिना किसी नेटवर्क के केवल एक कनेक्शन है - इंटरफ़ेस विधियों के लिए एक शुद्ध कॉल। उसी समय, क्लाइंट और सर्वर को परवाह नहीं है कि वे ज़ीरो-नेटवर्क के साथ काम करते हैं या वास्तविक नेटवर्क के साथ।
उदाहरण के लिए, ग्राफिक्स के संबंध में भी यही कहा जा सकता है। आर्किटेक्चर आपको किसी भी चीज़ के साथ OpenGL आउटपुट को बदलने के लिए Graphics.dll को फिर से लिखने की अनुमति देता है - कम से कम WinAPI, कम से कम D3D। इसके अलावा, सिद्धांत में, एक dll की जगह, आप एक आइसोमेट्री के साथ शीर्ष दृश्य को बदल सकते हैं, अगर ऐसी इच्छा उत्पन्न होती है।
नीचे विधानसभा स्तर निर्भरता गार्फ है:


खेल वास्तुकला

GoblinWarsII.exe और Server.exe वास्तव में निष्पादन योग्य फाइलें हैं। उनमें केवल कुछ पंक्तियाँ होती हैं, क्योंकि सभी तर्क dllok में है। उदाहरण के लिए, सभी सर्वर कोड इस तरह दिखता है:

class Program { static void Main(string[] args) { var game = new Game(); var networkServer = new UDPGameServer(game, int.Parse(args[2])); var matchParameters = new MatchParameters {Difficulty = DifficultyLevel.Easy, FragLimit=0, TimeLimit = uint.Parse(args[0]), MapName=args[1]}; game.StartMatch(matchParameters); networkServer.Start(); while (Console.ReadKey().KeyChar != 'q'); game.Halt(); networkServer.Stop(); } } 

Common.dll में एक विशेष टाइमर जैसे सामान्य घोषणाएं और सहायक कक्षाएं शामिल हैं। मूल रूप से, डेटा संरचनाओं का विवरण निहित है, उदाहरण के लिए, सर्वर और क्लाइंट दोनों द्वारा आवश्यक वस्तुओं के प्रकार

 public enum ItemType { PistolBullet, AKBullet, ShotgunBullet, Rocket, Louse, AVOBullet, PhaseBullet, Trapped, StronglyTrapped, WildLouse, LouslyTrapped, PoisonTrapped, FirstAid, MegaHealth, AVOModifier, Boost, LousePack, Equipment, GunabadianHello, LouseHunterEquipment } 

Network.dll, ज़ाहिर है, क्लाइंट और सर्वर को एक साथ जोड़ने वाला नेटवर्क लॉजिक है।
ServerLogic.dll का उपयोग केवल सर्वर द्वारा किया जाता है और इसमें सभी गेम लॉजिक होते हैं, यह वह जगह है जहां गेम ऑब्जेक्ट की सभी गणना होती है।
Media.dll का उपयोग केवल क्लाइंट द्वारा किया जाता है और इसमें क्लाइंट पर सर्वर ऑब्जेक्ट प्रदर्शित करने के लिए तर्क होता है (मैं इस पर बाद में पता लगाऊंगा)।
और अंत में, Graphics.dll में ऑब्जेक्ट्स को सीधे रेंडर करने के लिए कोड होता है।
लगभग हर dllka अपना स्वयं का प्रसंस्करण धागा शुरू करता है और दूसरों को रोकता नहीं है - ServerLogic - खेल तर्क की गणना करने के लिए एक धागा, नेटवर्क - प्राप्त करने और संचारित करने के लिए एक धागा, मीडिया - प्रसंस्करण मीडिया वस्तुओं के लिए एक धागा (क्लाइंट पर सर्वर ऑब्जेक्ट का प्रतिनिधित्व), ग्राफिक्स - एक प्रतिपादन धागा।
चलो एक विशिष्ट कार्यान्वयन के लिए आगे बढ़ते हैं, और हम सर्वर के कार्यान्वयन के साथ शुरू करेंगे।

गेम आर्किटेक्चर: सर्वर

इसलिए, जैसा कि ऊपर दिए गए कोड से पहले ही स्पष्ट था, सर्वर में मुख्य चीज गेम क्लास है, जिसका एक उदाहरण Server.exe बाइनरी में बनाया गया है:

 var game = new Game(); 

अन्य सभी सिस्टम केवल सर्वर लॉजिक इंटरफ़ेस देख सकते हैं, जो कुछ इस तरह दिखता है:


सर्वर आर्किटेक्चर

इस प्रकार, बाहर से आप खेल शुरू कर सकते हैं, खिलाड़ियों को जोड़ सकते हैं या हटा सकते हैं, मैच के बारे में विभिन्न जानकारी प्राप्त कर सकते हैं, और, सबसे महत्वपूर्ण बात, खेल वस्तुओं की सभी स्थिति प्राप्त करें।

 public IList<GameObjectState> GetAllObjectStates() 

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

  public interface IPlayerDescriptor { void PerformAction(PlayerAction action); Tuple<double, double> GetLookCoords(); long GetId(); double GetLoginTime(); } 

नतीजतन, हमें वही मिलता है जो ऊपर वर्णित था - खेल तर्क के साथ एक पूरी तरह से अलग उप-प्रणाली। आइए अब विचार करें कि वास्तव में यह अंदर कैसे काम करता है।
"शीर्ष परत" सुंदर मानक थ्रेड सुरक्षित शब्दकोश <ऑब्जेक्ट आईडी, ऑब्जेक्ट> - दिखता है

 private readonly ConcurrentDictionary<ushort, GameObject> gameObjects; 

और एक प्रसंस्करण चक्र जिसे प्रति सेकंड दी गई संख्या कहा जाता है और पिछले मिसकॉल से बीता समय गिना जाता है:

 private void ObjectProcessingTaskRoutine() { quantTimer.Tick(); Statistics.TimeQuantPassed(quantTimer.QuantValue); if (currentMatchParameters.TimeLimit > 0 && Statistics.MatchTime > currentMatchParameters.TimeLimit) EndMatch(); foreach(var gameObject in gameObjects) { if (!gameObject.Value.Destroyed()) gameObject.Value.Process(quantTimer.QuantValue); else gameContext.RemoveObject(gameObject.Key); } } 

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

 ConcurrentDictionary<ushort, GameObject> gameObjects; 

GameContext के सभी क्षेत्र पठनीय हैं, आसानी से, जो खेल की वस्तुओं के संदर्भ में "क्षति" को समाप्त करता है।

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

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

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

 internal interface IGameObject { void SendMessage(ComponentMessageBase msg); GameObjectState GetState(); IComponent[] GetComponents(); ushort GetId(); GameObjectType GetGOType(); IGameObject GetParent(); void Dispose(); bool Destroyed(); } 

एक गेम ऑब्जेक्ट केवल किसी अन्य ऑब्जेक्ट का ऐसा इंटरफ़ेस प्राप्त कर सकता है, जो दुरुपयोग के खिलाफ अतिरिक्त सुरक्षा देता है - एक तृतीय-पक्ष ऑब्जेक्ट न तो ऑब्जेक्ट में घटकों को जोड़ सकता है और न ही किसी भी तरह से उनके साथ बातचीत कर सकता है, केवल एक या किसी अन्य घटक की उपस्थिति की जांच कर सकता है, जिसके लिए IComentent मौजूद है [ ] गेटकॉमर्स ();

इंटरफ़ेस के कार्यान्वयन, GameObject में संदेश भेजने और प्राप्त करने का तर्क शामिल है (जिसका उपयोग दुनिया का स्नैपशॉट प्राप्त करते समय किया जाता है:

 public void SendMessage(ComponentMessageBase msg) { messageQueue.Enqueue(msg); } public GameObjectState GetState() { var states = new List<ComponentState>(components.Count); lock (lockObj) { if (Destroyed()) return null; foreach (var component in components) { var state = component.GetState(); if (state != null) states.Add(state); } } return new GameObjectState(Id, type, states); } public void Process(double quantValue) { if (Destroyed()) return; lock (lockObj) { SendMessage(new MsgTimeQuantPassed(this, quantValue)); //    ,     while (messageQueue.Count > 0) { ComponentMessageBase msg; messageQueue.TryDequeue(out msg); foreach (var component in components) component.ProcessMessage(msg); } } } 

नेटवर्क अनुरोध के समय ऑब्जेक्ट की स्थिति की अपरिहार्यता की गारंटी देने के लिए एक अवरुद्ध वस्तु आवश्यक है।

संदेश प्रपत्र के CANCARENT कतार में जोड़े जाते हैं
निजी आसानी से समवर्ती क्यू संदेश

सूची

  private readonly List<Component> components; 

बेशक, वस्तु के सभी घटक शामिल हैं।

खेल वास्तुकला: घटक

एक घटक के आधार वर्ग में सबसे पहले, तीन मुख्य कार्य शामिल हैं:

  public abstract void ProcessMessage(ComponentMessageBase msg); public virtual ComponentState GetState() { return null; } public virtual bool Probe() { return true; } 

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

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

 public SolidBody(GameObject owner, GameContext gameContext, double x, double y, double sizeX, double sizeY, byte angle = 0, bool semisolid = false) 

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

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

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

अगला, हम घटक को लागू करते हैं, जो सभी गोलियों, मिसाइलों और अन्य गोले के लिए तर्क का ध्यान केंद्रित है - यह एक सरल, समान, सीधी उड़ान के लिए जिम्मेदार होगा।

 internal class Projectile : Component { private SolidBody solidBody; //  ,    SolidBody! private readonly double speed; //  –   public Projectile(GameObject owner, double speed) : base(owner) { this.speed = speed; } public override void ProcessMessage(ComponentMessageBase msg) { //    –   ,        . if (msg.MessageType == MessageTypes.TimeQuantPassed) ProcessTimeQuantPassed(msg as MsgTimeQuantPassed); } //   .      ,      ,   ,     private void ProcessTimeQuantPassed(MsgTimeQuantPassed msg) { double dT = msg.MillisecondsPassed; var solidState = (SolidBodyState)solidBody.GetState(); byte angle = solidState.Angle; double dX = SpecMath.Cos(angle) * speed * dT, dY = SpecMath.Sin(angle) * speed * dT; // ,        –      ,        .         –     . solidBody.AppendCoords(dX, dY, angle); } //  ,    . GetOwnerComponent,    ,     .    ,   ,      .   . public override bool Probe() { solidBody = GetOwnerComponent<SolidBody>(); return solidBody != null; } } 

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

 internal class DieOnTTL : Component { private readonly double ttl; private double lifetime; public DieOnTTL(GameObject owner, double ttl) : base(owner) { this.ttl = ttl; lifetime = 0.0; } public override void ProcessMessage(ComponentMessageBase msg) { if (msg.MessageType == MessageTypes.TimeQuantPassed) ProcessTimeQuantPassed(msg as MsgTimeQuantPassed); } private void ProcessTimeQuantPassed(MsgTimeQuantPassed msg) { var dT = msg.MillisecondsPassed; lifetime += dT; if (lifetime >= ttl) //     Owner.SendMessage(new MsgDeath(Owner)); } } 

तब क्या, हमारी गोलियां दिखेंगी? बहुत सरल है। यहाँ, उदाहरण के लिए, एक पिस्तौल की गोली:

 class PistolBullet : GameObject { public PistolBullet(GameContext context, IGameObject parent, double x, double y, byte angle, double speed, double ttl) : base(context, GameObjectType.PistolBullet, parent) { AddComponents( new SolidBody(this, context.GameMap, x, y, 9, 9, angle, true), new DieOnTTL(this, ttl), new Projectile(this, speed), new DieOnCollide(this,new GameObjectType[]{GameObjectType.Player, GameObjectType.WildLouse}, true, new ushort[]{parent.GetId()}), new DecayOnDeath(this) ); } } 

जैसा कि मैंने कहा, एक अलग वर्ग केवल इसलिए बनाया गया था क्योंकि हाथ अभी तक बाहर से कॉन्फ़िगरेशन के लोड तक नहीं पहुंचे थे। यह कोड क्या करता है? सबसे पहले, यह गेम प्रकार को आधार से पास करता है GameObject कंस्ट्रक्टर - GameObjectType.PistolBullet
यह इस प्रकार से है कि क्लाइंट पर रेंडरिंग जाएगा, यह वह है जो विभिन्न घटकों द्वारा जांच की जाती है, जो बुलेट और इसी तरह की बातचीत के साथ महत्वपूर्ण टकराव हैं।
जो कुछ बचता है वह उन घटकों को जोड़ना है जो गोली को गोली बना देगा। इस मामले में, मापदंडों को बाहर से ऑब्जेक्ट के कंस्ट्रक्टर में स्थानांतरित किया जाता है, और वहां से कंपोनेंट कंस्ट्रक्टर को भेजा जाता है। लेकिन कोई भी उन्हें कोड में यहां मुश्किल से लिखने के लिए परेशान नहीं करता है, या उन्हें कुछ XML से घटकों की सूची के साथ लोड करता है।
सबसे पहले, सॉलिडबॉडी, चूंकि एक बुलेट पूरी तरह से भौतिक वस्तु है जिसमें दूसरों के साथ समन्वय और टकराव होता है। सेमीसॉलिड पैरामीटर में सही निर्दिष्ट करने के लिए मत भूलना - हमें अतिरिक्त गणनाओं की आवश्यकता नहीं है।
बुलेट को उड़ान के एक निश्चित समय के बाद गायब हो जाना चाहिए, भले ही वे किसी भी चीज से न टकराएं। इसलिए DieOnTTL ऑब्जेक्ट जोड़ें, जिसे हमने पहले ही आजीवन पैरामीटर के साथ बनाया था।
गोली आगे उड़नी चाहिए। हमने इसे प्रोजेक्टाइल में लागू किया, हम इसे इसी गति के साथ जोड़ते हैं।
गोली एक टक्कर से मरनी चाहिए। DieOnCollide जोड़ें। मैंने इसे छोड़ दिया, लेकिन यह पूरी तरह से तुच्छ है - सॉलिडबॉडी MsgCollide संदेश भेजता है, इसलिए हमें कुछ भी फिर से लागू करने की आवश्यकता नहीं है, बस MsgCollide.CollidedObject की जांच करें कि हम सभी किसके साथ हैं। यहाँ पैरामीटर टकराव को इंगित करते हैं जिनके साथ हम अनदेखा नहीं कर सकते हैं, यह कहता है कि दीवारों से टकराते हैं और ऑब्जेक्ट की आईडी निर्दिष्ट की जाती है, जिसे हमें अनदेखा करने की आवश्यकता है - इस बुलेट को बनाने वाले माता-पिता की आईडी को वहां से पारित किया जाता है, ताकि बुलेट खुद को घायल न करें।
और अंत में, आखिरी चीज जो हमें करने की आवश्यकता है वह किसी तरह से उन संदेशों का जवाब है जो हम मर चुके हैं - DecayOnDeath बस ऑब्जेक्ट को चुपचाप मार देगा जब यह MsgDeath संदेश प्राप्त करता है।
ठीक है, अगर हम एक रॉकेट चाहते हैं तो क्या होगा? कुछ भी आसान नहीं है:

  class Rocket : GameObject { public Rocket(GameContext context, IGameObject parrent, double x, double y, byte angle, double speed, double ttl, double radius) : base(context, GameObjectType.Rocket, parrent) { AddComponents( new SolidBody(this, context.GameMap, x, y, 15, 15, angle, true), new DieOnTTL(this, ttl), new Projectile(this, speed), new DieOnCollide(this,new[]{GameObjectType.Player, GameObjectType.WildLouse}, true, new ushort[]{parrent.GetId()}), new ExplodeOnDeath(this,context, radius) ); } } 

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

एक टेलीपोर्टिंग बुलेट, उदाहरण के लिए, केवल टेलिफ़ोन घटक की उपस्थिति में भिन्न होती है:

  AddComponents( new SolidBody(this, context.GameMap, x, y, 30, 30, angle,false, false, true), new DieOnTTL(this, ttl), new Projectile(this, speed), new Teleporter(this, context), new DieOnCollide(this, new GameObjectType[] {}, true, new ushort[] { parrent.GetId() }), new PhaseOnDeath(this, context, radius) ); 

वह टेलीपोर्टेबल कंपोनेंट वाली वस्तुओं को टेलीपोर्ट करने के लिए जिम्मेदार है। किसी ऑब्जेक्ट को टेलीपोर्टेबल बनाने के लिए, बस टेलीपोर्टेबल को घटकों की सूची में जोड़ें।
अधिकांश घटकों को किसी भी अतिरिक्त विरासत की आवश्यकता नहीं होती है, जो पूरी वास्तुकला को बहुत लचीला और पारदर्शी बनाती है।

यहाँ खेल में प्रयुक्त घटकों की एक सूची दी गई है:

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

   protected virtual void ProcessModifier(ItemType itemType, ModifierDescriptor modifier, double quantValue) 

  - समय की हर मात्रा (स्वास्थ्य पुनर्जनन, जहर) का संचालन करने वाले संशोधकों के लिए
  
  

   protected virtual void ModifierAcquired(ItemType itemType, ModifierDescriptor modifier) 

  - एक संशोधक के अधिग्रहण पर होने वाली घटना
  
  

   protected virtual void ModifierLost(ItemType itemType, ModifierDescriptor modifier) 

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

   protected abstract void Shoot(WeaponDescriptor weaponDescriptor, SolidBody solidBody) 

  - एक सफल शॉट के साथ, वहां से गुजरने वाले हथियार का हैंडल जिससे उन्होंने गोली चलाई
  
  

   protected virtual void OutOfAmmo(WeaponDescriptor weaponDescriptor, SolidBody solidBody) 

  - कारतूस के अभाव में
  
  

   protected virtual void Cooldowning(WeaponDescriptor weaponDescriptor) 

  - जब cooldown
• संग्रहणीय - एक घटक जो कलेक्टर के घटक के साथ टकराते हुए वस्तुओं को MsgItemsAvailable संदेश भेजता है, "मैं यहां हूं, मुझे उठाओ" चिल्ला रहा है।
• कलेक्टर - एक घटक जो कि MsgItemsAvailable पर सुनवाई करता है, आइटम को इन्वेंट्री में ले जाता है।
• विभिन्न DecayOn ... और DieOn ... पहले ही ऊपर वर्णित किया गया है।
• स्वस्थ - स्वास्थ्य और क्षति के लिए जिम्मेदार। इसके अलावा MsgDeath भेजता है जब स्वास्थ्य 0 तक पहुंचता है।
• इन्वेंट्री एक इन्वेंट्री घटक है जो उनकी संख्या के साथ वस्तुओं की सूची को संग्रहीत करने के लिए जिम्मेदार है। मुझे उन सभी चीजों की आवश्यकता है जो आइटम का उपयोग करती हैं - कलेक्टर, हथियार, आदि।
• प्रोजेक्टाइल एक सरल प्रोजेक्टाइल है।
• सॉलिडबॉडी - ऊपर वर्णित किया गया था, भौतिक अवतार - निर्देशांक, टकराव। यह एक मानचित्र पर पथ खोजने के लिए एक स्थैतिक फाइंडपाथ फ़ंक्शन भी प्रदान करता है।
• वॉकर - प्रोजेक्टाइल की तरह, लेकिन "उचित" वस्तुओं के लिए - एक निश्चित दिशा में चलता है, जो MsgWalk संदेश द्वारा निर्धारित किया जाता है। यदि दिशा। रुक जाती है तो MsgWalk में दिशा के रूप में निर्दिष्ट किया जाता है।

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

बाहरी सिस्टम, या बल्कि, नेटवर्क खिलाड़ी के साथ बातचीत करता है, जैसा कि पहले ही उल्लेख किया गया है, उसी संदेशों के साथ। ऐसा करने के लिए, नेटवर्क PerformAction () विधि के लिए संबंधित PlayerDescriptor yanks;
इस पद्धति का कार्यान्वयन संदेशों की सामान्य रचना है और उन्हें आवश्यक कार्रवाई के आधार पर PlayerRescriptor.PlayerObject.SendMeddage () को भेजना है।

निष्कर्ष

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

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