تقنيات لتقليل التعقيد في برمجة الألعاب [مغلقة

Question

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

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

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

أحاول حاليًا تفويض أنظمة فرعية مختلفة ووظائف النظام الفرعي إلى كائنات مختلفة يتم تجميعها معًا ، لكنني لم أجد استراتيجية اتصال مفصلة بما فيه الكفاية.

ما نوع التقنيات التي يمكنني استخدامها لمساعدتي في التوفيق بين كل هذه الأنظمة الفرعية المختلفة والتعامل مع تعقيد نظام متزايد باستمرار يحتاج إلى أن يكون معياريًا بما يكفي لتسهيل تغيير المتطلبات السريعة؟

غالبًا ما أجد نفسي أطرح نفس الأسئلة:

• كيف تتواصل الأشياء مع بعضها البعض؟
• أين يجب أن تذهب الرمز الذي يتولى أنظمة فرعية محددة؟
• ما مقدار قاعدة الكود التي يجب أن أفكر فيها في وقت واحد؟
• كيف يمكنني تقليل الاقتران بين كيانات اللعبة؟

Answer 1

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

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

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

• كيف تتواصل الأشياء مع بعضها البعض؟
• أين يجب أن تذهب الرمز الذي يتولى أنظمة فرعية محددة؟
• ما مقدار قاعدة الكود التي يجب أن أفكر فيها في وقت واحد؟
• كيف يمكنني تقليل الاقتران بين كيانات اللعبة؟

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

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

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

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

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

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