तत्काल जीयूआई - ये या नी? [बन्द है]

Question

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

अब मैं कंप्यूटर गेम लिख रहा हूं :)। मैंने अब तक एक जीयूआई के साथ काम किया: मियागी (अच्छी तरह से ज्ञात नहीं है, लेकिन मूल रूप से सभी अन्य प्रणालियों के समान ही आइडिया है।)

यह बहुत घटिया था।

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

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

मुझे संक्षेप में बताएं कि मुझे "बनाए रखने" और "तत्काल" से क्या मतलब है:

रिटायर्ड GUI: एक अलग इनिशियलाइज़ेशन चरण में, आप "GUI कंट्रोल" जैसे Labels, Buttons, TextBoxes आदि बनाते हैं और स्क्रीन पर रखने के कुछ वर्णनात्मक (या प्रोग्रामेटिक) तरीके का उपयोग करते हैं - सब कुछ होने से पहले। नियंत्रण X, Y स्थान, आकार, सीमा, बाल नियंत्रण, लेबल पाठ, चित्र और इसी तरह की स्मृति में अपने स्वयं के अधिकांश राज्य रखते हैं। आप घटनाओं से अवगत होने और GUI नियंत्रण में डेटा को अपडेट करने के लिए कॉलबैक और श्रोताओं को जोड़ सकते हैं।

तत्काल GUI: GUI लाइब्रेरी में एक-शॉट "RenderButton", "RenderLabel", "RenderTextBox" शामिल हैं ... फ़ंक्शंस (संपादित करें: Render द्वारा भ्रमित न होंउपसर्ग। ये कार्य मतदान उपयोगकर्ता इनपुट जैसे नियंत्रण के पीछे तर्क भी करते हैं, वर्ण सम्मिलित करते हैं, जब उपयोगकर्ता एक कुंजी वगैरह रखते हैं तो चरित्र-रिपीट-स्पीड को हैंडल करते हैं ...) जिसे आप "तुरंत" कॉल करके एक नियंत्रण प्रदान कर सकते हैं (doesn ') टी को तुरंत जीपीयू के लिए लिखा जाना चाहिए। आमतौर पर इसकी वर्तमान फ्रेम के लिए याद किया जाता है और बाद में एप्रॉपिएट बैचों में सॉर्ट किया जाता है)। पुस्तकालय इन के लिए कोई "राज्य" नहीं रखता है। यदि आप एक बटन छिपाना चाहते हैं ... बस रेंडरबटन फ़ंक्शन को कॉल न करें। सभी RenderXXX फ़ंक्शंस, जिसमें बटन या चेकबॉक्स की तरह उपयोगकर्ता इंटरैक्शन होता है, में रिटर्न मान होते हैं जो इंगित करते हैं कि जैसे उपयोगकर्ता ने बटन में क्लिक किया है। तो आपका "RenderGUI" फ़ंक्शन एक बड़ा अगर / अन्यथा फ़ंक्शन की तरह दिखता है, जहां आप अपने गेम स्टेट के आधार पर अपने RenderXXX फ़ंक्शंस को कॉल करते हैं या नहीं करते हैं और सभी डेटा अपडेट लॉजिक (जब एक बटन दबाया जाता है) प्रवाह में इंटरमेन्ग होता है। सभी डेटा स्टोरेज "बाहर" है और रेंडर कार्यों के लिए ऑन-डिमांड पारित किया गया है। (बेशक, आप बड़े कार्यों को कई लोगों में विभाजित करेंगे या गुई के भागों को समूहीकृत करने के लिए कुछ वर्ग सार का उपयोग करेंगे। हम 1980 की तरह कोड नहीं लिखते हैं, क्या हम;)

अब मैंने पाया कि यूनिटी 3 डी वास्तव में अपने अंतर्निहित जीयूआई सिस्टम में बहुत ही मूल दृष्टिकोण का उपयोग करता है। वहाँ शायद जीयूआई के एक जोड़े को इस दृष्टिकोण के साथ वहाँ भी हैं?

फिर भी .. जब चारों ओर देखते हैं, तो जीयूआई सिस्टम को बनाए रखने के लिए एक मजबूत पूर्वाग्रह प्रतीत होता है? यूनिटी 3 डी को छोड़कर कम से कम मुझे यह दृष्टिकोण नहीं मिला है और मूल आईएमजीयूआई समुदाय के बजाय लगता है .... शांत।

तो किसी ने दोनों विचारों के साथ काम किया है और कुछ मजबूत राय है?

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

Comments

इस प्रश्न की जाँच करें: gamedev.stackexchange.com/questions/3617/good-gui-for-opengl

— kaoD

लिंक के लिए धन्यवाद। मुझे लगता है कि आप Kylotan की टिप्पणी का उल्लेख कर रहे हैं । दिलचस्प ..;)

