अलावर इंजन। भाग दो क्रॉस-प्लेटफॉर्म गेम इंजन की विशेषताएं

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

• खेल की तीन-स्तरीय संरचना;
• 2 डी ग्राफिक्स के एकीकृत उपतंत्र;
• स्रोत कोड का सार्वभौमिक संगठन।

अलावर इंजन का सॉफ्टवेयर हिस्सा 2 पुस्तकालयों पर आधारित है: एसएफ (स्टारगेज फ्रेमवर्क लाइब्रेरी) और क्यूई (स्टारगेज क्वेस्ट इंजन लाइब्रेरी)। एसएफ पूरे सिस्टम का मूल है और इसमें गेम का लगभग पूरा प्लेटफॉर्म-विशिष्ट कार्यान्वयन है। इसके अलावा, पुस्तकालय में सभी प्लेटफार्मों के लिए एक सामान्य स्रोत शाखा है। वर्तमान में एसएफ छह प्लेटफार्मों के तहत काम करता है: विंडोज (एक्सपी, विस्टा, विंडोज 7), मैक ओएस एक्स, आईओएस, एंड्रॉइड, PS3 और विंडोज 8 (विकास के तहत)।

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

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



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

#if defined(__SF_WINDOWS) #include <Objbase.h> #elif defined(__SF_MAC) || defined(__SF_IPHONE) #include <uuid/uuid.h> #endif 

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

निम्न मॉड्यूल उच्च स्तर पर स्थित हैं:

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

अगले स्तर पर 2 डी ग्राफिक्स, ऑडियो और वीडियो के अपने सबसिस्टम हैं, जो सक्रिय रूप से पिछले स्तर और सिस्टम एकीकरण मॉड्यूल के दोनों सबसिस्टम का उपयोग करते हैं:

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

उपरोक्त उपप्रणालियों के अलावा, कई मध्यवर्ती को अलग किया जा सकता है:

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

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

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

 class CSystemIntegration { public: CSystemIntegration(); virtual ~CSystemIntegration(); virtual bool Init() = 0; virtual void Run() = 0; virtual void Stop() = 0; virtual void Shutdown() = 0; virtual bool EnsureSingleInstance() = 0; virtual bool ChangeScreenMode(bool _fullscreen, bool _32bpp, size_t _width, size_t _height) = 0; virtual bool GetOriginalDesktopDimentions(size_t &_width, size_t &_height) = 0; virtual EventInformation &GetCurrentEvent() = 0; virtual void DefaultWindowProc() = 0; virtual void GetWindowClientRect(misc::IntRect &_rc) = 0; virtual void AdjustClientRectToWindow(misc::IntRect &_rc) = 0; virtual void GetDesktopWindowedSpace(misc::IntRect &_rc) = 0; virtual void ScreenCoordsIntoClient(misc::IntVector& _pos) = 0; virtual void ClientCoordsIntoScreen(misc::IntVector& _pos) = 0; virtual void EnableSystemGestureRecognizer(int _recognizerType, bool _enable) {}; virtual void SetMouseCursorPos(const misc::IntVector& _pos) = 0; virtual void GetMouseCursorPos(misc::IntVector& _pos) = 0; virtual void SetSysCursor(gui::SysCursor _cursor, bool _show_now = true) = 0; virtual gui::SysCursor GetSysCursor() = 0; virtual void ShowSysCursor(bool _show = true) = 0; virtual bool IsSysCursorShown() = 0; protected: void AppUpdate(); void AppDraw(); void ActivateApp(bool _activate = true); void MinimizeApp(bool _minimized = true); }; 

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

 void CStandaloneApplicationWindows::MessageCycle() { MSG msg; while (!m_EndModal) { while (!m_Stop && PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) { TranslateMessage(&msg); DispatchMessage(&msg); } if (m_Stop) break; AppUpdate(); AppDraw(); } m_EndModal = false; } void CStandaloneApplicationPS3::MessageCycle() { while (!m_EndModal) { if (g_quitRequested == false) { cellSysutilCheckCallback(); if ( cellPadUtilUpdate() ) { input::PointerApp::main(); _updatePad(); } if (m_Stop) break; AppUpdate(); AppDraw(); }else break; } m_EndModal = false; } 

इस प्रकार, एप्लिकेशन लॉन्च करने के लिए, गेम प्रोग्रामर को बस एक एंट्री पॉइंट (कुछ प्लेटफार्मों पर इसे एसएफ से बाहर ले जाया जाता है) को व्यवस्थित करने की आवश्यकता है और निम्नलिखित कोड (आईओएस के लिए उदाहरण) लिखें:

 bool SFIPhoneMain() { static game::CGameApplication app; if (!app.Init()) return false; else return true; } void StartLoadGame() { sf::core::CApplication * app = sf::core::g_Application; app->SetMainWindow(new game::CMainMenuWindow()); app->Run(); } 

जहाँ CGameApplication CApplication का वारिस है, और CMainMenuWindow, खेल के कोड में प्रोग्रामर द्वारा निर्धारित CWindow का वारिस है। कोड बताता है कि दो-स्तरीय सॉफ़्टवेयर अमूर्त का यह मॉडल आपको एप्लिकेशन को व्यवस्थित करने की न्यूनतम लागत को प्राप्त करने की अनुमति देता है, और इसके परिणामस्वरूप, गेम को किसी अन्य प्लेटफ़ॉर्म पर स्थानांतरित करने से जुड़ा न्यूनतम सिरदर्द। और कई अनुप्रयोगों के संदर्भ में, यह आपको आवेदन के प्रवेश बिंदु को समाधानों के एक अलग पुस्तकालय में उजागर करने की अनुमति देता है।

एकीकृत 2 डी-ग्राफिक्स सबसिस्टम आपको विभिन्न रेंडर-मशीनों, जैसे कि डी 3 डी 9, डी 3 डी 11, ओपनजीएल ईएस (2.0 सहित), जीसीएम के साथ प्लेटफार्मों के लिए बिना किसी समस्या के स्टारगेज फ्रेमवर्क को पोर्ट करने की अनुमति देता है। यह बहुमुखी प्रतिभा CRenderer और CRenderDevice वर्गों के लिए धन्यवाद प्राप्त की है। CRenderer वर्ग एक शीर्ष-स्तरीय API को लागू करता है - 2D ग्राफिक्स के साथ काम करने के तरीकों का एक सेट जो पूरी तरह से 2K खेलों के लिए आवश्यकताओं को कवर करता है। उदाहरण के लिए:

•  void RenderString(const CFont* _font, const SF_WSTRING& _string, float _x, float _y, int _justify_h = -1, int _justify_v = -1, float _scale=1.f, const Color& _color=0xffffffff, const Color& _bk_color=0) –  ; 

•  void RenderTexture(const CTexture* _texture, const misc::FloatRect& _dest, size_t _frame = -1, const Color& _color = 0xffffffffu) –  ; 

•  void PushState() –   ; 

•  void PopState() –   ; 

•  void ApplyMatrix(const misc::FloatMatrix& _matrix) –   . 

यह रेंडर मशीन के स्टेट स्टैक को भी स्टोर करता है: ब्लेंड कलर, ट्रांसफॉर्मेशन मैट्रीस, करंट टेक्सचर और ब्लेंड मोड। संपूर्ण प्लेटफ़ॉर्म-विशिष्ट कार्यान्वयन CRenderDevice वर्गों (निचले स्तर के API) में छिपा हुआ है, जिसमें समान इंटरफ़ेस है:

 class CRenderDevice { public: CRenderDevice(); bool Init(); void Reset(); bool BeginScene(); bool EndScene(); void Render(RenderPrimitives _primitive, const RENDERVERTEX* const _verts, size_t _verts_count); void Render(RenderPrimitives _primitive, const void* const _verts, size_t _verts_count, DWORD _verts_fvf, DWORD _vertex_size); void Flush(); void SetTexture(DWORD _stage, IDirect3DTexture9* _texture); void SetTextureStageState(DWORD _stage, DWORD _state, DWORD _val); DWORD GetTextureStageState(DWORD _stage, DWORD _state) const; void SetBlendMode(BlendModes _blend_mode); void SetPixelShader(IDirect3DPixelShader9* _shader); void SetRenderTarget(IDirect3DTexture9* _texture); bool GetAvailableResolutions(std::list<Resolution> &_container); bool ClearRenderTarget(const Color& _color = 0); void ToggleHeavyRenderProfile(); private: … }; 

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

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

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

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