بنية لعبة المتصفح الاجتماعي متعددة اللاعبين (اختيار الواجهة الخلفية + اختيار الواجهة الأمامية [فلاش/سيلفرلايت]) [مغلق]

Question

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

1. محرك ألعاب سريع على الخادم (على سبيل المثال.c++ ) وبعض لغات الواجهة الأمامية (php/python/Ruby) + flash

2. مكدس كامل في بيثون (باستخدام بيثون ملتوي أو غير مكدس) + فلاش

3. .NET (asp.net أو asp.net mvc) + فلاش

4. .NET + سيلفرلايت

قد يكون الأول مبالغة من وجهة نظر الإنتاجية (3 طبقات غير متجانسة)

لا.4. قد تكون جنة المبرمجين (بيئة مشتركة على جميع الطبقات)، ولكن:

• لم يتم بناء أي شيء من هذا القبيل باستخدام Silverlight على الإطلاق، وربما يكون هناك بعض العروض المختبئة بالقرب من الزاوية
• قد يكون من الصعب العثور على مصممي Silverlight
• على الرغم من انتقاد نموذج فيلم/مقطع Flash عند مقارنته ببنية SL الكاملة OO، أليس هذا ميزة عندما يتعلق الأمر بتصميم أجزاء إضافية من العالم الافتراضي بواسطة مصممين خارجيين؟يمكنهم فقط إعداد .swf على سبيل المثال.4 وجهات نظر لعنصر ما في 4 إطارات - ألن يكون الأمر أكثر صعوبة مع SL؟
• يبدو أن Silvelight يفتقر إلى بعض ميزات الألعاب (مثل اكتشاف الاصطدام)

ماذا تعتقد؟

[تحرير] ستكون اللعبة نفسها جزءًا من بوابة أكبر - وبالتالي سيكون من الجيد دمج المحرك مع بعض أطر عمل الويب.

Answer 1

الخيار 2 - استخدام Python غير المكدس - هو ما تستخدمه Eve Online.

http://support.eve-online.com/Pages/KB/Article.aspx?id=128

---

يحرر

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

ومع ذلك، خذ بعين الاعتبار ما يلي.

1. يميل المحتوى الثابت (ملفات ‎.js، و‎.css، و‎.png، وما إلى ذلك) إلى السيطرة على النطاق الترددي لشبكتك.سيتعين عليك استخدام خادم وكيل عكسي (على سبيل المثال، Squid) للتعامل مع هذا الأمر.

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

3. يبدو أن المحتوى الديناميكي الخاص بك سيكون في شكلين.

   • JSON لدعم اللعبة.

   • HTML لدعم البوابة.

   لهذا، ستكون أسعد مع محرك mod_wsgi.من المؤكد أن أباتشي يفعل هذا؛قد يعمل ngingnx وlighttpd أيضًا.

   • يجب أن تكون عناصر JSON الخاصة بك عبارة عن مجموعة واحدة من URI.REST هو نمط تصميم جيد.من خلال mod_wsgi، تتصل هذه العناصر بالخادم الموجه نحو اللعبة باستخدام لغة Python غير المكدسة - إذا لزم الأمر.تحتوي الواجهة الأمامية (Apache، على سبيل المثال) على موقع أو دليل أو مضيف افتراضي لتصفية عناوين URL هذه وتوجيهها إلى البرنامج الخفي mod_wsgi الذي يخدم اللعبة.ينظر الى ويكزيوغ لبناء هذا.

   • عناصر HTML الخاصة بك هي مجموعة أخرى من URI.من خلال mod_wsgi، تتصل هذه بخادم Django الذي يقوم بتشغيل Python التقليدي.تحتوي الواجهة الأمامية (Apache، على سبيل المثال) على موقع أو دليل أو مضيف افتراضي لتصفية عناوين URL هذه وتوجيهها إلى البرنامج الخفي mod_wsgi.

Answer 2

لقد أمضيت عامًا في العمل على لعبة متعددة اللاعبين عبر الإنترنت باستخدام Silverlight للواجهة الأمامية وPython للواجهة الخلفية (لقد استخدمت IronPython بالفعل في Silverlight لتبسيط عملية التطوير).

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

إذا اضطررت إلى القيام بذلك مرة أخرى، فأعتقد أنني سأحتفظ بـ Python للخادم، لأنها تقنية الخادم التي أتقنها كثيرًا، ولكن أعتقد أنني سأستخدم C# على الواجهة الأمامية وأستخدم JSON لتمرير البيانات.

أفضل نصيحة يمكنني تقديمها لك هي:

1. استفد من المكتبات والأكواد الموجودة قدر الإمكان
2. لا تفكر في الأداء قبل الأوان

الجزء الأصعب هو إنهاء اللعبة، واستخدام التكنولوجيا التي تعرفها جيدًا، وتحسين وقتك، وليس الكود.آمل أن تتمكن من فعل ما لم أستطع - إنهاء اللعبة اللعينة :)

يحرر

بخصوص سبب استخدامي لـ C# إذا اضطررت إلى القيام بذلك مرة أخرى:

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

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

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

بعد فوات الأوان، لم يكن من المفترض أن أتشتت بسبب كل آثار الأرانب تلك.

Answer 3

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

http://www.chesspark.com/

بالإضافة إلى أن محرك اللعبة ليس من الضروري أن يكون في c/c++.يعتمد على مدى تعقيد اللعبة ونوعها.ولكن هناك أيضًا مكتبة pygame وهي جيدة جدًا.

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