كيفية تمثيل بيانات الحدث في الاتصال المبني على الحدث؟

Question

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

سيكون لدي EventManager الذي يسجل فئات المستمع لأنواع الأحداث المختلفة المحددة في تعداد ثابت مثل Event_Input_KeyPressed أو Event_Game_ActorMoved.سيقوم بتخزين الأحداث في قائمة انتظار وإرسالها إلى المستمعين المناسبين، والذين سيكون لكل منهم طريقة HandleEvent(Event e) أو شيء من هذا القبيل.

سيكون كل حدث عبارة عن كائن من النوع "حدث"، والذي يحتوي على بيانات مثل نوع الحدث الخاص به.

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

شكرًا

Answer 1

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

هذا هو MHO

Answer 2

• كما تقول أن هيكل أنواع الأحداث المختلفة مختلفة، من الأفضل إنشاء فصول ملموسة لكل حدث.لا تحتاج إلى إنشاء فئة لكل مفتاح!ولكن عموما أحداث لوحة المفاتيح
• أنت تقول يجب أن يتم إخطار الشخصيات فقط بمفاتيح محددة.لا أعرف ما هو النفقات العامة لإعلام الشخصية والسماح لهذا الكائن بتجاهل مفاتيح غير ذات صلة ولكن إذا كان هذا نمط شائعا بين الفئات على سبيل المثال، فسيكون لديك 10 فصول مختلفة قد تتفاعل مع مجموعة خاصة من المفاتيح، فستكون لطيفةلعدم تكرار الرموز وتنفيذ طبقة المرسل بين الأحداث والمستمعين.يمكن أن يكون نوع واحد من الانفصال KeyFilterDispatcher الذي يتلقى قائمة بأحداث المفاتيح والمرشحات بناء على ذلك.يمكن أن يكون نوع آخر من المرسلين Seqdispatcher يزعج المستمعين فقط إذا تم النظر في أحداث متعددة في أمر محدد! أنا أحب فكرة disuptacher القابلة للتوصيل madprorammer.أيضا قد ترغب في إنشاء أنابيب من المرسلين أيضا!