DevOps C++ आणि "किचन वॉर्स", किंवा मी जेवताना गेम कसे लिहायला सुरुवात केली

"मला माहित आहे की मला काहीही माहित नाही" सॉक्रेटिस

कोणासाठी: आयटी लोकांसाठी जे सर्व विकसकांची काळजी घेत नाहीत आणि त्यांचे गेम खेळू इच्छितात!

कशाबद्दल: तुम्हाला अचानक गरज पडल्यास C/C++ मध्‍ये गेम कसे लिहायचे याबद्दल!

आपण हे का वाचले पाहिजे: ऍप्लिकेशन डेव्हलपमेंट हे माझ्या कौशल्याचे क्षेत्र नाही, परंतु मी दर आठवड्याला कोड करण्याचा प्रयत्न करतो. कारण मला खेळ आवडतात!

हॅलो माझे नाव आहे आंद्रे ग्रँकिन, मी Luxoft येथे DevOps आहे. ऍप्लिकेशन डेव्हलपमेंट ही माझी खासियत नाही, पण मी दर आठवड्याला कोड करण्याचा प्रयत्न करतो. कारण मला खेळ आवडतात!

संगणक गेमिंग उद्योग खूप मोठा आहे, आजच्या चित्रपट उद्योगापेक्षाही मोठा आहे. आधुनिक मानके, जटिल आणि मूलभूत विकास पद्धती वापरून, संगणकाच्या सुरुवातीपासून खेळ लिहिले गेले आहेत. कालांतराने, आधीच प्रोग्राम केलेले ग्राफिक्स, भौतिकशास्त्र आणि ध्वनी असलेले गेम इंजिन दिसू लागले. ते आपल्याला गेम विकसित करण्यावर लक्ष केंद्रित करण्याची परवानगी देतात आणि त्याच्या पायाबद्दल काळजी करू नका. परंतु त्यांच्यासह, इंजिनसह, विकासक "आंधळे होतात" आणि अधोगती करतात. खेळांचे उत्पादन स्वतः कन्व्हेयर बेल्टवर ठेवले जाते. आणि उत्पादनांचे प्रमाण त्याच्या गुणवत्तेवर वर्चस्व गाजवू लागते.

त्याच वेळी, इतर लोकांचे गेम खेळताना, आम्ही सतत स्थाने, कथानक, पात्रे आणि गेम मेकॅनिकद्वारे मर्यादित असतो जे इतर लोक आले. त्यामुळे मला कळले की...

... माझी स्वतःची जगे निर्माण करण्याची वेळ आली आहे, फक्त माझ्या अधीन आहे. जग जेथे मी पिता, पुत्र आणि पवित्र आत्मा आहे!

आणि माझा प्रामाणिकपणे विश्वास आहे की तुमचे स्वतःचे गेम इंजिन लिहून आणि त्यावर खेळून, तुम्ही तुमचे शूज काढू शकाल, खिडक्या पुसून आणि तुमची केबिन अपग्रेड करू शकाल, अधिक अनुभवी आणि पूर्ण प्रोग्रामर बनू शकाल.

या लेखात मी तुम्हाला C/C++ मध्ये छोटे खेळ कसे लिहायला सुरुवात केली, विकास प्रक्रिया कशी आहे आणि व्यस्त वातावरणात मला छंदासाठी वेळ कुठे मिळतो हे सांगण्याचा प्रयत्न करेन. हे व्यक्तिनिष्ठ आहे आणि वैयक्तिक प्रारंभाच्या प्रक्रियेचे वर्णन करते. अज्ञान आणि विश्वास याबद्दलची सामग्री, या क्षणी जगाच्या माझ्या वैयक्तिक चित्राबद्दल. दुसऱ्या शब्दांत, "प्रशासन तुमच्या वैयक्तिक मेंदूसाठी जबाबदार नाही!"

सराव

"अभ्यासाशिवाय ज्ञान निरुपयोगी आहे, ज्ञानाशिवाय सराव धोकादायक आहे." कन्फ्यूशियस

माझी नोटबुक माझे जीवन आहे!

म्हणून, सराव मध्ये, मी असे म्हणू शकतो की माझ्यासाठी सर्वकाही नोटपॅडपासून सुरू होते. मी तिथे माझी दैनंदिन कामे लिहून ठेवत नाही, तर मी काढतो, प्रोग्राम करतो, फ्लोचार्ट तयार करतो आणि गणिताच्या समस्या सोडवतो. नेहमी नोटपॅड वापरा आणि फक्त पेन्सिलमध्ये लिहा. हे स्वच्छ, सोयीस्कर आणि विश्वासार्ह आहे, IMHO.

