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