مقدمة

في الآونة الأخيرة ، تلقت القصص حول الألعاب الكلاسيكية استقبالًا جيدًا في GDC ، ولكن كان هناك عدد قليل جدًا من القصص حول أدوات تطويرها. في هذه السلسلة من المقالات ، سنحاول سد هذه الفجوة عن طريق مقابلة الأشخاص الذين لعبوا دورًا مهمًا في تاريخ أدوات تطوير اللعبة.

في أول جزأين من السلسلة ، تحدثنا مع جون روميرو (حول TEd Editor) و Tim Sweeney (حول Unreal Editor) .

عند كتابة المقالة الثالثة ، تشرفت بالتحدث مع كريس نوردن حول الأدوات التي طورها لـ FPS / RPG الهجين المسمى Deus Ex . لقد تحدثت مع كريس في سان فرانسيسكو في GDC 2018.

قبل أيون العاصفة: الأصل والزجاج

ديفيد Lightbone: كيف بدأت في Deus Ex في Ion Storm؟

كريس نوردن: في عام 1994 ، عملت كمبرمج أصل في أوستن. كان أول مشروع مدفوع لي هو Jane's Combat Simulation AD-64D Longbow بواسطة Jane's Combat Simulation. كانت في الأصل لعبة أركايد تسمى Chopper Assault. عملت مع أندي هوليس على ذلك لمدة عامين.



بعد إصدار اللعبة ، فإن آخر شيء أود القيام به هو القيام بمحاكاة عسكرية أخرى ، لأنني لا أحب كل شيء عسكري. من وقت لآخر ، تحدثت مع وارين سبيكتور ، الذي عمل أيضًا في Origin. لقد أحب ألعاب الأدوار. قلت لنفسي: "أنا أيضًا أحب هذه الألعاب ، أريد أن أعمل على شيء من هذا القبيل!"

في عام 1996 ، استقال وارن من Origin وأصبح رئيس استوديوهات Glass Glass في أوستن ، والتي لم يكن أحد يعرفها بعد ذلك. صنع هذا الاستوديو منافذ لألعاب Mac ، مثل Links 386 Pro . كانت أيضًا بصدد تطوير لعبة الغولف الخاصة بها والتي تسمى بطولة الجولف البريطانية المفتوحة.

كان Origin لا يزال يطور Ultima Online. كانت تُلقب بـ Multima ، ويبدو أنها استخدمت محرك Ultima VII. لقد جربته قليلاً حتى تركت Origin وانضمت إلى Warren in Looking Glass.

[ملاحظة المؤلف: كان الاستوديو الرئيسي لـ Looking Glass في كامبريدج ، ماساتشوستس ، بالقرب من بوسطن]

كتب وارن وثيقة تصميم ، وعملنا لبعض الوقت في لعبة لعب الأدوار مع الاختصار AIR (من لعب الأدوار عبر الإنترنت في أوستن) ، والذي كان من المفترض أن يكون مشروعًا عبر الإنترنت. أردنا أن نفعل شيئًا ثلاثي الأبعاد ، لأنه بينما بدأت مسرعات 3D في الظهور. حصلنا على نموذج أولي لـ Voodoo 1 وكتبنا محركًا صغيرًا على GLide.

عقدنا شراكة مع مكتب Looking Glass's Cambridge. بعد إطلاق بطولة بريطانيا المفتوحة ، ساعدت مارك ليبلانك وكنيسة دوغ بمحرك لص يدعى Dark Engine .

لأسباب مالية وأسباب أخرى ، لم يكن Look Glass يشعر بتحسن كبير في ذلك الوقت. كان لدى الشركة ألعاب مذهلة ، لكنها كانت تباع بشكل سيئ. لذلك ، بعد حوالي عام ، تقرر إغلاق المكتب في أوستن.

[ملاحظة المؤلف: كريس محق تمامًا بشأن الألعاب - استقبل المنتقدون Ultima Underworld و System Shock و Terra Nova بشكل جيد جدًا ، وكانوا من أفضل الألعاب في التسعينات]

في الوقت الذي تم فيه إغلاق المكتب ، كان هناك القليل منا: Warren ، وأنا ، Al Yarusso ، Harvey Smith ، Steve Powers. ما زلنا نرغب في العمل على لعبة لعب الأدوار هذه. بعد إغلاق المكتب ، عقدنا بعضنا البعض لمدة ستة أشهر تقريبًا ، على أمل أن نتمكن من تأسيس شركة جديدة ونفعل شيئًا. كان لدينا وثيقة تصميم جيدة للغاية ، وبدأنا "ببيعها" للناشرين والتواصل مع أشخاص مختلفين. لا أتذكر حتى جميع الناشرين الذين اتصلنا بهم. أحد هؤلاء الأشخاص كان جون روميرو وتوم هول ، الذين عملوا مع إيدوس على إنشاء استوديو جديد في دالاس يسمى Ion Storm.


عرفت جون من السنوات الأولى من الهوية. في عام 1991 ، في دالاس ، أقامت MTV حفلة سفينة ضخمة مخصصة لـ Wolfenstein 3D. كان هناك جهازان من ماكينات الواقع الافتراضي VR . في ذلك الوقت كنت طفلة وفكرت ، "يا إلهي ، هذا أروع شيء في العالم!" قابلت جون مرة أخرى في الأيام التي عاش فيها بأسلوب "أنا غني جدًا لدرجة لا تقلق بشأن أي شيء."

جون هو شخص رائع ، لقد عملت معه في Monkeystone Games ، وساعدت في تطوير اللعبة لـ Gameboy Advance ، لكن هذه قصة أخرى.

[ملاحظة المؤلف: كانت اللعبة تسمى Hyperspace Delivery Boy. بالنسبة لـ Gameboy Advance ، كان من المفترض أن تنشرها Majesco ، ولكن في اللحظة الأخيرة رفضت الشركة الإفراج عنها.]

