परिचय

हाल ही में, क्लासिक खेलों के बारे में कहानियों का GDC में अच्छा स्वागत हुआ, लेकिन उनके विकास के औजारों के बारे में बहुत कम कहानियाँ थीं। लेखों की इस श्रृंखला में, हम उन लोगों का साक्षात्कार करके इस अंतर को भरने का प्रयास करेंगे, जिन्होंने खेल विकास के साधनों के इतिहास में महत्वपूर्ण भूमिका निभाई है।

श्रृंखला के पहले दो हिस्सों में, हमने जॉन रोमेरो (टीएचडी संपादक के बारे में) और टिम स्वीनी (अवास्तविक संपादक के बारे में) के साथ बात की ।

तीसरा लेख लिखते समय, मुझे क्रिस नोर्डन के साथ बात करने के लिए सम्मानित किया गया था, जो उन्होंने ड्यूस एक्स नामक एफपीएस / आरपीजी हाइब्रिड के लिए विकसित किए थे । मैंने जीडीसी 2018 में सैन फ्रांसिस्को में क्रिस के साथ बातचीत की।

आयन तूफान से पहले: उत्पत्ति और खोज ग्लास

डेविड लाइटबोन: आप इओन स्टॉर्म पर डेस पूर्व में कैसे शुरू हुए?

क्रिस नॉर्डेन: 1994 में, मैंने ऑस्टिन में एक ओरिजिनल प्रोग्रामर के रूप में काम किया। मेरा पहला भुगतान किया गया प्रोजेक्ट जेन के कॉम्बैट सिमुलेशन द्वारा जेन के कॉम्बैट सिम्यूशंस AD-64D लॉन्गबो था। यह मूल रूप से एक आर्केड गेम था जिसे चॉपर असॉल्ट कहा जाता था। एंडी हॉलिस के साथ, मैंने दो साल तक इस पर काम किया।



खेल की रिहाई के बाद, आखिरी चीज जो मैं करना चाहता हूं वह एक और सैन्य सिम्युलेटर करना है, क्योंकि मुझे पूरी तरह से सब कुछ सैन्य पसंद नहीं है। समय-समय पर, मैंने वॉरेन स्पेक्टर से बात की, जिन्होंने ओरिजिन में भी काम किया था। उन्हें वास्तव में प्लॉट रोल-प्लेइंग गेम्स पसंद थे। मैंने अपने आप से सोचा: "मुझे भी ये खेल पसंद हैं, मैं कुछ इस तरह से काम करना चाहता हूँ!"

1996 में, वॉरेन ने मूल से इस्तीफा दे दिया और ऑस्टिन में लुकिंग ग्लास स्टूडियो के प्रमुख बन गए, जिसका अस्तित्व तब कोई नहीं जानता था। इस स्टूडियो ने मैक गेम्स के लिए पोर्ट बनाए, जैसे लिंक्स 386 प्रो । वह ब्रिटिश ओपन चैम्पियनशिप गोल्फ नामक अपना स्वयं का गोल्फ खेल विकसित करने की प्रक्रिया में थी।

मूल अभी भी अल्टिमा ऑनलाइन विकसित कर रहा था। वह मुल्तिमा का उपनाम था, और लगता है कि उसने अल्टिमा VII इंजन का इस्तेमाल किया था। मैंने उसके साथ थोड़ा प्रयोग किया जब तक मैंने ओरिजिन नहीं छोड़ा और लुकिंग ग्लास में वॉरेन से जुड़ गया।

[लेखक का ध्यान दें: ग्लास का मुख्य स्टूडियो बोस्टन के पास कैम्ब्रिज, मैसाचुसेट्स में था]

वॉरेन ने एक डिज़ाइन दस्तावेज़ लिखा, और कुछ समय के लिए हमने संक्षिप्त नाम AIR (ऑस्टिन इंटरनेट रोल-प्लेइंग से) के साथ एक भूमिका निभाने वाले खेल पर काम किया, जो कि एक ऑनलाइन प्रोजेक्ट माना जाता था। हम 3 डी में कुछ करना चाहते थे, क्योंकि 3 डी एक्सीलेटर बस दिखाई देने लगे थे। हमें वूडू 1 का एक प्रोटोटाइप मिला और उसने GLide पर एक छोटा सा इंजन लिखा।

