مستقبل الألعاب عبر السلسلة: "وعد محرك MUD ECS"

متوسط3/18/2024, 8:59:36 AM
تقدم هذه المقالة شروحات وحلول تقنية لمشكلات صناعة الألعاب المتسلسلة المعتمدة على محرك ECS.

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

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

دروس من صناعة الألعاب التقليدية

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

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

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

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

هناك بعض المشكلات الأساسية المرتبطة بالألعاب الموجودة على السلسلة:

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

حل الطين:

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

ECS في العقود الذكية:

إن اللبنات الأساسية في MUD هي المكونات. إنها عقود منشورة تعمل مثل قواعد البيانات التي تخزن البيانات حول الكيانات. على سبيل المثال، لنأخذ كيانًا (عنوانًا) مثل محفظة اللاعب. يمكن أن يكون لهذا الكيان الذي يمثله عنوان خصائص مختلفة، مثل قيمة الموضع (x,y) في مكون الموضع، والمستوى 10 في مكون المستوى، و50 في مكون العملات المعدنية. تتكون المكونات فقط من التعيين والتكوين الأساسي. الأنظمة أكثر تعقيدًا وتنفذ منطق تغيير القيمة في المكونات. يمكنك التفكير في هذا الأمر باعتباره نظامًا يحدد واجهة برمجة التطبيقات (API) لطلبات POST على قواعد البيانات (المكونات). ولا يمكنهم القيام بذلك إلا إذا مُنحوا حق الوصول للكتابة إلى مكونات محددة. هنا يصبح الأمر مثيرًا للاهتمام. يمكن للأنظمة أن تتفاعل مع مكونات مختلفة لإنشاء منطق تفصيلي. يمكن أن يكون لديك نظام حركة يحدد الحركة الصالحة التي يمكن للاعب القيام بها (على سبيل المثال، خطوتين في كل مرة)، ويمكن أن يكون لديك نظام مكافآت يمنح اللاعبين عملات معدنية في كل مرة يصلون فيها إلى المستوى الأعلى. يتم تسجيلهم جميعًا في "الاتصال العالمي" بحيث يتبع كل تغيير في بيانات المكونات حدث منبعث. العقود العالمية لا يجوز. يمكن لأي شخص إضافة أنظمة ومكونات جديدة. من الناحية النظرية، يمكن للعوالم المختلفة أن تتفاعل مع بعضها البعض.

يؤدي جلب ECS إلى الألعاب عبر السلسلة إلى بنية أنيقة للغاية، بحيث تتكون OPcraft من 10 مكونات فقط وحوالي 15 نظامًا. يمكنك التحقق من منشور المدونة الرائع هذا على MUD.dev

قابلية التركيب الحقيقية

لا يعد نظام ECS منطقيًا تمامًا في تطوير الألعاب التقليدية فحسب، بل أكثر من ذلك في الألعاب المتصلة بالإنترنت من خلال توفير ميزتين مهمتين

  1. إمكانية ترقية اللعبة المنشورة
  2. أعلى درجة من القابلية للتكوين

تخيل طريقين. الأول هو الحفاظ على التصميم الأساسي. والآخر هو تغيير منطق اللعبة الأساسي.

فكر في لعبة إستراتيجية PVP قياسية حيث يمكن للاعبين بناء جيوش لمحاربة بعضهم البعض. كان الإصدار الأساسي ثنائي الأبعاد، لكن قرر الفريق الآن أنهم يريدون إنشاء عرض تفصيلي ثلاثي الأبعاد للعبة. كل ما يحتاجون إليه هو أخذ جميع الأنظمة المتعلقة بالموقع وإنشاء إصدارات مطورة بإحداثيات (x,y,z) بدلاً من (x,y). يمكن أن تظل جميع الأنظمة والمكونات الأخرى (مثل نظام الهجوم ونقاط الصحة ومبنى الجيش) كما هي. بل إنه يتجاوز فرق التطوير الأولية، حيث يمكن للمجتمعات إنشاء تعديلات مختلفة للعبة عن طريق إعادة نشر الأنظمة والمكونات أو حتى التفاعل مع نفس المكونات من خلال منح حق الوصول للكتابة إلى الأنظمة الجديدة (إذا كانت لعبة مملوكة للمجتمع، فيمكن إنشاء نماذج إدارة مختلفة تطبق على هذا النوع من القرارات)

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

