كيف أصحح الكون

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

استطرادا صغيرا حول الكشف عن المعلومات. تشعر معظم الشركات بالغيرة للغاية لأن "المطبخ الداخلي" لا يصبح متاحًا لعامة الناس. لماذا - أنا لا أعرف ، ولكن ما هو - هذا هو. في هذا المشروع بالذات - The Universim - كنت محظوظًا والرئيس التنفيذي لشركة Crytivo Inc. (سابقا Crytivo Games Inc.) تبين أن Alex Wallet كان عاقلًا تمامًا في مثل هذه المسألة ، لذلك أتيحت لي الفرصة لتبادل الخبرات مع الآخرين.

قليلا عن بتشر في حد ذاته

لقد شاركت في تطوير اللعبة لفترة طويلة. في بعض - كمصمم ومبرمج للألعاب ، في البعض - كدمج لمسؤول النظام والمبرمج (لا أحب مصطلح "devops" ، لأنه لا يعكس بدقة جوهر المهام التي أؤديها في مثل هذه المشاريع).

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

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

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

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

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

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

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

في الأنظمة المشابهة لـ Unix ، لا يمثل الكتابة فوق ملف مفتوح (ما لم يتم حظره على وجه التحديد) أي مشكلات ، ولكن على نظام Windows ، دون الرقص مع الدف ، لا يعمل مثل هذا "خداع مع آذان". هذا هو السبب في أنني صنعت بتشر كتطبيق منفصل لا يتم تحميل أي شيء سوى مكتبات النظام. في الواقع ، تحولت أداة الترقيع نفسها إلى أداة مساعدة مستقلة تمامًا عن محرك Unity3D ، والتي لم تمنعها من إضافتها إلى متجر Unity3D.

خوارزمية بتشر

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

من المطور

عند إعداد تصحيح ، تبدو الخوارزمية الخاصة بإجراءات patcher كما يلي:

○ إنشاء شجرة ملف لعبة مع سماتها واختبارات SHA512
○ لكل ملف:
► تقسيم المحتويات إلى كتل.
► احفظ المجموع الاختباري SHA256.
block ضغط كتلة وإضافتها إلى خريطة كتلة الملف.
► احفظ عنوان الكتلة في الفهرس.
○ حفظ شجرة الملف مع اختباريها.
○ احفظ ملف بيانات الإصدار.

يجب على المطور تحميل الملفات المستلمة إلى الخادم.

جانب اللاعب

على العميل ، يقوم patcher بما يلي:
itself نسخ نفسه إلى ملف باسم مختلف. سيؤدي هذا إلى تحديث الملف القابل للتنفيذ patcher إذا لزم الأمر. ثم يتم نقل السيطرة على نسخة ويكمل الأصلي.
○ قم بتنزيل ملف الإصدار ومقارنته مع ملف الإصدار المحلي.
○ إذا لم تكشف المقارنة عن وجود فرق - يمكنك اللعب ، فلدينا أحدث إصدار. إذا كان هناك فرق ، انتقل إلى العنصر التالي.
○ قم بتنزيل شجرة الملفات مع اختباريها.
each لكل ملف في الشجرة من الخادم:
► إذا كان هناك ملف ، فهو يعتبر المجموع الاختباري (SHA512). إذا لم يكن الأمر كذلك ، فهي تعتبره فارغًا (بمعنى أنه يتكون من أصفار صلبة) وأيضًا تعتبر المجموع الاختباري.
► إذا كان مجموع الملف المحلي لا يتطابق مع المجموع الاختباري للملف من أحدث إصدار:
► إنشاء خريطة كتلة محلية ومقارنتها مع خريطة الكتلة من الخادم.
each لكل كتلة محلية تختلف عن الكتلة البعيدة ، تقوم بتنزيل كتلة مضغوطة من الخادم وتقوم بالكتابة فوقها محليًا.
○ في حالة عدم وجود أخطاء ، قم بتحديث ملف الإصدار.

لقد جعلت حجم كتلة البيانات مضاعفات 1024 بايت ، بعد عدد معين من الاختبارات ، قررت أنه كان من الأسهل العمل مع كتل 64 كيلو بايت. على الرغم من أن الشمولية في الكود تبقى:

#region DQPatcher class public class DQPatcher { // some internal constants // 1 minute timeout by default private const int DEFAULT_NETWORK_TIMEOUT = 60000; // maximum number of compressed blocks, which we will download at once private const UInt16 MAX_COMPRESSED_BLOCKS = 1000; // default block size, you can use range from 4k to 64k, //depending on average size of your files in the project tree private const uint DEFAULT_BLOCK_SIZE = 64 * 1024; ... #region public constants and vars section // X * 1024 bytes by default for patch creation public static uint blockSize = DEFAULT_BLOCK_SIZE; ... #endregion .... 

إذا قمت بتجميع الكتل ، فسيطلب العميل تغييرات أقل عندما تكون التغييرات نفسها قليلة. ومع ذلك ، تنشأ مشكلة أخرى - زيادة حجم ملف الفهرس بشكل معاكس مع انخفاض حجم الكتلة - أي إذا كنا نعمل مع كتل 8KB ، فإن ملف الفهرس سيكون أكبر 8 مرات من كتل 64KB.

لقد اخترت SHA256 / 512 للملفات والكتل من الاعتبارات التالية: تختلف السرعة قليلاً مقارنةً بـ MD5 / SHA128 (المتقادمة) ، ولكن لا يزال عليك قراءة الكتل والملفات. واحتمال الاصطدام مع SHA256 / 512 هو أقل بكثير من MD5 / SHA128. أن تكون مملاً تمامًا - إنه في هذه الحالة ، لكنه صغير جدًا بحيث يمكن إهمال هذا الاحتمال.

بالإضافة إلى ذلك ، يأخذ العميل في الاعتبار النقاط التالية:
blocks يمكن نقل كتل البيانات في إصدارات مختلفة ، أي محليًا ، لدينا كتلة رقم 10 ، وعلى الخادم لدينا كتلة رقم 12 ، أو العكس. يؤخذ هذا في الاعتبار حتى لا يتم تنزيل بيانات إضافية.
► لا يتم طلب الكتل الواحدة تلو الأخرى ، ولكن في مجموعات - يحاول العميل دمج نطاقات الكتل اللازمة ويطلبها من الخادم باستخدام رأس النطاق. هذا يقلل أيضًا من تحميل الخادم:

 // get compressed remote blocks of data and return it to the caller // Note: we always operating with compressed data, so all offsets are in the _compressed_ data file!! // Throw an exception, if fetching compressed blocks failed public byte[] GetRemoteBlocks(string remoteName, UInt64 startByteRange, UInt64 endByteRange) { if (verboseOutput) Console.Error.WriteLine("Getting partial content for [" + remoteName + "]"); if (verboseOutput) Console.Error.WriteLine("Range is [" + startByteRange + "-" + endByteRange + "]"); int bufferSize = 1024; byte[] remoteData; byte[] buffer = new byte[bufferSize]; HttpWebRequest httpRequest = (HttpWebRequest)WebRequest.Create(remoteName); httpRequest.KeepAlive = true; httpRequest.AddRange((int)startByteRange, (int)endByteRange); httpRequest.Method = WebRequestMethods.Http.Get; httpRequest.ReadWriteTimeout = this.networkTimeout; try { // Get back the HTTP response for web server HttpWebResponse httpResponse = (HttpWebResponse)httpRequest.GetResponse(); if (verboseOutput) Console.Error.WriteLine("Got partial content length: " + httpResponse.ContentLength); remoteData = new byte[httpResponse.ContentLength]; Stream httpResponseStream = httpResponse.GetResponseStream(); if (!((httpResponse.StatusCode == HttpStatusCode.OK) || (httpResponse.StatusCode == HttpStatusCode.PartialContent))) // rise an exception, we expect partial content here { RemoteDataDownloadingException pe = new RemoteDataDownloadingException("While getting remote blocks:\n" + httpResponse.StatusDescription); throw pe; } int bytesRead = 0; int rOffset = 0; while ((bytesRead = httpResponseStream.Read(buffer, 0, bufferSize)) > 0) { // if(verboseOutput) Console.Error.WriteLine("Got ["+bytesRead+"] bytes of remote data block."); Array.Copy(buffer, 0, remoteData, rOffset, bytesRead); rOffset += bytesRead; } if (verboseOutput) Console.Error.WriteLine("Total got: [" + rOffset + "] bytes"); httpResponse.Close(); } catch (Exception ex) { if (verboseOutput) Console.Error.WriteLine(ex.ToString()); PatchException pe = new PatchException("Unable to fetch URI " + remoteName, ex); throw pe; } return remoteData; } 

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