— इमी

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

— काइलोटन

यह शर्म की बात है कि ये सवाल बंद हो रहे हैं! ये उसी तरह की राय हैं जो मैं देख रहा हूं जब मेरे पास एक ही सवाल है।

— हराल्ड स्किरीच

Answer 1

अस्वीकार। मैं एक भयानक 'बनाए रखा मोड' जीयूआई पर और एक भयानक 'तत्काल मोड' जीयूआई पर भुगतान किया है gamedev काम किया है और हालांकि दोनों ने मुझे अपनी आँखें फाड़ करना चाहते हैं, बनाए रखा मोड दृष्टिकोण अभी भी स्पष्ट रूप से बेहतर एक है।

तत्काल मोड के डाउनसाइड कई हैं:

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

तत्काल मोड GUI लोन प्रोग्रामर के लिए लुभा रहे हैं जो एक त्वरित HUD सिस्टम चाहते हैं, और इस उद्देश्य के लिए वे महान हैं। किसी और चीज के लिए ... सिर्फ ना कहना।

Comments

@ImanmanuelScholz: क्या आपने माना है कि शायद बनाए गए GUI वास्तव में "उस बदसूरत" नहीं हैं?

— निकोल बोलस

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

— काइलोतन

इस तथ्य को जोड़ें कि अनुरक्षित मोड GUIs (MVC, MVP, और MVVM 3 लोकप्रिय दृष्टिकोण हैं) बनाने के लिए कोई सहमति नहीं है या इसे कैसे करना है (डेटा से? कोड से?) या इनपुट व्यवहार कैसे संलग्न करें? इनलाइन स्क्रिप्ट, वेब के साथ? नामांकित संकेतों / स्लॉट? IMGUIs के साथ के रूप में जगह परिणाम?) और मानकीकरण की कमी ने GUIs के लिए वन ट्रू वे के विकास में बाधा उत्पन्न की है।

— काइलोटन

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

— द्रेता

@dreta: कलाकार विन्यास के बारे में मेरी बात यह है कि ऐसी चीजें हैं जो संपादक के माध्यम से बदलने के लिए पूरी तरह से अव्यावहारिक हैं, मूल रूप से इसके ऊपर अपनी स्वयं की बनाए रखी गई मोड परत को लिखे बिना (उदाहरण के लिए जब एक बटन क्लिक किया जाता है, तो क्या करना है या फिर से आदेश देना है। तत्व)। IMGUI बहुत ही सरल और तुच्छ दृश्यों के लिए अच्छा काम करता है, इससे ज्यादा कुछ नहीं।

— काइलोटन

Answer 2

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

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

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

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

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

किसी भी मामले में, अच्छी किस्मत!

Comments

"कोई अंतर्निहित कारण नहीं है कि IMGUI पुस्तकालयों को जटिलता से परेशान होना चाहिए या ग्लोबल्स से अटे रहना चाहिए या प्रस्तुति के साथ तर्क का मिश्रण करना चाहिए।" यह देखना बहुत कठिन है कि सामान्य IMGUI बटन कॉल कैसे करता है, उदाहरण के लिए। "यदि बटन (x, y) तो एक्शन" को प्रस्तुति के साथ मिश्रण तर्क नहीं कहा जा सकता है। यदि आप कॉल को विवरण प्रदान करने में पास नहीं होते हैं, तो आप इसे (वैश्विक या स्थिर को छोड़कर) स्थिति या शैली नहीं दे सकते हैं, और यदि आप बटन लॉजिक को तुरंत संसाधित नहीं करते हैं, तो यह वास्तव में एक तत्काल मोड GUI नहीं है। क्या आप समझाने के लिए एक उदाहरण दे सकते हैं?