تحدثنا مع روميرو وتوم هول وهم: "وارن ، أنت رائع ، لنصنع هذه اللعبة!". ورد وارن: "هناك عقبة. لن ننتقل إلى دالاس. لن ننتقل إلى كاليفورنيا. لن نتحرك في أي مكان على الإطلاق. سنبقي الاستوديو في أوستن. لذلك سنبقى مستقلين تماما. ستعطيني السيطرة الكاملة على كل شيء. سوف تعطيني المال ، وكل شيء سيكون على ما يرام ". أجابوا: "حسنا ، هذا يناسبنا. محلولة ".

[ملاحظة المؤلف: من الواضح أن هذه نسخة مبسطة للغاية من المفاوضات ، لكنها تعطي فكرة عما حدث]

كان لدى Warren مستند تصميم رائع للعبة Troubleshooter في ذلك الوقت ، والتي تحولت تدريجيًا إلى مستند تصميم Deus Ex.

لذا ، أسس ستة منا أيون ستورم أوستن. في ذلك الوقت كنت المدير الفني ورئيس قسم تكنولوجيا المعلومات "Homo Arom" ، خدمة الأمن والمهندس الرائد. لم يكن لدينا عدد كاف من الناس للقيام بكل هذه الأشياء. لذلك ، كان من الضروري إجراء المقابلات وتعيين الموظفين بسرعة.

كان الفريق صغيرًا. كان لدينا ثلاثة مهندسين: أنا سكوت مارتن والياسارسو. تم تعيين شيلدون باكوتي ككاتب سيناريو. كان لدينا فريقان للتصميم يتألف كل منهما من ثلاثة أشخاص. قاد روبرت روبرت واحد ، والثاني هارفي. يبدو أن هناك ستة فنانين آخرين بقيادة جاي لي.

أوه ، وقمت أيضًا بتعيين أليكس براندون لأنني كنت من أشد المعجبين بموسيقاه لـ Unreal. الآن نحن أصدقاء رائعون. تعرفت عليه لزوجته المستقبلية ، لأننا كنا أصدقاء في المدرسة الثانوية. إنه رجل رائع: موسيقي ممتاز ومتمرس في التفاصيل الفنية.

ثم قمنا بتعيين مسؤول ، وهذا كل شيء. ثم واجهنا عمل جهنمي لمدة عامين ونصف! [يضحك]

الاختيار بين محركات Unreal و Quake

JL: لذا ، بينما عملت بقية Ion Storm مع محرك الزلزال ، اخترت Unreal. هل يمكن ان توضح كيف جئت لهذا القرار؟

KN: بغض النظر عن مدى احترام محرك الزلزال ، كنت أعرف أنه في ذلك الوقت لن يكون لدينا أي دعم. لقد أنشأنا لعبة محددة للغاية حيث أردنا أن نكون قادرين على القيام بأي شيء. الزلزال كان مطلق النار ، وليس أكثر. إذا حاولنا القيام بشيء آخر غير FPS ، فسوف يستغرق الأمر الكثير من العمل ، ولن نتلقى الدعم من Id. قاموا ببساطة بحرق قرص مضغوط مع الرمز ، وأعطوه للمطورين ، وتركوه وشأنه.

جيه إل: في مقابلتي مع تيم سويني ، أطلق على نموذج ترخيص محرك الزلزال في ذلك الوقت "عملية نسخ ربع مليون دولار."

KN: نعم ، على حق تماما! أوافق ، المحرك كان مذهلاً. في ذلك الوقت ، قام بثورة ، لكننا عرفنا أن فريقًا من ثلاثة مهندسين لن يتمكنوا من إعادة كتابة المحرك ولا يمكنهم كتابة محركك الخاص. ببساطة لن يكون لدينا ما يكفي من الوقت.

في وقت من الأوقات كنت من أشد المعجبين بالمشهد التجريبي Amiga و C64 و PC. بدأت بمشاهدة لعبة فيديو تسمى Unreal وفكرت ، "يا إلهي ، نعم هناك إضاءة RGB و 3D كاملة. يستخدم المحرك MMX و SSE و 3DNow. يبدو رائعًا جدًا! " لكننا لم نتمكن من العثور على معلومات مفصلة عنه ، لذلك خططنا لرحلة إلى Digital Extremes في لندن (كندا). التقينا مع تيم وفريقه ، وأظهروا لنا جميع ميزات المحرك. قابلت أيضًا كارلو فوجيلسانج ، الذي أعمل معه الآن مع سوني - وهو في قسم بلاي ستيشن. كتب محرك الصوت في Galaxy: كل شيء تقريبًا في المجمع ، وهو رجل فائق المتشددين. المحرك لديه نظام جزيئات يسمى النار. كل هذا كان داخل المحرك. فكرت ، "يا شباب ، أنا أحب نهجكم."


في ذلك الوقت ، ركزوا على إنشاء أدوات فائقة الراحة لم يفعلها أحد من قبل. كانت أدوات الزلزال جيدة ، ولكن بالنسبة للمستخدمين غير التقنيين ، كانت تبدو غير ودية للغاية. كان لدينا مصممين ليس لديهم مهارات هندسية ، وكان عليهم معرفة كيفية استخدام هذه البرامج.

لذلك قررنا: "هؤلاء الرجال لديهم أدوات جيدة ، الجميع يساعدنا كثيرًا ، وهناك الكثير من شباب المدرسة القديمة الذين كتبوا أشياء رائعة في الثمانينيات. كيف يتم ترتيب الترخيص؟ " فأجابوا: "لم نفعل هذا من قبل ، فهذا أمر جديد بالنسبة لنا". أعتقد أنهم في ذلك الوقت لم يفهموا كيفية إنشاء نموذج ترخيص. قلنا: "لدينا وارن سبيكتور ، ويريد إنشاء لعبة على محركك". عندما سمعوا ذلك ، أصبح من الواضح أنهم يريدون حقًا العمل معنا.

بصراحة ، لا أتذكر تفاصيل اتفاقية الترخيص الخاصة بنا. ربما يتذكر تيم. لا أتذكر كم دفعنا ، لكنني لا أفكر كثيرا ".

JL: ربما يمكن مقارنته بعدد المعرفات الذي طلب الزلزال في ذلك الوقت؟