هنا يمكنك مشاهدة مقطع فيديو يوضح عمل بتشر في مشروع مثال Angry Bots:

حول كيفية تنظيم تصحيح لعبة الكون

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

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

في الإصدار العادي من patcher ، تبدو شجرة بيانات التصحيح كما يلي:

 ./
 | - لينكس
 |  | - 1.0.0
 |  `- version.txt
 | - macosx
 |  | - 1.0.0
 |  `- version.txt
 `- النوافذ
     | - 1.0.0
     `- version.txt

كنت بحاجة للتأكد من أن فقط أولئك الذين لديهم المفتاح الصحيح يمكنهم الوصول.

توصلت إلى الحل التالي - لكل مفتاح نحصل عليه من علامة التجزئة (SHA1) ، ثم نستخدمه كطريق للوصول إلى بيانات التصحيح على الخادم. على الخادم ، ننقل بيانات التصحيح إلى مستوى أعلى من docroot ، ونضيف روابط إلى الدليل مع بيانات التصحيح في docroot نفسه. تحتوي الروابط الرمزية على نفس أسماء علامات التجزئة ، مقسمة فقط إلى عدة مستويات (لتسهيل تشغيل نظام الملفات) ، أي 0f99e50314d63c30271 ... ... سيتم تمثيل ade71963e7ff كـ

 ./0f/99/e5/0314d63c30271….ade71963e7ff -----> / full / path / to / patch-data /

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

لإضافة مفاتيح جديدة (أو حذف المفاتيح القديمة) - ما عليك سوى إضافة / إزالة الرابط الرمزي المقابل.

من خلال هذا التطبيق ، من الواضح أنه لم يتم إجراء التحقق من المفتاح نفسه في أي مكان ؛ يشير تلقي 404 أخطاء على العميل إلى أن المفتاح غير صحيح (أو تم إلغاء تنشيطه).

تجدر الإشارة إلى أن الوصول إلى المفتاح ليس حماية كاملة لإدارة الحقوق الرقمية - فهذه مجرد قيود في مرحلة اختبار (ألفا) وبيتا (مغلق). ويتم قطع البحث بسهولة عن طريق خادم الويب نفسه (على الأقل في Nginx ، والذي أستخدمه).

في شهر الإطلاق ، تم تسليم 2.5 تيرابايت فقط من حركة المرور في اليوم الأول وحده ، وفي الأيام التالية ، يتم توزيع نفس الكمية تقريبًا في المتوسط ​​شهريًا:



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

في الممارسة العملية ، تعد وفورات حركة المرور سنويًا في المتوسط ​​في The Universim ضخمة - مقارنة الأرقام أعلاه. بالطبع ، إذا لم يكن لدى المستخدم أي لعبة على الإطلاق أو كانت قديمة جدًا ، فلن تحدث معجزة وسيتعين عليه تنزيل الكثير من البيانات من الخادم - إذا كان ذلك من نقطة الصفر ، ثم أكثر من اللعبة بقليل في الأرشيف. ومع ذلك ، مع التحديثات الشهرية ، الأمور جيدة حقا. في أقل من 6 أشهر ، أعطت المرآة الأمريكية أكثر قليلاً من 10 تيرابايت من حركة المرور ، دون استخدام بتشر هذه القيمة قد نمت بشكل كبير.

هكذا تبدو حركة المرور السنوية للمشروع:



بعض الكلمات حول "أشعل النار" التي لا تنسى والتي اضطررنا إلى المضي قدمًا في عملية العمل على جهاز بتشر مخصص للعبة "The Universim":

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

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

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