हमने लुकिंग ग्लास के कैम्ब्रिज कार्यालय के साथ भागीदारी की। ब्रिटिश ओपन को जारी करने के बाद, मैंने मार्क लेब्लांक और डग चर्च को डार्क इंजन नामक एक चोर इंजन के साथ मदद की।

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

[लेखक का ध्यान दें: क्रिस खेलों के बारे में बिल्कुल सही है - अल्टिमा अंडरवर्ल्ड, सिस्टम शॉक और टेरा नोवा को आलोचकों द्वारा बहुत अच्छी तरह से प्राप्त किया गया था, वे 1990 के दशक के कुछ सबसे अच्छे खेल थे]

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


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

जॉन एक अद्भुत व्यक्ति हैं, मैंने उनके साथ मोनकेस्टोन गेम्स में काम किया, गेमबॉय एडवांस के लिए गेम विकसित करने में मदद की, लेकिन यह एक और कहानी है।

[लेखक का ध्यान दें: गेम को हाइपरस्पेस डिलीवरी बॉय कहा जाता था। गेमबॉय एडवांस के लिए, इसे मेजेस्को द्वारा प्रकाशित किया जाना था, लेकिन आखिरी समय में कंपनी ने इसे जारी करने से इनकार कर दिया।]

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

[लेखक का नोट: जाहिर है, यह वार्ता का एक बहुत ही सरल संस्करण है, लेकिन यह इस बात का अंदाजा देता है कि क्या हुआ था]

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

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

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

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

फिर हमने एक व्यवस्थापक को काम पर रखा, और वह यह है। और फिर हम ढाई साल के लिए नारकीय काम का सामना कर रहे थे! [हंसता]

असत्य और क्वेक इंजन के बीच चयन

JL: तो, जबकि बाकी इयोन स्टॉर्म ने क्वेक इंजन के साथ काम किया, आपने अवास्तविक को चुना। क्या आप बता सकते हैं कि आप इस निर्णय पर कैसे आए?

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

जेएल: टिम स्वीनी के साथ मेरे साक्षात्कार में, उन्होंने उस समय के क्वेक इंजन लाइसेंसिंग मॉडल को "एक चौथाई मिलियन डॉलर का xcopy ऑपरेशन" कहा।

KN: हाँ, बिल्कुल सही! मैं सहमत हूं, इंजन अद्भुत था। उस समय, उन्होंने एक क्रांति की, लेकिन हम जानते थे कि तीन इंजीनियरों की एक टीम इंजन को फिर से लिखने में सक्षम नहीं होगी और अपना खुद का लेखन नहीं कर सकती है। हमारे पास पर्याप्त समय नहीं होगा।

एक समय मैं अमीगा, C64 और पीसी डेमो सीन का बहुत बड़ा प्रशंसक था। मैंने अवास्तविक नाम से एक वीडियो गेम देखना शुरू किया और सोचा, "मेरे भगवान, हाँ आरजीबी प्रकाश और पूर्ण 3 डी है। इंजन MMX, SSE और 3DNow का उपयोग करता है। वह बहुत अच्छा लग रहा है! ” लेकिन हमें उसके बारे में विस्तृत जानकारी नहीं मिली, इसलिए हमने लंदन (कनाडा) में डिजिटल एक्सट्रीम की यात्रा की योजना बनाई। हम टिम और उनकी टीम के साथ मिले, उन्होंने हमें इंजन की सभी विशेषताओं को दिखाया। मैं कार्लो वोगेलसांग से भी मिला, जिनके साथ मैं अब सोनी के साथ काम करता हूं - वह Playstation विभाग में है। उन्होंने गैलेक्सी ऑडियो इंजन लिखा: लगभग सब कुछ असेंबलर में, एक सुपर-कट्टर आदमी। इंजन में फायर नामक एक कण प्रणाली थी। यह सब इंजन के अंदर था। मैंने सोचा, "दोस्तों, मुझे आपका तरीका पसंद है।"


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

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

ईमानदारी से, मुझे हमारे लाइसेंस समझौते का विवरण याद नहीं है। टिम को शायद याद है। मुझे याद नहीं है कि हमने कितना भुगतान किया है, लेकिन मैं इतना नहीं सोचता। "