— काइलोटन

साझा स्थिति की मात्रा के कारण OpenGL संदर्भ बग का एक बड़ा स्रोत है, और फिर भी उस API के साथ भी कदम पिछले कुछ वर्षों से बरकरार मोड की ओर रहा है क्योंकि तत्काल मोड ने न तो लचीलेपन की पेशकश की और न ही प्रदर्शन की आवश्यकता है।

— काइलोटन

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

— काइलोटन

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

— टॉम

सीएसएस स्टाइलशीट स्टेटिक हैं; बल्कि OpenGL संदर्भों से अलग जो अत्यंत गतिशील हैं!

— काइलोटन

Answer 3

GUI लाइब्रेरी में एक-शॉट "RenderButton", "RenderLabel", "RenderTextBox" शामिल हैं ... फ़ंक्शंस जिन्हें आप "तुरंत" कॉल कर सकते हैं एक नियंत्रण प्रदान करते हैं (तुरंत GPU पर नहीं लिखा जाना चाहिए।) आमतौर पर याद किया जाता है। वर्तमान फ्रेम के लिए और बाद में एप्पीरिएट बैचों में सॉर्ट किया गया)।

मैं यह कहना चाहूंगा कि यह GUI लाइब्रेरी नहीं है। यह प्रतिपादन कार्यों का एक समूह मात्र है।

GUI का प्रतिपादन GUI बनाने का सबसे आसान हिस्सा है। उदाहरण के लिए एक टेक्स्ट बॉक्स लें। मैं सबसे आसान संभव मामला मानने जा रहा हूं: एक सरल सिंगल-लाइन एंट्री टेक्स्ट बॉक्स।

RenderTextBoxबस एक पाठ बॉक्स आकर्षित करेगा। यह कुछ सरल पाठ माप करेगा और स्क्रीन पर ग्लिफ़ को आकर्षित करेगा। यह नहीं होगा

• पता लगाएँ कि उपयोगकर्ता ने नियंत्रण में माउस को क्लिक किया है और कर्सर को स्ट्रिंग में उचित स्थान पर ले जाता है।
• पता लगाएँ कि उपयोगकर्ता ने नियंत्रण में माउस को डबल-क्लिक किया और पाठ का एक ब्लॉक चुनें।
• पता लगाएँ कि उपयोगकर्ता ने "होम" कुंजी दबाया और कर्सर को पाठ के सामने ले जाएं।
• पता लगाएँ कि उपयोगकर्ता ने एक वैध कुंजी दबाया और तदनुसार स्ट्रिंग को संशोधित किया। यदि पाठ का चयन किया गया था, तो चयनित भाग को सम्मिलित पाठ से बदल दिया जाएगा।

मैं चलता रह सकता हूं, लेकिन मुझे लगता है कि मेरी बात स्पष्ट है। यदि आप RenderTextBoxएक टेक्स्ट बॉक्स खींचने के लिए उपयोग करना चाहते हैं , तो आपको एक स्थिर, गैर-कार्यात्मक टेक्स्ट बॉक्स मिलेगा। किसी भी वास्तविक कार्यक्षमता को आपके द्वारा लागू किया जाना चाहिए।

पाठ माप करना और ग्लिफ़ खींचना? यह GUI कार्य का आसान हिस्सा है। GUI का अर्थ "ग्राफिकल यूजर इंटरफेस" है। अंतिम दो शब्द, जहां आप उपयोगकर्ता से इनपुट लेते हैं और इसके साथ कुछ करते हैं, कठिन हिस्सा हैं।

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

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

मूल रूप से, आपको TextBoxWindowकक्षा की आवश्यकता होगी ।

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

