يحاول الناس الاستمتاع بألعاب البرمجة. وهو يعمل نوعًا ما في البداية. ومع ذلك، مع نمو المشروع، تبدأ الأمور في الانهيار. لماذا؟ وماذا يمكننا أن نفعل حيال ذلك؟
سأتحدث عن المشكلة وكيف أصلحتها وإلى أين أذهب من هنا.
ما هو “الترميز الحيوي”؟
أولاً، ما هو التشفير الحيوي؟ تمت صياغتها في الأصل بواسطة Andrej Karpathy في تغريدة واسعة الانتشار حيث تم تعريفها على أنها المكان الذي “تستسلم فيه تمامًا للمشاعر، وتحتضن الأسيات وتنسى الكود الموجود حتى”.
ومع ذلك، منذ ذلك الحين، يتم استخدامه بشكل وصفي ليعني الكثير من الأشياء المختلفة، بدءًا من مجرد “استخدام الذكاء الاصطناعي عند البرمجة” إلى “عدم التفكير في الكود على الإطلاق”. في منشور المدونة هذا، سأعرّفها على أنها: استخدام الذكاء الاصطناعي كلغة برمجة عالية المستوى لبناء شيء ما. مثل لغات البرمجة الأخرى، يستفيد هذا من فهم ما يحدث تحت الغطاء، لكنه لا يتطلب ذلك بالضرورة.
باستخدام هذا التفسير، يمكنك إنشاء لعبة دون فهم التعليمات البرمجية، على الرغم من أن معرفة الأساسيات لا تزال مفيدة.
إدارة السياق
لقد ذكرت سابقًا أنه “مع نمو المشروع، تبدأ الأمور في الانهيار”. ويرجع ذلك إلى وجود دليل على أنه مع امتلاء نافذة السياق، يبدأ أداء النموذج في التدهور. وينطبق هذا بشكل خاص على تطوير اللعبة، حيث يمكن أن ينمو السياق بشكل كبير جدًا وبسرعة كبيرة.
لمعالجة هذه المشكلة، هناك العديد من الحلول الشخصية المخصصة، مثل كتابة سياق خاص بـ LLM مباشرة في ملفات المشروع، أو حلول أكثر شمولاً مثل Claude Code Development Kit لإدارة السياق على نطاق واسع.
لم أتمكن من العثور على حل خفيف الوزن وسهل الوصول إليه، ولا يعتمد على معرفة كبيرة بالمجال. لذلك قمت بإنشاء واحد: 🧅 Shallot، نظام إدارة سياق بسيط وخفيف الوزن وغير مدروس لكلود كود. يعتمد على أمرين أساسيين:
/peel [prompt]لتحميل السياق في بداية المحادثة/nourishلتحديث السياق في نهاية المحادثة
وفقًا للروايات، هذا يعمل بشكل جيد. ومع ذلك، فإنه يعمل بشكل أفضل عندما يظل المشروع بسيطًا ومنظمًا بشكل جيد، بحيث يمكن احتواء كل السياق ذي الصلة بسهولة في نافذة سياق النموذج. بينما يتم استخدام كود كلود هنا، فإن نفس المبادئ تنطبق على النماذج الأخرى.
وبعيدًا عن أدوات إدارة السياق، يعد اختيار النظام الأساسي أمرًا بالغ الأهمية. يجب أن تحافظ المنصة بشكل طبيعي على سلاسة المشاريع من خلال التجريدات عالية المستوى، مع كونها أيضًا شيئًا تفهمه نماذج الذكاء الاصطناعي جيدًا. إذًا، ما هي الأنظمة الأساسية الحالية الأكثر ملاءمةً للبرمجة الديناميكية؟
الاستكشاف الأولي
لقد قمت في البداية بتجربة 3 طرق مختلفة لألعاب البرمجة الجذابة: Roblox MCP، وUnity MCP، والويب. لكل منها، حاولت إنشاء لعبة تزايدية بسيطة مستوحاة من Grass Cutting Incremental، باستخدام Claude Code لكل منها.
وإليك كيف سارت الأمور:
المحاولة الأولى: Roblox MCP
خادم MCP الرسمي من Roblox. يتيح ذلك للذكاء الاصطناعي التفاعل مع Roblox Studio عن طريق إرسال أوامر لتشغيل التعليمات البرمجية.
الايجابيات:
- مستوى ممتاز من التجريد مع ميكانيكا اللعبة المدمجة
- يمكن للذكاء الاصطناعي أن يفهم بسهولة بناء الجملة ويحول التعليمات إلى تعليمات برمجية
سلبيات:
- لا توجد ملفات، فقط باستخدام التعليمات البرمجية لقراءة البيانات، مما يحد بشدة من إدارة السياق
- معلومات وقت تشغيل محدودة جدًا ليعمل الذكاء الاصطناعي معها
- حديقة مسورة خاصة
يوفر Roblox طبقة ممتازة من التجريد للحفاظ على قاعدة التعليمات البرمجية بسيطة وسهلة الإدارة، وهو مثالي للترميز الحيوي. ومع ذلك، فإن الحديقة المسورة والافتقار إلى السياق يجعل من غير الممكن برمجة الأجواء، إلا إذا كان ذلك داخل Roblox.
المحاولة الثانية: الوحدة MCP
خادم MCP غير الرسمي للوحدة. يتيح ذلك للذكاء الاصطناعي التفاعل مع Unity Editor: قراءة وحدة التحكم وإدارة الأصول والتحقق من صحة البرامج النصية.
الايجابيات:
سلبيات:
- هناك العديد من الطرق للقيام بكل شيء في Unity، وتتغير بشكل متكرر عبر الإصدارات، مما يتسبب في إرباك الذكاء الاصطناعي
- يتطلب معرفة كبيرة بالمجال لإخبار الذكاء الاصطناعي كيف لفعل الأشياء، بدلا من ماذا للقيام به
- كان أداء الذكاء الاصطناعي غير متسق وغير موثوق
- محرك خاص (رغم أنه أكثر شفافية من Roblox)
الوحدة هي محرك قوي مع الكثير من القدرات. ومع ذلك، فإن تعقيد المحرك وتنوعه يجعل من الصعب على الذكاء الاصطناعي أن يحقق نتائج جيدة باستمرار دون معرفة كبيرة بمجال المستخدم.
المحاولة 3: مكدس الويب
منصة الويب المفتوحة، تستخدم three.js للعرض ثلاثي الأبعاد، وRapier للفيزياء، وBitecs لمنطق اللعبة.
الايجابيات:
- كفاءة أعلى بكثير في الذكاء الاصطناعي مقارنة بمحركات الألعاب، ويرجع ذلك على الأرجح إلى بيانات التدريب الضخمة
- الوصول الكامل إلى نظام الملفات
- مكدس مفتوح المصدر بالكامل مع تحكم/شفافية كاملة
سلبيات:
- مكتبات منخفضة المستوى نسبيًا، وتتطلب بشكل أساسي بناء المحرك قبل إنشاء اللعبة
- عدم وجود نظام بيئي للألعاب ثلاثية الأبعاد عالية الجودة؛ يميل الويب نحو الألعاب ثنائية الأبعاد والتجارب البسيطة ثلاثية الأبعاد
حقق هذا النهج أفضل أداء للذكاء الاصطناعي على الإطلاق، ويرجع ذلك على الأرجح إلى الكم الهائل من بيانات تطوير الويب المتاحة أثناء التدريب. ومع ذلك، فإن الطبيعة ذات المستوى المنخفض للمكتبات تعني أنه كان عليّ إنشاء محرك لعبة قبل أن أتمكن من بناء اللعبة نفسها. وهذا يسمح لنا بالعمل على مستوى أعلى بكثير من التجريد، كما فعلنا مع Roblox.
على الرغم من أن الأمر يتطلب بناء محرك أولاً، إلا أن هذا الأسلوب كان هو الأسلوب الوحيد الذي أنتج نتيجة ممتعة دون معرفة كبيرة بالمجال.
ملخص المقارنة
| منصة | أداء الذكاء الاصطناعي | مستوى التجريد | إدارة السياق | مفتوح المصدر |
|---|---|---|---|---|
| روبلوكس | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ | ❌ |
| الوحدة | ⭐ | ⭐⭐ | ⭐⭐⭐ | ❌ |
| ويب | ⭐⭐⭐⭐⭐ | ⭐ | ⭐⭐⭐⭐⭐ | ✅ |
الحل: VibeGame
بعد هذه التجارب، كانت لدي صورة واضحة: تتمتع مجموعة الويب بأداء ذكاء اصطناعي ممتاز ولكنها كانت ذات مستوى منخفض للغاية، في حين تتمتع لعبة Roblox بتجريد مثالي ولكنها تفتقر إلى الانفتاح وإدارة السياق.
إذن، ماذا عن الجمع بين أفضل ما في الاثنين؟
نقدم لكم VibeGame، وهو محرك ألعاب تعريفي عالي المستوى مبني على ثلاثة.js وRapier وBitecs، وهو مصمم خصيصًا لتطوير الألعاب بمساعدة الذكاء الاصطناعي.
فلسفة التصميم
كانت هناك ثلاثة قرارات رئيسية ساهمت في تصميم VibeGame:
- التجريد: تجريد عالي المستوى مع ميزات مدمجة مثل الفيزياء والعرض وميكانيكا الألعاب الشائعة، مما يحافظ على قاعدة التعليمات البرمجية بسيطة وسهلة الإدارة. هذا مستوحى من ألعاب/محركات الألعاب المشهورة عالية المستوى مثل Roblox وFortnite UEFN وMinecraft.
- بناء الجملة: بناء جملة تعريفي يشبه XML لتعريف كائنات اللعبة وخصائصها، مما يسهل على الذكاء الاصطناعي فهم التعليمات البرمجية وإنشاءها. وهذا مشابه لـ HTML/CSS، الذي تتقنه نماذج الذكاء الاصطناعي بالفعل.
- بنيان: بنية نظام مكون الكيان (ECS) لقابلية التوسع والمرونة. تقوم ECS بفصل البيانات (المكونات) عن السلوك (الأنظمة)، مما يشجع المشروع على البقاء معياريًا ومنظمًا أثناء نموه، مما يفضي إلى الترميز الحيوي وإدارة السياق.
تبدو اللعبة الأساسية كما يلي:
<world canvas="#game-canvas" sky="#87ceeb">
<static-part pos="0 -0.5 0" shape="box" size="20 1 20" color="#90ee90"></static-part>
<dynamic-part pos="-2 4 -3" shape="sphere" size="1" color="#ff4500"></dynamic-part>
</world>
<canvas id="game-canvas"></canvas>
<script type="module">
import * as GAME from 'vibegame';
GAME.run();
</script>
شاهده عمليًا في JSFiddle أو العرض التوضيحي المباشر.
سيؤدي هذا إلى إنشاء مشهد بسيط بطائرة أرضية وكرة ساقطة. يتم إنشاء المشغل والكاميرا والإضاءة تلقائيًا. كل هذا معياري ويمكن استبداله. يمكن إضافة المكونات والأنظمة المخصصة حسب الحاجة.
ويأتي هذا مرفقًا بملف llms.txt يحتوي على وثائق حول المحرك، المصمم خصيصًا للذكاء الاصطناعي، ليتم تضمينه في موجه النظام أو السياق الأولي الخاص به.
فهل يعمل فعلا؟
نعم.
حسنا، نوعا ما.
هذه هي اللعبة التي صممتها لاختبار بناء لعبة بسيطة لجمع العشب التزايدي باستخدام VibeGame وClaude Code. لقد عملت بشكل جيد للغاية، وتتطلب الحد الأدنى من المعرفة بالمجال لتنفيذ آليات اللعبة الأساسية.
ومع ذلك، لا تزال هناك بعض التحذيرات الرئيسية:
- إنه يعمل بشكل جيد لبناء ما يدعمه محرك اللعبة، أي منصة أو لعبة بسيطة تعتمد فقط على الفيزياء الأساسية والعرض.
- ومع ذلك، فهي تعاني من أي شيء أكثر تعقيدًا لم يتم تنفيذه بعد في المحرك، مثل التفاعل والمخزون وتعدد اللاعبين والقتال وما إلى ذلك.
لذلك، مع تعريف البرمجة الحيوية التي تتمثل في نهج “اجعلني لعبة” الذي يتم تنفيذه مرة واحدة، فإنه لا يعمل. ومع ذلك، مع تعريف التعامل مع البرمجة الحيوية مثل لغة برمجة عالية المستوى، فإنها تعمل بشكل جيد للغاية، ولكنها تتطلب من المستخدمين فهم قدرات المحرك وقيوده.
جربه بنفسك
لتجربتها على الفور، قمت بإنشاء عرض توضيحي حيث يمكنك تطوير لعبة مباشرة في المتصفح باستخدام VibeGame مع Qwen3-Next-80B-A3B-Instruct: Live Demo on Hugging Face.
يمكنك أيضًا اختباره محليًا باستخدام نموذج حدودي مثل Claude Code:
npm create vibegame@latest my-game
cd my-game
npm run dev
ثم قم بلصق جميع محتويات المضمنة llms.txt ل CLAUDE.md، وتوفير وثائق كاملة حول المحرك ليرجع إليها الذكاء الاصطناعي (أو قم بتوجيه نظام إدارة السياق الخاص بك إليه). وهذا يعمل مع نماذج أخرى كذلك.
ما هي الخطوة التالية؟
يعد المحرك حاليًا مجردًا جدًا ولا يدعم سوى الميكانيكا الأساسية جدًا (ما لم يتم كتابته من الصفر). ومع ذلك، فإن النتائج الأولية واعدة.
الخطوات التالية ستكون:
- قم بتحسين المحرك باستخدام المزيد من الميكانيكا المدمجة، لتقترب من المساواة مع الإصدارات المبكرة من Roblox أو UEFN. وهذا يشمل:
- تفاعل
- المخزون / العناصر
- متعددة اللاعبين
- شبكات/رسوم متحركة مصقولة مع قاعدة بيانات منسقة
- الصوت مع قاعدة البيانات المنسقة
- تحسين أنظمة توجيه الذكاء الاصطناعي، مما يوفر للمبتدئين تجربة أفضل. وهذا يشمل:
- رسائل واضحة حول قدرات/قيود المحرك
- المطالبات الموجهة للمهام المشتركة
- والعديد من الأمثلة والقوالب
- الموارد التعليمية
من المفيد أيضًا استكشاف كيف يمكن لألعاب البرمجة الحماسية الاستفادة من المزيد من المحركات التي أثبتت جدواها. على سبيل المثال، يمكن أن يوفر إنشاء محرر ألعاب Sandbox عالي المستوى فوق Unity أو Unreal Engine (على غرار الطريقة التي تم بها إنشاء Unreal Editor for Fortnite على Unreal Engine) بيئة أكثر تحكمًا ليعمل الذكاء الاصطناعي معها، مع الاستفادة من قوة المحركات القائمة.
من المحتمل أيضًا أن نرى المزيد من الحلول الداخلية من اللاعبين الرئيسيين.
اتبعني لمواكبة ما يحدث في الفضاء!
الروابط:
