إلى الأمام العنوان الأصلي: أرى إطار الوكيل للجيل القادم في Project89

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

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

خلفية المطور

نظرًا لأن هذه مدونة تقنية ، دعنا نلقي نظرة أولاً على خبرة المؤسس التقنية.

قبل العمل على المشروع 89، قام المؤسس بتطوير هذا المشروع: https://github.com/Oneirocom/Magick، والذي يعد أيضًا برنامج برمجة مدعومًا بالذكاء الاصطناعي. بالإضافة إلى ذلك، يتم تصنيف شو كأرابع أفضل مطور لهذا المشروع. يمكنك أيضًا رؤية هذا المشروع في محفظة شو.

الجانب العلوي الأيسر: مؤسس project89؛ الجانب السفلي الأيمن: 'lalaune' هو شو من ai16z

اليوم سنقدم بشكل أساسي إطار الوكيل عالي الأداء في المشروع89:

https://github.com/project-89/argOS

1. لماذا استخدام ECS لتصميم إطار العميل؟

من وجهة نظر التطبيق في مجال الألعاب

الألعاب التي تستخدم حاليًا هندسة البرمجيات المعمارية ECS تشمل:

ألعاب البلوكشين: Mud، Dojo

الألعاب التقليدية: أوفرواتش، نجم المواطن، الخ.

علاوة على ذلك، تتطور محركات الألعاب الرئيسية نحو تركيبة ECS، مثل Unity.

ما هو ECS؟

ECS (Entity-Component-System) هو نمط معماري يستخدم عادة في تطوير الألعاب ونظم المحاكاة. يفصل تمامًا البيانات عن المنطق لإدارة الكيانات المختلفة وسلوكها بكفاءة في سيناريوهات قابلة للتوسع بمقياس كبير:

Entity

• مجرد معرف (رقم أو سلسلة نصية)، لا يحتوي على بيانات أو منطق.

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

المكون

• يُستخدم لتخزين بيانات محددة أو حالة كيان.

النظام

• مسؤول عن تنفيذ المنطق المتعلق ببعض المكونات.

لنستخدم مثالًا محددًا لإجراء الوكيل لفهم هذا النظام:

في ArgOS ، يُعتبر كل وكيل ككيان يمكنه تسجيل مكونات مختلفة. على سبيل المثال ، في الصورة أدناه ، يحتوي وكيلنا على أربعة مكونات التالية:

مكون الوكيل: يخزن بشكل رئيسي المعلومات الأساسية مثل اسم الوكيل واسم النموذج وما إلى ذلك.

مكون الإدراك: يُستخدم بشكل رئيسي لتخزين البيانات الخارجية الملموسة

عنصر الذاكرة: يُستخدم بشكل رئيسي لتخزين بيانات الذاكرة لكيان الوكيل، وأشياء مشابهة تمت من قبل، إلخ.

مكون العمل: يخزن بشكل أساسي بيانات العمل للتنفيذ

سير عمل النظام:

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

ثم نحصل على وكيل تحديث الكيان الذي يتم تحديث بيانات كل مكون.

4. لذا يمكننا أن نرى أن النظام هنا مسؤول في الأساس عن تحديد العناصر المطلوب تنفيذها بالمنطق المعالجة المقابلة.

ومن الواضح أن في project89 هو عالم مليء بأنواع مختلفة من الوكلاء. على سبيل المثال، بعض الوكلاء ليس لديهم فقط القدرات الأساسية أعلاه ولكن لديهم أيضًا القدرة على وضع الخطط.

ثم سيكون كما هو مبين في الصورة أدناه:

تدفق تنفيذ النظام

ومع ذلك، على عكس الأطر التقليدية حيث يُفعل نظام واحد مباشرة النظام الآخر (على سبيل المثال، يُدعو نظام الإدراك نظام الذاكرة)، في Project89، لا تستدعي الأنظمة بعضها البعض مباشرة. بدلاً من ذلك، يعمل كل نظام بشكل مستقل عند فترات زمنية ثابتة. على سبيل المثال:

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

حتى الآن، قد قام هذا المقال بتبسيط بنية ArgOS بشكل كبير لجعلها أسهل في الفهم. الآن، دعونا نلقي نظرة أقرب على نظام ArgOS الحقيقي.

2. الهندسة المعمارية لنظام ArgOS

لتمكين الوكيل من التفكير بشكل أعمق وأداء مهام أكثر تعقيدًا ، صممت ArgOS العديد من المكونات والأنظمة.

