ما كان أول محرر غير واقعي

أصبحت العروض الاسترجاعية للألعاب الكلاسيكية شائعة مؤخرًا ، ولكن نادرًا ما تتذكر أدوات التطوير الكلاسيكية. تمكنت من التحدث مع تيم سويني حول الإصدار الأول من Unreal Editor أو UnrealEd .

BSP والمغالطات: "نحن بحاجة إلى كتابة محررنا"

ديفيد Lightbone: شكرًا لك على تخصيص الوقت للتحدث معي ، تيم! لنبدأ من الأيام الأولى لمحرر Unreal. قرأت أن جيمس شمالتز ، مبتكر Epic Pinball ، أظهر لك اللعبة التي كان يعمل عليها ، وعندما رأيتها ، اقترحت إنشاء محرر لها. هل هذا صحيح؟

تيم سويني: بالضبط! استلهم من لعبة Bullfrog Magic Carpet . جيمس هو مطور موهوب بشكل لا يصدق ، لكنه كتب فقط رمزًا بلغة التجميع ، ولم يكن يرغب في تعلم C. [يضحك] وهكذا ، كتب في مجمّع نقي هذا المحرك ثلاثي الأبعاد الذي قدم خلفية الإغاثة وأشياء اللعبة. لم يكن يريد إنشاء محرر ، لذلك صنع شجرة BSP يدويًا ووضع كبسولة على هذا الإغاثة. عندما رأيت هذا ، قلت ، "لا ، لا ، لا ، جيمس ، جيمس ... عليك أن تفعل شيئًا مختلفًا تمامًا." [يضحك]



جيمس شمالز وبولفروج ماجيك كاربت

قلت أنني سأكتب محررًا ، لذلك بدأت في إنشاء واجهة مستخدم Unreal Editor من تخطيط واجهة المستخدم في Visual Basic ، الغريب. كان لديه واجهة أوامر نصية للتواصل مع محرك C ++ الذي تم عرضه. ثم كتبت محررًا للإطار السلكي ، واستمر التطوير على هذا الأساس.

أي أنها كانت عملية دراسة مثيرة للاهتمام. اعتقدت أنني سأكتب هذا المحرر وأدمجه في أداة تقديم جيمس. سألته ذات مرة: "هل يمكنك أن ترسل لي الرمز؟ أريد أن أفهم كيفية دمج العارض ". وأرسل لي 30 ألف سطر من كود المجمع. [يضحك] في محرك العرض ثلاثي الأبعاد ، كانت هناك بعض عناصر Epic Pinball وبعض كود المجمع السابق ، الذي نسخه ببساطة. فكرت: "يا إلهي ، أي نوع من الفوضى هذا؟ لا أريد لمس هذا! " [يضحك]

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

قبل تنفيذ الإضاءة وما شابه ، كان جزءًا مهمًا من سحر الإصدارات السابقة من Unreal Editor هو إنشاء شجرة BSP في الوقت الفعلي. كانت الفكرة أنه يمكنك تغيير موضع الفرش في مساحة ثلاثية الأبعاد ، وبعد ذلك تم تحديث جميع الأعمال المتعلقة بتوليد BSPs بالكامل في الوقت الفعلي.


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

JL: بالحديث عن BSP ، كما أفهمها ، كان John Carmack من أوائل من بدأوا استخدام BSP في محركات الألعاب وكانت فكرة العمل مع BSP جديدة تمامًا في صناعة الألعاب في ذلك الوقت.

TS: كتب كارماك محررًا قويًا حقًا على NeXT . لقد قرأت جميع المعلومات عنه ورأيت لقطات الشاشة ، لكنني لم أستخدمها أبدًا. في ذلك الوقت فكرت: "واو ، كتب كارماك محرر BSP في الوقت الحقيقي!" ما لم أفهمه هو أنه في الواقع لم يعمل في الوقت الفعلي ، كان هناك عملية ما قبل التجميع وعمليات أخرى. لم أكن أعرف ذلك واعتقدت أنه أنشأ محررًا يعمل بشكل كامل في الوقت الفعلي ، لذلك كتب أيضًا نفس المحرر. [يضحك]