KN: أعتقد أقل! وكان هذا إضافة أخرى. كان محركهم جديدًا نسبيًا ، لكننا لم نكن المرخصين الأوائل. واحدة من أولها كانت Wheel of Time و Klingon Honor Guard.

[ملاحظة المؤلف: يمكنك قراءة المزيد حول تاريخ ترخيص Unreal Engine في مقابلتي مع Tim Sweeney حول Unreal Editor ]

لذلك ، قررنا اختياره. أعطانا المطورون شفرة المصدر وقالوا: "سندعمك في أقرب وقت ممكن". تحدثنا دائما وجها لوجه. إذا كان لدينا سؤال ، فقد أرسلنا بريدًا إلكترونيًا: لم يكن هناك نظام دعم فني.

كان لدينا الكثير من المشاكل لأنهم لم يفعلوا ذلك من قبل. أرسلنا لهم الكثير من التعليمات البرمجية والأسئلة ، وكان لدينا مراسلات طويلة وتلقى تحديثات. لكن أعتقد أنه كان القرار الصحيح. أعتقد أنه إذا اخترنا Quake ، فسيكون إنشاء اللعبة أكثر صعوبة.

بالإضافة إلى ذلك ، أصبحت عضوًا في مجموعة Unreal Tech الاستشارية. توصلنا إلى فكرة الاجتماع التقني الأول ، الذي اجتمع فيه رؤساء جميع الشركات التي أصبحت مرخصًا لها (كان هناك أربعة في ذلك الوقت) ، وناقشوا طرق تحسين المحرك ، وبخ تيم لجوانب غير ملائمة ، تم حلها بالكحول والطعام ، حسنًا ، كل شيء مثل عادة. ما زلت على اتصال مع كل هؤلاء الناس.

JL: هل شاركت أي شيء مع أعضاء آخرين في Unreal Tech Advisory Group؟

KN: أعتقد أننا شاركنا بشكل رئيسي التحسينات على محرر Unreal. كان المحرك ممتازًا ، ولكن لا يزال أمامه طريق طويل. ثم ، عندما تمكنا من توظيف المزيد من المصممين والفنانين ، بدأوا أيضًا في تقديم اقتراحات لتحسين عمليات العمل. قمنا إما بتنفيذها بأنفسنا ، أو أرسلناها إلى فريق Unreal ، أو سألنا فريق Unreal إذا كان بإمكانهم القيام بذلك بشكل أسرع مما فعلنا.

لقد أجرينا العديد من التغييرات على المحرر الرئيسي ، ولكن معظمها يتعلق فقط بلعبتنا. شاركنا بعض التحسينات ، ولكن معظم المطورين الآخرين شاركوا في ألعاب مختلفة تمامًا.

كان علي أن أكتب مجموعة من الأنظمة التي أعتقد أنها كانت الأولى من نوعها. على الأقل لم أرهم من قبل. على سبيل المثال ، نظام خلط الرسوم المتحركة ؛ هذا هو ما يسمى أهداف الأشكال أو مزج اليوم. لا أتذكر أي شخص يفعل ذلك في الألعاب في ذلك الوقت. ربما تم تنفيذه بالفعل في مكان ما ، ولكن قبل الاستخدام الواسع للإنترنت ، كان تبادل المعلومات صعبًا للغاية.

JL: هل يمكنك التحدث عن التغييرات التي أجريتها على محرر Unreal؟

KN: أحد الأنظمة ، التي لم تكن في المحرر في ذلك الوقت لسبب ما ، هي تصور أجزاء الكاميرا.

في الإصدارات الأولى من UnrealEd ، كان عليك سحب الكاميرا وتعيين نقاط مسارها. في هذه الحالة ، كان من الممكن رؤية النقاط ، ولكن ليس الروابط بينها ، والتي تحدد مسار الكاميرا.


JL: إنها مثل لعبة نقطة إلى نقطة ، ولكن بدون أرقام!

KN: بالضبط! كان للخط الفقري نقاط توقف ولم يتمكن المصممون دائمًا من معرفة الشكل الذي سيبدو عليه المسار. أرادوا أن يعرفوا بدقة كيف ستتحرك الكاميرا على طول الطريق. لذا أضفت هذا النظام ، وقد أحبوه.

كانت بسيطة للغاية. أعني بساطة الكود: ارسم محاور الإحداثيات عند كل نقطة تحكم رئيسية ، ثم ارسم نقطة التحكم لترى بالفعل أين ذهبت. لقد ساعد المصمم حقًا ، وكان إنشاء مثل هذا النظام بسيطًا جدًا. لا أعرف لماذا اضطررنا لإضافته. أعتقد أن تيم لم تعتقد أنها ستكون مطلوبة حقًا.

DL: هذا مضحك لأنه إذا تذكرت العرض التوضيحي الأول لـ Unreal للجمهور ، فإن أول شيء شاهده الناس كان كاميرا تطير حول القلعة ، أي أن Epic لم يبد أن هناك أي مسارات للكاميرا.


KN: أعتقد أن السبب هو أن العديد من مصممي المستوى كانوا تقنيين عظمى وكانوا يستخدمون لمحاكاة مثل هذه الأشياء في رؤوسهم. لكن صناعة ألعاب الفيديو تنضج تدريجيًا ، لذلك كان من الضروري إنشاء أدوات للأشخاص ذوي مستويات مختلفة من الخبرة. لم يكن كل مصمم مهندسًا ، واليوم أكثر من ذلك! كان هذا هو الاستثناء وليس القاعدة. لذلك ، يجب أن تصبح الأداة مريحة وبسيطة.

بالمناسبة ، ما زلت لا أعرف لماذا يرمز إلى Pawn من قبل رأس ديناصور.

جوليان: [يضحك] نعم ، ناقشنا أنا وتيم هذا في مقابلة! بالمناسبة ، هل ندمت على أي قرارات تكنولوجية اتخذتها؟

KN: استخدمنا UnrealScript أكثر من اللازم. كان هذا أحد الأخطاء. كان UnrealScript مرنًا جدًا ، ولكنه بطيء جدًا. لقد احتجنا إلى كتابة عدد أكبر بكثير بلغة C الأصلية مقارنة بـ UnrealScript.

