LittleBee

ليتل بي

يقوم إصدار Little Bee المتقدم حاليًا باستخراج منطق مزامنة الإطار في SDK، يرجى الاطلاع على المشروع https://github.com/dudu502/littlebee_libs هذا مثال على لعبة مزامنة الإطار، حيث يقوم بمزامنة مئات الكائنات وآلاف الحالات في اللعبة خلفية اللعبة هي لعبة إطلاق نار في ظل نظام كوكبي، وفيما يلي رابط الفيديو.

[شاهد تشغيل الفيديو (يوتيوب)]

[شاهد إعادة الفيديو (يوتيوب)]

[شاهد تشغيل الفيديو (بيليبيلي)]

[شاهد إعادة تشغيل الفيديو (بيليبيلي)]

galaxy.alliance.playing-1280x384.mp4

galaxy.alliance.replaying-604x360.mp4

مزامنة الإطار ومزامنة الحالة

• تعد مزامنة الإطار ومزامنة الحالة من الأساليب التي تسمح للعديد من العملاء بالتصرف بشكل متسق في نفس الوقت. بالطبع، المظهر المتسق ليس كافيًا، أو أنه ليس دقيقًا بدرجة كافية في هذا الوقت، ومن الضروري أيضًا الحفاظ على اتساق البيانات المستوى، استخدم التغييرات في البيانات بشكل متسق لدفع التغييرات في الأداء الخارجي. وهذا هو نفسه سواء كان مزامنة الإطار أو مزامنة الحالة.
• فيما يتعلق بموضوع العرض المعتمد على البيانات، إليك مثال سلبي، تذكرت أنني سمعت قبل بضع سنوات أحد الزملاء يتحدث عن تجربته في تطوير لعبة Tetris، حيث شارك في اكتشاف تصادم الصور بين الكتل أثناء عملية التطوير الخبرة، وإظهار صعوبة تطوير هذه اللعبة، وكذلك ذكائي.
• لا يوجد تفوق أو دونية بين مزامنة الإطار ومزامنة الحالة، وكلاهما حلول مزامنة جيدة، ولكن لهما أيضًا قيودهما الخاصة. يتم استخدام وضع مزامنة الإطار في ألعاب RTS القديمة مثل StarCraft وWarcraft. تستخدم ألعاب RPG مثل Legend وMiracle وضع مزامنة الحالة، وتعتبر هذه التحف كلها نماذج ناجحة. لا معنى لمناقشة الطريقة التي تتفوق على الأخرى. يعتمد الموقف المحدد على سيناريو الطلب.

المزايا والعيوب

• المزايا والعيوب المذكورة أدناه عامة:

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

الصعوبات التي يجب التغلب عليها في مزامنة الإطار

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

مزيج من تزامن الإطار وECS

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

وصف ECS

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

• يمثل الحرف E في ECS الكيان، ولكنه ليس ضروريًا لأن E يمثل كائنًا فريدًا ويمكن تنفيذه باستخدام int.
• يشير C إلى المكون. يختلف هذا المكون عن المكون الموجود في Unity، وهو نوع لا يحتوي على طرق محددة، وهو يمثل الخصائص بشكل أساسي. أو للبيانات الخاصة به أعتقد أنه يمكن التعامل معها.
• يشير S إلى النظام، حيث توجد طرق فقط لتعديل خصائص المكون.
• بالطبع، يمكنك أيضًا إضافة R. R يمثل Renderer الذي يقرأ فقط المكون محل الاهتمام ويكون مسؤولاً عن عرض السلوك الصحيح. تعمل الأجزاء الثلاثة من ECS في سلاسل، ويتم تشغيل الجزء R في الخيط الرئيسي، وبالتالي زيادة الأداء إلى الحد الأقصى.

آلية التشغيل

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

اتصالات الشبكة

يوصى هنا باستخدام RevenantX/LiteNetLib. هذه المكتبة قوية جدًا وسهلة الاستخدام، وتوفر نقل UDP موثوقًا به، وهو ما أريده تمامًا. هناك العديد من بروتوكولات البيانات للاختيار من بينها للاتصال بالشبكة. أنا أستخدم بروتوكول دفق ثنائي عصامي. الوظائف الرئيسية هي التسلسل وإلغاء التسلسل. مثل هيكل PtRoom هذا:

 //Template auto generator:[AutoGenPt] v1.0
//Creation time:2021/1/28 16:43:48
using System ;
using System . Collections ;
using System . Collections . Generic ;
namespace Net . Pt
{
public class PtRoom
{
    public byte __tag__ { get ; private set ; }

