👊🏾 🌯 🍶 यूनिटी 3 डी में क्लाइंट-सर्वर संचार 🔖 🍇 💅🏿

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

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

तो, निम्नलिखित आवेदक पाए गए:
1. फोटॉन
2. स्मार्टफॉक्स
3. अंतर्निहित एकता नेटवर्क
4. एलेक्ट्रोसेवर
5. यूलिंक
6. क्रिस्टलबाइन

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

कुल, हमारे पास 2 फाइनलिस्ट बचे हैं:
फोटॉन बनाम स्मार्टफ़ोन

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

खैर, आगे बढ़ते हैं। प्रोग्रामर के डेमो के निर्माण की शुरुआत में, टीम में तीन थे: I, मुख्य सर्वर, और व्यापक रूप से संकीर्ण सर्कल नेड्रोप में जाना जाता है (यूनिटी 3 डी के लिए रूसी इंटरनेट समुदाय के संस्थापक और साइट unity3d.ru )। Smartfox को सर्वर इंजन के रूप में चुने जाने के बाद, हमारा सर्वर मैन चला गया। इसलिए मैं एक सर्वर प्रोग्रामर बनने का नाटक करने लगा।
प्री-प्रोडक्शन के डेढ़ महीने तक, यह एक डेमो को बंद करने के लिए निकला: जिसमें
1. साझा चैट रूम के साथ एक गैरेज है।
2. आप 2 टीमों के लिए लड़ाई शुरू कर सकते हैं।
3. प्रत्येक खिलाड़ी 4 कारों में से 1 की सवारी करता है:
स्काउट, भारी बख्तरबंद कार, तोपखाने या इंजीनियर। यह सब एक-दूसरे को खुश करने, गोली चलाने, गोली मारने और मारने के लिए होता है। अरे हां, अभी भी विश्व में टैंक के समान दृश्यता प्रणाली थी, लेकिन इतनी शांत नहीं, बिल्कुल।

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

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

हमारे सामने सबसे पहली समस्या क्लाइंट-सर्वर संचार प्रोटोकॉल थी। एक स्मार्टफोन में, सब कुछ निम्नानुसार व्यवस्थित होता है:
1. क्लाइंट कोड प्रकार की एक घटना के लिए ग्राहक है

smartFox.AddEventListener(SFSEvent.EXTENSION_RESPONSE, OnExtensionResponse);

2. सर्वर से कमांड को कॉल करके, क्लाइंट के सभी ग्राहकों के पास एक विधि होगी जो सर्वर से पैरामीटर भेजती है। सर्वर से पैरामीटर कमांड नाम स्ट्रिंग और एक निश्चित SFSObject के रूप में प्रेषित होते हैं, जो हैश टेबल का एक एनालॉग होता है और इसमें वह सभी डेटा होता है जो सर्वर हमें क्लाइंट पर भेजा जाता है।

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

 public class SFSExtensionsController : MonoBehaviour { public delegate void ExtensionResponceDelegate(string cmd, SFSObject parameters); public static event ExtensionResponceDelegate onExtensionResponce = null; void Start() { smartFox.AddEventListener(SFSEvent.EXTENSION_RESPONSE, OnExtensionResponse); } static void OnExtensionResponse(BaseEvent evt) { string cmd = (string)evt.Params["cmd"]; SFSObject sfsParameters = (SFSObject)evt.Params["params"]; if (onExtensionResponce != null) { onExtensionResponce(cmd, sfsParameters); } } }

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

लेकिन ... अपनी सभी कमियों के लिए, ऊपर वर्णित प्रणाली ने अपना कार्य पूरा किया और डेमो ने इस पर पूरी तरह से काम किया। हालांकि, यह स्थान पहले चरण में उत्पादन चरण में फिर से काम करने वाला था। हल किए जाने वाले कई कार्य थे:

1. डेटा विनिमय प्रोटोकॉल में आदेशों की पहचान, साथ ही साथ क्लाइंट और सर्वर के बीच SFSObject की संरचना।
खेल तर्क डेटा के 2. स्वचालित क्रमांकन / deserialization।
3. खेल तर्क की सेवा करने वाले वर्गों से संदेश भेजने / प्राप्त करने में सुविधाजनक।

चलो आउट ऑफ ऑर्डर हो गए।

दो बिंदु: स्वचालित क्रमांकन / deserialization। ऐसा लगता है कि यह तुच्छ हो सकता है - प्रतिबिंब का उपयोग करें, सभी आवश्यक अतिरिक्त जानकारी लिखें, जैसे कि वर्ग का नाम, SFSObject और वहाँ खुशी होगी। लेकिन इस मामले में हमारी खुशी पूरी तरह से दूर होगी, क्योंकि खिलौना वास्तविक समय है, जिसमें लगातार बदलते डेटा की एक बड़ी धारा होती है, जैसे कि मशीन की स्थिति, गति, बुर्ज रोटेशन आदि। आदि इस डेटा में से प्रत्येक सर्वर और क्लाइंट के बीच प्रत्येक खिलाड़ी के लिए प्रति सेकंड कई बार भेजा जाता है, और कमरे के लिए 32 खिलाड़ियों की योजना बनाई जाती है, और इन कमरों को सर्वर के लिए कम से कम 50 की आवश्यकता होती है, ताकि परियोजना दिवालिया न हो, इसलिए समाधान सिर पर फिट नहीं होता है। और फिर निम्नलिखित विचार हमारी सहायता के लिए आए। SFSObject में गेम डेटा को पैक / अनपैक करने का कोड तुच्छ है और यहां तक कि एक प्रोग्राम भी हमारे लिए इस कोड को लिख सकता है। कुल में, एक उपयोगिता लिखी गई थी जो इनपुट पर निर्दिष्ट प्रारूप में एक iksm फ़ाइल प्राप्त करती है, और आउटपुट पर स्रोत कोड के साथ दो फ़ाइलों को आउटपुट करती है, एक एकता के लिए C # में, और Smartfox के लिए जावा में दूसरा। परिणामी फ़ाइलों में दो तरीके SFSObject ToSFSObject() और void FromSFSObject(SFSObject sfsObject) साथ कक्षाएं होती हैं।