الشمال الحقيقي ومواطن الخلل وهمية

[ملاحظة المؤلف: في هذه المرحلة من المقابلة ، فتحت Deus Ex Editor (إصدار UnrealEd) ، بالإضافة إلى وثائق Deus Ex SDK]

JL: يحتوي مثبّت Deus Ex SDK على مجلد مستندات يحتوي على ملفين من وثائق التوثيق ، أنت روبرت وايت وشيلدون باكوتي و Al Yarusso وسكوت مارتن ترعاهم. هل يمكنك معرفة من هم هؤلاء الأشخاص وما الذي عملوا عليه؟

KN: شارك آل في محرر الحوار. عمل سكوت على الذكاء الاصطناعي. فعلت ... كل شيء . [يضحك] من بين أمور أخرى ، كنت مساعد مخرج ومبرمج رئيسي. لكننا فعلنا القليل من كل شيء ، لأنه في المشروع بأكمله من البداية إلى النهاية لم يكن هناك سوى ثلاثة مهندسين.


كريس نوردن (أسفل اليسار) ، إل ياروسو (يمين وأعلى كريس ، مع ساعة في يده) ، روبرت وايت (الصف الأوسط ، على يمين المركز قليلاً ، يرتدي نظارة شمسية) ، شيلدون باكوتي (أسفل اليمين) وسكوت مارتن (في الثانية الصف ، أقصى اليمين ، أيضًا في النظارات الشمسية)

DL: هناك قسم في وثائق المحرر يقول "Unreal ليس لديه دعم أصلي للسلالم العمودية ، ولكن تتم إضافتها إلى Deus Ex." هل يمكنك أن تخبرنا المزيد عن هذا؟

KN: السلالم هي قصة مثيرة للاهتمام ، لأنه كان علينا أن نتحرك حول المستوى ، وفي الرماة من منظور الشخص الأول في ذلك الوقت ، تم استخدام السلالم المائلة والصعود الناعم لهذا الغرض.

قال أحد مراسيم وارن (لأن التصميم هو القانون!) أنه يجب على اللاعب أن يكون قادرًا على إكمال أي مهمة بأي شكل من الأشكال. كانت الفكرة الرئيسية للعبة أنه إذا كنت ترغب في ذلك ، يمكنك المرور بها بالكامل ، وعدم إطلاق النار أبدًا. في الواقع ، لم ننجح تمامًا - هناك العديد من المناطق التي تحتاج إلى إطلاق النار عليها عدة مرات ، لكننا كنا قريبين جدًا.

DL: أعتقد أن المطورين نجحوا في التسلسل.

KN: نعم ، ربما.

لذا ، كان من المفترض أن يتمكن اللاعب من خوض المباراة بأكملها دون إطلاق طلقة. بالإضافة إلى ذلك ، يمكنه الذهاب إلى اللعبة بأكملها دون القيام بأي شيء بخلاف الرماية. يمكن للاعب المرور باللعبة بأكملها حتى لا يكتشفها العدو مطلقًا. كان من الممكن المرور بها بطرق مختلفة تمامًا.

جيه إل: هل كان نقص السلالم العمودية أحد الموضوعات التي ناقشتها مع تيم في اجتماعات مجموعة Unreal Tech الاستشارية؟

KN: للإجابة ، أحتاج إلى العثور على رمز البرنامج النصي والبحث فيه سواء كان يقول "Fuck you، Tim!" [يضحك] ، لأن هذا بالضبط ما فعلناه عندما كنا غاضبين - قمنا بكتابة التعليقات لنتذكر ذلك لاحقًا.

عندما بدأنا في التفكير في كيفية إضافة دعم للسلالم الرأسية ، فكرنا أولاً "دعونا ننشئ الشكل الهندسي ، وبعد ذلك ربما يمكننا القيام بحيل مادية صعبة حتى يتمكن اللاعب من الإمساك بالقضبان باستخدام الرسوم المتحركة المتزامنة". ولكن بعد أن قررنا - حسنًا ، كل هذا إلى الجحيم ، معقد جدًا.

JL: [يضحك]

KN: كان علينا القيام بذلك بسرعة كبيرة ، لأن المصممين طالبوا بإنشاء هذه الميكانيكا.

لذلك ، كنتيجة لذلك ، كان علي أن أذهب إلى الاختراق الجهنمي. المحرك لديه مفهوم "مجموعات الملمس". بشكل أساسي ، هو عبارة عن سلسلة نصية يتم تعيينها لأنواع معينة من الأنسجة لتسهيل فرزها. يمكننا طلبها في التعليمات البرمجية. لذا فكرنا: "لماذا لا يصنع الفنانون بعض القوام حتى يمكن تسلقهم؟" بعد ذلك ، قمنا ببساطة بإضافتهم إلى مجموعة النسيج ، وقمنا بإجراء أشعة للتعرف عليهم ، ثم ببساطة مع بعض القيود التي تمسك اللاعب بها في اتجاه حركته. كان هذا يعمل بشكل جيد ، ولكن ليس دائمًا مثاليًا ، لأنه عندما صعد اللاعب إلى الجزء العلوي من النسيج ، لم يعد ينبعث الشعاع فيه ، وتعين علينا دفع اللاعب إلى أعلى وإلى المنصة. أي أن الحل غير كامل ، ولكن نتيجة لذلك نجح. لقد كان اختراقًا رخيصًا وسهلاً.

قد يفكر قراء اليوم: لماذا لم يكن هناك سلالم في المحرك ، هل هذا منطقي؟ ولكن في تلك الأيام لم يكن هناك شيء. كانت هذه مجرد أجزاء BSP ، لم يكن لدينا شبكات ثابتة ، لم يكن هناك شيء من هذا القبيل.


جيه إل: كان لدى UnrealEd مولد سلم حلزوني رائع جدًا (يضحك) ، ولكن لم يكن هناك سلالم رأسية.

