ألعاب سحابية مفتوحة المصدر على WebRTC: p2p ، متعددة اللاعبين ، صفر زمن انتقال

البرمجيات كخدمة ، والبنية التحتية كخدمة ، والنظام الأساسي كخدمة ، ومنصة الاتصالات كخدمة ، ومؤتمرات الفيديو كخدمة ، وماذا عن الألعاب السحابية كخدمة؟ كانت هناك بالفعل عدة محاولات لإنشاء ألعاب سحابية (Cloud Gaming) ، مثل Stadia ، التي أطلقتها Google مؤخرًا. ستاديا ليس جديدًا على WebRTC، ولكن هل يمكن للآخرين استخدام WebRTC بنفس الطريقة؟

قرر ثان نجوين اختبار هذا الاحتمال في مشروعه مفتوح المصدر CloudRetro. يعتمد CloudRetro على Pion ، شعبي مكتبة WebRTC على أساس Go (شكرًا شونو من فريق تطوير Pion لمساعدتهم في هذه المقالة). في هذه المقالة ، يعطي ثانه لمحة عامة عن بنية مشروعه ، ويتحدث أيضًا عن ما تعلمه مفيدًا والتحديات التي واجهها أثناء العمل.

دخول

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

TLDR: نسخة شريحة قصيرة مع الإبرازات

لماذا الألعاب السحابية هي المستقبل

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

يتيح لك Google Stadia اللعب بشكل أساسي ألعاب AAA (مثل الألعاب عالية الجودة) على واجهة مثل YouTube. يمكن تطبيق نفس المنهجية على التطبيقات الثقيلة الأخرى غير المتصلة بالإنترنت مثل نظام التشغيل أو تصميم الرسوم ثنائية الأبعاد / ثلاثية الأبعاد وما إلى ذلك. حتى نتمكن من تشغيلها بثبات على أجهزة منخفضة المواصفات عبر الأنظمة الأساسية.

مستقبل هذه التقنية: تخيل لو كان نظام التشغيل Microsoft Windows 10 يعمل في متصفح Chrome؟

تعتبر الألعاب السحابية صعبة من الناحية الفنية

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

قالب لعبة السحابة العامة

مشروع مفتوح المصدر CloudRetro

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

مشروع CloudRetro.io هي خدمة ألعاب سحابية مفتوحة المصدر للألعاب القديمة. الهدف من المشروع هو تقديم تجربة الألعاب الأكثر راحة للألعاب التقليدية القديمة وإضافة لاعبين متعددين.
يمكنك معرفة المزيد عن المشروع هنا: https://github.com/giongto35/cloud-game.

وظائف CloudRetro

يستخدم CloudRetro الألعاب القديمة لعرض قوة الألعاب السحابية. يتيح لك ذلك الحصول على الكثير من تجارب الألعاب الفريدة.

• إمكانية نقل اللعبة
  • التشغيل الفوري عند فتح الصفحة ؛ لا يلزم التنزيل والتثبيت
  • يعمل على مستعرض الهاتف المحمول لذلك لا يلزم تشغيل أي برنامج