ويقسم ArgOS System إلى "ثلاثة مستويات" (ConsciousnessLevel):

1) نظام CONSCIOUS

• يتضمن نظام الغرفة، نظام الإدراك، نظام الخبرة، نظام التفكير، نظام العمل، نظام التنظيف
• تكون تردد التحديث عادةً أعلى (مثل كل ١٠ ثوانٍ).
• معالجة أقرب إلى مستوى "في الوقت الحقيقي" أو "الوعي" ، مثل الإدراك البيئي ، والتفكير في الوقت الحقيقي ، وتنفيذ الإجراءات ، إلخ.

2) النظام اللاواعي (SUBCONSCIOUS)

• نظام التخطيط للأهداف، نظام التخطيط
• تحديث التردد منخفض نسبيا (على سبيل المثال كل 25 ثانية).
• يتعامل مع منطق "التفكير" مثل التحقق/إنشاء الأهداف والخطط بشكل دوري.

3) النظام اللاوعي (UNCONSCIOUS)

• لم يتم تمكينه بعد
• تكون تردد التحديث أبطأ (مثل أكثر من 50 ثانية)

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

لماذا تم تصميمه بهذه الطريقة؟

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

1. تتولى نظام الإدراك مسؤولية جمع "المحفزات" من العالم الخارجي أو الكيانات الأخرى وتحديثها لمكون الإدراك في الوكيل.

تحديد ما إذا كان التحفيز يتغير بشكل كبير وتحديثه وفقًا للثبات ووضع المعالجة (نشط / تأملي / انتظار)، وما إلى ذلك.

في النهاية، يتم توفير بيانات "الإدراك الحالي" لنظام الخبرة التالي، ونظام التفكير، وما إلى ذلك.

2. يحول نظام الخبرة المحفزات التي تم جمعها بواسطة نظام الإدراك إلى "تجربة" أكثر انتقالية.

LLM أو منطق القاعدة (extractExperiences) يتم استدعاؤه لتحديد تجارب جديدة وتخزينها في مكون الذاكرة.

التكرار، والتصفية، والتحقق من التجارب، مع تشغيل "تجربة" الأحداث لأنظمة أخرى أو المستمعين الخارجيين من خلال eventBus.

3. ThinkingSystem يمثل عملية التفكير الداخلية للوكيل.

استخراج الحالة الحالية من المكونات مثل الذاكرة والإدراك ، وتوليد "نتيجة الفكر" من خلال توليد الفكر (... ) ومنطق LLM / القاعدة.

بناء على نتيجة الفكرة، قد:

• تحديث الأفكار في الذاكرة (تاريخ التفكير).

• تحفيز إجراء جديد (وضعه في Action.pendingAction[eid]).

• تغيير مظهر الوكيل الخارجي (التعبير، الوضع، إلخ) وتوليد المحفزات ذات الصلة لتمكين الكيانات الأخرى من "رؤية" التغيير.

4. يقوم النظام بتنفيذ الإجراءات إذا كانتالعمل.الرمز المعلق is not empty, using runtime.getActionManager().executeAction(…).

بعد التنفيذ، اكتب النتيجة مرة أخرى في Action.lastActionResult واعلم الغرفة أو الكيانات الأخرى.

تنتج هذه أيضًا محفزًا إدراكيًا (تحفيز إدراكي) بحيث يمكن للأنظمة التالية "معرفة" أن الإجراء قد تم إنجازه أو يمكن دمجه في الذاكرة.

5. يقوم نظام تخطيط الأهداف بتقييم تقدم الأهداف بشكل دوري في قائمة Goal.current[eid]، أو يفحص الذاكرة الخارجية/الخاصة للتغيرات الكبيرة (الكشف عن التغيرات الكبيرة).

عندما يتطلب هدف جديد أو تعديل هدف ، قم بإنشاء وكتابة Goal.current[eid] عبر generateGoals(…).

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

يقوم نظام التخطيط بإنشاء أو تحديث الخطة (خطة التنفيذ) لـ "الهدف الحالي" (الهدف الحالي [eid]).

إذا تم اكتشاف أن بعض الأهداف ليس لديها خطط نشطة مقابلة، فتولد خريطة طريق تنفيذية تحتوي على عدة خطوات من خلال generatePlan(…) وتُكتب إلى Plan.plans[eid].