KN: نعم ، صحيح ... يبدو أننا وبخنا المصممين لاستخدامه ، لأنه خلق ثقوبًا في BSP. بدا الدرج جميلًا إذا لم يكن هناك شيء قريب. ولكن بمجرد أن تبدأ في صنع شرائح زاوية في BSP ، يمكنك الحصول على ثقوب صغيرة في BSP يمكنك من خلالها السقوط ، ولكن الثقوب نفسها غير مرئية. تسببت هذه الوظيفة في الكثير من الألم وحظرنا استخدامها. بدت جيدة ، لكنها كانت مكسورة ...

DL: تصف الوثائق أيضًا فئة تسمى DeusExLevelInfo تحتوي على معلومات حول الخريطة (على سبيل المثال ، هل هي متعددة المستخدمين) ، واسم مؤلف الخريطة ، والمكان الذي تم فيه إكمال المهمة ، ورقم المهمة ، وما إلى ذلك. ولكن أود أن أسألك عن TrueNorth.

KN: [يضحك] كان نوع BAM من محرك Unreal: Binary Angle Measurement!

JL: ما هذه الأرقام المجنونة ؟!

KN: في ذلك الوقت ، كانت عمليات النقطة العائمة مكلفة للغاية. كانت المكواة ضعيفة ، لكنها لم تكن ذاكرة كافية. لم يتم وصف 360 درجة برقم 8 بت ، مما سيوفر 255 وحدة من الدقة ، أي حوالي 1.4 درجة للوحدة ، وهو ما لن يكون كافيًا. استخدم Tim رقم 16 بت للتوجيهات ، مما وفر دقة أكبر.

بالنسبة للمبرمج ، كل هذه الأرقام بسيطة للغاية. هذه مجرد قوى لاثنين ، لا توجد مشاكل ، يمكنك حسابها كلها في رأسك. لكن المصممين والفنانين يواجهون مشاكل. لذلك ، توصلنا إلى تبسيط صغير لمساعدة المطورين على تذكرها.

[بينما كنا نعمل مع المحرر ، وصل كريس إلى فصل الزينة]



KN: كانت الزخارف أيضًا فئة ضخمة. جميع الشبكات التي يمكنك التفاعل معها هي الزخرفة. أي أن كل شيء تقريبًا في اللعبة!

جيه إل: في قسم "الزينة" من الوثائق ، تقول "نحذرك من أنه إذا قمت بتغيير بعض الحقول غير المدرجة أدناه ، فقد يتعطل المحرر". لا تتذكر لماذا حدث هذا؟

KN: [يضحك] بصراحة ، لا أتذكر. أعتقد أن الديكور كان فئة كبيرة جدًا ، وكان به العديد من وظائف Epic التي تفاعلت مع المحرك بطريقة غريبة ، فبدلاً من شرح المصمم الذي لا يفهم الخفايا الفنية لماذا يمكن أن يؤدي مجال معين إلى سلوك غير متوقع ، فإننا ببساطة قالوا "لا تستخدمه ، وإلا تعطل المحرر".

JL: [يضحك]

KN: شيء من هذا القبيل تكتيكات الخوف. في اجتماعات المبرمجين ، تساءلنا: كيف نوضح للمستخدمين أن هذا سيؤدي إلى تلف سلسلة BSP ، وأنت بحاجة إلى القيام بذلك وذاك؟ دعنا نقول لهم فقط أن المحرر سوف ينهار.

يجب أن أدرس الشفرة مرة أخرى ، ولكن يبدو أننا مذنبون حتى بإخفاء حالات الفشل المتعمد في بعض الأماكن من أجل تخويف المستخدمين الذين يتعرضون للخداع بعمق.

JL: دعنا ننتقل. يقول قسم ParticleGenerator ، "إحدى الوظائف الرئيسية هي أنه يمكن تشغيلها وإيقاف تشغيلها باستخدام المشغلات و unTriggers." أي أنه في إصدار المحرك غير الواقعي الذي عملت معه ، كان من المستحيل تشغيل وإيقاف تشغيل الجسيمات؟

KN: في ذلك الوقت ، لا. إذا قمت بإدخال نظام جسيمات ، فإنه موجود باستمرار ولا يتم إيقاف تشغيله أبدًا. يبدو لي أن هذا إشراف غريب.

خلاف ذلك ، كان نظام الجسيمات غير الواقعية رائعًا. تمت كتابة معظمها في المجمع. كان إجرائيًا ، ومكتوبًا بشكل جيد جدًا مقارنة بكل شيء آخر. أحبها المصممون. في الواقع ، حتى أكثر من اللازم. كان من الممكن قتل معدل الإطارات بالكامل ، وقد أصيبوا بالجنون ، مضيفين المزيد والمزيد من الطبقات الشفافة.

في ذلك الوقت ، كان لا يزال يتعين علينا دعم عرض البرامج ، بينما لم يكن عرض الأجهزة منتشرًا بعد. كان تيم يتمتع بمهارات برمجة مذهلة وكتب عارضًا رائعًا للبرامج ، وكان رائعًا.

[بالنظر إلى كائنات مختلفة في اللعبة ، لاحظت فئة تحمل اسمًا غير معتاد في لوحة الخصائص]

DL: ما هي هذه الخاصية المميزة؟

KN: الحيوانات بحاجة إلى رائحة لأخذ أثر. في الواقع ، يمكن للكلاب تتبع عقد الرائحة. إذا كنت أتذكر بشكل صحيح ، ثم انتقل من خلال المستويات ، يمكن للاعب ترك عقد الرائحة التي كانت نشطة لفترة معينة. لذلك ، نجحنا حتى تشمه الكلاب.

DL: هذا إذا كنت تختبئ خلف صندوق ، فلن يجدك الناس ، ولكن يمكن للكلاب ...

KN: على وجه التحديد لأن هذا هو ما يحدث في الواقع ، واعتقدنا أنه سيكون جانبًا مثيرًا للاهتمام في اللعبة. ومع ذلك ، يبدو أنه تم قطعه في النهاية. نظرًا لعدم وجود ملاحظات رسومية ، كان من الصعب شرح هذا المفهوم للاعب.



[ Intro, — , . ]

: . . ...



