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

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

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

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

الأسباب التقنية التي تعيق مطوري الألعاب التقليدية من دخول نظام الويب3

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

1. الفرق بين تطبيقات الويب3 وهياكل البرمجيات التقليدية

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

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

1. القيود التصميمية للعقود الذكية

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

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

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

1. القيود على تخزين البيانات واسترجاعها

• العقود الذكية لديها مساحة تخزين مكلفة وتصميم محدود، مما يجعلها غير مناسبة لتخزين كميات كبيرة من بيانات اللعبة.
• قد تكون هناك حاجة إلى سجلات الأحداث لتتبع حالة اللعبة بشكل غير مباشر، وقد لا يكون التقاط الأحداث مستقرًا. قد تتطلب المشاكل مثل متى تحديث حالة اللعبة غالبًا من اللاعبين أو مشغلي اللعبة تشغيلها يدويًا.
• هيكل بيانات الحساب المعتمد من EVM يؤدي إلى قدرات فهرسة البيانات الضعيفة. عند الاستعلام عن بيانات حساب ما، يمكنك أن تعرف فقط رصيد ETH أو الرمز الخاص بالسلسلة الخاصة به، ولكن لا يمكن معرفة أصول ERC-20 التي يمتلكها ورصيد كل أصل مباشرةً. الأمر نفسه ينطبق على NFT. يتم تجميع هذه المعلومات في عقد كل أصل حصريًا، بدلاً من تخزينها تحت حساب المستخدم الخاص به.

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

يضطر مطورو الويب3 عادةً إلى دمج مزودي بيانات من الطرف الثالث مثل Etherscan، NFTscan، The Graph، وما إلى ذلك، وحتى يضطرون لدفع رسوم للحصول على مفتاح API الخاص بهم. بالإضافة إلى ذلك، هذه الخدمات من الطرف الثالث تعتبر أساسًا قواعد بيانات خارج السلسلة، والتي قد تتسبب في تأخيرات، أخطاء، تجاوز حدود الاستدعاء، عدم توفر الخدمة وفشل آخر.

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

1. التحديات في دمج الأصول اللعبة الحالية مع تقنية سلسلة الكتل

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

1. الترقيات، التصحيحات والوقاية من الكوارث

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

ترقية رمز الألعاب التقليدية ليست معقدة إلى هذا الحد من حيث الهيكل التقني. الشيء الوحيد الذي قد يحتاج إلى تقييد هو السلطة المركزية للترقية. يمكن تحقيق ذلك من خلال طرق مثل DAO بدلاً من الاعتماد على العقود الذكية.

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

1. تجزئة البيئة وقضايا تجربة المستخدم

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

في Web3، هذا أساسًا ترف فاخر. تهاجر إلى سلسلة أو آلة افتراضية مختلفة تعني إعادة بناء المشروع بأكمله وتكبد تكاليف هائلة. والأمر الأكثر أهمية، أن المطورين الجدد في Web3 ليس لديهم أي تجربة على الإطلاق لاختيار بيئة تناسبهم. هل هو من منظور تقني أم بيئي؟

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

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

يمكن القول إن معظم مطوري الألعاب الرائدين لم يدخلوا إلى Web3. إلى حد ما، يجعل هذا معظم ألعاب Web3 متحيزة نحو التكهن المالي بدلاً من أن تكون لها قابلية خاصة للعب والمرح.

توجد عقبات من نفس الطبيعة أيضًا على جانب المستخدم. تحتوي ألعاب Web3 على سلسلة من خطوات العمليات التي تعيق معدلات تحويل المستخدم، مما يؤدي إلى وجود مجموعة كبيرة من المستخدمين من Web2 الذين لا يرغبون في تجربة أو حتى لا يدركون تمامًا وجود ألعاب Web3.

هل هناك مشروع في مستوى البنية التحتية يمكن أن يحل المشاكل المذكورة أعلاه؟ قد يكون Tabi Chain مشروعًا قريبًا جدًا من إحدى الحلول النهائية لألعاب الويب3. مفهومه الأساسي هو "Omni Execution Layer": لم يعد المطورون بحاجة إلى الاهتمام بالفروق بين مختلف الآلات الظاهرية أو بيئات التشغيل. يمكنهم استخدام بيئات التشغيل المألوفة لديهم أو حتى قابلة للتخصيص مباشرة لتطوير ألعاب أو نقلها مباشرة.

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

Omni-Execution Layer: اختيار بيئة التنفيذ استنادًا إلى احتياجات المطور

دعونا نستعيد مفهوم البلوكشين الأساسي. بينما قد يصف البعض أنها دفتر أستاذ غير مركزي ولا يمكن تغييره، يمكن تحديده بدقة أكبر على أنه تزامن قابل للتحقق لحالة دائمة لآلة حالة ضمن شبكة موزعة.

بالجوهر، تحافظ سلسلة الكتل على جهاز حالة مقبول عالميا وحالته التشغيلية:

• كل إدخال محدد، مسجل في كل كتلة؛
• وظيفة انتقال الحالة هي محددة، تمثلها آلة الظاهرة أو الوقت التشغيلي داخل عميل سلسلة الكتل.
• الحالة الناتجة أيضًا محددة مسبقًا، مُسجلة في كل كتلة؛

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