माझी (आधीच भरलेली) वही. तो असाच दिसतो. त्यात दैनंदिन कामे, कल्पना, रेखाचित्रे, आकृत्या, उपाय, ब्लॅक बुककीपिंग, कोड इत्यादींचा समावेश आहे.

या टप्प्यावर, मी तीन प्रकल्प पूर्ण करण्यात व्यवस्थापित केले (हे माझ्या "पूर्णतेच्या" समजानुसार आहे, कारण कोणतेही उत्पादन तुलनेने अविरतपणे विकसित केले जाऊ शकते).

• प्रकल्प २: हे युनिटी गेम इंजिन वापरून C# मध्ये लिहिलेले 3D आर्किटेक्ट डेमो सीन आहे. macOS आणि Windows प्लॅटफॉर्मसाठी.
• गेम 1: विंडोजसाठी कन्सोल गेम सिंपल स्नेक (प्रत्येकाला "साप" म्हणून ओळखले जाते). सी मध्ये लिहिलेले.
• गेम 2: कन्सोल गेम Crazy Tanks (प्रत्येकाला “Tanks” म्हणून ओळखले जाते), C++ मध्ये लिहिलेले (वर्ग वापरून) आणि Windows साठी देखील.

प्रकल्प 0. आर्किटेक्ट डेमो

• प्लॅटफॉर्म: Windows (Windows 7, 10), Mac OS (OS X El Capitan v. 10.11.6)
• भाषा: C#
• गेम इंजिन: युनिटी
• प्रेरणा: डॅरिन लिले
• भांडार: GitHub

3D सीन आर्किटेक्ट डेमो

पहिला प्रकल्प C/C++ मध्ये नाही तर C# मध्ये युनिटी गेम इंजिन वापरून लागू करण्यात आला. या इंजिनला हार्डवेअर प्रमाणे मागणी नव्हती अवास्तव इंजिन, आणि स्थापित करणे आणि वापरणे देखील सोपे आहे. मी इतर इंजिनांचा विचार केला नाही.

युनिटीमध्ये माझे ध्येय खेळ विकसित करणे हे नव्हते. मला काही पात्रांसह 3D सीन तयार करायचा होता. त्याला, किंवा त्याऐवजी तिला (मी ज्या मुलीच्या प्रेमात होते त्या मुलीचे मॉडेल बनवले =) त्याला त्याच्या सभोवतालच्या जगाशी हलवावे आणि संवाद साधावा लागला. युनिटी म्हणजे काय, विकास प्रक्रिया म्हणजे काय आणि एखादी गोष्ट घडवण्यासाठी किती प्रयत्न करावे लागतात, हे समजून घेणे महत्त्वाचे होते. अशा प्रकारे आर्किटेक्ट डेमो प्रकल्पाचा जन्म झाला (नाव जवळजवळ कोठेही शोधले गेले नाही). प्रोग्रॅमिंग, मॉडेलिंग, अॅनिमेशन, टेक्सचरिंग मला दैनंदिन कामात दोन महिने लागले.

मध्ये 3D मॉडेल्स तयार करण्यासाठी मी YouTube वर ट्यूटोरियल व्हिडिओंसह सुरुवात केली ब्लेंडर. ब्लेंडर हे 3D मॉडेलिंग (आणि अधिक) साठी एक उत्कृष्ट विनामूल्य साधन आहे ज्यास इंस्टॉलेशनची आवश्यकता नाही. आणि इथे मला एक धक्का बसला... असे दिसून आले की मॉडेलिंग, अॅनिमेशन, टेक्सचरिंग हे खूप वेगळे विषय आहेत ज्यावर तुम्ही पुस्तके लिहू शकता. हे पात्रांसाठी विशेषतः खरे आहे. बोटे, दात, डोळे आणि शरीराच्या इतर अवयवांचे मॉडेल बनवण्यासाठी तुम्हाला शरीरशास्त्राचे ज्ञान आवश्यक असेल. चेहऱ्याच्या स्नायूंची रचना कशी असते? लोक कसे हलतात? मला प्रत्येक हात, पाय, बोट, बोटांच्या फॅलेंजेसमध्ये हाडे "घावायची" होती!

अॅनिमेशन नैसर्गिक दिसण्यासाठी कॉलरबोन्स आणि अतिरिक्त लीव्हर हाडे मॉडेल करा. अशा धड्यांनंतर, अॅनिमेटेड चित्रपटांचे निर्माते फक्त 30 सेकंदांचा व्हिडिओ तयार करण्यासाठी किती काम करतात हे तुमच्या लक्षात येते. पण थ्रीडी चित्रपट तासन्तास टिकतात! आणि मग आम्ही सिनेमा सोडतो आणि असे काहीतरी म्हणतो: “हे एक बकवास कार्टून/चित्रपट आहे! ते अधिक चांगले करू शकले असते..." मूर्खांनो!

आणि या प्रकल्पातील प्रोग्रामिंगशी संबंधित आणखी एक गोष्ट. असे झाले की, माझ्यासाठी सर्वात मनोरंजक भाग गणिताचा होता. तुम्ही सीन चालवल्यास (प्रोजेक्ट वर्णनातील रिपॉझिटरीशी लिंक), तुमच्या लक्षात येईल की कॅमेरा एका गोलामध्ये मुलीच्या पात्राभोवती फिरत आहे. कॅमेर्‍याचे असे रोटेशन प्रोग्राम करण्यासाठी, मला प्रथम वर्तुळावर (2D) आणि नंतर गोलावर (3D) स्थिती बिंदूचे निर्देशांक मोजावे लागले. गंमत म्हणजे मला शाळेत गणिताचा तिटकारा होता आणि ते C-minus ने कळत असे. अंशतः, बहुधा, कारण शाळेत हे गणित जीवनात कसे लागू केले जाते ते ते तुम्हाला स्पष्ट करत नाहीत. पण जेव्हा तुम्हाला तुमच्या ध्येयाचे वेड असते, तेव्हा तुमचे स्वप्न, तुमचे मन स्वच्छ होते आणि खुलते! आणि तुम्हाला कठीण कार्ये एक रोमांचक साहस म्हणून समजू लागतात. आणि मग तुम्ही विचार करता: "बरं, तुमचा *आवडता* गणितज्ञ तुम्हाला हे सूत्र कुठे लागू करता येईल हे सामान्यपणे का सांगू शकत नाही?"

वर्तुळावरील आणि गोलावरील बिंदूच्या निर्देशांकांची गणना करण्यासाठी सूत्रांची गणना (माझ्या नोटबुकमधून)

खेळ 1. साधा साप

• प्लॅटफॉर्म: Windows (Windows 7, 10 वर चाचणी केली आहे)
• भाषा: मला वाटते मी ते शुद्ध C मध्ये लिहिले आहे
• गेम इंजिन: विंडोज कन्सोल
• प्रेरणा: javidx9
• भांडार: GitHub

साधा साप खेळ

थ्रीडी सीन हा खेळ नाही. याव्यतिरिक्त, 3D वस्तूंचे मॉडेलिंग आणि अॅनिमेट करणे (विशेषत: वर्ण) वेळ घेणारे आणि कठीण आहे. युनिटीबरोबर खेळल्यानंतर, मला जाणीव झाली की मला मूलभूत गोष्टींपासून सुरू ठेवण्याची किंवा त्याऐवजी सुरुवात करणे आवश्यक आहे. गेमची रचना समजून घेण्यासाठी काहीतरी सोपे आणि जलद, परंतु त्याच वेळी जागतिक.

सोपे आणि जलद काय आहे? ते बरोबर आहे, कन्सोल आणि 2D. अधिक तंतोतंत, अगदी कन्सोल आणि चिन्हे. पुन्हा मी इंटरनेटवर प्रेरणा शोधत गेलो (सर्वसाधारणपणे, मला वाटते की इंटरनेट हा XNUMX व्या शतकातील सर्वात क्रांतिकारी आणि धोकादायक शोध आहे). मी एका प्रोग्रामरचा व्हिडिओ खोदला ज्याने कन्सोल टेट्रिस बनवले. आणि त्याच्या खेळाच्या रूपात मी "साप" बनवण्याचा निर्णय घेतला. व्हिडिओवरून मी दोन मूलभूत गोष्टी शिकलो - गेम लूप (तीन मूलभूत कार्ये/भागांसह) आणि बफरला आउटपुट.

गेम लूप यासारखे काहीतरी दिसू शकते:

int main()
   {
      Setup();
      // a game loop
      while (!quit)
      {
          Input();
          Logic();
          Draw();
          Sleep(gameSpeed);  // game timing
      }
      return 0;
   }

कोड संपूर्ण मुख्य() फंक्शन एकाच वेळी सादर करतो. आणि योग्य टिप्पणीनंतर गेम सायकल सुरू होते. लूपमध्ये तीन मूलभूत कार्ये आहेत: इनपुट(), लॉजिक(), ड्रॉ(). प्रथम, डेटा इनपुट इनपुट (मुख्यतः कीस्ट्रोकचे नियंत्रण), नंतर प्रविष्ट केलेल्या डेटावर प्रक्रिया करणे लॉजिक, नंतर स्क्रीनवर आउटपुट - काढा. आणि प्रत्येक फ्रेमवर. अशा प्रकारे अॅनिमेशन तयार होते. हे व्यंगचित्रांसारखे आहे. सामान्यतः, प्रविष्ट केलेल्या डेटावर प्रक्रिया करण्यासाठी सर्वात जास्त वेळ लागतो आणि, माझ्या माहितीनुसार, गेमचा फ्रेम दर निर्धारित करते. पण इथे Logic() फंक्शन खूप लवकर कार्यान्वित होते. म्हणून, तुम्हाला गेमस्पीड पॅरामीटरसह स्लीप() फंक्शन वापरून फ्रेम रेट नियंत्रित करावा लागेल, जो हा वेग निर्धारित करतो.

खेळ सायकल. नोटपॅडमध्ये "साप" प्रोग्राम करणे

जर तुम्ही कॅरेक्टर-आधारित कन्सोल गेम विकसित करत असाल, तर तुम्ही नियमित 'काउट' स्ट्रीम आउटपुट वापरून स्क्रीनवर डेटा आउटपुट करू शकणार नाही - ते खूप मंद आहे. म्हणून, आउटपुट स्क्रीन बफरवर पाठविले जाणे आवश्यक आहे. हे खूप वेगवान आहे आणि गेम कोणत्याही त्रुटीशिवाय चालेल. खरे सांगायचे तर, मला स्क्रीन बफर म्हणजे काय आणि ते कसे कार्य करते हे समजत नाही. परंतु मी येथे एक उदाहरण कोड देईन आणि कदाचित कोणीतरी टिप्पण्यांमध्ये परिस्थिती स्पष्ट करू शकेल.

स्क्रीन बफर मिळवणे (म्हणून बोलायचे तर):

// create screen buffer for drawings
   HANDLE hConsole = CreateConsoleScreenBuffer(GENERIC_READ | GENERIC_WRITE, 0,
 							   NULL, CONSOLE_TEXTMODE_BUFFER, NULL);
   DWORD dwBytesWritten = 0;
   SetConsoleActiveScreenBuffer(hConsole);

विशिष्ट स्ट्रिंग स्कोरलाइनचे थेट प्रदर्शन (स्कोअर डिस्प्ले लाइन):

// draw the score
   WriteConsoleOutputCharacter(hConsole, scoreLine, GAME_WIDTH, {2,3}, &dwBytesWritten);

सिद्धांतानुसार, या गेममध्ये काहीही क्लिष्ट नाही; मला वाटते की हे एक चांगले एंट्री-लेव्हल उदाहरण आहे. कोड एका फाईलमध्ये लिहिला जातो आणि अनेक फंक्शन्समध्ये फॉरमॅट केला जातो. वर्ग नाही, वारसा नाही. GitHub वरील रेपॉजिटरीमध्ये जाऊन तुम्ही गेमच्या सोर्स कोडमध्ये सर्वकाही स्वतः पाहू शकता.

खेळ 2. वेडा टाक्या

• प्लॅटफॉर्म: Windows (Windows 7, 10 वर चाचणी केली आहे)
• भाषा: C ++
• गेम इंजिन: विंडोज कन्सोल
• प्रेरणा: एक पुस्तक गेम प्रोग्रामिंगद्वारे C++ ची सुरुवात
• भांडार: GitHub

खेळ वेडा टाक्या

कन्सोलवर अक्षरे मुद्रित करणे ही कदाचित सर्वात सोपी गोष्ट आहे जी तुम्ही गेममध्ये बदलू शकता. परंतु नंतर एक समस्या दिसून येते: चिन्हांची उंची आणि रुंदी भिन्न आहे (उंची रुंदीपेक्षा जास्त आहे). अशा प्रकारे, सर्व काही प्रमाणाबाहेर दिसेल आणि डावीकडे किंवा उजवीकडे हलवण्यापेक्षा खाली किंवा वर जाणे खूप जलद दिसेल. स्नेक (गेम 1) मध्ये हा प्रभाव खूपच लक्षणीय आहे. "टँक्स" (गेम 2) मध्ये ही कमतरता नाही, कारण तेथील आउटपुट वेगवेगळ्या रंगांनी स्क्रीन पिक्सेल पेंटिंगद्वारे व्यवस्थित केले जाते. तुम्ही म्हणू शकता की मी रेंडरर लिहिले आहे. खरे आहे, हे थोडे अधिक क्लिष्ट आहे, जरी बरेच मनोरंजक आहे.

या गेमसाठी, स्क्रीनवर पिक्सेल प्रदर्शित करण्यासाठी माझ्या सिस्टमचे वर्णन करणे पुरेसे असेल. मी हा खेळाचा मुख्य भाग मानतो. आणि आपण स्वतःच इतर सर्व गोष्टींसह येऊ शकता.

तर, तुम्ही स्क्रीनवर जे पाहता ते फक्त हलत्या बहु-रंगीत आयतांचा संच आहे.

आयतांचा संच

प्रत्येक आयत संख्यांनी भरलेल्या मॅट्रिक्सद्वारे दर्शविला जातो. तसे, मी एक मनोरंजक सूक्ष्मता हायलाइट करू शकतो - गेममधील सर्व मॅट्रिक्स एक-आयामी अॅरे म्हणून प्रोग्राम केलेले आहेत. द्विमितीय नाही, तर एक-आयामी! एक-आयामी अ‍ॅरे काम करण्यासाठी खूप सोपे आणि जलद आहेत.

गेम टँक मॅट्रिक्सचे उदाहरण

गेम टँक मॅट्रिक्सचे एक-आयामी अॅरे म्हणून प्रतिनिधित्व

एक-आयामी अॅरे म्हणून मॅट्रिक्सचे प्रतिनिधित्व करण्याचे अधिक दृश्य उदाहरण

परंतु अॅरेच्या घटकांमध्ये प्रवेश दुहेरी लूपमध्ये होतो, जणू तो एक-आयामी अॅरे नसून द्विमितीय अॅरे आहे. हे केले जाते कारण आम्ही अजूनही मॅट्रिकसह काम करतो.

दुहेरी लूपमध्ये एक-आयामी अ‍ॅरे पार करणे. Y - पंक्ती अभिज्ञापक, X - स्तंभ अभिज्ञापक

कृपया लक्षात ठेवा: नेहमीच्या मॅट्रिक्स आयडेंटिफायर i, j ऐवजी, मी x आणि y आयडेंटिफायर वापरतो. अशा प्रकारे, मला असे वाटते की ते डोळ्यांना अधिक आनंददायक आणि मेंदूला अधिक समजण्यासारखे आहे. याव्यतिरिक्त, अशा नोटेशनमुळे द्वि-आयामी प्रतिमेच्या समन्वय अक्षांवर वापरल्या जाणार्‍या मॅट्रिक्सला सोयीस्करपणे प्रक्षेपित करणे शक्य होते.

आता पिक्सेल, रंग आणि स्क्रीन आउटपुट बद्दल. StretchDIBits फंक्शन आउटपुटसाठी वापरले जाते (शीर्षलेख: windows.h; लायब्ररी: gdi32.lib). हे फंक्शन, इतर गोष्टींसह, खालील गोष्टी प्राप्त करते: ज्या डिव्हाइसवर प्रतिमा प्रदर्शित केली जाते (माझ्या बाबतीत, ते विंडोज कन्सोल आहे), प्रतिमा प्रदर्शनाचे प्रारंभ निर्देशांक, त्याची रुंदी/उंची आणि प्रतिमा स्वतः बिटमॅपचे स्वरूप, बाइट्सच्या अॅरेद्वारे प्रस्तुत केले जाते. बिटमॅप बाइट अॅरे म्हणून!

StretchDIBits() फंक्शन कृतीत आहे:

// screen output for game field
   StretchDIBits(
               deviceContext,
               OFFSET_LEFT, OFFSET_TOP,
               PMATRIX_WIDTH, PMATRIX_HEIGHT,
               0, 0,
               PMATRIX_WIDTH, PMATRIX_HEIGHT,
               m_p_bitmapMemory, &bitmapInfo,
               DIB_RGB_COLORS,
               SRCCOPY
               );

VirtualAlloc() फंक्शन वापरून या बिटमॅपसाठी मेमरी आगाऊ वाटप केली जाते. म्हणजेच, सर्व पिक्सेलची माहिती संग्रहित करण्यासाठी आवश्यक संख्येने बाइट्स आरक्षित आहेत, जे नंतर स्क्रीनवर प्रदर्शित केले जातील.

m_p_bitmapमेमरी बिटमॅप तयार करणे:

// create bitmap
   int bitmapMemorySize = (PMATRIX_WIDTH * PMATRIX_HEIGHT) * BYTES_PER_PIXEL;
   void* m_p_bitmapMemory = VirtualAlloc(0, bitmapMemorySize, MEM_COMMIT, PAGE_READWRITE);

साधारणपणे बोलायचे झाल्यास, बिटमॅपमध्ये पिक्सेलचा संच असतो. अॅरेमधील प्रत्येक चार बाइट्स एक RGB पिक्सेल आहे. एक बाइट प्रति लाल रंग मूल्य, एक बाइट प्रति हिरवा रंग मूल्य (G), आणि एक बाइट प्रति निळा रंग मूल्य (B). शिवाय इंडेंटेशनसाठी एक बाइट शिल्लक आहे. हे तीन रंग - लाल/हिरवा/निळा (RGB) - परिणामी पिक्सेल रंग तयार करण्यासाठी एकमेकांशी वेगवेगळ्या प्रमाणात मिसळले जातात.

आता, पुन्हा, प्रत्येक आयत, किंवा गेम ऑब्जेक्ट, अंकीय मॅट्रिक्सद्वारे दर्शविले जाते. या सर्व गेम ऑब्जेक्ट्स संग्रहात ठेवल्या आहेत. आणि मग ते खेळाच्या मैदानावर ठेवले जातात, एक मोठे संख्यात्मक मॅट्रिक्स बनवतात. मी मॅट्रिक्समधील प्रत्येक संख्या एका विशिष्ट रंगाशी जोडली. उदाहरणार्थ, क्रमांक 8 निळ्याशी संबंधित आहे, क्रमांक 9 ते पिवळा, क्रमांक 10 ते गडद राखाडी इत्यादी. अशा प्रकारे, आपण असे म्हणू शकतो की आपल्याकडे खेळण्याच्या क्षेत्राचे मॅट्रिक्स आहे, जिथे प्रत्येक संख्या एक रंग आहे.

तर, आमच्याकडे एका बाजूला संपूर्ण खेळाच्या मैदानाचा अंकीय मॅट्रिक्स आहे आणि दुसरीकडे प्रतिमा प्रदर्शित करण्यासाठी बिटमॅप आहे. आतापर्यंत, बिटमॅप "रिक्त" आहे - त्यात अद्याप इच्छित रंगाच्या पिक्सेलबद्दल माहिती नाही. याचा अर्थ असा की खेळण्याच्या क्षेत्राच्या अंकीय मॅट्रिक्सवर आधारित प्रत्येक पिक्सेलबद्दल माहितीसह बिटमॅप भरणे ही शेवटची पायरी असेल. अशा परिवर्तनाचे स्पष्ट उदाहरण खालील चित्रात आहे.

खेळाच्या मैदानाच्या डिजिटल मॅट्रिक्सवर आधारित माहितीसह बिटमॅप (पिक्सेल मॅट्रिक्स) भरण्याचे उदाहरण (रंग निर्देशांक गेममधील निर्देशांकांशी जुळत नाहीत)

मी गेममधील वास्तविक कोडचा एक भाग देखील सादर करेन. लूपच्या प्रत्येक पुनरावृत्तीवरील व्हेरिएबल कलर इंडेक्सला प्ले फील्डच्या अंकीय मॅट्रिक्समधून मूल्य (रंग निर्देशांक) नियुक्त केले जाते (मुख्य डिजिटल मॅट्रिक्स). कलर व्हेरिएबल नंतर निर्देशांकावर आधारित रंगावर सेट केले जाते. परिणामी रंग नंतर लाल, हिरवा आणि निळा (RGB) च्या गुणोत्तरामध्ये विभागला जातो. आणि पिक्सेलपॅडिंगसह, ही माहिती पिक्सेलमध्ये पुन्हा पुन्हा लिहिली जाते, बिटमॅपमध्ये रंगीत प्रतिमा तयार करते.

कोड पॉइंटर आणि बिटवाइज ऑपरेशन्स वापरतो, जे समजणे कठीण असू शकते. म्हणून मी तुम्हाला अशी रचना कशी कार्य करते हे कुठेतरी स्वतंत्रपणे वाचण्याचा सल्ला देतो.

खेळाच्या मैदानाच्या संख्यात्मक मॅट्रिक्सवर आधारित माहितीसह बिटमॅप भरणे:

// set pixel map variables
   int colorIndex;
   COLORREF color;
   int pitch;
   uint8_t* p_row;
 
   // arrange pixels for game field
   pitch = PMATRIX_WIDTH * BYTES_PER_PIXEL;     // row size in bytes
   p_row = (uint8_t*)m_p_bitmapMemory;       //cast to uint8 for valid pointer arithmetic
   							(to add by 1 byte (8 bits) at a time)   
   for (int y = 0; y < PMATRIX_HEIGHT; ++y)
   {
       uint32_t* p_pixel = (uint32_t*)p_row;
       for (int x = 0; x < PMATRIX_WIDTH; ++x)
       {
           colorIndex = mainDigitalMatrix[y * PMATRIX_WIDTH + x];
           color = Utils::GetColor(colorIndex);
           uint8_t blue = GetBValue(color);
           uint8_t green = GetGValue(color);
           uint8_t red = GetRValue(color);
           uint8_t pixelPadding = 0;
 
           *p_pixel = ((pixelPadding << 24) | (red << 16) | (green << 8) | blue);
           ++p_pixel;
       }
       p_row += pitch;
   }