JL: संभवत: उस समय क्वेक के लिए कितने आईडी का अनुरोध किया गया था?

KN: मुझे लगता है कि कम! और वह एक और प्लस था। उनका इंजन अपेक्षाकृत नया था, लेकिन हम पहले लाइसेंसधारी नहीं थे। सबसे पहले व्हील ऑफ टाइम और क्लिंगन ऑनर गार्ड थे।

[लेखक का नोट: आप अवास्तविक इंजन लाइसेंसिंग इतिहास के बारे में और अधिक पढ़ सकते हैं।

इसलिए, हमने इसे चुनने का फैसला किया। डेवलपर्स ने हमें स्रोत कोड दिया और कहा: "हम जितनी जल्दी हो सके हम आपका समर्थन करेंगे।" हम हमेशा आमने-सामने बात करते थे। यदि हमारे पास कोई प्रश्न था, तो हमने एक ईमेल भेजा: कोई तकनीकी सहायता प्रणाली नहीं थी।

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

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

JL: क्या आपने अवास्तविक टेक सलाहकार समूह के अन्य सदस्यों के साथ कुछ भी साझा किया है?

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

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

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

जेएल: क्या आप अवास्तविक संपादक के लिए किए गए परिवर्तनों के बारे में बात कर सकते हैं?

केएन: सिस्टम में से एक, जो किसी कारण से उस समय संपादक में नहीं था, कैमरा स्प्लिन का दृश्य है।

UnrealEd के पहले संस्करणों में, आपको कैमरा खींचना था और इसके पथ के बिंदुओं को सेट करना था। इस मामले में, अंक देखना संभव था, लेकिन उनके बीच के कनेक्शन नहीं, जिसने कैमरे का मार्ग निर्धारित किया।


JL: यह एक पॉइंट-टू-पॉइंट गेम की तरह है, लेकिन बिना संख्या के!

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

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

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


KN: मुझे लगता है कि इसका कारण यह था कि उनके कई स्तर के डिजाइनर सुपर तकनीकी थे और उनका उपयोग उनके सिर में ऐसी चीजों का अनुकरण करने के लिए किया जाता था। लेकिन वीडियो गेम उद्योग धीरे-धीरे परिपक्व हो गया, इसलिए विभिन्न स्तरों के अनुभव वाले लोगों के लिए उपकरण बनाना आवश्यक था। प्रत्येक डिजाइनर एक इंजीनियर नहीं था, और आज और भी अधिक! यह नियम के बजाय अपवाद था। इसलिए, उपकरण सुविधाजनक और सरल होना चाहिए।

वैसे, मुझे अभी भी नहीं पता है कि पाइन को डायनासोर के सिर से क्यों दर्शाया गया है।

जेएल: [हंसते हुए] हां, टिम और मैंने एक साक्षात्कार में इस पर चर्चा की! वैसे, क्या आपने किए गए किसी भी तकनीकी निर्णय पर पछतावा किया?

KN: हमने UnrealScript का बहुत अधिक उपयोग किया है। यह गलतियों में से एक था। अवास्तविक बहुत लचीला था, लेकिन बहुत धीमा। हमें UnrealScript की तुलना में देशी C में बहुत अधिक लिखने की आवश्यकता है।

सच उत्तर और नकली glitches

[लेखक का ध्यान दें: साक्षात्कार के इस चरण में, मैंने डेस पूर्व संपादक (अनार्य के लिए संस्करण), साथ ही साथ ड्यूस एक्स एसडीके प्रलेखन खोला]

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

केएन: अल संवाद संपादक में शामिल थे। स्कॉट ने AI पर काम किया। मैंने किया ... सब कुछ । [हंसते हुए] अन्य बातों के अलावा, मैं एक सहायक निर्देशक और प्रमुख प्रोग्रामर था। लेकिन हमने सब कुछ थोड़ा सा किया, क्योंकि शुरू से अंत तक पूरे प्रोजेक्ट में केवल तीन इंजीनियर थे।


क्रिस नोर्डेन (नीचे बाएं), एल यारसो (दाएं और ऊपर क्रिस, अपने हाथ पर एक घड़ी के साथ), रॉबर्ट व्हाइट (मध्य पंक्ति, केंद्र के दाईं ओर धूप का चश्मा पहने हुए), शेल्डन पचोटी (नीचे दाएं) और स्कॉट मार्टिन (दूसरे में) पंक्ति, अभी तक, धूप के चश्मे में भी)