عند اكتمال الهدف أو فشله، سيتم تحديث حالة الخطة المرتبطة به وسيتم إنشاء تحفيز معرفي مقابل.

7. يتعامل نظام الغرف مع تحديثات ذات صلة بالغرفة:

• الحصول على قائمة السكان في الغرفة (السكان) وتوليد حوافز "المظهر" لكل وكيل لتمكين الكيانات الأخرى من "رؤية" مظهره أو أفعاله.

• إنشاء وربط حالة بيئة الغرفة المحفزة (مثل معلومات مناسبة حول "جو الغرفة").

تأكد من أنه عندما يكون الوكيل في بيئة مكانية معينة، يمكن للكيانات الأخرى التي تحس بالمكان تحس بالتغيرات في مظهره.

8. يقوم نظام التنظيف بشكل دوري بالعثور على الكيانات المحددة بواسطة مكون التنظيف. يستخدم لإعادة تدوير الحافز أو الكائنات الأخرى التي لم يعد لها حاجة لمنع ترك عدد كبير من الكيانات غير الصحيحة في ECS.

• مثال: حلقة من "رؤية الكائن" إلى "أداء الإجراء"

يوضح المثال التالي للمشهد كيف تتعاون كل نظام لإكمال عملية كاملة في جولة واحدة (أو عدة إطارات).

إعداد المشهد: هناك وكيل (EID=1) في العالم، الذي يكون في حالة "نشط" ويكون في غرفة (EID=100).

ظهرت ملكية جديدة "سيف سحري" في هذه الغرفة، وتم إنشاء الحافز المقابل.

1. تكتشف نظام الإدراك ظهور "سيف سحري" ، وتولد محفزًا (النوع = "ظهور العنصر") للوكيل (1) وتضيفه إلى الاستثارة الحالية للإدراك [1]. بالمقارنة مع هاش الاستثارة الأخيرة ، يتم تحديد أن هناك "تغيير كبير" وحالة المعالجة للوكيل هي "إعادة التنشيط" (وضع نشط).
2. يُعتَبَر نظام الخبرة أن Perception.currentStimuli للوكيل (1) ليس فارغًا، لذلك يستخرج معلومات مثل "تظهر السيف" إلى تجارب جديدة واحدة أو أكثر (النوع: "ملاحظة"). يتم تخزينه في ذاكرة الخبرات[1] وإرسال حدث "التجربة".
3. تقرأ ThinkingSystem الذاكرة والإدراك ومعلومات الحالة الأخرى وتستدعي generateThought:

رأيت سيف السحر، ربما يجب أن ألتقطه وأرى ماذا يمكنه فعله... نتيجة التفكير تحتوي على إجراء يجب تنفيذه: {tool: "pickUpItem"، parameters: {itemName: "MagicSword"}}

يقوم ThinkingSystem بكتابة هذا الإجراء إلى Action.pendingAction [1] .

إذا كان هناك تغيير في المظهر (على سبيل المثال "وجه بتعبير فضولي"), يتم تحديث المظهر ويتم إنشاء تحفيز بصري.

نظام العمليات يرى عملية معلقة[1] = {أداة: "التقاط العنصر", المعلمات: ...}.

قم بتنفيذ منطق "الامساك" من خلال runtime.getActionManager().executeAction("pickUpItem", 1, { itemName: "MagicSword" }, runtime). احصل على النتيجة: { success: true, message: "لقد التقطت سيف السحر" }, وقم بتحديث إلى Action.lastActionResult[1]، وقم بتشغيل حدث "العمل" ليتم بثه في الغرفة (100).

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

5. يقوم نظام تخطيط الأهداف (إذا كان لدى الوكيل أهداف) بتقييم أهداف الوكيل بشكل دوري. إذا كانت واحدة من أهداف الوكيل في هذا الوقت هي "الحصول على سلاح قوي" وتم اكتشاف حصول السيف السحري ، فقد يتم وضع علامة على الهدف كمكتمل. إذا حدثت تغييرات جديدة (على سبيل المثال ، "ظهور كائن جديد في الغرفة" يؤثر على الهدف الذي يسعى إليه الوكيل؟) ، فسيتم إنشاء هدف جديد أو التخلي عن الهدف القديم بناءً على اكتشاف التغييرات الكبيرة.
6. نظام التخطيط (إذا كان هناك هدف ذا صلة) يتحقق مما إذا كان هناك حاجة لخطة جديدة أو تحديث خطة قائمة لأهداف تم إكمالها أو إنشاءها حديثًا مثل "الحصول على أسلحة قوية".