वर वर्णन केलेल्या पद्धतीनुसार, क्रेझी टँक्स गेममध्ये ड्रॉ() फंक्शनमध्ये एक चित्र (फ्रेम) तयार होते आणि स्क्रीनवर प्रदर्शित होते. Input() फंक्शनमध्‍ये की स्‍ट्रोकची नोंदणी केल्‍यानंतर आणि लॉजिक() फंक्‍शनमध्‍ये त्‍यांच्‍या नंतरच्‍या प्रक्रियेनंतर, नवीन चित्र (फ्रेम) तयार होते. खरे आहे, गेम ऑब्जेक्ट्सची प्लेइंग फील्डवर आधीपासूनच वेगळी स्थिती असू शकते आणि त्यानुसार, वेगळ्या ठिकाणी काढली जाते. अशा प्रकारे अॅनिमेशन (हालचाल) घडते.

सैद्धांतिकदृष्ट्या (मी काहीही विसरलो नसल्यास), पहिल्या गेममधील गेम लूप समजून घेणे (“साप”) आणि दुसऱ्या गेममधून स्क्रीनवर पिक्सेल प्रदर्शित करण्याची प्रणाली (“टँक्स”) तुम्हाला काहीही लिहिण्याची गरज आहे. Windows अंतर्गत आपल्या 2D गेमचे. आवाजहीन! 😉 बाकीचे भाग फक्त फॅन्सीचे फ्लाइट आहेत.

अर्थात, “टाँक्स” हा खेळ “साप” पेक्षा खूपच गुंतागुंतीचा आहे. मी आधीच C++ भाषा वापरली आहे, म्हणजेच मी वर्गांसह विविध गेम ऑब्जेक्ट्सचे वर्णन केले आहे. मी माझा स्वतःचा संग्रह तयार केला आहे - कोड हेडर/Box.h मध्ये पाहिला जाऊ शकतो. तसे, संग्रहात बहुधा मेमरी लीक आहे. पॉइंटर्स वापरले. स्मृतीसह काम केले. पुस्तकाने मला खूप मदत केली असे मला म्हणायचे आहे गेम प्रोग्रामिंगद्वारे C++ ची सुरुवात. C++ मधील नवशिक्यांसाठी ही चांगली सुरुवात आहे. हे लहान, मनोरंजक आणि व्यवस्थित आहे.

हा गेम विकसित करण्यासाठी सुमारे सहा महिने लागले. मी मुख्यतः दुपारच्या जेवणादरम्यान आणि कामाच्या ठिकाणी स्नॅक्स दरम्यान लिहिले. तो ऑफिसच्या स्वयंपाकघरात बसला, अन्न तुडवले आणि कोड लिहिला. किंवा घरी रात्रीचे जेवण. म्हणून मी या "स्वयंपाकघरातील युद्ध" संपवले. नेहमीप्रमाणे, मी सक्रियपणे एक नोटबुक वापरली आणि त्यात सर्व वैचारिक गोष्टींचा जन्म झाला.

व्यावहारिक भाग पूर्ण करण्यासाठी, मी माझ्या नोटबुकचे काही स्कॅन घेईन. मी नेमके काय लिहिले, काढले, मोजले, डिझाइन केले हे दाखवण्यासाठी...

टाक्यांची प्रतिमा तयार करणे. आणि स्क्रीनवर प्रत्येक टँकने किती पिक्सेल व्यापले पाहिजे हे निर्धारित करणे

टाकीच्या अक्षाभोवती फिरण्यासाठी अल्गोरिदम आणि सूत्रांची गणना

माझ्या संग्रहाची योजना (ज्यामध्ये मेमरी लीक आहे, बहुधा). लिंक्ड लिस्ट प्रकारानुसार संग्रह तयार केला जातो

आणि खेळाला आर्टिफिशियल इंटेलिजन्स जोडण्याचे हे निरर्थक प्रयत्न आहेत

सिद्धांत

"हजार मैलांचा प्रवास देखील पहिल्या पायरीने सुरू होतो" (प्राचीन चीनी शहाणपण)

चला सरावातून सिद्धांताकडे जाऊया! आपल्या छंदासाठी वेळ कसा शोधायचा?

1. तुम्हाला खरोखर काय हवे आहे ते ठरवा (अरे, हा सर्वात कठीण भाग आहे).
2. प्राधान्यक्रम सेट करा.
3. उच्च प्राधान्यांच्या फायद्यासाठी "अतिरिक्त" सर्वकाही त्याग करा.
4. दररोज ध्येयाकडे वाटचाल करा.
5. छंदासाठी दोन किंवा तीन तासांचा मोकळा वेळ घालवण्याची अपेक्षा करू नका.

एकीकडे, आपल्याला काय हवे आहे हे निर्धारित करणे आणि प्राधान्य देणे आवश्यक आहे. दुसरीकडे, या प्राधान्यक्रमांच्या बाजूने काही उपक्रम/प्रकल्प सोडणे शक्य आहे. दुसऱ्या शब्दांत, तुम्हाला "अतिरिक्त" सर्वकाही त्याग करावे लागेल. आयुष्यात जास्तीत जास्त तीन मुख्य क्रिया असाव्यात असे कुठेतरी ऐकले होते. मग तुम्ही ते उच्च गुणवत्तेवर करू शकाल. आणि अतिरिक्त प्रकल्प/दिशा फक्त ओव्हरलोड होऊ लागतील. परंतु हे सर्व बहुधा व्यक्तिनिष्ठ आणि वैयक्तिक आहे.

एक निश्चित सुवर्ण नियम आहे: कधीही 0% दिवस नाही! मी एका इंडी डेव्हलपरच्या लेखात याबद्दल शिकलो. तुम्ही एखाद्या प्रोजेक्टवर काम करत असाल तर त्याबद्दल रोज काहीतरी करा. आणि तुम्ही किती करता याने काही फरक पडत नाही. एक शब्द किंवा कोडची एक ओळ लिहा, एक ट्यूटोरियल व्हिडिओ पहा किंवा बोर्डमध्ये एक खिळा हातोडा - फक्त काहीतरी करा. सर्वात कठीण गोष्ट म्हणजे सुरुवात करणे. एकदा आपण प्रारंभ केल्यावर, आपण कदाचित आपल्या इच्छेपेक्षा थोडे अधिक करू शकाल. अशा प्रकारे तुम्ही तुमच्या ध्येयाकडे सतत वाटचाल कराल आणि माझ्यावर विश्वास ठेवा, खूप लवकर. शेवटी, सर्व गोष्टींमध्ये मुख्य अडथळा म्हणजे विलंब.

आणि हे लक्षात ठेवणे महत्वाचे आहे की आपण 5, 10, 15 मिनिटांच्या विनामूल्य "भूसा" ला कमी लेखू नये आणि दुर्लक्ष करू नये, एक किंवा दोन तास टिकणार्‍या काही मोठ्या "लॉग" ची प्रतीक्षा करा. तुम्ही रांगेत उभे आहात का? आपल्या प्रकल्पासाठी काहीतरी विचार करा. एस्केलेटर घेत आहात? नोटपॅडमध्ये काहीतरी लिहा. तुम्ही बसने प्रवास करत आहात का? छान, काही लेख वाचा. प्रत्येक संधीचा फायदा घ्या. YouTube वर मांजरी आणि कुत्री पाहणे थांबवा! तुमचा मेंदू दूषित करू नका!

आणि एक शेवटची गोष्ट. हा लेख वाचल्यानंतर, तुम्हाला गेम इंजिन न वापरता गेम तयार करण्याची कल्पना आवडली असेल, तर केसी मुराटोरी हे नाव लक्षात ठेवा. या माणसाकडे आहे वेबसाइट. "पहा -> मागील भाग" विभागात तुम्हाला सुरवातीपासून एक व्यावसायिक गेम तयार करण्यावरील अद्भुत विनामूल्य व्हिडिओ ट्युटोरियल्स मिळतील. Windows धड्यांसाठी पाच Intro to C मध्ये तुम्ही विद्यापीठाच्या पाच वर्षांच्या अभ्यासापेक्षा जास्त शिकू शकाल (कोणीतरी व्हिडिओखाली टिप्पण्यांमध्ये याबद्दल लिहिले आहे).

केसी हे देखील स्पष्ट करतात की तुमचे स्वतःचे गेम इंजिन विकसित करून, तुम्हाला कोणत्याही विद्यमान इंजिनची चांगली समज असेल. फ्रेमवर्कच्या जगात जिथे प्रत्येकजण स्वयंचलित करण्याचा प्रयत्न करत आहे, तुम्ही वापरण्याऐवजी तयार करायला शिका. संगणकाचे स्वरूप तुम्हाला समजते. आणि तुम्ही अधिक हुशार आणि प्रौढ प्रोग्रामर देखील व्हाल - एक प्रो.

तुमच्या निवडलेल्या मार्गासाठी शुभेच्छा! आणि जग अधिक व्यावसायिक बनवूया.

लेखक: ग्रँकिन आंद्रे, DevOps

स्त्रोत: www.habr.com