    public uint RoomId { get ; private set ; }
    public byte Status { get ; private set ; }
    public uint MapId { get ; private set ; }
    public string RoomOwnerUserId { get ; private set ; }
    public byte MaxPlayerCount { get ; private set ; }
    public List < PtRoomPlayer > Players { get ; private set ; }

    public PtRoom SetRoomId ( uint value ) { RoomId = value ; __tag__ |= 1 ; return this ; }
    public PtRoom SetStatus ( byte value ) { Status = value ; __tag__ |= 2 ; return this ; }
    public PtRoom SetMapId ( uint value ) { MapId = value ; __tag__ |= 4 ; return this ; }
    public PtRoom SetRoomOwnerUserId ( string value ) { RoomOwnerUserId = value ; __tag__ |= 8 ; return this ; }
    public PtRoom SetMaxPlayerCount ( byte value ) { MaxPlayerCount = value ; __tag__ |= 16 ; return this ; }
    public PtRoom SetPlayers ( List < PtRoomPlayer > value ) { Players = value ; __tag__ |= 32 ; return this ; }

    public bool HasRoomId ( ) { return ( __tag__ & 1 ) == 1 ; }
    public bool HasStatus ( ) { return ( __tag__ & 2 ) == 2 ; }
    public bool HasMapId ( ) { return ( __tag__ & 4 ) == 4 ; }
    public bool HasRoomOwnerUserId ( ) { return ( __tag__ & 8 ) == 8 ; }
    public bool HasMaxPlayerCount ( ) { return ( __tag__ & 16 ) == 16 ; }
    public bool HasPlayers ( ) { return ( __tag__ & 32 ) == 32 ; }

    public static byte [ ] Write ( PtRoom data )
    {
        using ( ByteBuffer buffer = new ByteBuffer ( ) )
        {
            buffer . WriteByte ( data . __tag__ ) ;
            if ( data . HasRoomId ( ) ) buffer . WriteUInt32 ( data . RoomId ) ;
            if ( data . HasStatus ( ) ) buffer . WriteByte ( data . Status ) ;
            if ( data . HasMapId ( ) ) buffer . WriteUInt32 ( data . MapId ) ;
            if ( data . HasRoomOwnerUserId ( ) ) buffer . WriteString ( data . RoomOwnerUserId ) ;
            if ( data . HasMaxPlayerCount ( ) ) buffer . WriteByte ( data . MaxPlayerCount ) ;
            if ( data . HasPlayers ( ) ) buffer . WriteCollection ( data . Players , ( element ) => PtRoomPlayer . Write ( element ) ) ;

            return buffer . Getbuffer ( ) ;
        }
    }

    public static PtRoom Read ( byte [ ] bytes )
    {
        using ( ByteBuffer buffer = new ByteBuffer ( bytes ) )
        {
            PtRoom data = new PtRoom ( ) ;
            data . __tag__ = buffer . ReadByte ( ) ;
            if ( data . HasRoomId ( ) ) data . RoomId = buffer . ReadUInt32 ( ) ;
            if ( data . HasStatus ( ) ) data . Status = buffer . ReadByte ( ) ;
            if ( data . HasMapId ( ) ) data . MapId = buffer . ReadUInt32 ( ) ;
            if ( data . HasRoomOwnerUserId ( ) ) data . RoomOwnerUserId = buffer . ReadString ( ) ;
            if ( data . HasMaxPlayerCount ( ) ) data . MaxPlayerCount = buffer . ReadByte ( ) ;
            if ( data . HasPlayers ( ) ) data . Players = buffer . ReadCollection ( ( rBytes ) => PtRoomPlayer . Read ( rBytes ) ) ;

            return data ;
        }       
    }
}
} 

عميل

com.littleBee

هذا مشروع وحدة يعتمد على مزامنة الإطار

شائع

بعض الأدوات: أداة إنشاء هيكل Pt، أداة إنشاء Excel2Json، مشروع المكتبة العامة، مشروع مكتبة ServerDll

تصميم

وثائق التصميم: وثائق التصميم التفصيلية، وثائق تصميم النموذج الأولي، جداول التكوين.

تصف الأشكال الثلاثة التالية استخدام محاكي تزامن الإطار في ثلاثة سيناريوهات مختلفة.

يوضح الشكل أدناه السلوك العام للعميل والخادم في نفس الوقت، ويتوافق منطق التشغيل أيضًا مع نفس السلوك.

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

تصف الصورة الأخيرة كل إطار منطقي للتشغيل.

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

الخادم

هذا مشروع مجموعة خدمات، بما في ذلك WebServer وGateServer وRoomServer وما إلى ذلك.

تاريخ النجوم