كيف يجب أن أقوم بتصنيع خادم DB و API الخاص بي للحصول على لعبة iPhone متعددة اللاعبين القائمة على الدوران؟ (التفكير في Nodejs ، Mongo ، الأريكة ، إلخ)

Question

أنا أعمل على لعبة لوحة قائمة على iPhone و Android في نهاية المطاف. أنا أستخدم AppCelerator Titanium لتطويره. يشبه تصميمي متعدد اللاعبين الكلمات مع الأصدقاء. يتناوب المستخدمون عند استعدادهم ، ثم يتم تحديث لوحة لعبة الخصم وفقًا لذلك.

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

لقد فعلت واجهات برمجة التطبيقات في الماضي لمنصات الهاتف المحمول وللقيام بذلك ، استخدمت PHP مع MySQL وأرسلت JSON ذهابًا وإيابًا بين خادم API والجهاز المحمول. يعمل فقط Dandy للمستخدمين المتزامنين المنخفضة ، والتطبيقات غير الطائفة عمومًا. إليكم على أمل أن يصبح هذا الضخم ؛)

حتى الآن ، بدلاً من خادم HTTPD العام وما شابه ، بدأت في التفكير في مآخذ مستمر وإذا كان مطلوبًا أم لا في لعبتي الجديدة. أعتقد أيضًا أنه قد يكون من الذكاء التخلي عن مكدس المصباح الكبير ، وربما قابلية التوسع وربما سهولة التطوير ، لإثارة المزيد نحو تدفق البيانات لشيء مثل Mongo/Couch -> node.js -> iPhone. سأكون صادقًا ، سيكون أول غزو لي في DB و Node.js غير SQL.

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

Answer 1

بادئ ذي بدء ، يعد Nodejs رائعًا لكتابة وكلاء TCP العكسي لقواعد بيانات NOSQL. يمكنك السماح لجميع الأوامر القياسية بالمرور ولكن تغيير/تمديد واجهات برمجة التطبيقات الخاصة بهم بسحرك الخاص ، على سبيل المثال ، جعل MongoDB يتحدث HTTP أو CouchDB يتحدث بروتوكول ثنائي على مآخذ.

عندما يتعلق الأمر باختيار حل NOSQL لتخزين قطع ألعاب اللوح ومراقبة تحركات اللاعب ، أعتقد أن Redis و CouchDB هما أفضل المرشحين.

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

   curl "$HOST/dbname/_changes?filter=app/gameboard&feed=continuous&gameid=38934&heartbeat=1000

   
   سيتلقى كل عميل كائن JSON لكل سطر في الاستجابة في أي وقت يتم فيه تغيير وثيقة ذات صلة. (وخط جديد فارغ كل 1000ms كنوع من الاحتفاظ.)
   
   
2. ريديس. يستخدم بروتوكولًا بسيطًا يستند إلى الخط (مثل Memcached ++) للتحدث عبر مقبس ويسمح لك بتخزين القوائم ، والمجموعات ، والتجزئة مع التعسفي-حتى الثنائيات-. إنه سريع جدًا لأن كل شيء يحدث في الذاكرة ولكن يتم استمراره على القرص بشكل غير متزامن. ولكن الأهم من ذلك كله أنه يجب عليك تقييمه لأنه لديه بالفعل PubSub الإخطارات المخبوزة. لاحظ أنه سيتعين عليك نشر الإخطارات بشكل صريح عبر القناة التي يشاركها اللاعبون لأن Redis لن تنشر تلقائيًا عند تغيير المفتاح/القيمة.

نظرًا لأن MongoDB لا يتمتع بآلية لمراقبة التغييرات باعتبارها-فهي تعمل أو القيام بـ PubSub ، فأنا لا أعتبرها خيارًا جيدًا ، على الرغم من أن الجهد الإضافي الذي يمكنك جعله يعمل.

لذا ، في الختام ، قد تكون قادرًا على استبدال "The Big Lamp Stack" بـ CouchDB وحده ، أو redis بمفرده ، أو إما تم وضعها خلف تطبيق عقدة لتصفية/توسيع واجهات برمجة التطبيقات التي يقدمونها بالفعل في شيء يناسب لعبتك.

حظا سعيدا!

Answer 2

لقد بدأت للتو في تعلم Mongo ، وليس من الصعب التعلم. أشياء مثل الفهارس والشرح هناك وتعمل كما هي. عندما يتعلق الأمر بالهندسة المعمارية ، فأنت تريد أن تفكر في عكس SQL ؛ بدلاً من الحاجة إلى سبب وجيه لإلغاء الإطالة ، تحتاج إلى التوصل إلى سبب وجيه للتطبيع. سيقول الرجال في 10Gen (الذين يصنعون Mongo) إن التفكير في التسلسل الهرمي هو طريقة أكثر طبيعية للتفكير في الأشياء ، والتي أوافق عليها (مبدئيًا). يشعر الباحثون نوعًا ما من SQL-ish أيضًا ، على الرغم من أنك ستظل تستخدم REDUCE MAP لاستفسارات التجميع.

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

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