إذا تم الانتهاء، قم بتعيين الخطة المرتبطة [status] إلى "completed"، أو قم بإنشاء خطوات إضافية إذا كان الهدف هو توسيع العملية التالية ("بحث سيف السحر").

تقوم RoomSystem بتحديث قائمة المحتلين والكيانات المرئية في الغرفة (100) (في كل إطار أو جولة).

إذا تغير مظهر العامل (1) (على سبيل المثال ، Appearance.currentAction = "حمل السيف") ، فقم بإنشاء حافز مرئي "مظهر" جديد للسماح ل Agent2 و Agent3 الآخرين في نفس الغرفة بمعرفة أن "agent1 التقط السيف".

8. يزيل نظام التنظيف الكيانات أو المحفزات التي تم وضع علامة عليها (التنظيف). إذا لم تعد بحاجة إلى الاحتفاظ بمحفز "MagicSword" بعد التقاطه ، يمكنك حذف كيان المحفز المقابل في نظام التنظيف.

1. من خلال ربط هذه الأنظمة ، يتحقق AI Agent من:

• الإدراك للتغيرات في البيئة (الإدراك) → تسجيل أو تحويلها إلى تجربة داخلية (التجربة) → التفكير الذاتي واتخاذ القرار (التفكير) → تحويلها إلى عمل (العمل) → ضبط الأهداف والخطط بشكل ديناميكي (تخطيط الأهداف + التخطيط) → مزامنة البيئة (الغرفة) → إعادة تدوير الكيانات الغير مفيدة في الوقت المناسب (التنظيف)

3. تحليل الهندسة المعمارية العامة لأرجوس

1. طبقات البنية الأساسية

2. تصنيف المكونات

في ECS، يمكن لكل كيان أن يحتوي على عدة مكونات. وفقًا لطبيعتها ودورة حياتها في النظام، يمكن تقسيم المكونات تقريبًا إلى الفئات التالية:

1. فئات الهوية الأساسية (مكونات مستوى الهوية)

• العميل / ملف تعريف اللاعب / ملف تعريف NPC، إلخ.

• يُستخدم لتحديد هويات الكيانات بشكل فريد، وتخزين الأدوار الأساسية أو معلومات الوحدة، وعادة ما يتعين الاحتفاظ بها في قاعدة البيانات.

2. مكونات السلوك والحالة

• العمل، الهدف، الخطة، حالة المعالجة، إلخ.

• يمثل ما تحاول الكيان فعله حالياً أو ما هي أهدافه، بالإضافة إلى حالته استجابة للأوامر الخارجية والتفكير الداخلي.

• يحتوي على الإجراءات المعلقة، والأهداف قيد التقدم، والخطط، والأفكار أو المهام في الطابور، إلخ.

• عادةً حالات متوسطة / قصيرة الأجل، العديد منها يتغير بشكل ديناميكي عبر جولات اللعب أو دورات الأعمال.

• إذا كنت ترغب في الاستمرار في التشغيل بعد نقطة التوقف ، فقد تود تخزين البيانات في فترات منتظمة.

3. مكونات الإدراك والذاكرة

• الإدراك، الذاكرة، المحفز، التجربة، الخ.

• يسجل المعلومات الخارجية (المحفزات) التي يتم تصورها من قبل الكيان، والتجارب المعدلة فيه بعد الإدراك (التجارب).

يمكن للذاكرة في كثير من الأحيان تجميع كميات كبيرة من البيانات، مثل سجلات المحادثة وتاريخ الأحداث وما إلى ذلك؛ وعادة ما يكون الاستمرارية مطلوبة.

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

4. فئات البيئة والمساحة (الغرفة، يحتل الغرفة، مكاني، بيئة، مخزون، الخ).

• يمثل معلومات مثل الغرف والبيئات والمواقع وحاويات الكائنات، إلخ.

•Room.id, يجب غالبًا الاحتفاظ بالمجالات مثل OccupiesRoom وEnvironment وغيرها، مثل وصف صفحة الغرفة الرئيسية وهيكل الخريطة، إلخ.

• يمكن كتابة تغيير المكونات (مثل كيان يتحرك بين الغرف) بناءً على الأحداث أو بشكل دوري.