● Apple غير مرتاح جدًا لهذه الطريقة لتثبيت التطبيقات. السياسة الرسمية - يجب تثبيت التطبيقات فقط من متجرهم. ولكن المشكلة هي أن التطبيقات في مرحلتي اختبار ألفا وبيتا غير مسموح بها في المتجر. وحتى أكثر من ذلك ، لا يوجد شيء للحديث عن بيع التطبيقات الخام من الوصول المبكر. لذلك ، يجب عليك كتابة تعليمات حول كيفية الرقص على الخشخاش. لم يتم النظر في الخيار مع AppAnnie (بعد ذلك كانا مستقلين) بسبب الحد الأقصى لعدد المختبرين.

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

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

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

على الرغم من أن المشروع ككل كان ناجحًا ، إلا أن له بعض العيوب:

● على الرغم من أنني أخرجت في البداية كل المنطق الرئيسي بشكل منفصل ، إلا أن جزء واجهة المستخدم الرسومية مختلف في تطبيق نظامي التشغيل MAC و Windows. لم يتسبب إصدار Linux في حدوث مشكلات - فكانت جميع المشكلات بشكل رئيسي فقط عند استخدام بنية متجانسة لا تتطلب بيئة وقت التشغيل Mono - MRE. ولكن نظرًا لأنك تحتاج إلى ترخيص إضافي لتوزيع هذه الملفات القابلة للتنفيذ ، فقد تقرر التخلي عن بنيات متجانسة وتطلب ببساطة تعليم مخاطر الألغام. يختلف إصدار Linux عن إصدار Windows فقط في دعم سمات الملفات الخاصة بأنظمة * nix. بالنسبة لمشروعي الثاني ، والذي سيكون أكثر من مجرد بتشر ، أخطط لاستخدام نهج وحدات في شكل عملية kernel تعمل في الخلفية وتسمح بإدارة كل شيء على الواجهة المحلية. ويمكن تنفيذ التحكم نفسه من تطبيق قائم على الإلكترون وما شابه (أو ببساطة من متصفح). مع أي شيء صغير. قبل الحديث عن حجم توزيع هذه التطبيقات - انظر إلى حجم الألعاب. تحتل الإصدارات التجريبية (!!!) من بعضها 5 غيغابايت أو أكثر في الأرشيف (!!!).

● الهياكل المستخدمة الآن لا توفر مساحة عند إصدار اللعبة لـ 3 منصات - بحكم الواقع ، تحتاج إلى الاحتفاظ بثلاث نسخ من البيانات المتطابقة تقريبًا ، وإن كانت مضغوطة.

● لا يعمل الإصدار الحالي من patcher على تخزين عمله مؤقتًا - في كل مرة يتم فيها إعادة حساب جميع اختباري جميع الملفات. سيكون من الممكن تقليل الوقت بشكل ملحوظ إذا بتشر مؤقتاً نتائج تلك الملفات الموجودة بالفعل على العميل. ولكن هناك معضلة واحدة - إذا كان الملف تالفًا (أو مفقودًا) ، ولكن تم حفظ إدخال ذاكرة التخزين المؤقت لهذا الملف ، فسيتخطاه بتشر ، مما سيتسبب في حدوث مشكلات.

● لا يعرف الإصدار الحالي كيفية العمل في وقت واحد مع خوادم متعددة (إلا إذا قمت بإجراء Round-robin باستخدام DNS) - أرغب في التبديل إلى تقنية "تشبه السيل" بحيث يمكنك استخدام خوادم متعددة في نفس الوقت. لا يوجد أي شك في استخدام العملاء كمصدر للبيانات ، لأن هذا يثير العديد من المشكلات القانونية ومن السهل رفضها من البداية.

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

● يتم إنشاء بتشر لمشروع واحد فقط في وقت واحد. إذا كنت ترغب في بناء شيء مشابه لـ Steam ، فإن نظام تسليم المحتوى بالكامل مطلوب بالفعل. وهذا مشروع بمستوى مختلف تمامًا.

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

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

سأكون سعيدًا للإجابة على أسئلتك.