الإجابة على هذا السؤال أكثر وحشية بكثير مما يتخيله معظم الناس.

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

بدأ كل شيء من البكسلات.

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

هذه العملية تسمى اليوم “التقديم البرمجي”. لم يكن لها اسم في ذلك الوقت، لأنه لم يكن هناك بديل — كانت ببساطة تسمى “كيف تظهر الصورة”.

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

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

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

الصوت كان مشكلة من بعد مختلف تماماً.

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

كان هناك مبرمجون في ذلك الوقت يدرسون專門 كيف يستخرجون طبقات صوت أكثر من مكبر الصوت PC Speaker. كانت طريقتهم هي التبديل بين ترددات مختلفة في نوافذ زمنية قصيرة للغاية، مما يخلق تأثيراً ستيريو زائفاً. كانت هذه التقنية تُعامل مثل السحر الأسود في مشهد العروض التوضيحية في ذلك الوقت. تأخذ جرساً لا يصدر سوى “بيب” وتصنع شيئاً قريباً من الموسيقى. المبرمجون الآخرون الذين سمعوه لم تكن لديهم أدنى فكرة كيف فعلت ذلك — لأن المبدأ لم يكن بديهياً. كنت بحاجة إلى فهم دقيق للغاية للتحكم في التوقيت لتحقيق ذلك.

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

الإحساس بالتصميم على مستوى منطق اللعبة كان أمراً آخر تماماً.

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

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

اللاعبون في ذلك الوقت لم يسموا هذا عطلاً. سموه ميزة في اللعبة. لأنهم لم يعرفوا أن الأمر يمكن أن يكون مختلفاً.

شيء آخر جدير بالذكر: الحواسيب المبكرة كانت ذات ذاكرة محدودة للغاية. 640 كيلوبايت كان السقف العتادي لعقد كامل. هذا الرقم اليوم لا يمكنه حتى تخزين لقطة شاشة واحدة. كان على المبرمجين حشر كل محتوى اللعبة — الرسومات، المؤثرات الصوتية، الخرائط، كود المنطق — داخل هذه الـ 640 كيلوبايت، وترك مساحة لبيانات وقت التشغيل.

كيف؟ الضغط، التحميل المجزأ، وإعادة الاستخدام.

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

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

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

كارماك كتب مرة كوداً لحساب الجذر التربيعي العكسي، مع تعليق فيه كتب عليه “what the fuck”. استخدم هذا الكود خدعة معالجة بتات غير بديهية للغاية لتقريب الجذر التربيعي العكسي بسرعة، أسرع بكثير من مكتبة الرياضيات القياسية — كل ذلك لتوفير وقت الحساب في التقديم ثلاثي الأبعاد. أصبح هذا المقطع من الكود لاحقاً أسطورة في ثقافة المبرمجين، تم اقتباسه مراراً وتكراراً، لأنه يمثل أسلوب تفكير قد اختفى: طريقة عصر الأداء من الرياضيات والإبداع ضمن حدود العتاد.

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

هذان سؤالان مختلفان جداً.

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

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

لكن تلك الحقبة من بناء الألعاب بدءاً من البكسلات كان فيها شيء لم يعد موجوداً اليوم.

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

هذا الشعور له اسم. يسمى السيطرة الكاملة.

لذا، العظماء الذين طوروا الألعاب في تلك الأيام — كانوا عظماء حقاً. رائعين حقاً.