تحرك طالبة قطعة على لوحة ورقية إلى محطة «الحديقة»، بينما تعرض الشاشة القطعة في محطة «الجسر». هل نعيد الحركة، أم نتراجع عن الدور، أم نثق بالشاشة؟ هذه لحظة مناسبة لأحد مشاريع تخرج البرمجة: لعبة طاولة بسيطة لها نسخة رقمية تتبادل معها أحداث اللعب. يبدأ المشروع بإدخال يدوي من هاتف الميسّر، ويجعل الاختلاف قابلاً للفهم والإصلاح. لا تحتاج الفكرة إلى كاميرا تتعرف على القطع كي تثبت الجزء البرمجي المهم.

ارسم لعبة يمكن وصف حالتها كاملة

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

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

نسخة أولى من جولة واحدة مكتملة

يكفي في البداية إنشاء جلسة محلية وإضافة لاعبين وتنفيذ حركة وجمع بطاقة وإنهاء دور وحفظ نقطة استعادة. لوحة HTML أو SVG تعرض الحالة، والنسخة الورقية مطبوعة من التصميم نفسه. اجعل «طلب الحركة» منفصلاً عن «حدث مقبول»: قد يرسل الهاتف طلباً أثناء دور لاعب آخر، فيرفضه المحرك دون إضافة حركة إلى السجل.

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

ظرف الرسالة قبل رسم المؤثرات

يمكن بناء الواجهة بـTypeScript والخادم بـNode.js مع SQLite لتخزين الأحداث. تنقل WebSocket الطلبات والتأكيدات في الاتجاهين، وفق ما تشرحه وثائق MDN. الاتصال لا يغني عن تأكيد الحفظ بعد إعادة الاتصال. ضع حداً لحجم الرسالة وعدد الطلبات المعلقة، لأن واجهة WebSocket التقليدية لا تقدم تحكماً تلقائياً في ضغط الاستقبال.

{
  "protocolVersion": 1,
  "sessionId": "demo-game-7",
  "commandId": "phone-a-19",
  "expectedVersion": 8,
  "type": "MOVE",
  "playerId": "p1",
  "steps": 2
}

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

مثال: رسالة واحدة تصل مرتين

لنفترض أن القطعة في الخانة الثالثة وإصدار الحالة 8. يصل الطلب السابق، فيثبت الخادم حدثاً رقمه 9 ينقلها إلى الخامسة، ثم يعيد التأكيد. ينقطع الاتصال قبل وصول التأكيد للهاتف فيكرر الطلب بالمعرّف نفسه. يبحث الخادم عن commandId ضمن الجلسة ويعيد التأكيد المحفوظ، دون نقل القطعة إلى السابعة. يجب أن يكون حفظ الحدث ومعرف الطلب وتحديث الإصدار ضمن عملية ذرية واحدة.

قرارات قبول افتراضية
الطلبالقرارسبب القرار
معرف جديد وإصدار 8 والدور صحيحقبولإنشاء الحدث 9
المعرف نفسه والمحتوى نفسهإعادة التأكيدمنع التكرار
المعرف نفسه ومحتوى مختلفرفضتعارض هوية الطلب
معرف جديد وإصدار قديمطلب مزامنةالعميل يبني قراره على حالة قديمة

استعد اللعبة من نقطة معلومة

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

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

اختبر الاتفاق قبل سرعة اللعب

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

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

ما الذي يستحق الإضافة لاحقاً؟

ثلاث توسعات مناسبة هي قارئ QR لتأكيد محطة القطعة دون استنتاج حركتها، ووضع متفرج يعيد جولة سابقة، ومحرر قواعد محدود يغيّر طول المسار وعدد البطاقات. سلّم ملفات الطباعة وعقد الرسائل ومحرك القواعد وسجلاً نموذجياً ونقاط حفظ وتقرير الفشل والاستعادة. اربط الحالات في سجل اختبارات واضح، وحدد هذه المخرجات عند تخطيط مشروع التخرج.

المصادر

مراجعة المصادر: .

اختبار المثال وحدوده

تصميم تعليمي مقترح؛ القصص والبيانات والحسابات افتراضية، ولم يُنفذ النموذج أو بروتوكول اختباره ميدانياً. تُسجّل النتائج الفعلية عند التنفيذ ولا تُستنتج من المثال.

مقالات ذات صلة

الخدمة المرتبطة: تطوير المشاريع البرمجية الجامعية.

أرسل متطلبات مشروعك