डीएल: संपादक के लिए प्रलेखन में एक खंड है जो कहता है कि "अवास्तविक के पास ऊर्ध्वाधर सीढ़ियों के लिए मूल समर्थन नहीं है, लेकिन उन्हें डेस पूर्व में जोड़ा जाता है।" क्या आप हमें इसके बारे में और बता सकते हैं?

केएन: सीढ़ियां एक दिलचस्प कहानी है, क्योंकि हमें पूरे स्तर पर घूमना था, और उस समय के प्रथम-व्यक्ति निशानेबाजों में, पारंपरिक रूप से सीढ़ियों और चिकनी आरोही को इसके लिए इस्तेमाल किया गया था।

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

DL: मुझे लगता है कि डेवलपर्स सीक्वल में सफल रहे।

KN: हाँ, शायद।

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

जेएल: क्या आप अवास्तविक तकनीक सलाहकार समूह की बैठकों में टिम के साथ चर्चा किए गए विषयों में से एक में खड़ी सीढ़ियों की कमी थी?

केएन: जवाब देने के लिए, मुझे स्क्रिप्ट कोड को खोजने और देखने की जरूरत है कि क्या यह कहता है कि "भाड़ में जाओ, टिम!" [हंसते हुए], क्योंकि जब हमने क्रोध किया था, तब हमने वही किया था - बाद में इसे वापस बुलाने के लिए हमने टिप्पणी लिखी थी।

जब हमने सोचना शुरू किया कि ऊर्ध्वाधर सीढ़ी के लिए समर्थन कैसे जोड़ा जाए, तो हमने पहले तर्क दिया "चलो ज्यामिति बनाएं, और फिर शायद हम मुश्किल शारीरिक चालें कर सकते हैं ताकि खिलाड़ी सिंक्रनाइज़ किए गए एनीमेशन के साथ सलाखों पर पकड़ सके"। लेकिन बाद में हमने फैसला किया - ठीक है, यह सब नरक है, बहुत जटिल है।

जेएल: [हंसते हुए]

KN: हमें यह बहुत जल्दी करना था, क्योंकि डिजाइनरों ने इस यांत्रिकी को बनाने की मांग की थी।

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

आज के पाठक सोच सकते हैं: इंजन में सीढ़ियाँ क्यों नहीं थीं, क्या यह भी तर्कसंगत है? लेकिन उन दिनों कुछ भी नहीं था। ये बसपा के टुकड़े थे, हमारे पास स्थैतिक जाल नहीं थे, ऐसा कुछ नहीं था।


JL: UnrealEd में एक बहुत अच्छा सर्पिल सीढ़ी जनरेटर [हंसता है] था, लेकिन कोई खड़ी सीढ़ियाँ नहीं थीं।

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

JL: प्रलेखन में DeusExLevelInfo नामक एक वर्ग का वर्णन किया गया है जिसमें मानचित्र के बारे में जानकारी है (उदाहरण के लिए, क्या यह बहु-उपयोगकर्ता है), मानचित्र के लेखक का नाम, वह स्थान जहाँ मिशन पूरा हुआ था, मिशन संख्या, और इसी तरह। लेकिन मैं आपसे TrueNorth के बारे में पूछना चाहूंगा।

KN: [हंसो] यह असत्य का एक BAM प्रकार था: बाइनरी एंगल मापन इंजन!

JL: ये पागल नंबर क्या हैं?!

KN: वापस तो, अस्थायी बिंदु संचालन बहुत महंगा थे। लोहा कमजोर था, लेकिन पर्याप्त स्मृति नहीं थी। 360 डिग्री को 8-बिट संख्या द्वारा वर्णित नहीं किया गया था, जो 255 इकाइयों को सटीकता प्रदान करेगा, अर्थात लगभग 1.4 डिग्री प्रति यूनिट, जो पर्याप्त नहीं होगा। टिम ने अभिविन्यास के लिए 16-बिट संख्या का उपयोग किया, जो अधिक सटीकता प्रदान करता था।

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

[जब हम संपादक के साथ काम कर रहे थे, क्रिस को डेकोरेशन क्लास मिला]