QuakeEd على NeXT و John Carmack

جوليان: [يضحك] ظننت أنه قوي للغاية ، لذا قبلت التحدي.

TS: نعم! نشأت العديد من ميزات Unreal بسبب سوء فهمي لما فعله الآخرون.

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

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



أمثلة على الإضاءة من غير واقعي بناءً على خرائط الإضاءة

أخذت لقطة شاشة وأرسلتها بالبريد إلى صديق من فنلندا ، عمل لدى شركة المعدات. أجاب: "واو ، هذا مذهل! لكن صورتنا هي مجرد عرض من 3D Studio Max ، لأننا لم نتمكن من فهم كيفية القيام بذلك في الوقت الحقيقي. " [يضحك]

JL: [يضحك] نعم!

[ملاحظة الكاتب: الشركة التي يتحدث عنها تيم هي Bit Boys ]

TS: أي أن محرك Unreal تحول إلى أن يكون أول محرك إضاءة حجمي في العالم ، كما أعتقد ... واستند إلى مغالطي.

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

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

جوليان: نعم ، كيف استندت فكرة BSP على مقال كتب عام 1969.

TS: بالضبط ، قبل ولادتي!

TurboPascal و Maya: إلهام غير واقعي

جيه إل: ما هي مصادر الإلهام التي استخدمتها لتطوير فلسفة تصميم Unreal Editor؟

TS: لم يكن هناك سوى مصادر قليلة للإلهام.

إذا نظرت إلى لعبة ZZT ، التي تم إصدارها في عام 1991 ، سترى المجموعة الأساسية من وظائف Unreal Engine. في جوهره ، هو محرك لعبة مع لعبة مدمجة فيه. تحتوي اللعبة على لغة نصية صغيرة ، والتي ، على الرغم من بساطتها ، كانت لغة نصية بالكامل تسمح لك بكتابة نصوص لعبة صغيرة.

[ملاحظة المؤلف: يمكن العثور على تفاصيل ZZT في كتاب Anna Anthropy الذي نشرته Boss Fight Books]

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



ZZT ، وضع اللعبة ووضع المحرر

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

هناك مصدر إلهام خطير آخر أدى إلى إنشاء العديد من عناصر التصميم للمحرك: Visual Basic ، على غرار Microsoft clone Delphi ، أي إصدار Object Pascal for Windows مع التحرير في الواجهة المرئية لـ Borland. لكنني لم أستخدم دلفي أبدًا ، لقد عملت فقط في Visual Basic.

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



TurboPascal من بورلاند

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

جانب آخر مهم في تطوير Unreal هو أن Epic اشترت العديد من محطات عمل Silicon Graphics التي أطلقت الإصدار الأول من Maya. كانت Maya قديمة تمامًا في ذلك الوقت ، ولكن كان هناك وضع ثلاثي الأبعاد تفاعلي مع مساحة خلفية زرقاء حمراء وسوداء تم رسم الأشياء والإطارات السلكية عليها في الوقت الفعلي. لا يمكن القيام بذلك بواسطة أي برنامج على الكمبيوتر ؛ كلهم عالقون في الكود القديم وأنماط واجهة المستخدم القديمة.



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

من Visual Basic إلى Slate: تطور واجهة UnrealEd

[ملاحظة المؤلف: في بداية المقابلة ، أطلقت UnrealEd 1 في جهاز افتراضي على الكمبيوتر المحمول. أعطيت Tim ماوسًا حتى يتمكن من العمل فيه.]

TS: رائع ، رائع ، لقد أطلقته بالفعل!

JL: نعم! قدمت أن الإصدار الذي نراه هنا هو Visual Basic.

TS: نعم ، نعم!

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