5. فصول المظهر والتفاعل (المظهر ، حالة واجهة المستخدم ، العلاقة ، الخ)

• سجل الأجزاء الخارجية 'المرئية' أو 'التفاعلية' للكيان، مثل الصورة الرمزية، والوضعية، وتعبير الوجه، وشبكة العلاقات الاجتماعية مع الكيانات الأخرى، إلخ.

• قد يتم معالجة بعض الأجزاء فقط في الذاكرة (التمثيل في الوقت الحقيقي)، بينما يمكن الاحتفاظ بأجزاء أخرى (مثل العلاقات الاجتماعية الرئيسية).

6.مكونات الأدوات والصيانة (التنظيف، المعلومات التصحيحية، بيانات البروفايل، إلخ.)

• يُستخدم لوضع علامة على الكيانات التي يجب إعادة تدويرها (التنظيف)، أو تسجيل معلومات التصحيح (معلومات الإصلاح) للاستخدام في المراقبة والتحليل.

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

3. هندسة النظام

مثل ما تم ذكره بالفعل

4. تصميم المدير

بالإضافة إلى المكونات والأنظمة، يُطلب طبقة إدارة موارد إضافية. تتعامل هذه الطبقة مع الوصول إلى قاعدة البيانات، وتضارب الحالة، والعمليات الأساسية الأخرى.

الجانب الأيسر: الأنظمة (نظام الإدراك ، نظام الخبرة ، نظام التفكير ، إلخ):

• يتم جدولة كل نظام للتنفيذ بواسطة SimulationRuntime في حلقة ECS، باستعلام ومعالجة الكيانات التي يهتم بها (من خلال شروط المكون).

• عند تنفيذ الخطط، تحتاج إلى التفاعل مع المديرين، على سبيل المثال:

• اتصل بمدير الغرف (RM) للاستعلام / تحديث معلومات الغرفة.
• استخدم StateManager (SM) للحصول على حالة العالم / الوكيل أو حفظها مثل الذاكرة والهدف والخطة، إلخ.
• البث أو الاستماع للأحداث خارجيًا باستخدام EventBus (EB).
• يتم استدعاء PromptManager (PM) عندما يكون مطلوبًا معالجة اللغة الطبيعية أو الرسائل التحفيزية.

الجانب الأيمن: المديرين (EventBus، RoomManager، StateManager، EventManager، ActionManager، PromptManager، الخ)：

• توفير وظائف على مستوى النظام، التي في الأساس لا تقوم بتنفيذ الـ "دافع" بنشاط للمنطق، ولكنها تستدعى بواسطة الأنظمة أو وقت التشغيل.

• أمثلة نموذجية:

• إن ActionManager متخصص في إدارة التسجيل وتنفيذ الإجراءات.
• تستخدم "EventManager / EventBus" لنشر الأحداث وآليات الاشتراك.
• يدير RoomManager الغرف والتخطيطات والمحتلين.
• StateManager مسؤول عن التزامن بين ECS وقاعدة البيانات أو التخزين.
• يوفر PromptManager الامتدادات مثل قوالب LLM Prompt وإدارة السياق.
• Intermediate SimulationRuntime (R):

• هل هو "جدول زمني" لجميع الأنظمة، بدء أو إيقاف دورات النظام على مستويات مختلفة (الواعي / اللاواعي، إلخ)؟

• يتم إنشاء المديرين أيضًا خلال مرحلة البناء ويتم تمريرهم إلى كل نظام للاستخدام.

• نظام التنظيف:

• لاحظ على وجه الخصوص أنه يتفاعل أيضًا مع ComponentSync (CS) ، والذي يُستخدم لإزالة المكونات أو الاشتراكات في الأحداث بطريقة متزامنة عند إعادة تدوير الكائنات.

في الختام:

سيقوم كل نظام بقراءة وكتابة البيانات أو استدعاء الخدمات من خلال المدير المقابل عند الحاجة ، وسيقوم Runtime بجدولة الدورة الحياتية وسلوك جميع الأنظمة والمديرين على مستوى أعلى بشكل موحد.

5. كيف تتفاعل الفيكتورات وقواعد البيانات في ECS

في نظام ECS، تتعامل الأنظمة مع تنفيذ المنطق الفعلي، بينما تُدار عمليات قاعدة البيانات (القراءة/الكتابة) من خلال مدير الصمود (PersistenceManager / DatabaseManager) أو مدير الحالة (StateManager). العملية العامة هي كما يلي:

1. Initial Load (مرحلة بدء التشغيل أو التحميل)

يقوم StateManager / PersistenceManager بتحميل بيانات مكونات الثبات الأساسية مثل العملاء والغرف والأهداف وما إلى ذلك من قاعدة البيانات ، وإنشاء كيانات مقابلة (Entities) وتهيئة حقول المكون ذات الصلة.

• على سبيل المثال ، قراءة دفعة من سجلات الوكيل وإدخالها في عالم ECS ، وتهيئة المكونات مثل الوكيل والذاكرة والهدف وغيرها لهم.

2. تشغيل ECS (حلقة تحديث الأنظمة)

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

يكتب ExperienceSystem "تجربة معرفية" الجديدة في Memory.experiences. إذا كانت تجربة مفتاحية ، فقد يطلب أيضًا من StateManager التخزين الفوري ، أو يضع علامة عليها بـ "needsPersistence" للكتابة الدفعية في وقت لاحق.

يتخذ نظام الفكر / نظام العمل / نظام تخطيط الأهداف وغيرها من القرارات استنادًا إلى محتوى المكون وتحديث الحقول في ECS.

إذا مرت بعض المكونات (مثل Goal.current) بتغييرات رئيسية وتتطلب الاستمرارية (مثل هدف جديد طويل الأجل)، فأعلم StateManager بكتابة هذا الحقل إلى قاعدة البيانات من خلال الاستماع إلى المكون أو أحداث النظام.

3. الحفظ الدائم الدوري أو المستند إلى الحدث

• يمكنك استدعاء الواجهات مثل PersistenceManager.storeComponentData(eid, "Goal") لإسقاط المكتبة في نقاط مفتاحية معينة في النظام (مثل عند تحديث الخطة المستهدفة أو عند حدوث حدث مهم على الوكيل).

• يمكنك أيضًا لدى StateManager مسح المكونات أو الكيانات بوسم "needsPersistence" في CleanupSystem أو المؤقت، وكتابتها مرة واحدة إلى قاعدة البيانات.

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

4. الحفظ اليدوي أو إيقاف التشغيل (التحقق والثبات عند الخروج)

• عند إيقاف خادم أو عملية، استخدم StateManager.saveAll() لكتابة البيانات غير المكتوبة إلى قاعدة البيانات بشكل موحد لضمان أن يمكن استعادة حالة ECS في المرة القادمة التي يتم فيها تحميلها.

• بالنسبة لبعض السيناريوهات المستقلة / غير المتصلة بالإنترنت، يمكن أيضًا تشغيل الأرشيف يدويًا.

• عملية العينة الكاملة

التالي هو سيناريو بسيط لتوضيح الطرق الممكنة التي تتفاعل بها المكونات وقواعد البيانات:

1. مرحلة البدء: StateManager.queryDB("SELECT * FROM agents") → الحصول على دفعة من سجلات الوكيل ، وإنشاء Entity (EID = x) لكل سجل بدوره ، وتهيئة حقول الوكيل والذاكرة والهدف والمكونات الأخرى.

في نفس الوقت، قم بتحميل معلومات الغرفة من جدول "الغرف" وإنشاء كيان غرفة.

2. العمليات الزمنية: PerceptionSystem يكتشف حدوث الحدث 'ظهور سيف سحري' في غرفة معينة ويكتب Perception.currentStimuli [eid]. ExperienceSystem يحول المحفزات إلى تجربة ويسندها إلى Memory.experiences [eid]. يحدد ThinkingSystem الإجراء التالي بناءً على الذاكرة والهدف ومعلومات أخرى ويولد Action.pendingAction [eid]. بعد تنفيذ ActionSystem الإجراء ، يكتب النتيجة إلى الذاكرة أو Action.lastActionResult. إذا كان هذا حدثًا رئيسيًا في القصة ، سيتم وضع علامة على الجزء الأحدث من Memory.experiences [eid] على أنه يحتاج إلى الاستمرار. بعد فترة من الزمن ، يجد StateManager أن Memory.experiences [eid] يحتوي على 'needsPersistence' ويكتبه إلى قاعدة البيانات (INSERT INTO memory_experiences ...).