खैर, यह इस बात पर निर्भर करता है कि नियंत्रण क्या सक्रिय है। यदि समूह नियंत्रणों में से एक सक्रिय है (हाल ही में क्लिक किया गया था), तो यह अगले समूह में चला जाता है। यदि इसके बजाय समूह के भीतर कोई नियंत्रण सक्रिय है, तो यह उस समूह में अगले नियंत्रण पर चला जाता है। इस तरह सिस्टम काम करने का इरादा रखता है।

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

यह एक अनुरक्षित GUI की तरह अधिक से अधिक लगता है, है ना? फर्क सिर्फ इतना है कि ... आप कड़ी मेहनत कर रहे हैं। किसी व्यक्ति के GUI का उपयोग करना कम काम करने का एक तरीका माना जाता है। लेकिन GUI को प्रतिक्रिया देने के लिए जो प्रयास किया जाता है, क्योंकि उपयोगकर्ता को उम्मीद है कि यह गैर-तुच्छ है।

याद रखें: UI आपके लिए नहीं है, यह आपके उपयोगकर्ताओं के लिए है । यह खिलाड़ी के लिए है। जैसा उन्हें उम्मीद है, वैसा ही व्यवहार करना चाहिए। और अगर ऐसा नहीं है, तो आप असफल रहे हैं।

उपयोगकर्ता इंटरफ़ेस को आमतौर पर ऑटो-लेआउट होने की आवश्यकता नहीं होती है या उनके पास रेसिजेबल विंडो ऑन-द-फ्लाई है।

यह एक सीमित और सीमित सोच है।

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

आपकी इस तरह की सोच ग्रैटूटियस स्पेस बैटल की समस्या की ओर ले जाती है।

यदि आपने उस गेम को कभी नहीं खेला है, तो यह एक सस्ता, इंडी और बहुत जीयूआई-भारी गेम है। वास्तविक गेमप्ले सभी GUI में किया जाता है (यह एक "यूनिटों को सेटअप करता है और उन्हें" गेम के प्रकार से लड़ने के लिए देखता है)। समस्या?

जीयूआई निष्कर्ष निकाला नहीं जा सकता है!

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

दी गई, जीएसबी एक जीयूआई-आधारित खेल है, इसलिए यह उनके लिए बिल्कुल अक्षम्य है। एक GUI- लाइट गेम शायद इससे दूर हो जाए।

कभी भी यह न समझें कि आपका उपयोगकर्ता उनके खेल को ठीक वैसे ही देख रहा है जैसे आप हैं। ऐसा करना मूर्खता है।

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

इसलिए मैं कहूंगा कि इस विषय पर आपकी सोच बहुत ही कम है। आप करते हैं कि सामान की जरूरत है। आप की जरूरत है जो GUI प्रदान करते हैं। ओह, आपको किसी विशेष जीयूआई प्रणाली द्वारा प्रदान की जाने वाली सभी चीजों की आवश्यकता नहीं हो सकती है। लेकिन आपको इसकी कुछ जरूरत है।

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

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

Comments

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

— इमी

@ इमानुएल: "वैसे: एक टेक्स्टबॉक्स की आपकी चित्रित कार्यक्षमता रेंडरटेक्स्टबॉक्स कक्षा के भीतर लागू की गई (और, जैसे कि यूनिटीग्यूई.टेक्फील्ड में हो सकती है)।" आपने कहा कि RenderTextBoxएक समारोह था , एक वर्ग नहीं। तो "तत्काल मोड" और "बनाए रखा मोड" के बीच का विभाजन ऐसा प्रतीत होता है जहां डेटा संग्रहीत किया जाता है, जो इसे प्रबंधित नहीं कर रहा है। यदि हां, तो आपको अपने प्रश्न में उस अंतर को और अधिक स्पष्ट करने की आवश्यकता है, क्योंकि यह बताता है कि "तत्काल मोड जीयूआई" बस स्क्रीन पर सामान खींचता है। यह इनपुट नहीं मिल सकता है (क्योंकि इसके लिए लगातार राज्य की आवश्यकता होगी) और ऐसे। तो कौन सा है?

