Half-Life की 25वीं वर्षगांठ पर डॉक्यूमेंट्री [वीडियो]
(youtube.com)- 1996 में Microsoft छोड़ने के बाद Mike Harrington और Gabe Newell ने गेम रिलीज़ करने का बहुत कम अनुभव रखने वाली टीम के साथ Half-Life का विकास और Valve के संगठनात्मक डिज़ाइन की शुरुआत साथ-साथ की
- Quake engine license, mod creators की hiring, और गैर-पारंपरिक backgrounds वाले talent के मेल से Valve का पहला IP शुरुआत से बनाया गया
- Half-Life ने 16-bit color, skeletal animation, छोटे level transitions, scripted events, reactive AI और sound के ज़रिए बिना टूटे first-person immersion का लक्ष्य रखा
- 1997 में internal review में यह निष्कर्ष निकलने पर कि गेम cohesive नहीं है, release टाल दिया गया और multidisciplinary small group वाले cabal process से level flow को फिर से डिज़ाइन किया गया
- आख़िरी चरण में 18 घंटे का काम, काटे गए monsters और levels, और जल्दबाज़ी में पूरा किया गया Xen जैसी सीमाएँ थीं, लेकिन iterative production और playtesting ने अंतिम quality को ऊपर उठाया
Microsoft छोड़ना और Valve की स्थापना
- Mike Harrington को लगा कि Microsoft बहुत बड़ा हो गया है, और लगभग एक साल पहले से ही वे managers से कह रहे थे कि वे कंपनी छोड़कर game company बनाएँगे
- Harrington ने शुरुआत में Michael Abrash से बात की, लेकिन Abrash बाद में John Carmack के मनाने पर id Software में शामिल हो गए
- Gabe Newell ने Harrington को game company बनाने की बात कहते देखा तो कहा कि वे भी जाना चाहते हैं, और दोनों ने मिलकर Valve शुरू किया
- Newell को उस समय की स्थिति देखकर लगा कि असफल होने की संभावना ज़्यादा है, और वे सोचते थे कि करीब एक साल बाद गलती समझकर Microsoft के दोस्तों के पास वापस जाकर नौकरी माँगनी पड़ेगी
- दोनों founders के पास software development का अनुभव और company design पर विचार थे, और Half-Life बनाते समय Valve को भी साथ-साथ डिज़ाइन किया गया
Quake engine, पहला IP, शुरुआती टीम
- Valve स्पष्ट योजना के बिना शुरू हुई, लेकिन Michael Abrash के connections से id Software गई और Quake source code को CD में लेकर आई
- उस समय अभी contract नहीं था, लेकिन Valve ने id की core assets के करीब माने जाने वाले Quake source code को हासिल कर लिया
- John Romero ने सलाह दी कि game company शुरू करने के लिए level designers को hire करना चाहिए
- शुरुआती टीम के अधिकांश लोगों के पास game development का अनुभव नहीं था, और पूरी कंपनी में वास्तव में game release कर चुके लोग करीब 3–4 ही थे
- Valve को अपने पहले game का IP शुरुआत से बनाना था, और Gabe Newell ने Stephen King की “The Mist” से महसूस हुए tension और atmosphere को reference point बनाया
- शुरुआती दिनों में Valve के पास दो projects थे
- Quiver: जो बाद में Half-Life बना
- Prospero: अलग project था, लेकिन Half-Life ने Prospero के features और resources absorb कर लिए, जिससे वह गायब हो गया
- Prospero के लिए बनाए गए beam effects Half-Life की disaster sequence और Vortigaunt effects में शामिल हुए
Mod creators और गैर-पारंपरिक प्रतिभाएँ
- Valve ने mod creator community से कई designers hire किए
- Steve Guthrie, Steve Bond, John Guthrie जैसे युवा mod creators जुड़े
- Steve Bond QuakeC से mods बनाने वाले व्यक्ति थे, और Half-Life soldier AI के बड़े हिस्से में उनका योगदान रहा
- टीम में कई लोग game industry के standard path से काफ़ी दूर थे
- Half-Life में सबसे ज़्यादा code लिखने वाला व्यक्ति chemistry major के बाद Atlanta में IP lawyer बनने जा रहा था
- creature AI design में बड़ा योगदान देने वाला व्यक्ति Waffle House manager था
- Marc Laidlaw कहानी की structure और ideas टीम में लेकर आए, और दूसरों के ideas बाहर निकालने की भूमिका भी निभाई
- उस समय game industry में “video game design PhD” जैसा formal path नहीं था, और Valve को talented लोगों को ढूँढकर यह समझाना पड़ता था कि यह बेहतर workplace है
Half-Life बनाने वाली technical choices
- Valve ने id के Quake engine के आधार पर development किया, लेकिन Half-Life के लिए ज़रूरी कई technologies जोड़ीं
- Level transitions को save/load system का उपयोग करके implement किया गया
- corridors या train sections में छोटा pause देकर अगला level load किया जाता था
- Half-Life 1 के अधिकांश transitions लगभग 1–2 सेकंड के थे
- Half-Life के दो बड़े technology investments 16-bit color और monsters के लिए skeletal animation थे
- 8-bit से 16-bit पर आने से textures को 256 colors के भीतर फिट करने की ज़रूरत नहीं रही
- Quake characters समय के अनुसार vertex positions रखने वाले तरीके पर आधारित थे, लेकिन skeleton का उपयोग करने से अधिक animations, body-part swapping, gun attachment और model reuse संभव हुआ
- Skeletal animation 100, 200, 500 frames से अधिक animations जोड़ने और character variations आसान बनाने का आधार बनी
Scripted events और response देने वाली दुनिया
- development team ने सिद्धांत बनाया कि player जब आगे बढ़े तो हर 3–5 सेकंड में कुछ न कुछ होना चाहिए
- घटना कोई बड़ा combat होना ज़रूरी नहीं; signboard, sound, छोटी scene या scripted sequence भी हो सकती थी
- सोच यह थी कि player खड़ा रहे तो world शांत रह सकता है, लेकिन सक्रिय हो तो world को respond करना चाहिए
- Scripted sequences ने characters को किसी खास जगह तक दौड़ाने, या animation के अनुसार उड़ने और टकराने वाले scenes बनाने की सुविधा दी
- Scripted events शक्तिशाली थे, लेकिन टूटने में आसान भी थे
- headcrab का scientist पर झपटने वाला scene 90% बार ठीक चलता था, लेकिन कुछ players सीधे scientist की ओर दौड़ते तो वह टूट जाता
- कुछ scenes को player approach रोकने के लिए glass के पीछे रखना पड़ा
- Tentacle sequence play और scripted events के गहरे मिश्रण का representative scene बनकर रह गया
- Gabe Newell मज़े को realism से ज़्यादा इस रूप में देखना चाहते थे कि game player की choices और actions को कितना पहचानता और respond करता है
- दीवार पर गोली चलाने पर bullet marks रहने चाहिए
- बहुत सारे soldiers मारने पर soldiers को भागना चाहिए
- game world को player की presence और actions को acknowledge करना चाहिए—यह विचार Half-Life का core strengthening element बना
Creatures, characters, G-Man
- Half-Life के creature design ने naturalistic और alien दोनों दिशा अपनाने की कोशिश की
- Ted Backman ने headcrab, houndeye, bullsquid जैसे fleshy और biological designs बहुत बनाए
- Chuck Jones Duke Nukem से आए थे और उन्होंने अलग style के monsters बनाए; दोनों styles के बीच harmony खोजनी पड़ी
- Headcrab Half-Life की प्रतीकात्मक creatures में से एक बन गया, और scientist model पर headcrab रखकर zombie बनाया गया
- Gordon Freeman की appearance शुरुआत से स्पष्ट तय नहीं थी
- शुरुआती model “Ivan the space biker” एक rough prototype था
- Chuck Jones ने अपनी appearance शुरुआती Gordon model में डाली, और multiplayer model में छोटी ponytail का निशान बचा रहा
- G-Man X-Files के cigarette man को ध्यान में रखकर बनाया गया character था
- शुरुआत में वह शुरुआती office scene के पीछे मौजूद creepy व्यक्ति जैसा था
- बाद में उसे ऐसी जगहों पर रखा गया जहाँ पहुँचना संभव नहीं था, और वह mysterious entity बन गया
- Vortigaunt को शुरुआती monsters की repetition कम करने के लिए अपेक्षाकृत देर से आगे वाले maps में जोड़ा गया
- Assassin भी देर से जोड़ा गया enemy था; model और animations पहले से थे, और नए animations के बिना AI लगाकर उसे पूरा किया गया
- Panthereye, stooka bat, chub toad जैसी creatures game में लंबे समय तक रहीं या implementation stage तक पहुँचीं, लेकिन अंत में हटा दी गईं
Black Mesa की spaces और textures
- Black Mesa की शुरुआत DC के पास के साधारण बड़े office building, linoleum tiles, drop ceilings, concrete block walls और black-and-white tile floors जैसे elements से हुई
- Karen Laur ने game की अधिकांश texture work संभाली, और शुरुआत में हाथ से drawing करती थीं, फिर बाद में photo references आधारित approach पर चली गईं
- Seattle, Harbor Island, Gasworks Park आदि में rusty metal और industrial imagery की photos ली गईं
- Half-Life के कई corridor textures में boxcars या train surfaces जैसी images इस्तेमाल हुईं
- Eastern Washington और Columbia Gorge के desert/cliff images भी Southwest atmosphere के references बने
- Black Mesa के अंदर research facilities के साथ offices, kitchen, microwave और soup फटने वाले scenes जैसे रोज़मर्रा के elements भी डाले गए
- microwave scene का संबंध वास्तविक Valve office में soup फोड़ने के अनुभव से था
- Color stripes का इस्तेमाल players को जटिल research facility के भीतर रास्ता खोजने में मदद देने के लिए किया गया
1997 का संकट और cabal process
- development का पहला साल opportunity-driven था, और team अभी दिशा खोज रही थी
- 1997 में planned release से लगभग 3 महीने पहले internally निष्कर्ष निकला कि game ठीक से fit नहीं हो रहा
- engineering, level design और animation एक-दूसरे से disconnected थे
- monsters थे लेकिन उन्हें कहाँ डालना है इसकी योजना नहीं थी, और levels में क्या डालना है यह अक्सर तय नहीं था
- हर level designer के अपना world बनाने वाली mod-making culture का विस्तार होने से overall cohesion कम था
- Gabe Newell ने दो दिनों तक सारे levels खेलकर review किया और “हम fail होंगे” जैसी प्रतिक्रिया दी—यह scene team पर गहरी छाप छोड़ गया
- Valve ने कहा कि वह Sierra के schedule के अनुसार release नहीं करेगी, और Sierra अतिरिक्त development cost न दे तब भी बनाना जारी रखेगी
- “Late होना थोड़े समय की बात है, लेकिन खराब होना हमेशा के लिए है” इस judgement के तहत game को जबरन release न करने का फैसला हुआ
- इसके बाद cabal process लागू किया गया
- artists, level designers, engineers आदि को शामिल करने वाली छोटी multidisciplinary team ने level specifications लिखे
- Marc Laidlaw द्वारा लिखे story flow के अनुसार कौन-से maps चाहिए, अगला piece क्या होगा, यह क्रम से design किया गया
- combat, exploration और puzzle ratio तय कर पूरे game में समान रूप से लागू करने की कोशिश की गई
- sketches ने visual meeting notes की भूमिका निभाई और cabal के मजबूत outputs के रूप में बचे रहे
Opening, disaster sequence, और uninterrupted immersion
- Half-Life का opening train scene उस समय के first-person shooters की conventions पर प्रतिक्रिया था
- कई games cutscene के बिना सीधे gun और enemies दे देते थे, या cutscene के बाद play शुरू करते थे
- Half-Life एक anonymous scientist के commute train से Black Mesa में प्रवेश करने वाले scene से शुरू हुआ
- कई players ने शुरुआत में इसे recorded scene समझा, फिर mouse हिलाने पर समझा कि यह real-time scene है
- disaster से पहले वाले sections की कुछ structure first-year version से बची रही, और बाद में John Guthrie आदि ने उसे shipping version के लिए polish किया
- test chamber sequence एक महत्वपूर्ण turning point था
- John Guthrie ने रात भर में जो version बनाया, वह लगभग shipped form जैसा ही था
- lighting, sound, heartbeat, breathing और direction को जोड़कर “player के साथ सचमुच घटित होने वाला uninterrupted experience” बनाया गया
- disaster से पहले और बाद को जोड़ने वाली इस sequence के बाद team को भरोसा हुआ कि game अलग-अलग content collection नहीं, बल्कि एक product के रूप में बँध सकता है
Leaked preview और बाहरी प्रतिक्रिया
- Valve ने development funding के एक तरीके के रूप में video card companies को Half-Life preview builds बेचे
- contract के अनुसार एक खास तारीख तक deliver करना था, और team ने पहले तीन levels पूरा करके deliver किए
- वह build जल्द ही leak हो गया; पहले गुस्सा आया, लेकिन फिर online play reactions फैलने लगे
- एक magazine ने कहा कि वह आम तौर पर beta software review नहीं करती, फिर भी इस build को review किया और positive rating दी
- यह बाहरी प्रतिक्रिया Valve जिस दिशा में कोशिश कर रही थी, उसके लिए मजबूत validation बनी
Weapons, sound, AI signals
- Half-Life के weapons को इस तरह design किया गया कि वे एक-दूसरे से जितना संभव हो अलग roles निभाएँ
- shotgun, pistol जैसे basic axes के अलावा rocket launcher, Gauss gun, snark आदि शामिल किए गए
- Snark को camping करने वाले players से निपटने के weapon के रूप में सोचा गया था; छोटे creature को फेंकने पर वह घूमने लगता था
- Crowbar world के respond करने वाले device की चाह का परिणाम था
- दीवार पर वार करना उस समय बहुत satisfying feedback जैसा महसूस होता था
- यह “मज़ा world के actions पर respond करने में है” वाले विचार के concrete decision में बदलने का उदाहरण था
- Sound को AI की internal state player तक पहुँचाने के core माध्यम के रूप में इस्तेमाल किया गया
- soldiers injury, grenade throw, cover लेना आदि voice से दिखाते थे
- player बिना conscious हुए भी sound से अगली घटना predict करने लगता था
- Kelly Bailey ने sound engine लिखा और soundtrack भी बनाया
- उन्होंने पहले कभी soundtrack नहीं लिखा था, लेकिन पूरे game का music बनाया और award भी जीता
- Headcrab sound चूहे की आवाज़ को बहुत धीमा करके और reverse करके बनाया गया था
- DSP effects ने vents या विशाल spaces की echo को अलग सुनाकर sense of space को मजबूत किया
- character lip movement को audio signal का उपयोग करके अपेक्षाकृत जल्दी implement किया गया
- animator और programmer कठिन हिस्सों को अलग-अलग समझते थे, इसी वजह से lunch conversation के बाद थोड़े समय में character बोलने और होंठ हिलाने लगा
Level design और representative sections
- Power Up section Gargantua creature के हिसाब से design हुआ था, इसलिए उसका मूल रूप लगभग बचा रहा
- player को Gargantua से निपटना, power on करना और train चलाकर बाहर निकलना था
- level design का starting point यह था कि player को सीधे exit तक जाने से कैसे रोका जाए
- दूसरे साल में approach बदली: मौजूदा maps में AI डालने के बजाय पहले सीमित environments बनाए गए जहाँ AI अच्छी तरह दिखे, फिर level designers ने उन्हें integrate किया
- soldier AI ऊपर-नीचे positions, retreat, stairs usage और flanking जैसे combat situations दिखाने वाले test maps में विकसित हुआ
- train section player को controlled लेकिन constrained vehicle देने की कोशिश थी
- Half-Life 2 जैसी vehicles संभव नहीं थीं, इसलिए सबसे limited form में train चुनी गई
- players train छोड़कर पैदल चलने लगते थे, इसलिए rails में बिजली डालकर train लाने के लिए motivate किया गया
- Surface Tension cliffs, tanks, soldier outposts, desert, helicopters, dam आदि वाले sketches से मजबूत motivation लेकर बना
- cliff section को vertigo का उपयोग करने की दिशा में design किया गया
- Hoover Dam की याद दिलाने वाला dam section कुछ घंटों में बनाया गया
- Karen Laur ने नए textures को कई levels में बेतरतीब उपयोग होने से रोकने के लिए texture sets के names उस level के आधार पर रखे, ताकि visual cohesion बने
Story delivery, names, voices
- Half-Life की narrative cutscene के बाहर explanation से ज़्यादा game के भीतर दी जाने वाली diegetic writing का लक्ष्य रखती थी
- playtesting के बाद जिन जगहों पर route guidance या situation explanation कम लगता था, वहाँ scientist dialogue जोड़ा गया
- उदाहरण के लिए, scientist के अचानक आकर “उधर जाओ” जैसा clue देने वाला scene आख़िरी चरण में जोड़ा गया
- Black Mesa location और कुछ names शुरुआती map के dots और naming से बने
- lobby map में Mexico पर dot लगाने से बाद में location setting और name जुड़े
- developers हर चीज़ समझाने के बजाय suggestive names से mystery बढ़ाने का तरीका पसंद करते थे
- Barney voice Hal Robins ने फोन पर बोलते ही team को “यही व्यक्ति सही है” महसूस करा दिया, और तुरंत तय हो गया
- G-Man की भूमिका Michael Shapiro ने की; शुरुआत में safe, straight performance भी record हुई, लेकिन बाद में “crazy lizard voice” जैसी performance चुनी गई
- Nihilanth voice भी team के भीतर ही की गई
Development के अंतिम चरण की मेहनत और निजी जीवन
- Half-Life development के अंतिम दौर में लंबे working hours जारी रहे
- कुछ team members ने कहा कि वे 18 घंटे काम करते थे
- युवा members अक्सर देर रात तक office में रहते थे
- Karen Laur ने याद किया कि उस समय वे team की एकमात्र महिला थीं, और वह स्थिति अच्छी नहीं थी
- एक developer की बेटी Isabel की photo Gordon के locker में डाली गई
- मूल रूप से उसे destroyed office में कहीं personal easter egg के रूप में छिपाया गया था, लेकिन बाद में Gordon के locker में ले जाया गया
- Isabel का जन्म Half-Life बनाने के दौरान हुआ, और उसे special care की ज़रूरत थी, जिससे परिवार के लिए यह बहुत कठिन समय था
- developers ने कहा कि final release के तुरंत बाद भी यह भरोसा करना मुश्किल था कि game सचमुच मज़ेदार है या नहीं
- यह कहा गया कि team का कोई भी member अगर एक महीने के लिए गायब हो जाता तो game ship नहीं हो पाता—हर member ने महत्वपूर्ण भूमिका निभाई
Xen और अंतिम sections की सीमाएँ
- Xen की शुरुआत मूल रूप से ऐसे idea से हुई थी कि player किसी विशाल alien creature के अंदर जाकर उसे रोकता या manipulate करता
- alien architecture या biological structure दिखाना चाहते थे, लेकिन tools rectangles बनाने के लिए उपयुक्त थे और धीरे-धीरे यह ज़्यादा corridor-like structures तक सीमित हो गया
- Xen game का अंतिम हिस्सा था, इसलिए time pressure बहुत ज़्यादा था
- कुछ हिस्सा first draft के करीब ही रह गया
- बीच में Xen में बिल्कुल न जाने का विकल्प भी सोचा गया, लेकिन art concept मजबूत था इसलिए रखा गया
- Xen textures electron microscope images, insects और beetles जैसी organic imagery से inspired थे
- organic shapes बनाने के लिए editor friendly नहीं था, और level creation बहुत कठिन था
- low gravity और jump pack जैसे changes देर से आए, और पहले से बने spaces में उन्हें अतिरिक्त रूप से reflect करना पड़ा
- team ने एक समय तय किया कि अब और polish नहीं करना, बस समाप्त करना है
- अगर player उस point तक मज़ा महसूस नहीं कर रहा था तो game पहले ही fail हो चुका है; इसलिए अंतिम section का complete होना महत्वपूर्ण माना गया
- “Half-Life 2 हमेशा है” जैसा मज़ाक भी हुआ
Completion के बाद retrospective
- team members Half-Life बनाने में अलग-अलग professional backgrounds वाले लोगों के collaboration को महत्वपूर्ण अनुभव के रूप में याद करते हैं
- Karen Laur कहती हैं कि वे texture artist के रूप में आई थीं, लेकिन game क्या बनेगा इस पर वे काफ़ी बड़ा असर डाल सकीं
- अच्छे game के लिए दो games जितना बनाकर खराब game को फेंकने की प्रक्रिया ज़रूरी होती है, और Valve Mike Harrington के support की वजह से यह कर सकी
- Gabe Newell कहते हैं कि वे past legacy को देखने से ज़्यादा future में क्या किया जा सकता है, इसे महत्व देते हैं; past work उनके लिए आगे बढ़ने का stepping stone जैसा है
1 टिप्पणियां
Hacker News की राय
यह सचमुच दिलचस्प था कि Valve ने शुरुआती hiring में जैकपॉट मार लिया
कई लोगों का CS तो दूर, गेमिंग बैकग्राउंड भी नहीं था, लेकिन उनमें से काफी लोग बेहद जिद्दी, resourceful, creative और मेहनती निकले
Half-Life का ज्यादातर code लिखने वाला व्यक्ति भी developer नहीं था, और मुझे याद है कि उस समय वह वकील या accountant बनने की पढ़ाई कर रहा था
आखिरकार timing, founders, और बस किस्मत ने निर्णायक भूमिका निभाई, ऐसा ही मानना पड़ेगा
असल में पहला साल अनुभव जुटाने में गया, और अहम बात यह थी कि publisher Sierra ने इसे स्वीकार कर लिया
आजकल, खासकर AAA games में, ऐसा शायद ही हो। budgets बहुत बड़े हो गए हैं, और publisher plan B देने के बजाय developer पर दबाव डालेगा कि जो है उसी को किसी तरह duct tape से जोड़कर release कर दो
बाद में patch कर देंगे, है न?
tech industry Carmack जैसे 10x developers पर obsessed लगती है, लेकिन motivated लोग भी कमाल कर सकते हैं
इसलिए वे id के पास गए और Quake engine लेकर आए, और Romero से सलाह भी ली
कभी-कभी आप किसे जानते हैं, यह वाकई मदद करता है, और success में हमेशा कुछ न कुछ luck भी शामिल होता है। यह भी साफ है कि एक शानदार team ने उस game को वैसा बनाया
realism और fun के बीच balance बनाने का तरीका भी दिलचस्प था, और कोई चीज कैसे बनती है यह देखना हमेशा मजेदार होता है
उस समय ऐसी चीजें आज की तुलना में कहीं ज्यादा common रही होंगी। आजकल launch work के लिए जितने level की जरूरत है, उससे एक-दो level ऊपर का काम करने में सक्षम होना पड़ता है, शायद इसलिए कि management और schedules इतने गड़बड़ हैं कि जल्दबाजी और overwork के बावजूद output देना पड़ता है
जो लोग अभी शुरू कर रहे हैं या career बदल रहे हैं, उन्हें ऐसी support लगभग नहीं मिलती, और वे बस उम्मीद कर सकते हैं कि अकेले कोशिश करते हुए hire होने लायक skills सीख रहे हों
90s के आखिर में मैं Australia की Team Fortress (Quake 1 version) community में गहराई से शामिल था, और ‘bro’ (Robin Walker) और John Cook हमारे लिए देवता जैसे थे
RMIT/Melbourne LAN culture और online में उनकी लगातार मौजूदगी थी, और वह दौर था जब ज्यादातर लोग 28.8/33.6k modems इस्तेमाल करते थे और east coast universities की ISDN पर कुछ LPB थे
qwtf से ‘tf2’ पर जाने में जो संघर्ष हुआ, वह अंततः अच्छा ही रहा होगा। उस wilderness में सीखे गए सबक बाद में Valve में जाकर HL2 पर काम करते समय काम आए होंगे
यह भी काफी मजेदार है कि TF2 मूल रूप से कहीं ज्यादा realistic modern military shooter बनने वाला था, लेकिन scope बढ़ने के कारण वह योजना पटरी से उतर गई
जब उन्हें Valve में hire किया गया और वे TFC और बाद में HL2 बनाने लगे, तो बहुत excitement हुई
बाद में Day of Defeat आया और उसने उस role को काफी अच्छी तरह निभाया
यहां एक काफ़ी obvious सवाल उठता है। उस टीम में अलग क्या था? प्रतिभा, leadership, या product focus में से क्या था?
लंबे समय से JavaScript developer के तौर पर काम करने के नाते मैं सच में मानता हूं कि मुख्य रूप से JavaScript पर काम करने वाले लोगों में से सिर्फ़ करीब 4% ही सच में जानते हैं कि वे क्या कर रहे हैं
शुरुआती Valve टीम में जोश बहुत था, लेकिन लगता है कि उस तरह के code या product का असली अनुभव लगभग नहीं था। उन्हें Quake code के रूप में एक बहुत बड़ा आधार मिला, और बाकी उन्होंने खुद समझ लिया
वे Quake code के ऊपर जमे नहीं रहे, बल्कि अपनी ज़रूरतों के हिसाब से उसे बड़े पैमाने पर बदल डाला। ज़्यादातर JavaScript टीमें ऐसा नहीं कर पातीं। वे अपने पसंदीदा framework में ही रहती हैं, और code style व process के इर्द-गिर्द ही घूमती रहती हैं
शुरुआती Valve टीम और अलग-अलग JavaScript टीमों को अलग करने वाली चीज़ क्या है? यह निश्चित रूप से शिक्षा या पेशेवर परिपक्वता नहीं है
उससे आगे, जब तक कोई काफ़ी senior न हो, उसे आम तौर पर बड़े बदलाव करने का अधिकार नहीं मिलता, और अगर कोई developer लगातार self-improvement करने का फैसला भी करे, तो कंपनी के उस technical growth का इनाम देने की संभावना कम होती है
आखिरकार मुझे लगता है कि यह diminishing returns वाला काफ़ी बड़ा क्षेत्र है
अगर आपने competitive multiplayer games खेले हैं, तो आप जानते होंगे कि कुछ लोग हज़ारों घंटे खेलने के बाद भी बिल्कुल बेहतर नहीं होते
कभी-कभी लगता है लोग bottleneck तक पहुंचते हैं, लेकिन उसे पार कैसे करना है यह नहीं जानते
उस दौर में videogame levels, models, animations वगैरह बनाना आज की तुलना में नाटकीय रूप से सरल था
एक व्यक्ति ने पूरे game की texture work की, एक व्यक्ति ने सारे sound effects और music बनाए, और environment के हिसाब से real-time में sound manipulate करने वाला DSP engine तक code किया
अगर कुछ बेहद प्रतिभाशाली लोग smart, enthusiastic और motivated लोगों को lead करने की इच्छा रखें, तो बहुत कुछ किया जा सकता है। मुझे लगता है Valve में यही हुआ
वे काम पूरा करने लायक जानते थे, लेकिन इतने नहीं जानते थे कि जिन चीज़ों को वे करना चाहते थे उन्हें “नहीं किया जा सकता” मान लें
ज़्यादा अनुभवी developer शायद Half-Life टीम द्वारा आखिरकार implement किए गए कई ideas को “बहुत समय लगेगा” या “लगभग असंभव है” कहकर छोड़ देते
उस समय Valve developers इतने अनुभवी नहीं थे कि ऐसी धारणाएं बना लें, इसलिए वे बस जी-जान से लगे रहे और तरीका खोज निकाला
आखिरकार उन्होंने “cabal” के साथ प्रभावी रूप से फिर से शुरुआत की, और पहले से बने अच्छे टुकड़ों को जोड़कर game पूरा करना पड़ा
cabal process पर ज्यादा विस्तृत लेख यहां है (page 2 से शुरू):
https://web.archive.org/web/20210823181232/https://www.gamas...
यह 1999 का लेख है और video से कहीं ज्यादा detailed है
game development मूल रूप से waterfall method है। कई साल तक काम करके उसे एक विशाल release में जमा किया जाता है। आजकल milestones के अंदर agile process हो सकता है, लेकिन बुनियादी तौर पर यह एक बड़े waterfall की ओर जाता है
यह महत्वपूर्ण है। आज का agile autonomous developers को बड़ी machine के cog में बदल देता है। लेकिन Valve के “cabal” को वह काम करने की आज़ादी थी जो उन्हें best लगता था
Gabe Newell के पास अंतिम decision authority और opinions रहे होंगे, लेकिन अंततः उस group के पास flexibility थी। developers पूरे system को जानते थे, और अंधे लोगों और हाथी वाली कथा[1] की तरह board से Jira tickets उठाने जैसा नहीं था
टुकड़े कैसे जुड़ते हैं, यह वे इसलिए जानते थे क्योंकि वे ही लोग थे जिन्होंने उन टुकड़ों को वहां रखा था। अगर टुकड़े fit नहीं होते, तो उन्हें fit कराने का अधिकार भी उनके पास था
Half-Life की कहानी को The Mythical Man-Month[2] के नजरिए से देखना भी दिलचस्प है
नतीजा सफल रहा हो, फिर भी crunch एक कड़वा reminder है
उन्हीं working hours की वजह से मैंने modding छोड़कर boring business software की तरफ़ रुख किया
ऊपर से खाली समय में अब भी game development कर सकते हैं। असल में खाली समय होता भी है
Dario Casali का Half-Life 25वीं वर्षगांठ वाला playthrough भी देखने लायक है: https://www.youtube.com/playlist?list=PLk5gaNp4x_AVIJviyHueH...
लगातार 12–16 घंटे काम, ईमेल पर चलती बहसें, और मनोबल तोड़ने वाला मैनेजमेंट दिखता है
बचपन में Valve में काम करने की मेरी छवि किसी परीकथा जैसी थी—जहाँ होशियार लोग शानदार माहौल में बेहतरीन काम करते हैं। कुछ हद तक यह शायद अब भी सच हो, लेकिन एक वीडियो गेम के लिए इन डेवलपर्स ने जो बलिदान झेले, वैसा मैं कर पाऊँगा, ऐसा नहीं लगता। हैरान करने वाला
सबसे दिलचस्प वीडियो में से एक आख़िर का multiplayer map वाला वीडियो था, क्योंकि Dario के पास map design के बारे में कहने को बहुत कुछ था
कल देखा; game development सच में बहुत उथल-पुथल भरा और अप्रत्याशित होता है
खास तौर पर इस मामले में लगभग सभी लोग amateur थे, programming या games की background बहुत कम या बिलकुल नहीं थी, लेकिन जुनून बहुत था
यह कैसे बना, उससे जुड़ा रहस्य भी टूट जाता है। Half-Life की अच्छी चीज़ें—जैसे intro, G-Man, Xen, headcrab, music—लगभग कुछ भी शुरुआत से मौजूद नहीं था; सब काम आगे बढ़ने के साथ बना
documentary वाकई बहुत अच्छी थी। कभी उस game को बेहिसाब खेला था
अभी Half-Life Deathmatch में भी थोड़ी-सी renaissance आई लगती है, इसलिए अगर nostalgia चाहिए तो आज़माने लायक है
Valve ने कुछ concept art character models, gameplay adjustments और नए maps भी जारी किए हैं। यानी 25 साल पुराने game के लिए नया content आया है
वैसे, Half-Life और HL2 दोनों अभी VR में काफ़ी playable हैं। Half-Life तो Quest 2 पर natively भी चलता है
लेकिन Valve ने Half-Life 2 Episode 3 की घोषणा की 17वीं वर्षगांठ को acknowledge नहीं किया
“देर होना थोड़ी देर की बात है, लेकिन घटिया होना हमेशा के लिए है” एक अच्छी लाइन है
No Man’s Sky याद आता है, और Cyberpunk 2077 भी ऐसा हो सकता है
शानदार documentary थी। anniversary documentary देखने के बाद original Half-Life को Source engine में remake करने वाले Black Mesa का पहला part[1] भी देखने की सलाह दूँगा
modders ने उन elements के बारे में काफ़ी बात की है जिनका original developers ने ज़िक्र किया था, और उन्हें recreate करते समय आई मुश्किलों के बारे में भी
[1] https://www.youtube.com/watch?v=G_TcAxAKCAI