KN: सजावट भी एक बहुत बड़ा वर्ग था। आपके द्वारा बातचीत की जा सकने वाली सभी जाली सजावट के सामान हैं। यही है, खेल में लगभग सब कुछ!

JL: डॉक्यूमेंटेशन के डेकोरेशन सेक्शन में कहा गया है, "हम आपको चेतावनी देते हैं कि यदि आप नीचे सूचीबद्ध नहीं किए गए कुछ फ़ील्ड बदलते हैं, तो संपादक क्रैश हो सकता है।" याद नहीं कि ऐसा क्यों हुआ?

KN: [हंसते हुए] ईमानदारी से, मुझे याद नहीं है। मुझे लगता है कि सजावट इतनी बड़ी कक्षा थी, और इसमें बहुत सारे महाकाव्य कार्य थे जो एक अजीब तरीके से इंजन के साथ बातचीत करते थे, कि एक डिजाइनर को समझाने के बजाय जो तकनीकी बारीकियों को नहीं समझता है कि एक निश्चित क्षेत्र अप्रत्याशित व्यवहार क्यों कर सकता है, हम बस उन्होंने कहा "इसका उपयोग न करें, अन्यथा संपादक दुर्घटनाग्रस्त हो जाता है।"

जेएल: [हंसते हुए]

KN: डराने की रणनीति की तरह कुछ। प्रोग्रामर की बैठकों में, हमने सोचा: उपयोगकर्ताओं को कैसे समझाया जाए कि इससे बीएसपी श्रृंखला को नुकसान होगा, और आपको ऐसा करने की आवश्यकता है और यह? आइए, उन्हें बताएं कि संपादक दुर्घटनाग्रस्त हो जाएगा।

मुझे फिर से कोड का अध्ययन करना चाहिए, लेकिन ऐसा लगता है कि हम उपयोगकर्ताओं को डराने के लिए कुछ स्थानों पर जानबूझकर विफलताओं को छिपाने के लिए भी दोषी हैं जो बहुत गहराई से घोटाले में हैं।

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

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

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

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

[खेल में विभिन्न वस्तुओं को देखते हुए, मैंने गुण पैनल में एक असामान्य नाम के साथ एक श्रेणी देखी]

डीएल: यह गंध संपत्ति क्या है?

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

डीएल: यही है, यदि आप एक बॉक्स के पीछे छिपते हैं, तो लोग आपको नहीं पाएंगे, लेकिन कुत्ते कर सकते हैं ...

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



[ Intro, — , . ]

: . . ...



KN: नहीं, दर्पण असली थे! वे बहुत धीमी गति से थे, इसलिए हमने डिजाइनरों से उन्हें शायद ही कभी उपयोग करने के लिए कहा, हालांकि, ये असली दर्पण हैं।

वास्तव में, जब मैंने लेजर कोड लिखा ... [हंसते हुए]

डीएल: [हंसते हुए] मुझे लगता है कि आपको जो मिल रहा है ...

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

बेशक, फ्रेम दर कहीं नीचे गिर गया, क्योंकि मुझे सभी लाइनों का पता लगाना था ...

लाइट वेव देखें: LWO23D कमांड लाइन टूल

[लेखक का ध्यान दें: LWO का अर्थ लाइटव्यू ऑब्जेक्ट है। यह न्यूटेक के लाइटवेट 3 डी सॉफ्टवेयर पैकेज का 3 डी ज्यामिति प्रारूप है , जो टेक्सास में भी आधारित है, उस समय ड्यूस एक्स टीम की तरह]



टैक की ड्यूस एक्स लैब से स्क्रीनशॉट

जेएल: आपकी टीम ने लाइटवेट का उपयोग करने का फैसला क्यों किया?

KN: हमारे कलाकार उसे अच्छी तरह से जानते थे। इसलिए, हमें अनुकूलन करना पड़ा।

जेएल: हमें इस बारे में अधिक बताएं कि आपने निर्यातक को कमांड लाइन टूल के रूप में क्यों लिखा है।

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

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

डीएल: मुझे लगता है कि स्थैतिक मेष निर्यात एक काफी मानक प्रक्रिया थी। लेकिन हमें बताएं कि आपने एनीमेशन कैसे निर्यात किया।