— निकोल बोल्स

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

— निकोल बोल्स

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

— इमी

@ImmanuelScholz: "मैंने निश्चित रूप से इस बात का वर्णन नहीं किया है कि" तत्काल GUI "में यहाँ क्या विवरण है" तो आपका प्रश्न अधूरा है। वास्तव में, यह बल्कि भ्रामक है, क्योंकि "तत्काल मोड" का मतलब राज्य की कमी है। शब्द "बरकरार" इस ​​तथ्य से आता है कि इसमें राज्य है। तो अगर एक "तत्काल मोड जीयूआई" राज्य को बनाए रखता है ... यह तत्काल मोड नहीं है।

— निकोल बोल

Answer 4

कुछ समय पहले IMGUI ने भी मेरी रुचि को पकड़ा था, एक परीक्षण के रूप में मैंने तकनीकों के साथ खुद को परिचित करने के लिए कुछ ट्यूटोरियल लिखे ( यहां शुरू करें यदि आप रुचि रखते हैं, लेकिन यह सी # / एक्सएनए + मूल 'ट्यूटोरियल' से अधिक नहीं है ) ।

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

अंत में मुझे लगा कि GUI की तत्कालता ने GUI को डेटा से अलग करना कठिन बना दिया है और कई बार मैंने कुछ राज्य शुरू करके, IMGUI की शान को तोड़ते हुए चीजों को और अधिक डिकम्प्लस करने की कोशिश की। मुझे यह भी नहीं लगता कि GUIs के लिए कोड लिखना IMGUIs के लिए कोड लिखने से अधिक काम है और मुझे लगता है कि बरकरार GUIs को निकाल दिया जा सकता है और इसके बारे में भूल गए, और मुझे वास्तव में इवेंट पसंद हैं :)।

हालाँकि, हर बार किसी ने मेरे अंदर IMGUI का उल्लेख किया है कि वह फिर से कोशिश करना चाहता है, और इसे सही तरीके से प्राप्त करने के लिए कठिन प्रयास करना चाहता है, क्योंकि वास्तव में वहाँ कुछ लालित्य है, मुझे सिर्फ 100% यकीन नहीं है अगर यह हमेशा आपके काम को आसान बना देगा। मैं कहूंगा कि इसे आज़माएं, शायद जैसा मैंने किया और कुछ ट्यूटोरियल लिखने की कोशिश की (मुझे नई तकनीकों को सीखने का सबसे अच्छा तरीका है दूसरों को समझाकर)।

Answer 5

मैंने यूनिटी 3 डी जीयूआई सिस्टम के साथ बहुत काम किया, जो आपके बताए अनुसार ही काम करता है। और मुझे कहना होगा, मैं इसे एक जुनून के साथ नफरत करता हूं।

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

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

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

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

मैं यह नहीं कह सकता कि "तत्काल" मोड निश्चित रूप से "बनाए रखा" से भी बदतर है, लेकिन मैं निश्चित रूप से "बनाए" मोड में बहुत बेहतर काम कर रहा हूं।

Comments

हां, मैंने एकता GUI के साथ इन समस्याओं में से हर एक का अनुभव किया है, और परिणामस्वरूप इसे नफरत करता हूं। यह त्वरित स्थैतिक HUDs के लिए बहुत अच्छा है लेकिन किसी और चीज़ के लिए एक वास्तविक परेशानी है।

— काइलोटन

Answer 6

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

• स्कीमा से GUI लोड हो रहा है

शायद पहले यह लगता है कि कलाकारों के पास IMGUI के साथ बहुत अधिक लचीलापन नहीं है, यह एक xml या JSON स्कीमा से GUI लेआउट लोड करने के साथ हल या बेहतर है।

• मेनू लेयर ड्रा कॉल्स

इस समस्या को हल करने के साथ हल किया जाता है, आपको यूआई प्रबंधक वर्ग बनाना चाहिए जो ड्रॉ के क्रम को क्रमबद्ध करता है, मैंने इस समस्या को C # XNA में जंगम, क्लिक-सक्षम पैनलों के साथ हल किया जो एक दूसरे के ऊपर आकर्षित होते हैं। अगर पूछा जाए तो मैं छद्म कोड पोस्ट कर सकता हूं।

