كيفية إنشاء بيئة أفضل لمطوري الألعاب التقليدية من الناحية الفنية

المؤلف: لو بنبين ، CTO من سلسلة Tabi

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

قابلية لعب السلسلة ليست عالية بشكل عام ، والمرح غير كافٍ ، وهو أكثر ميلًا إلى التكهنات المالية.جوهر

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

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

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

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

الأسباب الفنية التي تعيق مطوري اللعبة التقليدية يدخلون بيئة Web3

في المقالة السابقة ، ذكرنا لفترة وجيزة أن التكنولوجيا المرتفعة وتكاليف التعلم المرتفعة هي العامل الأساسي الذي يعيق ممارسي اللعبة التقليديين الذين يدخلون بيئة Web3.

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

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

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

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

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

لا يوجد رد فعل وآليات أخرى ، ولا يدعمان الفرات المتعددة وغير المتزامنة.نظرًا لأن الصلابة مصممة لتطوير عقود Ethereum الذكية ، فإن بيئة التنفيذ الخاصة بها تختلف اختلافًا كبيرًا عن بيئة وقت التشغيل التقليدية.إن تشغيل EVM هو المعاملات.هذا يعني أن دعوة الدالة في الصلابة تبدأ حتى نهاية النهاية.
لا توجد قدرة على اقتباس البيانات الخارجية.على الرغم من وجود آلة نبوية مثل ChainLink ، سواء كانت من منظور التكامل أو استدعاء البيانات ، إلا أن سهولة الاستخدام وطلب HTTPS المباشر يمكن أن تحصل على مكالمات البيانات.
قيود التوسع والأداء.游戏逻辑必须被简化或分解成多个简单的交易，以避免单一交易的gas费变得过高或超出最大限制，这限制了复杂交互和功能的实现。

3. الحد من تخزين البيانات والاتصال

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

يمكننا أن نرى من أدوات مثل Etherscan وأدوات أخرى ، أي نوع من المعلومات مثل الرمز المميز وأرصدةها ، وما إلى ذلك. السلسلة.

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

我们来对比一下，大多数游戏自身的数据库形态与区块链中数据存储方式的差异，两者的不同是显而易见的。大多数游戏的数据结构完全由自己定制，有良好的表达和索引能力，不需要依赖任何第三方服务。

4. صعوبة الاندماج مع أصول اللعبة الحالية

عادة ما لا يتم إنشاء أصول اللعبة الحالية (مثل الدعائم والشخصيات) وإدارتها على blockchain.将这些资产迁移到区块链上，通常要将通用但长尾的数据类型转换成标准的NFT或Token，这涉及到复杂的迁移和集成工作，会影响到现有的游戏经济系统。

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

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

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

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

6. مشكلات الانقسام البيئي وتجربة المستخدم

تختلف السلاسل العامة المختلفة و VM ، ولغة العقد الذكي ، والهندسة المعمارية ، وهيكل البيانات ، وما إلى ذلك.في Web2 ، سيختار مطورو الألعاب محرك -Plat -platform مثل الوحدة ، والذي يمكنه تحقيق مجموعة من الرموز التي تم تكييفها قليلاً وتشغيلها في بيئات مختلفة مثل iPhone و Android ، نهاية سطح المكتب. .

في Web3 ، هذا هو الآمال الباهظة في الأساس.

على مستوى تجربة المستخدم ، كان blockchain مترابطًا ومجمعه.

بعد إدراج الحجج الستة المذكورة أعلاه ، فإننا نلخص: يواجه مطورو Web2 عتبة تكيف ضخمة. لا يعرف ما إذا كان يمكن أن ينجح.

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

هناك أيضًا نفس الطبيعة لجانب المستخدم.

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

بالإضافة إلى ذلك ، تتمتع Tabi Chain أيضًا بخصائص إجماع وحدات السلامة.

全能执行层：按照开发者需求来选择执行环境

我们来回忆一下，区块链的本质是什么。有人可能会说是去中心化的不可篡改的账本。ولكن إذا كان الأمر أقرب إلى جوهر التكنولوجيا ، فيجب أن يقال إن مزامنة الحالة الدائمة التي تم التحقق منها لآلة الحالة في شبكة موزعة تتم مزامنتها.

也即，区块链实际在维护一个全网公认的状态机和其运转的状态：

每一次输入都是确定的，被记录在每个区块中；
状态转换函数是确定的，具体表现为区块链客户端中的VM或运行时；
状态的输出也是确定的，也被记录在每个区块中；

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

في Tabi ، يمكن لكل لعبة أو DAPP بناء خدمتها المستقلة الخاصة بها.جميع الخدمات تقدم كتلها الخاصة إلى نظام الإجماع في السلسلة ؛

يخرجيمكن اعتبار جوهر طبقة التنفيذ الخاصة بكل Tabi بمثابة VM مع تعدد الأشكال ، لذلك يطلق عليه تعدد الأشكال VM.

بالنسبة إلى blockchain vm الحالي ، يحتاج تعدد الأشكال VM إلى تضمين VM في بيئة التشغيل الخاصة به وتوفير طريقة استدعاء الواجهة المقابلة.يحتوي مفهوم “يتضمن” على تطبيقين محددين هنا:

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

لذلك ، يمكن أيضًا تمديد علاقة التعيين إلى VMs الأخرى.

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

ستستخدم الخدمات الرئيسية لسلسلة Tabi هذا الشكل من مشاركة الدولة العالمية.لذلك ، طالما أن هناك تكيفًا مع VM المقابل ، يمكن لـ DAPP تطويره استنادًا إلى VM أن يتم نشره مباشرة على الخدمة الرئيسية بدلاً من خدمة أخرى.

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

ولكن بغض النظر عن الشكل ، يجب التحقق منه من قبل العقد المشرف ، أي تعدد الأشكال VM يحتوي على جميع أساليب التنفيذ VM أو وقت التشغيل.

حالة زرع لعبة Web2

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

على افتراض أن Minecraft تريد الزرع إلى Tabi ، فإن العملية العامة هي:

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

حتى الآن انتهت جميع العمليات.

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

تفاصيل وظيفة تحويل حالة str str

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

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

يمكن لـ STR الاندماج في تعدد الأشكال VM بواسطة وحدة ثنائية أو وحدة.

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

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

الهيكل التنظيمي التالي هو محتوى أساسي في STR.سيقدم Tabi افتراضيًا لـ SDK لتسهيل المطورين لإجراء هذا التشغيل.

Worldd DB

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

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

UID: يمثل مستخدمًا فريدًا ، يمكن أن يكون مفتاحًا عامًا أو معرفات أخرى.
NONCE: تستخدم لمنع تجاوز الهجمات.
حقل بيانات إضافي: أي نوع من البيانات.

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

وظيفة تحويل الحالة

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

تراكم الدولة العالمية

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

A_S + 1 = التجزئة (A_S + التجزئة (استعلام))

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

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

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

رقم عشوائي

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

لخص

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

بموجب نظام Web3 الأصلي ، لا تحتوي الأعمال التي تم تطويرها على ألعاب Web2 بشكل أساسي ، وهي لغة وبيئة غريبة للغاية التفاهم.

في Tabi ، يستخدم المطورون اللغة الأصلية ومنصة التطوير والمحرك.تحسين هذه الكفاءة وانخفاض في التعقيد هي مستويات الفهرس.

نتطلع إلى تفردها للتبني الجماعي للعبة Web3 ، وجذب مطوري الألعاب الممتازين في Web2 ، وجلب Web3 مع قيمة الترفيه الحقيقية وقابلية اللعب.