جانب العميل منظور شامل:

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

لقد نظرنا حتى الآن في MUD على مستوى العقد الذكي. ولكن هناك الكثير. يوفر MUD مجموعة كاملة من مكتبات وطبقات العميل. هناك بعض الميزات الفريدة التي تم تصميم MUD من أجلها.

  1. قابلية تكوين العميل
  2. العميل متزامن بالكامل مع تغيير حالة blockchain (بيانات اللعبة)
  3. PhaserX كطبقة العرض

دعونا نتعمق في التفاصيل الفنية لجعلها أكثر واقعية.

طبقة الشبكة:

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

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

قد تسأل عن كيفية مزامنة مكونات العميل مع مكونات السلسلة بالضبط. يعد هذا أحد التحديات المهمة التي يواجهها المنشئون عند التعامل مع جانب العميل في الألعاب الموجودة على السلسلة. لدى MUD بعض الحلول لذلك.

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

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

طبقة العرض - متى وكيف يتم عرض الأحداث

يأتي MUD مزودًا بـ PhaserX، "مبنى محرك قابل للتطوير بشكل كبير فوق جهاز Phaser"، وهو ليس إلزاميًا. يوجد في OPcraft محرك Noa voxel بدلاً من محرك PhaserX. من الناحية النظرية، يمكنك استخدام أي محرك تريده طالما أنه يتبع الهيكل.

كما ذكرنا سابقًا، يتم تسجيل كل مكون ونظام في العقد العالمي، وعندما يحدث تغيير، سيتم إصدار حدث (مع بيانات محددة مثل معرف المكون ومعرف الكيان). هنا يمكن لخدمة البث ECS أن توفر للعميل خيار اختيار الأحداث التي سيتم الاشتراك فيها.

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

تنصل:

  1. تمت إعادة طباعة هذه المقالة من [مرآة]، جميع حقوق الطبع والنشر مملوكة للمؤلف الأصلي [Matchbox DAO]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn "Gate Learn")، وسوف يتعاملون مع الأمر على الفور.
  2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
  3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.

مستقبل الألعاب عبر السلسلة: "وعد محرك MUD ECS"

متوسط3/18/2024, 8:59:36 AM
تقدم هذه المقالة شروحات وحلول تقنية لمشكلات صناعة الألعاب المتسلسلة المعتمدة على محرك ECS.

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

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

دروس من صناعة الألعاب التقليدية

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

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

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

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

هناك بعض المشكلات الأساسية المرتبطة بالألعاب الموجودة على السلسلة:

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

حل الطين:

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

ECS في العقود الذكية:

إن اللبنات الأساسية في MUD هي المكونات. إنها عقود منشورة تعمل مثل قواعد البيانات التي تخزن البيانات حول الكيانات. على سبيل المثال، لنأخذ كيانًا (عنوانًا) مثل محفظة اللاعب. يمكن أن يكون لهذا الكيان الذي يمثله عنوان خصائص مختلفة، مثل قيمة الموضع (x,y) في مكون الموضع، والمستوى 10 في مكون المستوى، و50 في مكون العملات المعدنية. تتكون المكونات فقط من التعيين والتكوين الأساسي. الأنظمة أكثر تعقيدًا وتنفذ منطق تغيير القيمة في المكونات. يمكنك التفكير في هذا الأمر باعتباره نظامًا يحدد واجهة برمجة التطبيقات (API) لطلبات POST على قواعد البيانات (المكونات). ولا يمكنهم القيام بذلك إلا إذا مُنحوا حق الوصول للكتابة إلى مكونات محددة. هنا يصبح الأمر مثيرًا للاهتمام. يمكن للأنظمة أن تتفاعل مع مكونات مختلفة لإنشاء منطق تفصيلي. يمكن أن يكون لديك نظام حركة يحدد الحركة الصالحة التي يمكن للاعب القيام بها (على سبيل المثال، خطوتين في كل مرة)، ويمكن أن يكون لديك نظام مكافآت يمنح اللاعبين عملات معدنية في كل مرة يصلون فيها إلى المستوى الأعلى. يتم تسجيلهم جميعًا في "الاتصال العالمي" بحيث يتبع كل تغيير في بيانات المكونات حدث منبعث. العقود العالمية لا يجوز. يمكن لأي شخص إضافة أنظمة ومكونات جديدة. من الناحية النظرية، يمكن للعوالم المختلفة أن تتفاعل مع بعضها البعض.