KN: لا ، كانت المرايا حقيقية! كانت بطيئة جدًا ، لذلك طلبنا من المصممين استخدامها نادرًا ، ومع ذلك ، هذه مرايا حقيقية.

في الواقع ، عندما كتبت رمز الليزر ... [يضحك]

DL: [يضحك] أرى ما تحصل عليه ...

KN: ... كان علي بالفعل التحقق من المرايا. كان لدي مستوى اختبار حيث اختبرت الرمز لجميع الأجهزة. عندما كتبت رمز مؤشر الليزر ، أنشأت كرة ديسكو مرآة عاكسة ، ثم بنيت غرفة بها مرايا على كلا الطرفين. أخذت مؤشر الليزر ، وجهته إلى كرة الديسكو ، وعملت!

بالطبع ، انخفض معدل الإطارات إلى ما دون أي مكان ، لأنني اضطررت إلى تتبع جميع الخطوط ...

راجع Light Light: LWO23D Command Line Tool

[ملاحظة المؤلف: LWO تعني كائن Lightwave. هذا هو التنسيق الهندسي ثلاثي الأبعاد لحزمة برامج Lightwave 3D من Newtek ، ومقرها أيضًا في تكساس ، مثل فريق Deus Ex في ذلك الوقت]



لقطة شاشة من Tack's Deus Ex Lab

JL: لماذا قرر فريقك استخدام Lightwave؟

KN: عرفه فنانونا جيدا. لذلك ، كان علينا التكيف.

جيه إل: أخبرنا المزيد عن سبب كتابة المصدر كأداة سطر أوامر.

KN: في ذلك الوقت ، وحتى الآن غالبًا ما أكتب أدوات سطر أوامر صغيرة لأتمتة المهام. أنا مبرمج في المدرسة القديمة ولا أحب المضاعفات غير الضرورية. أنا في الغالب لا أحب C ++. لا أحب الأنماط. لا أحب كل شيء يستغرق وقتًا.

عندما أكتب أدوات سطر الأوامر ، أقوم بإنشاء ملف دفعي Win32 ، والتخلص من كل شيء مضمن ، ابدأ بملف فارغ ، مع int main() ، وانتقل فقط. هذا حل سريع ومحمول لا يسبب مشاكل.

DL: أعتقد أن تصدير الشبكات الثابتة كان عملية قياسية إلى حد ما. ولكن أخبرنا كيف قمت بتصدير الرسوم المتحركة.



لقطة شاشة من Tack's Deus Ex Lab

KN: لم يكن هناك رسوم متحركة للهيكل العظمي في اللعبة. لا أعرف محرك واحد من العصر الذي يتم تنفيذه فيه. لذلك ، تم عمل كل شيء عن طريق خلط القمم. كان الجلد باهظ الثمن في ذلك الوقت. لا توجد GPUs ، كان يجب حساب كل شيء على وحدة المعالجة المركزية وبأي وسيلة تجنب حسابات الفاصلة العائمة.

داخل Lightwave ، أنشأ المصممون رسومًا متحركة للهيكل العظمي ، ثم عرضوا إطاراتها الرئيسية. كان من الضروري إنشاء T-pose ، لأنه لخلط الرسوم المتحركة كان من الضروري البدء من أساس مشترك. هذا هو ، بالنسبة للمزيج الصحيح ، كانت الرسوم المتحركة هي في الأساس تعويضات من T-pose. تم إجراء الخلط على جانب المحرك.

JL: إذن ، في Unreal ، كل شيء فعل الشيء نفسه؟

KN: نعم ربما. لا أعتقد أن تيم أضاف الرسوم المتحركة الهيكل العظمي إلى الإصدار التالي.

يتحدث رؤساء: ConvEdit و Lipsink

[الآن نفتح مجلد ConvEdit]


JL: أخبرنا عن ConvEdit

KN: كان من بنات أفكار Al ، كتبه في Visual Basic.

JL: مثل UnrealEd في ذلك الوقت.

نعم ، في تلك الأيام ، لم تكن هناك فرص كثيرة للتنفيذ البسيط للواجهة. كان هناك دلفي والعديد من أطر عمل واجهة المستخدم الأخرى. إذا لم تستخدمها ، فسيتعين عليك كتابتها جميعًا ، على سبيل المثال ، على Win32 API و GDI وكل ذلك. لقد كانت مشكلة كبيرة.

هذا هو ، Visual Basic ، الذي يبدو اليوم بدائيًا إلى حد ما ، في ذلك الوقت كان جيدًا جدًا - إطار مرئي بسيط بلغة البرمجة الخاصة به ، على غرار Basic ، سلف C #. سمح لنا بوضع نماذج أولية وكتابة الأدوات بسرعة كبيرة.

[ملاحظة: إذا كنت مهتمًا بكيفية استخدام Visual Basic في أدوات تطوير الألعاب في تلك الحقبة ، فاقرأ مقابلتي مع Tim Sweeney حول Unreal Editor ]

تم استخدامه بشكل رئيسي من قبل شيلدون. كان بحاجة إلى أدوات للتحكم في الكاميرا وأدوات للتحكم في الأصوات. أراد استخدام العديد من الأدوات السينمائية التي لم يستخدمها أحد من قبل. تعلمت لأول مرة ما هو تقريب المنصة ، والعمل على هذه اللعبة مع شيلدون.

أعتقد أن هذه الأداة لا تزال تستخدم حتى اليوم.

بالمناسبة ، كان شيلدون مصابًا بمتلازمة نفق الرسغ (RSI ، إصابة الإجهاد المتكرر) ، لذلك أصبح الختم تعذيبًا له. عمل تقريبًا بشكل كامل على Deus Ex باستخدام النسخ الصوتي في Dragon Dictate ، والذي كان في ذلك الوقت أسوأ بكثير من اليوم. حتى اضطر شيلدون إلى ارتداء أجهزة التقويم ، لأن المتلازمة كانت قوية جدًا.




JL: واو! لم اكن اعرف. تحتوي اللعبة على العديد من الحوارات ومجموعة من الفروع ...

KN: كمية هائلة من البيانات ، حتى لمهمة واحدة.

