ما هو أفضل العمارة لعدة خوادم اللعبة التي تحتاج إلى التحدث مع بعضهم البعض ؟
https://stackoverflow.com/questions/608674
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
اللعبة هو الرسومات المنخفضة (SVG) لعبة استراتيجية.كل خادم يمثل اللعبة المجال مع اللاعبين.جميع خوادم ينبغي أن تكون قادرة على التحدث مع بعضهم البعض ، كما يمكن للاعبين التحرك (في اللعبة) من المجال إلى المجال/إرسال "الدبلوماسية الرسل" وما إلى ذلك..
اخترنا هذه الفكرة لأنها تمكننا من توسيع خريطة العالم إلى ما لا نهاية ، فإنه يتيح الثانية الأطراف إلى ربط خوادم اللعبة لنا تلك تكبير العالم حتى أكثر من ذلك.إذا كان ملقم واحد (و النسخ الاحتياطي) فشل اللعبة سوف لا تزال مستمرة إلى تشغيل (الحقيقي توزيع البيئة).
نحن فقط في البداية.ما هي منصات هناك والتي يجب أن ننظر ، من شأنها أن تساعدنا على تطوير مثل هذا العالم ؟
المحلول
وXMPP، المعروفة سابقا باسم جابر، قد يكون مكانا جيدا للبدء.
نصائح أخرى
الكثير من هذا يعتمد على مقدار البيانات التي تريد مشاركتها بين الخوادم.تريد كل خادم التعامل مع المجال نفسه ، ولكن ماذا عن حساب قاعدة البيانات حول من يملك اي معلومة تضاريس المجالات, هذه البيانات ستكون المركزية و/أو توزيع و كيف يمكن الحفاظ عليها متزامنة.وبغض النظر عن طريقة عمل اللعبة, هناك مجموعة أخرى من البيانات الوصفية التي تحتاج إلى خوادم التواصل حول.أما بالنسبة بيانات اللعبة, وربما كنت سوف تمر حول الأحداث كائنات بيانات ومعلومات حول ملكية البيانات و التحكم.علاوة على ذلك يجب أن يكون هناك في اللعبة على مدار الساعة الفوقية للحفاظ على نطاقات زمنية متزامنة.
ربما أود أن استخدام نظام متزامن طوابير مع أولويات مختلفة عن الفوقية ، طلبات و الرد على الرسائل.مثل بروتوكول XMPP على رأس تبادل الرسائل يمكن أن تجلب لك وجود معلومات المصادقة والتشفير وغيرها من المزايا.ولكن في البداية ، بروتوكول تسليم نفسها ليست مهمة بقدر هيكل الرسائل و تبادل البيانات.في جوهر التسليم البروتوكولات هي قابلة للتبديل.
على سبيل المثال: لاعب واحد يرسل مباراة الوحدة X من المجال إلى المجال B.المجال الخادم يرسل رسالة مع الحدث المجال B server.أثناء معالجة طابور من الأحداث ، ب يتلقى الرسالة و يرسل الطلبات إلى قائمة انتظار الطلب على البيانات عن الوحدة X إذن التحكم/تعديل البيانات من وحدة X.طلب الانتظار له أولوية أعلى و سيتم التعامل معها من قبل الأحداث الأخرى في المجال A.المجال يرسل البيانات المطلوبة والتحكم المميز المجال B استجابة انتظار ذات أولوية قصوى.وفي الوقت نفسه المجال B server معالجتها بالفعل 3 أحداث أخرى لا تنتظر في الدورة.
- ملاحظة: ينبغي عفا عليها الزمن ، إصدار أو إزالة البيانات عن الوحدة X في هذه المرحلة.إذا طلب البيانات من المجال ج ، ينبغي إحالة هذا الطلب إلى الخادم ب من الآن فصاعدا.
- ملاحظة: المثال أعلاه يمكن أن يكون الأمثل لإرسال البيانات عن الوحدة X مباشرة مع الحدث المطابق ، ولكن أردت مثال بسيط لتوضيح.
الشيء المهم هو أنه سيكون لديك تصميم تغليف البيانات بروتوكول ربما بعض مخطط XML.بروتوكول التعامل مع الحدث.قائمة الأحداث, مسموح الردود, رسائل خطأ الانتعاش.هذه كلها لعبة معينة.
وكنت تنظر بجدية إرلانج وكاوتش دي بي، أو تنفيذه تحت جوجل إلى AppEngine.
إذا انها وزعت حقا ثم انا التخمين انه لا توجد خطط لخادم مركزي. وهذا يعني أن ما كنت تبحث حقا لهو آلية الاتصالات بين مختلف الخوادم. REST و XML-RPC على حد سواء آليات بسيطة حقا لملقمات لتكون قادرة على التحدث مع بعضهم البعض على التواصل أن المستخدم يحتاج إلى الانتقال من واحدة إلى أخرى.
ويمكنك أيضا استخدام شيء من هذا القبيل XMPP كما قال دانيال لكن هذا يعني أنك قد حصلت على ربط مجموعة أخرى من برنامج الخادم في مزيج جنبا إلى جنب مع كل ما كنت قد حصلت على تشغيل اللعبة نفسها (التي انا التخمين من وصفك هو ربما الخادم تطبيق ويب من نوع ما).
من وجهة نظر التنمية، أي لغة / الإطار التي هي قوية لتطوير تطبيقات الويب يجب أن تعمل. أن روبي على القضبان، بيثون على جانغو، أطر عديدة بالإضافة إلى جافا، أو حتى كعكة ث / PHP (إك) العمل من أجل تطوير العمل.
ولقد فكرت في شيء من هذا القبيل في الماضي ولكن قضايا فحص ملقمات مختلفة (أي كيف يمكن التعامل مع الخادم الذي هو إما كسر أو خبيثة، ويتيح لاعب في وقت واحد يتحرك نفس قطعة على اثنين أو ثلاثة خوادم أخرى )، والتعامل مع تسربوا خوادم (ما يحدث للاعبين الذين الماضي كانت موجودة هناك)، وما إلى ذلك بدا صعبا للغاية.
وأعتقد أن السؤال الأول للإجابة هو ما إذا كانت اللعبة في الوقت الحقيقي أو الحدث يحركها، وما إذا كان العميل هو المتصفح أم لا. هذا يبدو وكأنه أنها تستند إلى الحدث ولكن تذكر أن الخادم لا يمكن دفع النتائج إلى العميل HTML عادي على نحو فعال، إلا أن برنامج Java، جزءا لا يتجزأ من فيلم فلاش، وما إذا كان لديك عميل مخصصة ثم ليس هناك حاجة لاستخدام HTTP نظام على غرار على الخادم، وهذا يعني server-> الخادم وserver- يمكن القيام به> اتصال العميل في نفس الطريق.
يجب أن يكون لديك نظرة للأوراق "إدارة المصالح" عن الألعاب P2P، سوف تواجه نهج مثيرة للاهتمام حقا. جوجل Schoolar نقدم لكم أوراق جيدة حقا.
ولكن حذر من أن يكون، وتطوير التطبيقات الموزعة هو أكثر من ذلك بكثير تعقيدا بكثير مما كان خادم النهج واحدة بسيطة.
