नोड.जेएस पर टैनिकी - अनुकूलन

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

रूपरेखा

तो, कुछ को अनुकूलित करने के लिए, आपको अड़चनें खोजने की जरूरत है। नोड.जेएस के मामले में, मैंने निम्नलिखित कार्य किया: खेल को - प्रॉफिट विकल्प से शुरू करें

node --prof src/server 

जब स्क्रिप्ट पूरी हो जाती है, तो v8.log फ़ाइल वर्तमान फ़ोल्डर में दिखाई देती है। इसे सुपाच्य में बदलने के लिए, मैंने v8 स्रोतों से लिनक्स-टिक-प्रोसेसर उपयोगिता का उपयोग किया। मैं लिनक्स-टिक-प्रोसेसर के विवरण में नहीं गया था, लेकिन इसे अपने लिए प्राप्त करने और इसे काम करने के लिए प्राप्त करने के लिए, मुझे कई कमांड निष्पादित करना पड़ा:

 svn co http://v8.googlecode.com/svn/branches/bleeding_edge/ v8 cd v8 svn co http://gyp.googlecode.com/svn/trunk build/gyp make native 

देशी बनाने के बाद, वर्तमान फ़ोल्डर में लिनक्स-टिक-प्रोसेसर द्वारा उपयोग किए जाने वाले बायनेरिज़ के साथ आउट फ़ोल्डर दिखाई देता है। V8.log संसाधित करने के लिए, v8 फ़ोल्डर में, निष्पादित करें:

 tools/linux-tick-processor /full/path/to/v8.log > /full/path/to/v8.out 

परिणामी v8.out में, हम परिणामों को देखते हैं। प्रोफाइलिंग जानकारी यहाँ से ली गई है । यदि मैं इसे बहुत कठिन बनाता हूं और कोई बेहतर तरीका जानता है, तो मुझे यह जानकर खुशी होगी।

भार का अनुकरण करें

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

 phpunit --repeat=10 test.php 

हमें लोड अनुकरण करने का एक अच्छा तरीका मिलता है।

अनुकूलन 1 - क्लोजर

हम एक प्रोफाइल के साथ नोड शुरू करते हैं, लॉग को प्रोसेस करते हैं, और v8.out को देखते हैं। V8.out में, निष्पादन समय के अवरोही क्रम में कार्यों को क्रमबद्ध किया जाता है। लॉग में पहला Array.forEach फ़ंक्शन है:

 ticks total nonlib name 1514 2.3% 14.9% LazyCompile: *forEach native array.js:1019 

तब मुझे तुरंत समझ नहीं आया कि क्या हो रहा है। मैंने तय किया कि ऐसा इसलिए है क्योंकि कुछ जगहों पर मैं निर्माण का उपयोग करता हूं:

 someArray.forEach(function(item){ ... }, this); 

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

 Class.prototype.handler = function(item) { ... } Class.prototype.func = function() { someArray.forEach(this.handler, this); } 

ऐसा कोड तेजी से चलना चाहिए, लेकिन जैसा कि बाद में पता चला, वह बात नहीं थी।

अनुकूलन 2 - अंतर खोज

हम प्रोफाइलर लॉन्च करते हैं, सेलेनियम परीक्षण चलाते हैं और आगे देखते हैं:

  ticks total nonlib name 31043 3.8% 16.5% LazyCompile: MapArrayed.intersects src/utils/map_arrayed.js:45 26763 3.3% 14.3% Stub: CEntryStub 22800 2.8% 12.1% LazyCompile: *forEach native array.js:1019 16323 2.0% 8.7% LazyCompile: IN native runtime.js:353 13800 1.7% 7.4% Stub: KeyedLoadElementStub 6911 0.9% 3.7% LazyCompile: *MapArrayed.forEach src/utils/map_arrayed.js:59 

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

अनुकूलन 3 - forEach

फिर से, प्रोफाइलिंग के परिणामों को देखें। यहाँ हमें एक अजीब तस्वीर मिलती है, अगर मैंने केवल एक ही गेम खेला है, तो हमारे पास है:

  ticks total nonlib name 51 0.1% 11.6% LazyCompile: *Loggable.log battlecity/src/server/loggable.js:32 12 0.0% 2.7% LazyCompile: MapTiled.intersects battlecity/src/utils/map_tiled.js:106 8 0.0% 1.8% Stub: CEntryStub 6 0.0% 1.4% LazyCompile: *forEach native array.js:1019 4 0.0% 0.9% Stub: StringAddStub 4 0.0% 0.9% Stub: ArgumentsAccessStub_NewNonStrictFast 

अगर मैंने सेलेनियम शुरू किया और सर्वर ने कई दर्जन गेम खो दिए:

  ticks total nonlib name 4108 2.0% 16.1% LazyCompile: *forEach native array.js:1019 3626 1.8% 14.3% Stub: CEntryStub 2176 1.1% 8.6% LazyCompile: *MapTiled.forEach battlecity/src/utils/map_tiled.js:139 2048 1.0% 8.0% LazyCompile: IN native runtime.js:353 1755 0.9% 6.9% Stub: KeyedLoadElementStub {1} 1475 0.7% 5.8% LazyCompile: *Loggable.log battlecity/src/server/loggable.js:32 337 0.2% 1.3% LazyCompile: MapTiled.intersects battlecity/src/utils/map_tiled.js:106 336 0.2% 1.3% Stub: ToBooleanStub_Bool 

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

 a=[1]; a[1000000]=1; console.time('qwe'); a.forEach(function(i){console.log(i);}) console.timeEnd('qwe'); console.time('asd'); for (var i in a) console.log(a[i]); console.timeEnd('asd'); 

नतीजा निराशाजनक है।

एफएफ:

 qwe: 163ms asd: 2ms 

क्रोम:

 qwe: 254ms asd: 1ms 

खैर, बड़ी तस्वीर के लिए ओपेरा:

 qwe: 0ms (188µsec) asd: 0ms (87µsec) 

जैसा कि हम ओपेरा में देखते हैं, forEach () और for (var i in ...) रनटाइम में मूलभूत रूप से भिन्न नहीं होते हैं, लेकिन क्रोम और फ़ायरफ़ॉक्स ने मुझे वास्तव में परेशान किया, यही कारण है कि सर्वर (और क्लाइंट) ने कई गेम के बाद बहुत धीमा करना शुरू कर दिया। करने के लिए कुछ भी नहीं है, हम forEach () के लिए (var i in ...) पर फिर से लिखते हैं। और ओह, एक चमत्कार! मेमोरी लीक के लिए मैंने जो ब्रेक लगाया, वह गायब हो गया!

हम कई कंसोल में "phpunit --repeat = 100 test.php" चलाकर कुछ घंटों के लिए नोड छोड़ देते हैं:

  ticks total nonlib name 746 0.2% 16.1% LazyCompile: *Loggable.log battlecity/src/server/loggable.js:28 128 0.0% 2.8% LazyCompile: *Game._stepItem battlecity/src/core/game.js:77 101 0.0% 2.2% LazyCompile: MapTiled.intersects battlecity/src/utils/map_tiled.js:102 61 0.0% 1.3% Stub: CEntryStub 52 0.0% 1.1% Function: EventEmitter.emit events.js:38 50 0.0% 1.1% Stub: SubStringStub 46 0.0% 1.0% LazyCompile: *MapTiled.add battlecity/src/utils/map_tiled.js:24 45 0.0% 1.0% LazyCompile: FILTER_KEY native runtime.js:398 

अंत में, प्रोफाइलिंग परिणामों में, ऐसी चीजें हैं जिनके बारे में मैंने अनुमान लगाया है, और यह स्पष्ट नहीं है कि forEach () कहां से आया है।

अनुकूलन 4 - यातायात

फिर मैंने प्रोफाइलर से थोड़ा पीछे हटने का फैसला किया। तथ्य यह है कि पिछले अनुकूलन की खोज में, मैंने क्लाइंट और सर्वर के बीच ट्रैफ़िक की गणना की। यह गेम के बीच में निकला जिससे क्लाइंट को 30kb / s तक भेजे जा सकते हैं। जाहिर है, टैंकों जैसे खेल के लिए, यह एक अपमानजनक आंकड़ा है। लेकिन इसके कई कारण हैं। सबसे पहले, केवल एक संपत्ति को बदलते समय, ऑब्जेक्ट को क्लाइंट को एक पूरे के रूप में भेजा जाता है। दूसरी बात, JSON में ऑब्जेक्ट भेजे जाते हैं, जो ट्रांसमिट किए गए डेटा के आकार को भी बढ़ाता है। प्रारंभ में, वस्तुओं को इस तरह भेजा गया था:

 Bullet.prototype.serialize = function() { return { type: 'Bullet', id: this.id, x: this.x, y: this.y, z: this.z, speedX: this.speedX, speedY: this.speedY, finalX: this.finalX, finalY: this.finalY }; }; 

जिसके कारण स्ट्रिंग {"टाइप": "बुलेट", "आईडी": 777, "x": 123, "y": 456, "z": 1, "speedX": 2, "speedY": 0 का प्रसारण हुआ। "फ़ाइनलएक्स": 123, "फ़ाइनली": 456} लगभग 100 बाइट्स लंबा। थोड़ा विचार करने के बाद, मैंने वस्तुओं के क्रमांकन को भुनाया ताकि यह एक वस्तु नहीं, बल्कि एक सरणी हो:

 Bullet.prototype.serialize = function() { return [ battleCityTypesSerialize['Bullet'], // 0 this.id, // 1 this.x, // 2 this.y, // 3 this.speedX, // 4 this.speedY, // 5 this.finalX, // 6 todo remove this.finalY // 7 todo remove ]; }; 

परिणामस्वरूप, हमें लगभग 25 बाइट्स [0,777,123,456,2,0,123,456] मिलते हैं। खेल की ऊँचाई पर ट्रैफ़िक लगभग 7-8kb / s तक गिर गया। इसे कई बार कम किया जा सकता है, केवल परिवर्तित गुणों को पारित करना और केवल नियंत्रण आदेशों को पारित करना, लेकिन मैंने भविष्य के लिए इस परिवर्तन को छोड़ दिया।

अनुकूलन 5 - ग्राहक के साथ सिंक्रनाइज़ेशन

पिछले लेख से सिंक्रनाइज़ेशन एल्गोरिथ्म असफल रहा था। इस विकल्प का एकमात्र कारण, उन सभी ग्राहकों के लिए तुरंत परिवर्तन भेजने के बजाय जो उनमें रुचि रखते हैं, यह था कि एक नया जुड़ा ग्राहक अतीत में सभी परिवर्तनों को वर्तमान डेटा के समान ही प्राप्त कर सकता है। इसके अलावा, इस पद्धति के कार्यान्वयन के दौरान, मैं वस्तुओं को संग्रह में समूहीकृत करने, और वस्तुओं के लिए खुद को अपडेट करने के लिए नहीं, बल्कि वस्तुओं के संग्रह के लिए आवेदन करने के विचार के साथ आया था। इस तरह के संग्रह "सभी उपयोगकर्ता", "सामान्य चैट में संदेश", "गेम की सूची", "वर्तमान गेम में उपयोगकर्ता", "वर्तमान गेम में संदेश" और "वर्तमान गेम के मानचित्र पर ऑब्जेक्ट" हैं।
सिंक्रनाइज़ करने का एक नया तरीका उपयोगकर्ता वस्तुओं में परिवर्तन का तत्काल वितरण है, जहां वे जमा होते हैं। और उपयोगकर्ता ऑब्जेक्ट अभी भी हर 50ms में बैचों में ब्राउज़र को डेटा भेजता है। प्रश्न यह है कि प्रारंभिक डेटा को कब और कैसे सिंक्रनाइज़ किया जाए? मैंने उपयोगकर्ता ऑब्जेक्ट में 2 विधियाँ जोड़ने का निर्णय लिया: watchCollection () और undathCollection () और ऑब्जेक्ट्स के समूह से कनेक्ट होने के समय, उपयोगकर्ता क्लाइंट को सभी ऑब्जेक्ट्स नव निर्मित के रूप में भेजता है:

 /** * @param collection * @param syncKey ,          */ ServerUser.prototype.watchCollection = function(collection, syncKey) { this.unwatchCollection(syncKey); //      this.updateCollector[syncKey] = []; var user = this; var cb = function(item, type) { user.onCollectionUpdate(syncKey, item, type); }; //    collection.on('update', cb); //  callback,     ,     this.collections[syncKey] = {'callback': cb, 'collection': collection}; //     ,    collection.traversal(function(item){ this.onCollectionUpdate(syncKey, item, 'add'); }, this); }; ServerUser.prototype.unwatchCollection = function(syncKey) { if (this.collections[syncKey]) { //   this.collections[syncKey].collection.removeListener('update', this.collections[syncKey].callback); //  ,        this.clientMessage('clearCollection', syncKey); delete this.collections[syncKey]; delete this.updateCollector[syncKey]; } }; 

इस प्रकार, सर्वर पर उपयोगकर्ता के प्राधिकरण के तुरंत बाद, उपयोगकर्ता ऑब्जेक्ट ऑब्जेक्ट्स (संग्रह) के तीन समूहों से जुड़ा होता है:

 user.watchCollection(registry.users, 'users'); user.watchCollection(registry.premades, 'premades'); user.watchCollection(registry.messages, 'messages'); 

और खेल में प्रवेश करने और खेल से बाहर निकलने के दौरान, उपयोगकर्ता तदनुसार जोड़ता है और उसके लिए अन्य संग्रह से डिस्कनेक्ट करता है:

 Premade.prototype.join = function(user, clanId) { // ... user.watchCollection(this.users, 'premade.users'); user.watchCollection(this.messages, 'premade.messages'); // ... }; Premade.prototype.unjoin = function(user) { // ... user.unwatchCollection('premade.users'); user.unwatchCollection('premade.messages'); user.unwatchCollection('f'); user.unwatchCollection('game.botStack'); // ... }; Premade.prototype.startGame = function() { // ... this.users.traversal(function(user){ // ... user.watchCollection(this.game.field, 'f'); user.watchCollection(user.clan.enemiesClan.botStack, 'game.botStack'); // ... }, this); // ... } 

यह एक दया है कि सरल और सही विचार तुरंत दिमाग में नहीं आते हैं।
परिणामस्वरूप, हमारे पास:

  ticks total nonlib name 2074 0.5% 9.9% LazyCompile: *Game._stepItem battlecity/src/core/game.js:29 751 0.2% 3.6% LazyCompile: MapTiled.intersects battlecity/src/utils/map_tiled.js:102 489 0.1% 2.3% LazyCompile: MapTiled.traversal battlecity/src/utils/map_tiled.js:132 376 0.1% 1.8% LazyCompile: FILTER_KEY native runtime.js:398 

इस तथ्य को देखते हुए कि Game._stepItem शीर्ष पर आया था, और 9.9% समय निष्पादित होना शुरू हुआ, और 2.8% नहीं, पहले की तरह, हम परिवर्तन को सफल मानते हैं। इस बिंदु पर, सर्वर लगभग 50% 10 युगपत खेलों से भरा हुआ है। मैंने डेमो में एक ही समय में 20 गेम डालने की हिम्मत नहीं की, इस तथ्य के कारण कि सबसे खराब शाम के घंटों में, मेरे इंटरनेट की गति 200kByte / s और कम हो जाती है।

अनुकूलन 6 - गेम ऑब्जेक्ट्स को बायपास करें

प्रारंभ में, मैंने इस बारे में नहीं सोचा था, और लूप में क्षेत्र की प्रत्येक वस्तु के लिए मैंने _stepItem () फ़ंक्शन को बुलाया:

 Game.prototype._stepItem = function(item) { // tanks and Base processing within Clan.step if (item.step && !(item instanceof Tank) && !(item instanceof Base)) { // todo item.step(); } }; Game.prototype.step = function() { this.field.traversal(this._stepItem, this); this.premade.clans[0].step(); this.premade.clans[1].step(); }; 

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

 Game = function Game(level, premade) { // ... this.stepableItems = []; this.field.on('add', this.onAddObject.bind(this)); this.field.on('remove', this.onRemoveObject.bind(this)); // ... }; Game.prototype.onAddObject = function(object) { if (object.step && !(object instanceof Tank) && !(object instanceof Base)) { this.stepableItems[object.id] = object; } }; Game.prototype.onRemoveObject = function(object) { delete this.stepableItems[object.id]; }; Game.prototype.step = function() { for (var i in this.stepableItems) { this.stepableItems[i].step(); } // ... }; 

नतीजतन, मैं फिर से वस्तुओं के प्रतिच्छेदन पर लौट आया, लेकिन पूरी तरह से अलग स्तर पर:

 ticks total nonlib name 129 0.0% 2.4% LazyCompile: MapTiled.intersects battlecity/src/utils/map_tiled.js:102 66 0.0% 1.2% Stub: SubStringStub 54 0.0% 1.0% Stub: CEntryStub 47 0.0% 0.9% Function: EventEmitter.emit events.js:38 39 0.0% 0.7% LazyCompile: MapTiled.add battlecity/src/utils/map_tiled.js:24 30 0.0% 0.6% Function: Socket._writeOut net.js:389 

अब 5 गेम एक साथ प्रोसेसर समय के 15-16% पर कब्जा कर लेते हैं। यही है, मेरे पुराने सर्वर को एक धागे में लगभग 30 गेम खींचने चाहिए।

विरासत के साथ बैगा

मुझे एक बग के साथ लड़ना पड़ा, जिसके कारण ध्यान देने योग्य हैं। विरासत के दौरान, मैं माता-पिता को "कंस्ट्रक्टर" कहना भूल गया:

 function Parent() { this.property = []; } function Child() { // Parent.apply(this, argiments); -  }; Child.prototype = new Parent(); Child.prototype.constructor = Child; 

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

भविष्य की योजना

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

पहला भाग