خلال مؤتمر Game Developers Conference هذا العام، كشف استوديو Sandfall Interactive عن الكواليس التقنية التي مكّنته من تطوير لعبة تقمّص الأدوار Clair Obscur: Expedition 33 رغم امتلاكه فريقًا صغيرًا للغاية من المبرمجين. السر؟ الاستوديو بالكاد كتب شيفرة خاصة به، واعتمد بشكل كبير على الأدوات الجاهزة في محرك Unreal Engine لبناء معظم ميزات اللعبة.

قدّم الاستوديو جلسة خاصة في المؤتمر بعنوان:

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

في بداية الجلسة، كشف المبرمجان مفاجأة لافتة: نحو 95% من أنظمة اللعب في Clair Obscur صُممت باستخدام أداة Unreal Blueprints. هذا التصريح أثار دهشة واضحة بين الحاضرين من المطورين. ووفقًا لغيلرمين وتوريس، فإن فريق البرمجة المكوّن من أربعة أشخاص كتب قدرًا ضئيلًا جدًا من شيفرة C++ الخاصة به أثناء تطوير اللعبة.

ببساطة، تُعد Blueprints أداة برمجة داخل Unreal Engine تسمح بربط عناصر جاهزة (Nodes) ببعضها لإنشاء أنظمة لعب معقدة دون الحاجة إلى كتابة الكثير من الشيفرة. هذه الميزة تسهّل على المطورين — حتى من يملكون خبرة برمجية محدودة — تحويل أفكارهم إلى أنظمة لعب فعلية بسرعة، وهو أمر كان ضروريًا لفريق Sandfall، خاصة أن النموذج الأولي للعبة صممه مبرمج واحد فقط.

وقد اعتمدت اللعبة بشكل كبير على Blueprints، إذ شرح الفريق كيف تم بناء ميزات مثل المهارات وتعزيزات القتال (Battle Buffs) باستخدام هذه الأداة. وأوضح المطوران أن لهذا الأسلوب إيجابيات وسلبيات.

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

وخلال الجلسة، كشف المطورون سرًا طريفًا عن اللعبة: الشخصية Esquie في الواقع لا تسبح عندما تكون في الماء!

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

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

ومع ذلك، خرج كثيرون من القاعة بانطباع واضح:

العرض كان بمثابة دعاية قوية لقدرات محرك Unreal Engine في تمكين الفرق الصغيرة من تطوير ألعاب ضخمة ومعقدة.