أراد شيلدون أن يكون له سيطرة قوية على اللعبة والعديد من الحوارات التفاعلية. أراد أن يقوم اللاعب باختيار هادف. كره هو ووارن الاضطرار إلى النقر من خلال الحوارات دون اختيار. أرادوا أن يتفاعل اللاعب مع الشخصيات ويختار أشياء مهمة ، بحيث تضع اللعبة الأعلام وتذكر كيف تفاعل مع الشخصيات وتصرفاتهم خلال المقطع.

JL: منذ أول جولة تجريبية لـ Deus Ex ، أتذكر موجز Anna Navarre في مكتبها. كالعادة في أي لعبة فيديو ، بدأت أتجول في المكتب لأقوم بكل أنواع الهراء حتى تنتهي الشخصيات غير الرسمية من حوارها. فجأة أوقفت حوارها ، والتفت إلي وسألت: "ماذا تفعل؟"

KN: [يضحك]

دل: لثلاجة تجمدت وسألت نفسي: "هل هذا ما حدث حقا؟" لقد كان حدثًا مهمًا بالنسبة لي من حيث الانغماس في اللعبة. لا لعبة واحدة قبل أن تلتقي هذه اللعبة على الإطلاق. أظن أن هذا يرجع جزئيًا إلى محرر المحادثة.

KN: كان أحد مبادئ وارن: "إذا كان اللاعب في مكتب شخص ما ، يتصرف مثل الحيوانات ويكسر الأشياء ، فيجب على الشخصية أن تقول شيئًا!" لا يجب ان يتجاهل اللاعب لانه غير واقعي ".

جيه إل: هل كانت هناك أي جوانب متعلقة بالقصاصات تبين أنه من الصعب بشكل خاص إنشاء أدوات؟

KN: كان لدينا الكثير من الحوارات ، وتم التعبير عنها جميعًا. قضينا أسابيع في حوارات تسجيل استوديو التسجيل مع الممثلين. هذا يعني أننا بحاجة إلى التفكير في مزامنة حركة الشفاه (lipsyne). فكرت: "كيف تصمم ليبكينك للعديد من الحوارات؟" بعد كل شيء ، لم يكن لدينا فقط مجموعة من العبارات ، ولكن أيضًا العديد من اللغات.

في ذلك الوقت ، لم يكن هناك العديد من الأدوات للمساعدة في التجصيص. قام معظم المطورين بمعالجة مسبقة: قاموا بتشغيل مربع الحوار في الأداة وعرض ملف بيانات ثم تشغيله مرة أخرى. لكنني قررت: "لن يكون لدينا الوقت لذلك ، وإذا كان عليك إعادة تسجيل الصوت ، فستحتاج إلى إعادة معالجة كل شيء مرة أخرى."

لذلك بدأت أفكر أنه يجب أن تكون هناك طريقة للقيام بذلك في الوقت الحقيقي باستخدام التحليل الصوتي الديناميكي. في الكلية ، درست الهندسة الكهربائية ، وقررت اكتشافها بنفسي ، دون إخبار أي شخص.

JL: [يضحك]

KN: فكرت: "دعونا نرى ما إذا كان يمكنني القيام بذلك ومفاجأة الجميع." مرة أخرى ، لا أعتقد أن أحدًا قد فعل شيئًا كهذا من قبل ، ولكن هذه التقنية موجودة اليوم في كل مكان.

في ذلك الوقت ، من بين كل ما رأيته ، كان نصف العمر هو الأقرب إلى مثل هذا النظام. استخدم المطورون تقنية تتبع المغلفات ، والتي كانت حرفياً هذه: افتح وأغلق فمك اعتمادًا على حجم الصوت. نجح النظام ، لكنه لا يبدو واقعيًا جدًا.

جوليان: في الواقع ، كان ذلك بمثابة "ارتعاش الفك".

KN: نعم ، بالضبط ، بالضبط.

أتذكر أنني ناقشت ذات مرة مع غابي نيويل كيف أنجزوا هذه المهمة ، وقال: "أوه ، فقط استخدم Envelope Follow ، وسيكون ذلك كافيًا. كل شيء آخر سيكون معقدًا للغاية ".

ثم عدت إلى المنزل وبدأت في تقدير الحسابات الرياضية ، ثم كتبت نظامًا قام بإجراء تحويل فورييه سريع (FFT). أكرر ، في حين أن حسابات الفاصلة العائمة كانت مكلفة للغاية ، وربما كتبتُ تقريبًا صحيحًا يحاكيها.

حللت في الوقت الحقيقي قطعة قصيرة من التسجيل الصوتي واستخلصت مكونات التردد الرئيسية ، ثم ربطتها بستة إلى سبع أصوات مختلفة.

سراً ، طلبت من أحد الفنانين محاكاة عدة أشكال من المزج (مزيج الأشكال): كنت بحاجة إلى "o" و "a" وشفاه مغلقة وما شابه ذلك. سأل لماذا ، وأجبت أنه فعل ذلك ببساطة وأعطاني البيانات.



تحويل فورييه السريع (صورة ويكيبيديا) وسلسلة بريستون بلير فونيمز

جيه إل: [يضحك] يبدو أن هذه هي المباراة المثالية لمزيج الرسوم المتحركة الذي استخدمته في Deus Ex.

KN: نعم ، بالضبط ، ممتاز.

لذلك ، أعطاني البيانات ، وكتبت حسابات رياضية ، وأستطيع إرفاق النماذج يدويًا قدر الإمكان. لم أقم بأي بحث جاد ، وكان النظام مكلفًا للغاية من حيث الأداء.

لقد قمت بإنشاء مستوى اختبار برأس ضخم في المنتصف ، وأطعمتها بضعة خطوط. لقد راجعت العبارة بالألمانية والإنجليزية والفرنسية ، وكل شيء متزامن تمامًا. فكرت ، "اللعنة ، إنه لأمر مدهش! لقد نجحت بالفعل! "

لقد وجدت وارن وقلت له ، "أريد أن أريك شيئًا رائعًا." يبدو أنه فوجئ. [يضحك] سألني: "ماذا بحق الجحيم ، هل يمكننا وضع هذا في اللعبة؟ إنه رائع! "

