الذكاء الاصطناعي

خبير قواعد البيانات يشغّل لعبة Doom عبر SQL في 5900 سطر

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

رضوان عبدالهاديمحرر وكاتب تقني

نُشر: 4 أكتوبر 2026 · آخر تحديث: 4 أكتوبر 2026 · 5 دقائق قراءة

خبير قواعد البيانات يشغّل لعبة Doom عبر SQL في 5900 سطر — الصورة: Tom's Hardware

الخلاصة

استخدم المطوّر Lukas Vogel قاعدة بيانات CedarDB المتوافقة مع Postgres لتنفيذ منطق اللعبة بدلاً من المعالج المركزي.
بلغ حجم الكود البرمجي 5900 سطر من SQL، وهو أقل من الكود الأصلي المكتوب بلغة C والذي يتجاوز 9000 سطر.
يعتمد النظام على واجهة أمامية بلغة Python تعمل كـ"أطراف خارجية"، بينما تتم جميع العمليات الحسابية داخل قاعدة البيانات.
يتضمن المشروع عارضاً رسومياً مكوّناً من 1300 سطر يتوزع على 89 جدولاً مختلفاً، ويدعم اللعب الجماعي عبر التزامن التلقائي.

منطق اللعبة داخل قاعدة البيانات

في عام 2026، لا يزال تحويل لعبة Doom إلى منصات غير تقليدية هو الهواية الأشهر بين هواة البرمجة، حيث تم نقل اللعبة إلى أجهزة متنوعة تمتد من اختبارات الحمل إلى الأقمار الصناعية. والآن، يضيف مشروع SQLDoom فصلاً جديداً لهذه السلسلة من خلال تشغيل اللعبة داخل قاعدة بيانات، وهو ما تم بالتعاون مع نظام CedarDB. يعتمد المشروع على فكرة بسيطة لكنها عميقة: إذا فكّرت كمهندس قواعد بيانات، فإن تشغيل اللعبة يصبح أمراً أسهل مما تتخيل. فالواجهة الأمامية التي تعرض الرسوميات وتشغل الصوت وتستقبل المدخلات مكتوبة بلغة Python، لكنها تعمل فقط كأجهزة طرفية لحاسوب شخصي، بينما يتم تنفيذ جميع العمليات الحسابية والمنطقية داخل قاعدة البيانات نفسها. ويمكن الرجوع إلى Tom's Hardware للاطلاع على التفاصيل الأصلية للمصدر.

تم كتابة الجزء الخلفي خصيصاً لقاعدة بيانات CedarDB، وهي نظام إدارة قواعد بيانات علائقية (RDBMS) يركز على الأداء ومتوافق مع Postgres. وعلى غرار إصدارات Doom الحديثة، يستخدم SQLDoom مسارين منفصلين: مسار واحد يعمل بتردد 35 هرتز (التردد الأصلي للعبة) لمعالجة جميع المنطق، ومسار منفصل لعرض الرسوميات وتنعيم موضع الكاميرا بين تحديثات اللعبة. هذا الفصل بين المنطق والعرض يضمن سلاسة الأداء حتى عند تنفيذ العمليات المعقدة داخل البيئة العلائقية. ويمكن الرجوع إلى Terms & Conditions للاطلاع على التفاصيل الأصلية للمصدر.

تحويل البيانات إلى جداول

بدأ Lukas Vogel، الذي سبق له تطوير DoomQL، بالعمل من خلال تحويل الكيانات الموجودة في ملف WAD الخاص بـ Doom إلى جداول قاعدة بيانات. وتبيّن أن هذه العملية كانت أسهل مما كان متوقعاً، لأن البيانات في الملف الأصلي "علائقية بطبيعتها". فعلى سبيل المثال، تكون مستويات الخريطة مبنية على علاقات أب-ابن، وهي هياكل يمكن تكرارها بسهولة في جداول عادية. لم يستغرق هذا التحويل سوى 1000 سطر من كود Python، مما يعكس كفاءة التمثيل العلائقي للبيانات الأصلية للعبة.

أما فيما يتعلق بالدورة الرئيسية للعب، ففوجئ Vogel مرة أخرى بسهولة تحويل منطق اللعبة. بلغ حجم الكود الناتج 5900 سطر من SQL، مقارنةً بـ 9000 سطر في الكود الأصلي المكتوب بلغة C. جاء هذا التوفير الكبير في عدد الأسطر بسبب طبيعة لغة SQL؛ فبدلاً من الحاجة إلى حلقات تكرارية (for أو while) لتحديث قيم الكيانات، يكفي استخدام جملة بسيطة مثل "UPDATE... WHERE" للقيام بذلك في بيان واحد، بل وبشكل متوازٍ. هذا يفتح الباب أمام تعديلات فورية وسهلة، مثل تغيير خصائص الأسلوك أو سلوك الأعداء أثناء اللعب، لأن كل شيء يمثل صفاً في جدول قاعدة بيانات.

تحدي العرض الرسومي

يُعد العارض الرسومي أصغر حجماً، حيث يتكون من 1300 سطر فقط، لكنه أكثر تعقيداً لأنه الاستعلام الوحيد الذي يمتد عبر 89 جدولاً مختلفاً. يشير Vogel إلى أن خط الأنابيب النهائي يشبه إلى حد كبير خط أنابيب Doom الأصلي. فبيانات تقسيم الفضاء الثنائي (BSP) الذي ابتكره John Carmack، وهو تطبيق لأشجار ثنائية، يمكن تمثيله بسهولة في جدول. حيث يمكن تحويل كل قيمة يسار/يمين إلى بت، وتقليل قيمة ترتيب الرؤوس إلى رقم واحد فقط.

بفضل هذا التمثيل، يقوم استعلام بسيط مثل "SELECT... ORDER BY" بترتيب الجدران من الأمام إلى الخلف تلقائياً. يذكر Vogel أنه استخدم نفس تقنية قاعدة البيانات عندما كتب نظام التعليقات المتشعبة لموقع Tech Report السابق. ومع ذلك، يؤكد أن عارضي الأرضية والسقف لم ينقلوا إلى SQL بسلاسة كبيرة، لأنهما يعتمدان في النهاية على خوارزميات ملء بالفيضان (flood-fill) الذكية، مما يجعل تحويلهما إلى استعلامات علائقية مباشرة أكثر صعوبة.

تفوق قواعد البيانات في اللعب الجماعي

عندما يتعلق الأمر باللعب الجماعي، تبرز ميزة استخدام قاعدة البيانات بشكل واضح مقارنة باللعبة الأصلية. السبب بسيط: الحفاظ على حالات متزامنة عبر العديد من الجداول التي تحتوي على كميات هائلة من الاعتماديات المتبادلة هو بالضبط ما صُممت قواعد البيانات للقيام به. لذلك، تكون اللقطات (snapshots)، والمصادقة، والتحكم في الوصول، جميعها مجانية فعلياً ومُنفذة مسبقاً. لتشغيل نبضة لعبة واحدة (game tick)، كل ما تحتاجه هو تنفيذ "START TRANSACTION"، ثم تشغيل المنطق، وأخيراً "COMMIT"، لتتزامن كل العناصر تلقائياً دون الحاجة إلى بروتوكولات مخصصة.

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

إمكانات تقنية جديدة

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

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