جيه إل: ما الذي دفعك إلى استخدام Visual Basic لتطوير واجهة الإصدار الأول من UnrealEd ، وما هي الخيارات الأخرى التي لديك؟



آلان كوبر و Visual Basic

TS: كان ذلك في عام 1995. في تلك اللحظة ، كانت أطر واجهة المستخدم لـ C ++ مروعة. كان هناك برنامج Microsoft Foundation Classes ، والذي كان الجزء الأكثر بؤسًا من واجهة برمجة التطبيقات التي يمكنك تخيلها. بدأ المستخدم في رسم عناصر تحكم النافذة وأنشأ إطار العمل كميات هائلة من كود C ++ مع أكوام من التعليقات مثل: "هنا نقوم بإنشاء عنصر تحكم لك!" إذا قام المستخدم بتحريك الكائن ، فحدث الإطار جزءًا من الرمز ، ولكن ليس الأجزاء الأخرى ، وكان ينكسر باستمرار ، لذلك قلت لنفسي: "لن ألمس هذا بعد الآن".

كان Visual Basic أداة رائعة لتطوير واجهة مستخدم يمكنك من خلالها وضع جميع عناصر التحكم وعناصر القائمة وأجزاء من واجهة المستخدم بكفاءة عالية. لقد كانت مجموعة الأدوات الأكثر إنتاجية لواجهة المستخدم التي رأيتها على الإطلاق ، ويرجع ذلك أساسًا إلى أنه كان برنامجًا واضحًا ومترابطًا للغاية: لقد رسمت واجهة مستخدم ، ونقرت عليها وأضفت رمزًا بسيطًا لتفاعلها. أدركت أنه من الأسهل إنشاء واجهة مستخدم ثم تمريرها إلى C ++ عبر واجهة سطر الأوامر ، وإرسال النص ذهابًا وإيابًا ، كطريقة لتسلسل البيانات. أعتقد أن الوضع لم يتغير لما يقرب من اثني عشر عامًا ، حتى في أوائل 2000s بدأت مجموعة أدوات واجهة المستخدم اللائقة لـ C ++ ، مثل Qt وما شابه ، في الظهور.

[ملاحظة المؤلف: تم تطوير الإصدار الأول من Visual Basic بواسطة Alan Cooper ، والذي يُشار إليه غالبًا باسم " أبو Visual Basic ". وهو أيضًا شخصية مهمة في مجال سهولة الاستخدام وتجربة المستخدم]



UnrealEd 3 ، حيث كانت عناصر wxWidgets موجودة

DL : أعتقد أنه بمرور الوقت ، بدأ استبدال أجزاء من المحرر بأجزاء أخرى. كيف حدث هذا التطور؟

TS: بعد إكمال Unreal Editor 1 ، هدأت وأجريت مجموعة كاملة من أبحاث الجيل الجديد التي لم تؤتي ثمارها بشكل عام حتى ظهر وارن مارشال ، الذي أعاد كتابة أجزاء من Visual Basic في Unreal Editor باستخدام C ++ باستخدام wxWidgets . wxWidgets التي كانت في ذلك الوقت أفضل مجموعة أدوات. أصبح هذا الأساس لإطار عمل واجهة المستخدم في Unreal Editor 2.

بحلول منتصف عملية تطوير Unreal Engine 2 ، اختفى رمز Visual Basic تمامًا من المحرك. كان لدينا إطار C ++ أكثر ملاءمة ونظيفة. وهكذا ، حصلنا على نفس واجهة المستخدم تقريبًا ، ولكن بدون صعوبات لغوية. لكن المشكلة الحقيقية كانت أن wxWidgets لم تتطور وظهرت مجموعات أدوات أخرى لواجهة المستخدم ، لذلك واصلنا دمجها لأدوات خاصة. لذلك ، في الوقت الذي بدأت فيه دورة تطوير Unreal Engine 4 ، كان لدينا خمس مجموعات أدوات مختلفة لواجهة المستخدم ...

