استخدام ROR وجلسة السجل النشط لتنفيذ خادم ألعاب خالي من الغش

Question

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

1. يحدث التوفيق على العملاء باستخدام واجهة برمجة تطبيقات Center Game لإنشاء قائمة من اثنين من اللاعبين (العملاء)
2. يقوم كل من العملاء بتسجيل الوصول والتوثيق مع خادم اللعبة لبدء لعبة جديدة ، ثم يقوم خادم اللعبة بمزامنة بداية اللعبة على كلا العملاء
3. يبدأ كلا اللاعبين في حل اللغز ، عندما ينتهي أي مشغل (يحل اللغز أو التوقف) ، يرسل العميل النتائج إلى الخادم.
4. عندما ينتهي كلا اللاعبين ، يقوم الخادم بتخزين النتائج في DB ويرسل النتائج إلى كلا العملاء ، ثم تنتهي جلسة اللعبة.

دون تنفيذ هذا ، يبدو أن هذا سيعمل بشكل جيد مع ROR. ومع ذلك ، فإن الغش هو مصدر قلق وفكرتي عن الحل هو استخدام مفهوم ROR لجلسة السجل النشط لمصادقة اللاعبين عند بدء اللعبة. وهذا يعني ، فقط السماح لطلبات العملاء الذين تمت مصادقتهم في الخطوة 2 أعلاه ليتم تكريمهم من قبل الخادم.

• هل ترى أي مشاكل في استخدام ROR لتنفيذ هذا النوع من خادم الألعاب القائم على الدوران؟
• كما ذكر أعلاه ، أحاول منع الغش عن طريق الحد من مصادقة اللاعب من خلال تطبيق iOS الخاص بي. ما هي بعض الطرق التي يمكنني من خلالها التأكد من أن المصادقة يطلبها تطبيق iOS الخاص بي؟
• على افتراض أنه يمكنني الحد من مصادقة المشغل بشكل فعال لتطبيق iOS الخاص بي ، هل أفتقد أي طرق واضحة لا يزال بإمكان اللاعبين إرسال الخادم البيانات الخاطئة والغش؟

شكرا جزيلا مقدما على كل مساعدتك!

Answer 1

1. لا أرى أي مشكلة في استخدام القضبان لذلك ، أو أي لغة ويب أخرى لهذه المسألة.
2. أعتقد أن طريقة المصادقة المناسبة لمتطلباتك هي OAUTH.
3. إذا كنت أنت ، فسأفكر في قصر عملائك على تسجيل دخول واحد فقط في وقت واحد.