• सूची बक्से

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

• जीयूआई से डेटा को अलग करना

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

• एसडीके से जीयूआई

यह एसडीके के कोड की सीमा और कार्यक्षमता है, न कि आपकी। मुझे लगता है कि एसडीके यूआई (हैमर, यूनिटी, यूडीके) वैसे भी सीखने के लिए लगभग एक नई भाषा है। वास्तव में वे मेरे लिए Windows.Forms के समान हैं, दोनों को व्यापक संभावना के लिए स्थापित किया गया है और जटिलता में कुछ अतिरिक्त वजन है।

और अंत में इसे देखें> http://mollyrocket.com/861

Answer 7

उपयोगकर्ता इंटरफ़ेस को आमतौर पर ऑटो-लेआउट होने की आवश्यकता नहीं होती है या उनके पास रेसिजेबल विंडो ऑन-द-फ्लाई है। इसके बजाय, उन्हें हमेशा-बदलते डेटा (जैसे दुनिया में 3 डी मॉडल) के साथ बहुत कुशलता से बातचीत करने की आवश्यकता होती है

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

मैं तत्काल जीयूआई के साथ n 'ड्रॉप को खींचने का एक तरीका नहीं सोच सकता हूं जो बहुत अधिक करतब या उपयोगकर्ता राज्य की बचत नहीं करता है जैसे कि Z बफर को अस्थायी रूप से बदलना और एक क्लिक करने के लिए हुई क्लिक पर शासन करने के लिए समय की जानकारी संग्रहीत करना। बिट।

लेकिन एक डिजाइन के नजरिए से मुझे अपने GUI इवेंट्स के बिना दुनिया की कल्पना करने में परेशानी होती है। इसके अलावा एक तत्काल जीयूआई OOP के साथ संगत नहीं है जो आपको प्रक्रियात्मक प्रोग्रामिंग का सहारा लेने के लिए मजबूर करता है।

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

Comments

मैं आपसे पूछना चाहता हूं: क्या आपकी राय वास्तविक वास्तविक दुनिया के अनुभव से या सैद्धांतिक सोच से दोनों प्रणालियों को देखकर आती है? उम्म .. यह इरादा से अधिक कठोर लगता है, क्षमा करें .. मेरा मतलब है: मैं एक सैद्धांतिक पहलू से आपकी राय और मूल्यांकन साझा करता हूं । IMGUI जैसी प्रणालियां संभवतः सबसे कम OOPish कोड (यदि यह एक चिंता का विषय है) की ओर ले जाती हैं, तो उन्हें उन नियंत्रणों के साथ समस्या होती है जिनके लिए कुछ राज्य की आवश्यकता होती है और इसी तरह। इसकी बस ... सामान्य जीयूआई सिस्टम भी पहले से ही बहुत बड़े और जटिल हैं, इसलिए आपको जोड़ने के लिए बहुत जटिलता है जब तक आप इन सिस्टमों के करीब नहीं आते हैं ..

— Imi

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

— काइलोटन

@Immanuel Scholz मैं स्वीकार करता हूं कि मुझे बनाए रखने वाले UI के साथ बहुत अधिक अनुभव है; ओएसएस परियोजनाओं के रूप में एक को बनाए रखना और उनके साथ काम करना हालांकि मेरे वाहक (जो कि वास्तव में बहुत युवा हैं)। हालाँकि, मैंने Unity3D के UI सिस्टम का उपयोग किया है और जब मैंने XNA में स्थानांतरित किया तो इसे डुप्लिकेट कर दिया। मेरे द्वारा बनाए रखा UI विकसित किया गया था क्योंकि मैं समान कार्यक्षमता प्राप्त करने के लिए प्रोजेक्ट से प्रोजेक्ट तक एक ही हैक चिपकाते हुए थक गया।

— क्लासिकटाउन

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

— इमी

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

— काइलोतन