يؤدي جلب ECS إلى الألعاب عبر السلسلة إلى بنية أنيقة للغاية، بحيث تتكون OPcraft من 10 مكونات فقط وحوالي 15 نظامًا. يمكنك التحقق من منشور المدونة الرائع هذا على MUD.dev

قابلية التركيب الحقيقية

لا يعد نظام ECS منطقيًا تمامًا في تطوير الألعاب التقليدية فحسب، بل أكثر من ذلك في الألعاب المتصلة بالإنترنت من خلال توفير ميزتين مهمتين

  1. إمكانية ترقية اللعبة المنشورة
  2. أعلى درجة من القابلية للتكوين

تخيل طريقين. الأول هو الحفاظ على التصميم الأساسي. والآخر هو تغيير منطق اللعبة الأساسي.

فكر في لعبة إستراتيجية PVP قياسية حيث يمكن للاعبين بناء جيوش لمحاربة بعضهم البعض. كان الإصدار الأساسي ثنائي الأبعاد، لكن قرر الفريق الآن أنهم يريدون إنشاء عرض تفصيلي ثلاثي الأبعاد للعبة. كل ما يحتاجون إليه هو أخذ جميع الأنظمة المتعلقة بالموقع وإنشاء إصدارات مطورة بإحداثيات (x,y,z) بدلاً من (x,y). يمكن أن تظل جميع الأنظمة والمكونات الأخرى (مثل نظام الهجوم ونقاط الصحة ومبنى الجيش) كما هي. بل إنه يتجاوز فرق التطوير الأولية، حيث يمكن للمجتمعات إنشاء تعديلات مختلفة للعبة عن طريق إعادة نشر الأنظمة والمكونات أو حتى التفاعل مع نفس المكونات من خلال منح حق الوصول للكتابة إلى الأنظمة الجديدة (إذا كانت لعبة مملوكة للمجتمع، فيمكن إنشاء نماذج إدارة مختلفة تطبق على هذا النوع من القرارات)

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

جانب العميل منظور شامل:

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

لقد نظرنا حتى الآن في MUD على مستوى العقد الذكي. ولكن هناك الكثير. يوفر MUD مجموعة كاملة من مكتبات وطبقات العميل. هناك بعض الميزات الفريدة التي تم تصميم MUD من أجلها.

  1. قابلية تكوين العميل
  2. العميل متزامن بالكامل مع تغيير حالة blockchain (بيانات اللعبة)
  3. PhaserX كطبقة العرض

دعونا نتعمق في التفاصيل الفنية لجعلها أكثر واقعية.

طبقة الشبكة:

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

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

قد تسأل عن كيفية مزامنة مكونات العميل مع مكونات السلسلة بالضبط. يعد هذا أحد التحديات المهمة التي يواجهها المنشئون عند التعامل مع جانب العميل في الألعاب الموجودة على السلسلة. لدى MUD بعض الحلول لذلك.

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

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

طبقة العرض - متى وكيف يتم عرض الأحداث

يأتي MUD مزودًا بـ PhaserX، "مبنى محرك قابل للتطوير بشكل كبير فوق جهاز Phaser"، وهو ليس إلزاميًا. يوجد في OPcraft محرك Noa voxel بدلاً من محرك PhaserX. من الناحية النظرية، يمكنك استخدام أي محرك تريده طالما أنه يتبع الهيكل.

كما ذكرنا سابقًا، يتم تسجيل كل مكون ونظام في العقد العالمي، وعندما يحدث تغيير، سيتم إصدار حدث (مع بيانات محددة مثل معرف المكون ومعرف الكيان). هنا يمكن لخدمة البث ECS أن توفر للعميل خيار اختيار الأحداث التي سيتم الاشتراك فيها.

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

تنصل:

  1. تمت إعادة طباعة هذه المقالة من [مرآة]، جميع حقوق الطبع والنشر مملوكة للمؤلف الأصلي [Matchbox DAO]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn "Gate Learn")، وسوف يتعاملون مع الأمر على الفور.
  2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
  3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.
Şimdi Başlayın
Kaydolun ve
100 USD
değerinde Kupon kazanın!