• يمكن مشاركة جلسات الألعاب عبر أجهزة متعددة وتخزينها في السحابة لتسجيل الدخول التالي
• يمكن بث اللعبة ، أو يمكنك لعبها مع عدة مستخدمين في وقت واحد:
  • Crowdplay مثل TwitchPlayPokemon ، فقط أكثر عبر الأنظمة الأساسية والمزيد في الوقت الفعلي
  • ألعاب غير متصلة بالإنترنت. يمكن للعديد من المستخدمين اللعب بدون إعداد الشبكة. يمكن الآن لعب Samurai Shodown مع لاعبين عبر شبكة CloudRetro

  
  نسخة تجريبية من لعبة متعددة اللاعبين عبر الإنترنت على أجهزة مختلفة

  بنية التحتية

  المتطلبات والمكدس التكنولوجي

  فيما يلي قائمة بالمتطلبات التي حددتها قبل البدء في المشروع.

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

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

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

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

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

  5. فصل واضح بين واجهة اللعبة والخدمة
  أرى خدمة الألعاب السحابية كمنصة. يجب أن يكون كل شخص قادرًا على توصيل أي شيء بالمنصة. لقد دمجت الآن LibRetro مع خدمة الألعاب السحابية لأن LibRetro يقدم واجهة محاكي ألعاب جميلة للألعاب القديمة مثل SNES و GBA و PS.

  6. غرف متعددة اللاعبين ولعب جماعي وربط خارجي (رابط عميق) باللعبة
  يدعم CloudRetro العديد من طرق اللعب الجديدة مثل CrowdPlay و Online MultiPlayer للألعاب القديمة. إذا فتح العديد من المستخدمين نفس الرابط لموضع معين على أجهزة كمبيوتر مختلفة ، فسيشاهدون نفس اللعبة قيد التشغيل وحتى يمكنهم الانضمام إليها.

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

  7. التحجيم الأفقي
  مثل أي SAAS في الوقت الحاضر ، يجب تصميم الألعاب السحابية لتكون قابلة للتطوير أفقيًا. يسمح لك تصميم المنسق-العامل بإضافة المزيد من العمال لخدمة المزيد من حركة المرور.

  8. غير مرتبطة بسحابة واحدة
  تتم استضافة البنية التحتية CloudRetro من قبل مزودي خدمات سحابية مختلفين (المحيط الرقمي ، علي بابا ، مزود مخصص) لمناطق مختلفة. أقوم بتمكين التشغيل في حاوية Docker للبنية التحتية وقم بتهيئة إعدادات الشبكة باستخدام برنامج نصي bash لتجنب الاعتماد على مزود خدمة سحابي واحد. بدمج هذا مع NAT Traversal في WebRTC ، يمكننا التمتع بالمرونة لنشر CloudRetro على أي منصة سحابية وحتى جهاز أي مستخدم.

  التصميم المعماري

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

  منسق: مسؤول عن إقران المستخدم الجديد بأنسب عامل بث. يتواصل المنسق مع العمال عبر WebSocket.

  تخزين حالة اللعبة: تخزين مركزي عن بعد لجميع حالات اللعبة. يوفر هذا التخزين ميزات مهمة مثل الحفظ / التحميل عن بُعد.

  
  بنية CloudRetro عالية المستوى

  برنامج نصي مخصص

  عندما يفتح مستخدم جديد CloudRetro في الخطوتين 1 و 2 الموضحين في الشكل أدناه ، يُطلب من المنسق ، جنبًا إلى جنب مع قائمة العمال المتاحين ، الانتقال إلى الصفحة الأولى. بعد ذلك ، في الخطوة 3 ، يحسب العميل التأخيرات لجميع المرشحين باستخدام طلب اختبار اتصال HTTP. ثم يتم إرسال قائمة التأخيرات هذه إلى المنسق حتى يتمكن من تحديد العامل الأنسب لخدمة المستخدم. الخطوة 4 أدناه تخلق لعبة. يتم إنشاء اتصال دفق WebRTC بين المستخدم والعامل المعين.
  
  نص مخصص بعد الحصول على حق الوصول

  ماذا يوجد داخل العامل

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

  
  تفاعل مكونات العمال

  المكونات الرئيسية:

  • يتطلب WebRTC: مكون العميل الذي يقبل مدخلات المستخدم ويخرج الوسائط المشفرة من الخادم.
  • محاكي الألعاب: مكون اللعبة. بفضل مكتبة Libretro ، يمكن للنظام تشغيل اللعبة داخل نفس العملية واعتراض الوسائط وتدفق الإدخال داخليًا.
  • يتم التقاط الإطارات داخل اللعبة وإرسالها إلى المشفر.
  • برنامج ترميز الصورة / الصوت: خط أنابيب ترميز يستقبل إطارات الوسائط ، ويشفرها في الخلفية ، ويخرج صورًا / صوتًا مشفرًا.

  تطبيق

  تعتمد CloudRetro على WebRTC كتقنية أساسية ، لذا قبل الغوص في تفاصيل تطبيق Golang ، قررت التحدث عن WebRTC نفسها. إنها تقنية رائعة ساعدتني بشكل كبير في تحقيق تدفق بث أقل من الثانية.

  WebRTC

  تم تصميم WebRTC لتوفير اتصالات عالية الجودة من نظير إلى نظير على تطبيقات الجوال الأصلية والمتصفحات التي تستخدم واجهات برمجة تطبيقات بسيطة.

  اجتياز NAT

  تشتهر WebRTC بوظيفة NAT Traversal الخاصة بها. تم تصميم WebRTC للاتصال من نظير إلى نظير. والغرض منه هو العثور على المسار المباشر الأنسب ، وتجنب بوابات NAT والجدران النارية ، من أجل الاتصال من نظير إلى نظير من خلال عملية تسمى ICE. كجزء من هذه العملية ، تعثر واجهات برمجة تطبيقات WebRTC على عنوان IP العام الخاص بك باستخدام خوادم STUN وإعادة توجيهه إلى خادم ترحيل (منعطف أو دور) عندما يتعذر إنشاء اتصال مباشر.

  ومع ذلك ، لا تستغل CloudRetro هذه الإمكانية بشكل كامل. لا توجد اتصالات نظير إلى نظير الخاصة به بين المستخدمين ، ولكن بين المستخدمين والخوادم السحابية. يحتوي جانب الخادم من النموذج على قيود أقل على الاتصال المباشر مقارنة بجهاز المستخدم العادي. يتيح لك ذلك فتح المنافذ الواردة مسبقًا أو استخدام عناوين IP العامة مباشرةً ، نظرًا لأن الخادم ليس خلف NAT.

  في السابق ، كنت أرغب في تحويل المشروع إلى نظام أساسي لتوزيع الألعاب لـ Cloud Gaming. كانت الفكرة هي السماح لمنشئي الألعاب بتوفير الألعاب والموارد المتدفقة. وسيتفاعل المستخدمون مع مقدمي الخدمة بشكل مباشر. في هذا الأسلوب اللامركزي ، يعد CloudRetro مجرد وسيلة لتوصيل موارد دفق الجهات الخارجية بالمستخدمين ، مما يجعلها أكثر قابلية للتوسع عندما لا تكون الاستضافة معلقة عليها. دور WebRTC NAT Traversal مهم جدًا هنا لتسهيل تهيئة اتصال نظير إلى نظير على موارد دفق خارجية ، مما يسهل على المنشئ الاتصال بالشبكة.

  ضغط الفيديو

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

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

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

  
  مقارنة إطارات الفيديو باستخدام بكمن كمثال

  ضغط الصوت

  وبالمثل ، تحذف خوارزمية ضغط الصوت البيانات التي لا يمكن للبشر إدراكها. Opus هو أفضل برنامج ترميز صوتي أداءً حاليًا. إنه مصمم لنقل موجة صوتية عبر بروتوكول مخطط بيانات مرتب مثل RTP (بروتوكول النقل في الوقت الحقيقي). تأخره أقل من mp3 و aac ، والجودة أعلى. عادةً ما يكون وقت الاستجابة حوالي 5 ~ 66,5 مللي ثانية.

  بيون ، ويب آر تي سي في جولانج

  البيون هو مشروع مفتوح المصدر يجلب WebRTC إلى Golang. بدلاً من الالتفاف المعتاد لمكتبات C ++ WebRTC الأصلية ، يعد Pion تطبيقًا أصليًا لـ Golang WebRTC مع أداء أفضل وتكامل Go والتحكم في الإصدار على بروتوكولات WebRTC.

  توفر المكتبة أيضًا تدفق البيانات مع الكثير من الوحدات المدمجة الرائعة مع تأخير أقل من ثانية. لديه تطبيقه الخاص لـ STUN و DTLS و SCTP وما إلى ذلك. وبعض التجارب مع QUIC و WebAssembly. تعد هذه المكتبة مفتوحة المصدر بحد ذاتها مصدرًا جيدًا للتعلم مع توثيق رائع ، وتنفيذ بروتوكول الشبكة ، وأمثلة رائعة.

  مجتمع Pion ، بقيادة منشئ متحمس للغاية ، حيوي للغاية ولديه الكثير من المناقشات الجيدة حول WebRTC. إذا كنت مهتمًا بهذه التكنولوجيا ، انضم http://pion.ly/slack - سوف تتعلم الكثير من الأشياء الجديدة.

  كتابة CloudRetro في Golang

  
  تنفيذ العامل في Go

  انطلق في عمل القنوات

  بفضل التصميم الجميل لقنوات Go ، يتم تبسيط مشكلات تدفق الأحداث والتزامن إلى حد كبير. كما في الرسم التخطيطي ، هناك العديد من المكونات التي تعمل بالتوازي في GoRoutines مختلفة. كل مكون يدير حالته الخاصة ويتواصل عبر القنوات. يتسبب التأكيد الانتقائي لـ Golang في معالجة حدث ذري واحد في كل مرة في اللعبة (علامة اختيار اللعبة). هذا يعني أنه لا حاجة إلى حظر لهذا التصميم. على سبيل المثال ، عندما يتم حفظ مستخدم ، يلزم الحصول على لقطة كاملة لحالة اللعبة. يجب أن تظل هذه الحالة مستمرة ، وتسجيل الدخول حتى يكتمل الحفظ. أثناء كل علامة لعبة ، يمكن للواجهة الخلفية فقط معالجة عملية حفظ أو إدخال ، مما يجعل العملية آمنة.

  func (e *gameEmulator) gameUpdate() {
  for {
  	select {
  		case <-e.saveOperation:
  			e.saveGameState()
  		case key := <-e.input:
  			e.updateGameState(key)
  		case <-e.done:
  			e.close()
  			return
  	}
      }
  }

  مروحة في / مروحة خارج

  يعد نموذج Golang هذا رائعًا لحالة استخدام CrowdPlay و Multi Player. باتباع هذا النمط ، يتم تضمين جميع مدخلات المستخدم في نفس الغرفة في قناة الإدخال المركزية. يتم بعد ذلك نشر وسائط اللعبة لجميع المستخدمين في نفس الغرفة. بهذه الطريقة ، نحقق تقسيم حالة اللعبة بين عدة جلسات لعب لمستخدمين مختلفين.

  
  التزامن بين الجلسات المختلفة

  عيوب Golang

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

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

  CGO

  يستخدم المشروع مكتبة Golang مفتوحة المصدر VP8 / H264 الحالية لضغط الوسائط و Libretro لمحاكيات الألعاب. كل هذه المكتبات عبارة عن أغلفة لمكتبة C في Go باستخدام CGO. يتم سرد بعض العيوب في هذا المنصب ديف تشيني. المشاكل التي واجهتها:

  • عدم القدرة على التقاط حادث في CGO ، حتى مع Golang RecoveryCrash ؛
  • عدم القدرة على تحديد عنق الزجاجة في الأداء عندما لا نتمكن من اكتشاف المشكلات الدقيقة في CGO.

  اختتام

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

  على الرغم من سهولة الدمج ، يعد تدفق P2P بالفعل مجالًا معقدًا للغاية في علوم الكمبيوتر. يجب أن تتعامل مع تعقيد بنى الشبكات متعددة السنوات مثل IP و NAT لإنشاء جلسة نظير إلى نظير. أثناء العمل في هذا المشروع ، جمعت الكثير من المعرفة القيمة حول الشبكات وتحسين الأداء ، لذلك أوصي الجميع بمحاولة بناء منتجات P2P باستخدام WebRTC.

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

المصدر: www.habr.com