टैक की ड्यूस एक्स लैब से स्क्रीनशॉट

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

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

JL: तो, अवास्तविक में, सब कुछ एक ही किया?

KN: शायद हाँ। मुझे नहीं लगता कि टिम ने कंकाल एनीमेशन को अगले संस्करण में जोड़ा है।

टॉकिंग हेड्स: कन्विडेट एंड लिपसिंक

[अब हम रूपांतरण फ़ोल्डर खोलते हैं]


JL: हमें ConvEdit के बारे में बताएं

KN: यह अल के दिमाग की उपज थी, उन्होंने इसे Visual Basic में लिखा।

JL: उस समय की तरह अवास्तविक।

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

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

[नोट: यदि आप रुचि रखते हैं कि विज़ुअल बेसिक का उपयोग उस युग के खेल विकास साधनों में कैसे किया गया था, तो अवास्तविक संपादक के बारे में टिम स्वीनी के साथ मेरा साक्षात्कार पढ़ें]

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

मुझे लगता है कि आज भी इस उपकरण का उपयोग किया जाता है।

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




जेएल: वाह! मुझे नहीं पता था खेल में कई संवाद और शाखाओं का एक समूह था ...

KN: डेटा की एक बड़ी राशि, एक मिशन के लिए भी।

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

जेएल: पहले डेस एक्स वॉकथ्रू से, मुझे याद है कि अन्ना नवार्रे ने अपने कार्यालय में ब्रीफिंग की थी। किसी भी वीडियो गेम में हमेशा की तरह, मैंने एनपीसी द्वारा अपना संवाद समाप्त करने तक सभी प्रकार की बकवास करते हुए कार्यालय के चारों ओर दौड़ना शुरू कर दिया। अचानक उसने अपना संवाद बंद कर दिया, मुझसे पूछा और पूछा: "तुम क्या कर रहे हो?"

केएन: [हंसते हुए]

डीएल: एक दूसरे के लिए मैं जम गया, और खुद से पूछा: "क्या यह वास्तव में हुआ है?" खेल में विसर्जन के लिहाज से यह मेरे लिए एक महत्वपूर्ण घटना थी। इससे पहले एक भी खेल नहीं हुआ है। मुझे संदेह है कि यह आंशिक रूप से वार्तालाप संपादक के कारण है।

KN: वारेन की एक प्रस्तावना थी: "यदि कोई खिलाड़ी किसी के कार्यालय में है, जानवरों की तरह व्यवहार करता है और चीजों को तोड़ता है, तो चरित्र को कुछ कहना होगा!" उन्हें खिलाड़ी की उपेक्षा नहीं करनी चाहिए, क्योंकि यह अवास्तविक है। ”

JL: क्या ऐसे कोई कटक-संबंधी पहलू थे जिनके लिए उपकरण बनाना विशेष रूप से कठिन था?

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

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

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

जेएल: [हंसते हुए]

केएन: मैंने सोचा: "चलो देखते हैं कि क्या मैं ऐसा कर सकता हूं और सभी को आश्चर्यचकित कर सकता हूं।" फिर से, मुझे नहीं लगता कि किसी ने भी पहले ऐसा कुछ किया है, लेकिन आज यह तकनीक हर जगह है।

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

JL: वास्तव में, यह एक "जबड़े की चिकोटी" थी।

KN: हाँ, बिल्कुल, बिल्कुल।

मुझे याद है कि मैंने एक बार गैबी नेवेल के साथ चर्चा की थी कि कैसे उन्होंने इस कार्य को पूरा किया, और उन्होंने कहा: "ओह, बस एनवलप का पालन करें , और यह पर्याप्त होगा। बाकी सब बहुत जटिल हो जाएगा। ”

फिर मैं घर लौट आया और गणितीय गणनाओं का अनुमान लगाने लगा और फिर मैंने एक प्रणाली लिखी जिसमें एफएफटी ( फास्ट फूरियर ट्रांसफॉर्म ) किया गया। मैं दोहराता हूं, जबकि फ्लोटिंग पॉइंट गणना बहुत महंगी थी, और मैंने शायद एक पूर्णांक सन्निकटन लिखा था जो उन्हें अनुकरण कर रहा था।