3. إيقاف أو حفظ نقطة التفتيش: باستنادًا إلى جدولة ECS أو النظام ، يتم استدعاء StateManager.saveAll () عندما يتم إيقاف تشغيل الخادم لكتابة آخر حالة لحقول المكونات الرئيسية (العميل ، الذاكرة ، الهدف ، إلخ.) ما زالت في الذاكرة إلى قاعدة البيانات. يمكن تحميل حالة عالم ECS المخزنة في قاعدة البيانات واستعادتها عند إعادة التشغيل المقبلة.

• تصنيف المكونات ليس فقط يسهل إدارة البيانات الكيان في المشروع، ولكنه يساعدنا أيضًا في التحكم في حدود البيانات بين "يتطلب الاستمرارية" و "الموجودة فقط في الذاكرة".

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

بهذه الطريقة ، يمكنك الاستمتاع في نفس الوقت بالكفاءة المنطقية والمرونة لـ ECS ، بالإضافة إلى مزايا الاستمرارية واستئناف النقاط وتحليل البيانات التحصيلية التي يوفرها قاعدة البيانات.

4. الابتكارات المعمارية

تبرز من الهندسة المعمارية بأكملها:

• يعمل كل نظام بشكل مستقل ولا يوجد علاقة استدعاء بينه وبين الأنظمة الأخرى. ولذلك، حتى لو أردنا تنفيذ قدرات "إدراك التغييرات في البيئة (الإدراك) → تسجيلها أو تحويلها إلى تجربة داخلية (التجربة) → التفكير واتخاذ القرار (التفكير) → وضعها في التطبيق (التطبيق) → ضبط الأهداف والخطط بشكل ديناميكي (التخطيط الهدف + التخطيط) → مزامنة البيئة (الغرفة) → إعادة تدوير الكيانات العديمة الفائدة في الوقت المناسب (التنظيف)", فسوف يكون لكل نظام العديد من التبعيات في الوظائف، ولكن يمكننا ما زلنا نستخدم بنية ECS لتقسيم الكل إلى أنظمة مستقلة. وما زال بإمكان كل نظام العمل بشكل مستقل ولن يتفاعل مع الأنظمة الأخرى. هناك أشخاص وعلاقات تشابكية.
• أعتقد أن هذا هو السبب الرئيسي الذي جعل Unity تنتقل بشكل متزايد إلى تطبيق الهندسة العكسية ECS في السنوات الأخيرة.
• وعلى سبيل المثال، أرغب فقط في أن يكون لدى الوكيل بعض القدرات الأساسية. أحتاج فقط إلى تقليل تسجيل بعض العناصر وتسجيل النظام عند تحديد الكيان، وهذا يمكن تحقيقه بسهولة دون تغيير بضعة أسطر من الكود.

كما هو موضح أدناه:

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

• بالإضافة إلى ذلك، أداء الهندسة المعمارية الحالية في الواقع أفضل بكثير من الهندسة المعمارية الموجهة نحو الكائنات التقليدية. وهذه حقيقة معترف بها في دائرة الألعاب، لأن تصميم ECS أكثر مناسبة للتوازي، لذا عند استخدام ECS في سيناريوهات Defai المعقدة، قد تكون الهندسة المعمارية لديها مزيد من المزايا، خصوصاً في السيناريوهات حيث يُتوقع أن يتم استخدام الوكلاء في المعاملات الكمية، سيكون ECS أيضاً مفيد (ليس فقط في سيناريوهات الألعاب الوكيل).
• تجزئة النظام إلى الواعي واللاواعي واللاوعي للتمييز بين مدى تنفيذ أنواع مختلفة من الأنظمة هو تصميم ذكي للغاية وهو بالفعل قدرة إنسانية ملموسة جدًا.

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

تنويه:

1. هذه المقالة مستنسخة من [0xhhh]. إعادة توجيه العنوان الأصلي: أرى إطار الوكيل للجيل القادم في Project89. حقوق النشر تنتمي إلى الكاتب الأصلي [0xhhh]. إذا كان لديك أي اعتراض على إعادة الطبع، يرجى الاتصال بوابة تعلمالفريق، سيتولى الفريق الأمر في أقرب وقت ممكن وفقا للإجراءات ذات الصلة.
2. تنويه: تعبر الآراء والآراء المعبر عنها في هذه المقالة فقط عن آراء الكاتب الشخصية ولا تشكل أي نصيحة استثمارية.
3. تترجم الفريق التعلم في بوابة النسخ الأخرى من المقالة. ما لم ينص على خلاف ذلك، قد لا يتم نسخ المقالة المترجمة أو توزيعها أو نسخها.