उदाहरण वर्ग सी # के लिए प्रोग्रामेटिक रूप से उत्पन्न

 public class StartMultipleArtilleryShootProxy : ISFSSerializable { public int userId { get; set; } public long barrelId { get; set; } public long projectile { get; set; } public Vec3fProxy position { get; set; } public List<Vec3fProxy> direction { get; set; } public float startSpeed { get; set; } //---------------------------------------------------------------- public StartMultipleArtilleryShootProxy() {} public StartMultipleArtilleryShootProxy(ISFSObject obj) { FromSFSObject(obj); } public StartMultipleArtilleryShootProxy(int userId, long barrelId, long projectile, Vec3fProxy position, List<Vec3fProxy> direction, float startSpeed) { this.userId = userId; this.barrelId = barrelId; this.projectile = projectile; this.position = position; this.direction = direction; this.startSpeed = startSpeed; } //---------------------------------------------------------------- public void FromSFSObject(ISFSObject obj) { this.userId = obj.GetInt("ui"); this.barrelId = obj.GetLong("bi"); this.projectile = obj.GetLong("pr"); this.position = new Vec3fProxy(obj.GetByteArray("p").Bytes); this.direction = new List<Vec3fProxy>(); ISFSArray direction_array = obj.GetSFSArray("d"); for (int i = 0; i < direction_array.Size(); i++) this.direction.Add( new Vec3fProxy(direction_array.GetByteArray(i).Bytes)); this.startSpeed = obj.GetFloat("s"); } //---------------------------------------------------------------- public SFSObject ToSFSObject() { SFSObject obj = new SFSObject(); obj.PutInt("ui", userId); obj.PutLong("bi", barrelId); obj.PutLong("pr", projectile); obj.PutByteArray("p", new ByteArray(position.ToBytes())); if (this.direction == null) Debug.LogError("direction == null in ToSFSObject()"); ISFSArray direction_array = new SFSArray(); for (int i = 0; i < this.direction.Count; i++) direction_array.AddByteArray(new ByteArray(direction[i].ToBytes())); obj.PutSFSArray("d", direction_array); obj.PutFloat("s", startSpeed); return obj; } }

Iksml फ़ाइल में इस वर्ग के बारे में एक रिकॉर्ड:

 <StartMultipleArtilleryShootProxy userId-ui="int" barrelId-bi="long" projectile-pr="long" position-p="Vec3fProxy" direction-d="Vec3fProxy array" startSpeed-s="float"/>

प्रोटोकॉल को बदलते समय, हम xml फ़ाइल को बदलते हैं, उपयोगिता को चलाते हैं, हमें वह कोड मिलता है जो हमें आवश्यक वर्गों में SFSObject को जल्दी से SFSObject / SFSObject कर सकता है। हम क्लाइंट और सर्वर पर फ़ाइल को प्रतिस्थापित करते हैं और यह बात है!

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

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

 SFSProtocol.Protocol.BATTLE.HitRivalRequest.onGetResponce += OnGetHitRivalResponce;

और इवेंट हैंडलर, बदले में, गेम लॉजिक के लिए पहले से ही सख्ती से टाइप किए गए डेटा को आवश्यक लेता है:

 void OnGetHitRivalResponce(HitResultProxy hitResultProxy) { //    }

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

 cmdWasCatched = false; if (onExtensionResponce != null) { onExtensionResponce(cmd, sfsParameters); } if (!cmdWasCatched) { Debug.LogError(string.Format("SFSExtensionsController.OnExtensionResponse cmd={0} was not catched!", cmd)); }

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

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

 public class SFSRequest<TReqData, TRespData> : DataTransporter where TReqData : ISFSSerializable, new() where TRespData : ISFSSerializable, new() { ….......... protected override void Execute(Sfs2X.Entities.Data.SFSObject sfsParameters) { responceData = new TRespData(); responceData.FromSFSObject(sfsParameters); OnGetResponce(); } }

और सब कुछ ठीक लग रहा है, लेकिन एक बड़ी बात है: इस मामले में, new TRespData() कंस्ट्रक्टर प्रतिबिंब का उपयोग करेगा। नतीजतन, जो वे साथ लड़ रहे थे, वे उसमें भाग गए: रिफ्लेक्सियन अभी भी उपयोग किया जाता है, और पहले से ही लड़ाई में 8 खिलाड़ियों के साथ मंदी ध्यान देने योग्य है। स्थिति को ठीक करने के लिए, प्रतिनिधियों के लिए टीम के वर्ग में 2 फ़ील्ड जोड़े गए, जो एकमात्र काम करते हैं - TRespData और TReqData बनाएं। तो, बेस क्लास हैंडलर इस तरह दिखने लगा:

 protected override void Execute(Sfs2X.Entities.Data.SFSObject sfsParameters) { responceData = respDataConstructor(); responceData.FromSFSObject(sfsParameters); onGetResponce(); }

और एक विशेष कमांड के लिए अंतिम वर्ग है:

 public class MultipleArtilleryShootStartRequest : SFSRequest<StartMultipleArtilleryShootProxy, StartMultipleArtilleryShootProxy> { public MultipleArtilleryShootStartRequest(string sendCommand, string receiveCommand, Func<StartMultipleArtilleryShootProxy> reqDataConstructor, Func<StartMultipleArtilleryShootProxy> respDataConstructor) : base(sendCommand, receiveCommand, reqDataConstructor, respDataConstructor) { } }

वैसे, हैबर के एक लेख ने इस जंब को खोजने में मदद की, जिस लिंक से मैं दुर्भाग्य से हार गया।

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

यूनिटी 3 डी में क्लाइंट-सर्वर संचार

More articles: