हमने विभिन्न प्लेटफार्मों के लिए अपने थीम अस्पताल को कैसे अनुकूलित किया

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

प्रदर्शन का स्तर: हम जो हासिल करना चाहते थे

विकास के एक प्रारंभिक चरण में, हमने मुख्य मापदंडों पर निर्णय लिया: दृश्यों का अधिकतम आकार, प्रदर्शन का स्तर और सिस्टम की आवश्यकताएं।

हमने खुद को एक स्क्रीन पर कम से कम सौ सक्रिय और पूरी तरह से एनिमेटेड पात्रों के लिए सहायता प्रदान करने का काम निर्धारित किया है, कुल मिलाकर तीन सौ सक्रिय पात्रों, टाइल के नक्शे लगभग 100x100 और इमारत में चार मंजिल तक मापते हैं।

हम दृढ़ता से आश्वस्त थे कि खेल को 1080p में एकीकृत ग्राफिक्स कार्ड पर भी एक सभ्य फ्रेम दर के साथ काम करना चाहिए, और अपने आप में यह लक्ष्य हासिल करना इतना मुश्किल नहीं था: मुख्य सीमित कारक सीपीयू है, खासकर अस्पताल की मात्रा में वृद्धि के साथ। आधुनिक एकीकृत ग्राफिक्स कार्ड लगभग 2560 x 1440 के प्रस्तावों पर ही समस्याओं का अनुभव करने लगते हैं।

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

ग्राफिक्स

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


एक ज्यामितीय रूप से प्रदान किए गए दृश्य में सभी ज्यामिति गतिशील रूप से C # में बनाई गई है, इसलिए ग्राफिक्स प्रदर्शन के लिए दो सबसे महत्वपूर्ण पहलुओं में से एक ज्यामिति पुनर्निर्माण की आवृत्ति है। दूसरा पहलू ड्रा कॉल की संख्या है।

कॉल ड्रा करें

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


यहां कुछ नंबर दिए गए हैं: 96 x 96 टाइल पर, आप सैद्धांतिक रूप से 9216 ऑब्जेक्ट रख सकते हैं, जिसमें 9216 ड्रॉ कॉल की आवश्यकता होगी। बैचिंग के बाद, यह संख्या 192 हो जाती है।

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


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

गगनचुंबी

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

shaders

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

इसके अलावा, हमने बहुत जल्दी सीखा कि शेडर मापदंडों को निर्दिष्ट करने से बचें और इसके बजाय जब भी संभव हो तो शीर्ष रंगों का उपयोग करें।

बनावट की गुणवत्ता

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

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

सीपीयू प्रदर्शन को अनुकूलित करें - मल्टीथ्रेडिंग

हालांकि एकता स्क्रिप्टिंग तर्क अनिवार्य रूप से एकल-थ्रेडेड है, हम हमेशा C # में सीधे कई थ्रेड चलाने की क्षमता रखते हैं। शायद यह दृष्टिकोण खेल तर्क के लिए उपयुक्त नहीं है, लेकिन अक्सर समय-महत्वपूर्ण कार्य होते हैं जिन्हें अलग-अलग थ्रेड्स में कार्य प्रणाली को व्यवस्थित करके किया जा सकता है। हमारे मामले में, थ्रेड्स का उपयोग दो कार्यों के लिए किया गया था:

1. एक पथ खोजने का कार्य, विशेष रूप से एक भ्रामक व्यवस्था के साथ बड़े मानचित्रों पर, सैकड़ों मिलीसेकंड तक हो सकता है, इसलिए यह मुख्य धारा से स्थानांतरण के लिए मुख्य उम्मीदवार था। समानांतर कार्य एक मशीन के हार्डवेयर थ्रेड्स की संख्या को ध्यान में रखते हैं।

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

एनिमेशन

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

एक जिज्ञासु तथ्य: अलग-अलग हड्डियों के परिवर्तन के अनुकूलन के उपयोग में सबसे उपयोगी सुधार, नक्शे की खोज से सरणियों के सरल अनुक्रमण के लिए संक्रमण के रूप में निकला।


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

कैशिंग

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

बिखरे और आस्थगित अद्यतन

कुछ मामलों में, केवल आंशिक रूप से कुछ अपडेट करना तर्कसंगत है। यहाँ कुछ उदाहरण हैं:

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

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

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

निष्कर्ष

कई इंटरेस्टिंग पार्ट्स के साथ गेम मैनेजर को ऑप्टिमाइज़ करना एक लंबी प्रक्रिया साबित हुई है। मुझे नियमित रूप से यूनिटी प्रोफाइलर के साथ काम करना पड़ा और सबसे स्पष्ट समस्याओं को ठीक करना पड़ा, यह विकास प्रक्रिया का एक अभिन्न अंग बन गया है।

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

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