جيه إل: يحدث هذا غالبًا ...

TS: ... بما في ذلك القطع المجنونة من WPF المكتوبة بلغة C # ومدمجة في Unreal Engine 4 التي لم تعمل على Mac ، على سبيل المثال. لذلك ، في تلك اللحظة في قانوننا كان هناك فوضى كبيرة.

في الوقت نفسه ، أنشأ Nick Atamas نموذجًا أوليًا لطبقة واجهة المستخدم الجديدة في C ++ ، ومع مرور الوقت قررنا استخدامها. لذلك تحول إلى سليت. لذلك قمنا بإعادة كتابة 100 في المائة من واجهة مستخدم Unreal Engine ، وتخلصنا من جميع مجموعات أدوات واجهة المستخدم الإضافية وقم بإعادة تصميمها بنفس النمط. هذا سمح لنا بزيادة حجم المحرر والوصول إلى ما لدينا اليوم.


لقطة شاشة لـ UnrealEd مع واجهة مستخدم Slate

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

لقطات و XCopy: أهمية الترخيص

DL: ما هي الشركات التي كانت أول من استخدم Unreal Editor؟

TS: في المراحل الأولى ، قبل الإصدار بسنتين ، كان لدينا بالفعل مشتران للترخيص: استخدم محرك Unreal Microprose ، ثم استخدمه Legend Entertainment في لعبة Wheel of Time ، وقدمنا ​​لهم الدعم.



أسطورة الترفيه عجلة الزمن

JL: لقد ساعدوك أيضًا ، أليس كذلك؟ كان التعاون جزءًا من هذه العلاقة.

TS: نعم ، أبقت مدفوعات ترخيصهم ملحمة طافية أثناء عملية التطوير غير الواقعية.

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

جوليان: [يضحك] حسنًا ، ما الذي أدى إلى بيع ترخيص Unreal Engine إلى Microprose و Legend Entertainment حتى قبل إصدار Unreal 1؟

TS: أعتقد أن ذلك حدث لأننا ما زلنا في المراحل المبكرة ، حوالي عام 1995 ، أصدرنا لقطات شاشة مذهلة ليس فقط لعبتنا ، ولكن أيضًا لقطات شاشة لمحررنا. هذا جعل الشركة تتصل بنا. اتصلوا بنا من Microprose وقالوا: "نريد ترخيص محركك!" ، ونحن مثل: "محرك؟ أي محرك؟ آه ، محركنا! سيكلفك غاليا ". [يضحك] هذا هو حرفًا ما كانت عليه المحادثة.



واحدة من أول لقطات الشاشة لـ Unreal Editor و Unreal

الديناصورات والسحالي: المصطلحات والأيقونات UnrealEd

DL: بالحديث عن لقطات الشاشة: هنا واحد منهم منشور في Blue's News في أواخر التسعينيات. هناك اختلافات طفيفة ملحوظة عن الإصدار الذي يتم تشغيله في جهازي الظاهري: على سبيل المثال ، في الزاوية العلوية اليسرى توجد أزرار Play و Help و Epic ، وهي ليست في الإصدار النهائي.

هل يمكنك ان تخبرنا قليلا عنه؟


لقطة شاشة لـ UnrealEd نشرت في أخبار البلوز في عام 1998

TS: هذا بالتأكيد Unreal Engine 1 ، حوالي عام 1998 ، لأنه يحتوي على رمز Steve Polge ، الذي كان ينسق لعبة متعددة اللاعبين في ذلك الوقت.

كان زر "Epic" مجرد رابط لصفحة ويب ، بدا مزعجًا للجميع لأنهم نقروا باستمرار وأزعجوا: "آه ، يفتح المتصفح مرة أخرى!" [يضحك]

جوليان: [يضحك] حسنا ، هل يمكنك التحدث قليلا عن الايقونية؟

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

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



دانيال كوك والرموز التي أنشأها لـ UnrealEd. رمز "إضافة البيدق" في الأسفل ، الثالث إلى اليمين.

DL: لقد تحدثنا بالفعل عن كلمة "pawn". هل توصلنا إليها بأنفسنا ، أم رأيناها في مكان ما؟

TS: أعتقد أنه تم اقتراحه من قبل Steve Polge أو James Schmalz.

JL: وماذا عن "الممثل"؟

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

JL: [يضحك]

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

Schmalcism وفيروس الدماغ الفودو: إنشاء UnrealScript

جيه إل: أخبرنا المزيد عن كيفية مساهمة جيمس وستيف في استخدام وإنشاء UnrealScript.

TS: كان جيمس شمالز ماسة فريدة من نوعها ، بارعة. كان أفضل فنان للفريق ، ومصممًا رائعًا ، ويمكنه أيضًا البرمجة في UnrealScript والمجمع.

DL: في الاعتمادات غير الواقعية ، يظهر اسمه في زوج من الفئات المختلفة تمامًا.

: .

UnrealScript UnrealScript, , , . «- instigator -», - … «self». [يضحك]

: []

: «». «walk speed = run speed x 3.072». : « 3.072, ?» [يضحك]



: UnrealScript Java; C++. , . UnrealScript , Java .

, C# UnrealScript, UnrealScript, C#. , .

- SmallTalk, , , -, . , Haskell - , , .

SoftDisk, Id

: , shareware, , , , ?

: Epic , , — . , -, . , , .





- American Express , .

: []

: TG Interactive . . . , . Id, Id.

: SoftDisk, ?

: ! , ZZT SoftDisk. SoftDisk. SoftDisk , .


Id Software. .

Id . - shareware- Id. , Wolfenstein 3D, shareware. , . , . — .

[ : . TEd.]

WYSIWYG : —

: , 1998 Maximum PC, , , . , "[Unreal Editor] " « Quake ».

: « [Quake III: Arena] » «Prey Trespasser , Unreal. , , Unreal».

, — ?



Maximum PC, 1998

: , . , : , . , , « , » («what-you-see-is-what-you-get», WYSIWYG). . , Epic .

: Epic, , ?

: Epic — , , , , . , , , , . : , , .

, , , , .

. . , , , , .


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

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

مصدر الإلهام والتراث: تأثير UnrealEd

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

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


رسم تخطيطي لمحركات FPS من ويكيبيديا. انقر لفتح نسخة أكبر.

تأثرت بعض الجوانب بالمبادئ العامة ، على سبيل المثال ، Maya ، ولكن بعضها مرتبط بشكل خاص بـ Unreal - وهي طريقة لتنظيم التسلسل الهرمي للطبقات ، وتنفيذ نظام التراجع وجميع المشاكل الخطيرة الأخرى لتطوير اللعبة. كل من دخل الصناعة في أوائل العقد الأول من القرن الحادي والعشرين يمر عادة إما غير واقعي أو زلزال. على الرغم من أن Quake كانت لعبة أكبر بكثير ، يبدو لي أن معظم المصممين أتوا من خلال UnrealEd لأن أدواتها كانت مريحة للغاية.

الضرب والقسمة على الإنتاجية: نصائح لمطوري الألعاب

JL: في عام 2011 ، أجريت مقابلة مع Kotaku. سأقرأ بعض الاقتباسات التي يبدو لي أنها تتعلق بموضوعنا:

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

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

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



في مقابلتي مع جون روميرو ، أدرك الأمر جيدًا قائلاً: "الأدوات تعيش لفترة أطول من الألعاب".

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

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

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

DL: لأنك تعتقد أن المطورين يعانون من نصف التدابير؟

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

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


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

يجب أن تزيد الأدوات الإنتاجية ، وإذا اتضح أنها تقللها ، فأنت بحاجة للتخلص منها.

JL: عظيم. شكرًا لك على الوقت الذي قضيته في الدردشة معي.