في تابي، يمكن لكل لعبة أو dApp بناء خدمتها المستقلة الخاصة. تقوم جميع الخدمات بتقديم الكتل التي تم إنشاؤها ذاتيًا إلى نظام الاتفاق في السلسلة؛ تشمل العقد المشرفة الوقت التشغيل/VM في جميع الخدمات للتحقق من حالة كتل الخدمة. يمكن اعتبار نواة طبقة التنفيذ شاملة الكل في تابي على أنها VM بقدرات متعددة الشكل، لذا يُطلق عليها اسم Polymorphism VM.

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

الحالة العالمية المشتركة: شبيهة بـ Ethermint، التي تدعم EVM على Cosmos. يعمل EVM كطبقة سطحية، مركزًا على تفاعل المستخدم وعمليات العقد، مما يجعل جميع أنشطة الجانب الخاص بالمستخدم تبدو وكأنها تُنفذ على EVM. ومع ذلك، يتم تخزين النتائج النهائية والبيانات لهذه العمليات في وحدات Cosmos أخرى. وبالتالي، تعددية EVM هذه في الأساس تعددية للبيانات الأساسية.

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

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

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

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

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

مثال على نقل لعبة Web2

يمكن تخصيص جهاز الـ Polymorphism بشكل كبير، مما يجعله مفيدًا بشكل خاص لمطوري الويب2. يمكنهم استخدام لغات وأطر عمل مألوفة لنقل أي منطق تجاري إلى جهاز الـ Polymorphism.

نفترض أن Minecraft يرغب في الانتقال إلى Tabi. سيكون العملية العامة كما يلي:

1. تعديل كود الخادم: قم بتعديل بسيط على كود خادم Minecraft (Java أو أي لغة أخرى)، بنقل البيانات التي تحتاج إلى أن تكون على السلسلة إلى قاعدة بيانات (أو مجموعة من قواعد البيانات). حدد وحدد جميع الوظائف التي قد تعدل هذه القاعدة البيانات (أي وظائف انتقال الحالة).
2. قم بتعبئة المكونات: قم بتعبئة قاعدة البيانات هذه وهذه الوظائف في ملف JAR، والذي يعتبر برنامجًا قابلًا للتنفيذ في Java. قم بتضمين بيئة تشغيل Java (JRE) في هذه الحزمة. يتم تحميل هذه الحزمة بأكملها ثم في جهاز Polymorphism VM، مما يضمن أن جميع البيانات على السلسلة الرئيسية.
3. تشغيل منطق خارج السلسلة: تشغيل منطق الخلفية الآخر الذي لا يحتاج إلى أن يكون على السلسلة (مثل تشكيل الفريق، الدردشة، الخ) على خوادم خارج السلسلة.
4. بدء خدمة: بادر بخدمة في سلسلة تابي وأخطر بوليمورفيسم VM الخوادم المشرفة بتحميل نفس JRE.
   

بهذا، العملية بأكملها قد اكتملت.

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

تفاصيل وظائف اللعبة STR (State Transition Runtime)

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

بالأساس، يمكن النظر إلى تخصيص بيئة تشغيل اللعبة على أنها إنشاء جهاز حالة اللعبة على سلسلة الكتل، المشار إليه بجهاز تشغيل تحويل الحالة (STR) في Tabi.

المثال أعلاه هو العملية العامة لنقل الألعاب Web2. لا يزال علينا معرفة المزيد عن التفاصيل. هذه المرة نستخدم مثالًا عامًا بدلاً من مثال لعبة محدد لعرض التفاصيل المشاركة في التشغيل في طبقة التنفيذ القاهرة.

في الأساس، يمكن اعتبار تخصيص بيئة تشغيل لعبة على البلوكشين كإنشاء آلة حالة للعبة معينة، والتي تُسمى وقت التشغيل لتحويل الحالة في تابي.

يمكن دمج STR في Polymorphism VM على شكل ثنائي أو وحدة.

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

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

الهياكل التنظيمية التالية هي عناصر أساسية في هذا STR. ستوفر تابي SDK بشكل افتراضي لتسهيل عمل المطورين في إنشاء الوقت التشغيلي.

World DB

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

التالي هو مثال بسيط على قاعدة بيانات علاقية:

1. UID: يمثل مستخدمًا فريدًا، والذي يمكن أن يكون مفتاحًا عامًا أو معرفًا آخر.
2. Nonce: يستخدم لمنع هجمات الردود التكرارية.
3. حقول البيانات الإضافية: أي نوع من البيانات.

هذا هو قاعدة بيانات بسيطة مفتاح-قيمة:

وظيفة الانتقال بين الحالات

هذه وظيفة تحول الحالة بسيطة. عندما تتلقى هذه الوظيفة إدخالًا من المستخدم، فإنها تضربه بمجرد 5 وتعدل البيانات في قاعدة البيانات العلاقاتية.

متراكم الحالة العالمية

يمكننا بناء مجمع تجميع مجموعات بسيط لتمثيل حالة العالم:

A_s+1 = هاش(A_s + هاش(الاستعلام))

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

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

يتبع عملية التحديث لقاعدة بيانات القيمة المفتاحية (KVDB) نفس المبدأ.

أرقام عشوائية

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

تلخيص

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

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

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

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

تنصل:

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