كيف بنينا خادم MCP في الوقت الفعلي لـ Godot

لماذا يعتبر “الوقت الفعلي” مهمًا لخادم MCP في Godot

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

عندما صممنا Godot MCP لـ VberAI، كان الموجز صريحًا:

• يجب أن يشغل مساعد الذكاء الاصطناعي (Cursor، Claude، Windsurf، وعملاء MCP مشابهون) المحرر، وليس فقط قراءة ملفات .gd من القرص
• يجب أن تكتمل إجراءات مثل إنشاء عقدة، وإعادة تسمية، وإرفاق سكربت، والاستعلام عن التحديد بينما يظل المحرر سريع الاستجابة
• يجب أن تظل سياقات وضع اللعب ووضع التحرير صادقة - يجب أن تفشل الأدوات بصوت عالٍ عندما تكون العملية غير آمنة أثناء اللعب

هذه المقالة هي قصة الهندسة: كيف بنينا خادم MCP في الوقت الفعلي يجلس بجوار Godot بدلاً من التظاهر بأن المشروع مستودع ثابت.

المشكلة مع MCP “الملفات فقط” للمحركات

النهج الساذج مغري:

1. وجّه خادم MCP إلى مجلد المشروع
2. كشف read_file / write_file / list_dir
3. دع النموذج يخترع GDScript ويأمل أن يعيد المحرر التحميل بشكل جيد

هذا يعمل لمواقع التوثيق. يفشل في عمل المحرك للأسباب التالية:

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

كنا بحاجة إلى سطح MCP يعكس ما يراه الإنسان بالفعل في رصيف Godot: التسلسل الهرمي، والخصائص على شكل مفتش، ومقابض الموارد - وليس فقط سلاسل المسار.

نظرة عامة على البنية

على مستوى عالٍ، يتكون Godot MCP من ثلاث طبقات متعاونة:

عميل MCP (Cursor / Claude / …)
        │  JSON-RPC عبر stdio أو ناقل محلي
        ▼
خادم MCP (عملية جسر VberAI Godot)
        │  قائمة انتظار الأوامر + مغلفات النتائج
        ▼
إضافة محرر Godot (GDExtension / إضافة محرر)
        │  استدعاءات مؤجلة على الخيط الرئيسي
        ▼
شجرة مشهد المحرر / ResourceDB / محرر السكربتات

الطبقة 1 - سطح أدوات MCP

الأدوات صغيرة عمدًا وذات شكل فعلي:

• godot_get_scene_tree - لقطة للمشهد المحرر مع أنواع العقد ومساراتها
• godot_create_node / godot_set_property
• godot_attach_script / godot_run_script_snippet (محمي)
• godot_list_resources / godot_get_selection

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

الطبقة 2 - الجسر في الوقت الفعلي

الجسر هو حيث يعيش “الوقت الفعلي” فعليًا:

• قناة ثنائية الاتجاه بين عملية MCP وإضافة المحرر (مقبس محلي أو أنبوب مسمى في التطوير؛ قد تغلف إصدارات المنتج هذا خلف مساعد سطح المكتب VberAI)
• قائمة انتظار أوامر تسلسل الطفرات بحيث لا يمكن لاستدعائي أداتين متداخلين أن يتسابقا على شجرة المشهد
• معرفات الطلبات + إقرارات حتى يتمكن عميل MCP من انتظار “تم التطبيق” دون استطلاع نظام الملفات
• نبض القلب / حيوية المحرر حتى يعرف العملاء متى خرج Godot في منتصف الجلسة

الطبقة 3 - سلامة الخيط الرئيسي في Godot

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

1. يصل أمر MCP على خيط الجسر
2. يتم وضع الحمولة في قائمة الانتظار
3. يعمل رد الاتصال المؤجل للمحرر على الخيط الرئيسي (call_deferred / خطاف إطار الخمول)
4. يُرجع مغلف النتيجة نجاحًا، أو خطأ منظمًا، أو “أعد المحاولة بعد انتهاء وضع اللعب”

هذا النمط ممل بالتصميم. الملل هو ما يبقي “الوقت الفعلي” من أن يصبح “تجميد محرر عشوائي”.

جعله يبدو في الوقت الفعلي (دون الكذب بشأن الكمون)

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

لقطة مقابل تدفق

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