ونتيجة لذلك ، أصدرنا لعبة مع هذا النظام ، ولكن من أجل الأداء ، كان علي أن أقطعها كثيرًا ، والتي انخفضت بسببها الجودة البصرية. ولكن كان مستوى الاختبار الأول عظيم. ما زلت أعتقد أن هذا كان أول نظام مزامنة للشفاه في الوقت الفعلي. لا أتذكر أي شخص يفعل ذلك من قبل.

ربما كان يستحق ذلك براءات الاختراع. لكني لا أؤمن براءات اختراع البرمجيات لأنني أعتقد أنها ممارسة شريرة ...

حصلت أيضًا على جدال كبير مع أحد مديري الفن في دالاس ، الذين أرادوا استخدام هذا النظام في Anacronox. كان يجب أن تخرج قبل مباراتنا. قلت: "لن أمانع في المشاركة ، لكني أريد أن تكون Deus Ex اللعبة الأولى التي تظهر فيها." قال: "لا ، يجب أن تعطينا إياها!" صرخ علينا عمليا في القاعة. أجبت ، "لا ، لا ينبغي لي" ، ودعمني وارين. حدث أن أصدرنا اللعبة أولاً ، لذلك لم يكن هذا مهمًا على أي حال. في الواقع ، أعتقد أنه نتيجة لذلك ، قاموا بشكل مستقل بتنفيذ نسختهم الخاصة من النظام ، لأننا لم نرغب في التخلي عنه. ربما كانت أنانية ، لكنني أردت أن نتخرج أولاً حتى نتمكن من إظهار هذه الميزة.

تم تطوير كل شيء آخر من إنتاج Ion Storm في دالاس: Dominion: Storm Over Gift 3 ، Daikatana ، Anacronox - تم عمل كل شيء في دالاس. تم إنشاء Deus Ex فقط في أوستن ، ولم يكن هناك سوى فريقنا ، ولا أحد آخر. كنا في فقاعة ، منعزلين تمامًا عن المكتب في دالاس ، وقد تم ذلك عن قصد. لم نرغب في العبث مع مجموعة ... سأكون صادقًا مع مجموعة من القمامة. كان هذا الفصل مقصودًا تمامًا ومهمًا جدًا بالنسبة لنا. لم يتبادل فريقنا وفرقهم التقنيات ، ولا توجد اتصالات حقيقية.

الخلاصة

DL: باختصار ، أود أن أسأل: إذا كان بإمكانك تقديم المشورة لمطوري الأدوات الذين يقرؤون هذه المقالة ، فماذا تقول؟

KN: استمع إلى عميلك. لا تكتب أبدا أدوات في فراغ. كمهندس ، قد تعتقد: "يمكنني استخدام هذه الأداة بهذه الطريقة ، وهذه الطريقة هي الأكثر فاعلية ، لذا سأكتبها بهذه الطريقة".

ولكنك دائمًا مخطئ. يجب الاستماع إلى المصممين والفنانين لأن سير عملهم مختلف جدًا. إنهم يعملون بشكل مختلف تمامًا عن البقية. لن يتم استخدام الأداة من قبلك ، غالبًا ما تكون مخصصة لهم.

DL: هل سبق لك أن قابلت مثل هذه العقلية في الفرق التي عملت معها؟ وكيف تعاملت مع هذا؟

KN: تحتاج فقط إلى إخبار المبرمجين: "لماذا تعتقد أن المستخدم لديه هذه المشكلة؟ هل تعتقد أن المشكلة في الكود؟ أو ربما المشكلة هي هيكل الشاشة؟ هل الخط صغير جدًا؟ لون زر خاطئ؟ ربما كنت تفعل شيئا غير قياسي؟ "

لأنه إذا نظرت إلى معظم الأدوات ذات التصميم الاحترافي ، فعادة ما تكون متسقة تمامًا. هناك أدلة تصميم حول كيفية عمل الأشياء.

يجب أن يكون الفريق الإبداعي قادرًا على استخدام هذه الأدوات. لا ينبغي أن يكون عليهم قراءة الوثائق. في عالم مثالي ، يجب أن يكون كل شيء واضحًا.

يوجد اليوم مصممو UX / UI ، ولكن في ذلك الوقت لم يكن هناك أي منهم ، لذلك كان علينا إنشاء تصميم الواجهة بأنفسنا ، ولكن مع تعليقات المستخدمين.

لذا ، اجلس بجوار المستخدمين وشاهد كيف يستخدمون الأداة. شاهدنا كيف تعمل في Lightwave. عندما كتبنا النسخة الأولى من الأداة ، جلسنا في مكان قريب ، ولم نطالب بما يجب فعله ، ونظرنا إليهم ، ودوّنوا الملاحظات ، مثل "كانت هناك صعوبات في هذا" أو "عليهم باستمرار الصعود إلى القائمة للعثور على ذلك" أو "ربما إنه يستحق جعله مفتاح الاختصار. " مجرد إلقاء نظرة عليهم ، والتعلم والتكيف.

أي أنك يجب أن تفكر حقًا في سير عمل المصممين. من الضروري تقليل الحركات غير الضرورية ، وتقليل الزحف في القائمة ، ومحاولة إضافة مفاتيح التشغيل السريع. لقد قمنا بالترويج بنشاط لاختصارات لوحة المفاتيح لجميع الوظائف لأنها تسرع سير العمل. في عملية تعلم الأداة ، تقوم بتسريع العمل بشكل كبير بمساعدة مفاتيح التشغيل السريع ، ولا تحتاج إلى تسلق القائمة.

لا داعي للوقوع في الفخ الكلاسيكي للمهندسين: "أعرف بشكل أفضل ، لقد كتبت الأداة ، أعرف كيف تعمل. إذا كنت لا تستطيع استخدامه ، فأنت مجرد أحمق ". هذا هو أسوأ شيء يمكن أن يحدث عند تطوير أداة.

JL: نصيحة ممتازة. شكرا جزيلا لكريس!