उसने वास्तविक समय में ऑडियो रिकॉर्डिंग के एक छोटे टुकड़े का विश्लेषण किया और मुख्य आवृत्ति घटकों को निकाला, और फिर उन्हें छह से सात अलग-अलग वाक्यांशों से बांधा।

गुप्त रूप से, मैंने कलाकारों में से एक को सम्मिश्रण (मिश्रण आकार) के कई रूपों को अनुकरण करने के लिए कहा: मुझे "ओह", "ए", बंद होंठ और पसंद आया। उसने पूछा कि क्यों, और मैंने जवाब दिया कि उसने बस यही किया और मुझे डेटा दिया।



फास्ट फूरियर ट्रांसफॉर्म (विकिपीडिया इमेज) और प्रेस्टन ब्लेयर फोनीम्स सीरीज़

जेएल: [हंसते हुए] यह डेस पूर्व में आपके द्वारा उपयोग किए गए एनिमेशन के मिश्रण के लिए एकदम सही मैच लगता है।

KN: हाँ, बिल्कुल, एकदम सही।

इसलिए, उन्होंने मुझे डेटा दिया, मैंने गणितीय गणनाएँ लिखीं और जैसा कि मैंने स्वयं, प्रपत्रों को संलग्न किया। मैंने कोई गंभीर शोध नहीं किया और प्रदर्शन के मामले में यह प्रणाली काफी महंगी थी।

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

मैंने वॉरेन को पाया और उससे कहा, "मैं तुम्हें कुछ अच्छा दिखाना चाहता हूं।" लगता है, वह स्तब्ध था। [हंसते हुए] उन्होंने मुझसे पूछा: “क्या बात है, क्या हम इसे खेल में डाल सकते हैं? यह सिर्फ भयानक है! ”

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

शायद यह इसे पेटेंट कराने लायक था। लेकिन मुझे सॉफ्टवेयर पेटेंट पर विश्वास नहीं है क्योंकि मुझे लगता है कि यह एक शातिर प्रथा है ...

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

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

निष्कर्ष

DL: तो, संक्षेप में, मैं पूछना चाहता हूं: यदि आप इस लेख को पढ़ने वाले टूल डेवलपर्स को सलाह दे सकते हैं, तो आप क्या कहेंगे?

KN: अपने ग्राहक की सुनो। कभी भी वैक्यूम में उपकरण न लिखें। एक इंजीनियर के रूप में, आप सोच सकते हैं: "मैं इस तरह से इस उपकरण का उपयोग कर सकता हूं, और यह विधि सबसे प्रभावी है, इसलिए मैं इसे इस तरह लिखूंगा।"

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

DL: क्या आपने कभी उन टीमों के साथ काम करने वाली मानसिकता के साथ मुलाकात की है? और आपने इससे कैसे निपटा?

KN: आपको बस प्रोग्रामर को यह बताने की जरूरत है: “आपको क्यों लगता है कि उपयोगकर्ता को यह समस्या है? क्या आपको लगता है कि समस्या कोड में है? या शायद समस्या स्क्रीन संरचना है? क्या फ़ॉन्ट बहुत छोटा है? गलत बटन का रंग? शायद आप कुछ गैर-मानक कर रहे हैं? "

क्योंकि यदि आप एक पेशेवर डिजाइन के साथ अधिकांश उपकरणों को देखते हैं, तो आमतौर पर वे काफी सुसंगत होते हैं। चीजों को कैसे काम करना चाहिए, इस पर डिजाइन गाइड हैं।

रचनात्मक टीम को इन उपकरणों का उपयोग करने में सक्षम होना चाहिए। ऐसा नहीं होना चाहिए कि उन्हें प्रलेखन पढ़ना होगा। एक आदर्श दुनिया में, सब कुछ स्पष्ट होना चाहिए।

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

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

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

इंजीनियरों के लिए क्लासिक जाल में पड़ने की जरूरत नहीं है: “मैं बेहतर जानता हूं, मैंने लिख दिया कि मैं लिखता हूं, मुझे पता है कि यह कैसे काम करता है। यदि आप इसका उपयोग नहीं कर सकते हैं, तो आप सिर्फ एक मूर्ख हैं। ” यह सबसे खराब चीज है जो एक उपकरण विकसित करते समय हो सकती है।

जेएल: उत्कृष्ट सलाह। बहुत बहुत धन्यवाद क्रिस!