• لقطات ضحلة افتراضيًا (الجذر + مستوى واحد، أو مركزة على التحديد)
• قراءات بنطاق المسار عندما يعرف النموذج بالفعل شجرة فرعية
• رموز تغيير اختيارية بحيث يمكن للاستدعاءات اللاحقة أن تسأل “ما الذي تغير منذ X؟” بدلاً من إعادة تسلسل كل شيء

نتائج صديقة للفرق

تتضمن نتائج الأدوات:

• سلاسل NodePath الأساسية
• أسماء الأنواع (CharacterBody2D, Control, …)
• مفاتيح خصائص تتوافق بشكل نظيف مع حقول المفتش
• تحذيرات صريحة عند تطبيق كتابة ولكن المشهد لا يزال متسخًا / غير محفوظ

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

سلوك وضع اللعب المحدود

وضع اللعب هو المكان الذي يبدأ فيه نصف تذاكر “الذكاء الاصطناعي كسر مشروعي”. مجموعة القواعد لدينا:

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

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

مشاكل صعبة واجهناها (وأبقيناها)

1. المحرر ليس قاعدة بيانات

ترتيب العقد، وعلاقات المالك، والمشاهد المعبأة تتفاعل بطرق تبدو بسيطة في صورة GIF وفوضوية في ملف .tscn. اعتمدنا على واجهات برمجة تطبيقات Godot الخاصة (Node, EditorInterface, محملات الموارد) بدلاً من اختراع نموذج مشهد موازٍ قد ينحرف.

2. السكربتات مقابل المشاهد كمصدرين للحقيقة

إرفاق سكربت ليس مثل ضمان أن السكربت يُترجم وأن اسم الفئة يُحل. يبلغ الخادم عن نتائج الترجمة/الإرفاق بشكل منفصل. أوقف ذلك فئة من إخفاقات “قالت الأداة نجاح، المفتش لا يُظهر شيئًا”.

3. جلسات متعددة النوافذ / متعددة المشاريع

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

4. حدود الأمان

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

كيف يتناسب هذا مع AI Studio وبقية VberAI

Godot MCP هو مشغل المحرك. القطع التكميلية:

• VberAI Studio (AI Studio) - هيكل من التصميم إلى المحرك لـ Figma/PSD → تسلسلات هرمية للتحكم؛ ثم يربط MCP الأزرار ويعيد تسمية العقد بعد الاستيراد
• Unity MCP / Cocos MCP - نفس فكرة MCP، مضيفو محررين مختلفون وقواعد أمان مختلفة
• AI Super Matting - ينظف قناة ألفا قبل أن تصبح القواميس موارد محرك يعينها MCP لاحقًا

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

نصائح عملية إذا كنت تبني MCP محرك خاص بك

1. ضع الطفرات في قائمة انتظار على الخيط الرئيسي للمحرك - لا تتظاهر أبدًا بأن محركات الألعاب هي خوادم بلا مشاركة
2. فضل الأدوات الصغيرة ذات المخططات - التحقق يتفوق على شعرية المطالبة
3. أرجع NodePaths وأنواعًا، وليس نثرًا - تحتاج النماذج إلى مقابض قابلة للتشغيل
4. قم بترميز أوضاع اللعب/التحرير في كل استجابة - الغموض هنا يدمر الثقة
5. قس الرحلة ذهابًا وإيابًا إلى “مرئي في الرصيف” - وليس فقط وقت ترميز JSON

إذا قمت بتحسين عملية MCP فقط وتجاهلت جسر المحرر، فسوف تشحن حلقة هلوسة سريعة.

الخلاصة

بناء خادم MCP في الوقت الفعلي لـ Godot يعني معاملة المحرر كزميل حي: جسر آمن للخيط الرئيسي في قائمة انتظار؛ أدوات مصممة مثل إجراءات المحرر؛ وصدق بشأن حدود وضع اللعب. MCP للملفات فقط أسهل - وغير مكتمل للعمل الأصلي للمشهد.

تريد المسار المُسلم بدلاً من نموذج أولي لنهاية الأسبوع؟ ابدأ بـ VberAI Godot MCP، واربط عميل MCP المفضل لديك، وجرب أول استدعاء أداة بسيط: قائمة شجرة المشهد الحالية، ثم أنشئ عقدة واحدة تحت التحديد. هذه الحلقة الواحدة - استعلام ← تحوير ← رؤيتها في الرصيف - هي المنتج. كل شيء آخر هو هندسة موثوقية حولها.