Studio / ROBLOX
لماذا لا تصل الشخصية إلى النهاية: مراجعة Pathfinding في Studio
تساعد ساحة تدريب صغيرة على فصل مشكلة حساب الطريق عن مشكلة الحركة. جهز تجربة واضحة قبل إضافة مطاردة أو شخصية مساعدة إلى لعبتك.
اختر سؤالاً واحداً للمشهد التدريبي #
تخيل ساحة اختبار مستقلة: تبدأ الشخصية من اليسار، وتوجد منطقة هدف محددة على اليمين، وبينهما ممران. هذا مثال تخيلي لمشروعك، وليس وصفاً لمساعد يعمل بالفعل في ألعاب مؤلف الموقع. السؤال الأول بسيط: هل تستطيع هذه الشخصية الوصول عبر الممر الواسع المفتوح؟
سجل الشروط قبل التشغيل: موضع البداية وكائن الهدف وما الذي يعد اكتمالاً. اترك المكافآت ومطاردة اللاعبين والتنقل بين العوالم خارج التجربة الأولى. الأنظمة الإضافية تجعل تفسير طريق أساسي غير واضح أصعب. احفظ المشهد التدريبي منفصلاً عن مرحلة اللعبة الفعلية.
افحص المساحة المتاحة #
افتح Visualization Options أعلى يمين نافذة العرض الثلاثي في Studio، ثم فعل Navigation mesh. يساعد هذا العرض على فحص المساحة التي تدخل في حساب التنقل. قارنه بالساحة: هل توجد وصلة مفهومة بين البداية والهدف؟ وأين يمر الحد قرب الجدار؟ سجل الملاحظة قبل تغيير عدة عناصر معاً.
جهز نسختين من مشهدك. في الأولى اترك ممراً واسعاً بلا زخارف، وفي الثانية أضف قوساً منخفضاً. اكتب النسخة التي فحصتها فعلياً. الشبكة دليل مفيد للتشخيص، لكن نتيجة التمرين ينبغي أن تكون وصولاً ملاحظاً إلى الهدف، لا مجرد لقطة جميلة من المحرر.
قارن أبعاد الشخصية بالممر #
تؤثر معلمات العامل عند إنشاء الطريق في إمكان المرور ضمن المساحة المتاحة. تذكر الوثائق نصف القطر والارتفاع والأفعال المسموحة. اختر شخصية واحدة ومجموعة معلمات ثابتة للتمرين. بعد ذلك غير شكل المكان فقط: وسع الممر أو أزل القوس، ثم قارن النتائج.
لا تستنتج أن البحث عن الطريق معطل بعد محاولة واحدة غير ناجحة. الملاحظة المحددة أفضل: لم يتأكد الطريق مع القوس، وتأكد بدونه. تغيير النموذج والعرض والإعدادات في الوقت نفسه يضيع العلاقة بين التغيير والنتيجة. جدول النسخ يساعد مطوراً آخر على إعادة التجربة ومتابعة التشخيص.
افصل الحساب عن الحركة #
ينشئ CreatePath كائن الطريق، ويحسب ComputeAsync بين البداية والنهاية، ويجري تقييم النتيجة عبر الخاصية المستقلة Status. لا يعيد ComputeAsync علامة تؤكد أن الشخصية وصلت. نجاح الحساب يسمح بفحص الطريق، لكنه لا يكمل السيناريو كله تلقائياً.
اجعل للسجل ثلاثة بنود منفصلة: الحساب والتقدم عبر النقاط والوصول. افترض أن الحساب تأكد لكن الشخصية بقيت عند البداية. هذا سؤال مختلف عن عدم وجود طريق متاح. يوفر الفصل وقتاً لأنك تفحص المرحلة المرتبطة بالملاحظة بدلاً من تعديل جميع الأنظمة معاً.
تابع ترتيب نقاط الطريق #
يتيح GetWaypoints الحصول على نقاط الطريق المحسوب. تعامل معها بوصفها خطة حركة. ميز البداية والنهاية بلونين مختلفين، وسجل المرحلة الحالية. لا تصف آخر نقطة محسوبة بأنها تمت زيارتها قبل التحقق من الفعل المقابل للشخصية.
تخيل أن السجل يبين الحصول على طريق والوصول إلى النقطة الأولى، بينما تبقى التالية غير محققة. سجل موضع التوقف ولقطة للمشهد؛ فهذا أنفع من عبارة أن الشخصية لا تمشي. وضح أيضاً من يتحكم في الحركة. مثال الصفحة الرسمية يتحكم في شخصية اللاعب، ولا يصبح تلقائياً نظام NPC كاملاً على الخادم.
ضع عائقاً أمام الشخصية #
أعد النسخة الأساسية الناجحة وأضف صندوقاً قابلاً للحركة. سجل المرور أولاً عندما يكون الممر مفتوحاً، ثم أغلق جزءاً لم تصل إليه الشخصية بعد. يقدم Path.Blocked فهرس النقطة المحجوبة، وتفرق الوثائق بين عائق أمام التقدم الحالي وعائق خلفه.
صمم تجربتين مستقلتين. في الأولى يمنع الصندوق الحركة المقبلة، وفي الثانية يغلق جزءاً جرى تجاوزه. لا تفرض الاستجابة نفسها على الحالتين ضمن النتيجة المتوقعة. يفحص التمرين إن كان القرار يراعي الجزء المتبقي المهم من الطريق، بدلاً من الاستجابة لكل تغيير في الساحة دون تمييز.
افتح الصورة بالحجم الكامل ↗اكتب سلوك الفشل #
اختر سلوكاً واضحاً للمشروع عند عدم العثور على طريق: التوقف أو تسجيل رسالة للمطور أو إعادة محاولة محدودة بعد تغير الشروط. هذا قرار تصميم، وليس سلوكاً كاملاً يظهر من استدعاء API واحد. لا تحول الفشل إلى سلسلة لا تنتهي من حسابات جديدة مع بقاء العائق كما هو.
ميز في السجل بين طريق مؤكد وحساب غير مؤكد وفحص انتهى بخطأ. اكتب الخطوة التالية لكل حالة. تكرار التجربة دون تغيير لا يفيد كثيراً إذا بقي القوس منخفضاً. وإذا استبدل الهدف، افحص هل تستطيع الحركة القديمة والمعالجات القديمة اتخاذ قرارات تخص الطريق الجديد.
افحص الهدف ضمن بيئة التنفيذ #
مع تفعيل streaming قد تغيب أجزاء من العالم على العميل، ولذلك يحتاج الوصول إلى كائن الهدف إلى فحص مستقل. توضح الوثائق رؤية الخادم للعالم مقارنة بظهور الكائنات على العميل. لا يعني ذلك نقل كل الأفعال إلى مكان واحد؛ حدد أولاً أين يعمل نظامك فعلياً.
اكتب في بطاقة التمرين جهة تشغيل منطق الحركة ومصدر إحداثيات الهدف. افحص حالة يكون الهدف فيها متاحاً، وأخرى لم تجهز بياناته بعد. لا تستبدله بنهاية عشوائية لمجرد تجنب خطأ. اشرح حالة الانتظار دون إعلان وصول إلى هدف غير متاح.
فرق بين التخطيط عبر الباب وفتحه #
يمكن أن يسمح PathfindingModifier مع PassThrough بالتخطيط عبر عائق معين. هذا لا يفتح الباب ولا يمنح الشخصية القدرة الفيزيائية على عبوره تلقائياً. تستخدم الوثائق هذه الأساليب في سيناريوهات أكثر تعقيداً؛ وما زال الفعل المطلوب داخل اللعبة يحتاج إلى تنفيذ وفحص.
اترك الباب خارج التجربة الأساسية. عند إضافته لاحقاً، سجل فحصين: اختيار الطريق للجهة المقصودة، وسماح آلية الباب بالمرور فعلياً. ظهور خط الطريق خلف كائن مغلق ليس إثباتاً للعبور. يفيد المبدأ نفسه عند مراجعة سلالم وقوارب وانتقالات خاصة أخرى.
| النسخة | ما يُسجل |
|---|---|
| ساحة مفتوحة | الحساب والتقدم والوصول |
| قوس منخفض | الاختلاف عن المشهد الأساسي |
| صندوق أمام الشخصية | الاستجابة للجزء المقبل |
| صندوق خلف الشخصية | الاستجابة للجزء الذي تم تجاوزه |
سلم نتيجة قابلة للتكرار #
احفظ بطاقة قصيرة فيها اسم المشهد والشخصية ومعلمات العامل وإحداثيات البداية والهدف والتغيير الوحيد في آخر تجربة. أرفق ملاحظات مستقلة للحساب والتقدم والوصول. أضف لقطات من مشروعك للممر الأساسي والنسخة المشكلة؛ لا تثبت صورة شخص آخر اختبارك أنت.
يقدم هذا الدليل خطة مراجعة، وليس متحكماً مكتملاً لشخصية NPC. لم نشغل مشهدك في Studio ولم نؤكد سلوكه. بعد التنفيذ كرر مجموعة التجارب الصغيرة كلها، بما فيها صندوق أمام الشخصية وآخر خلفها. ثم انقل الحل الذي راجعته إلى مرحلة أكبر بها شخصيات وعوائق وأهداف أكثر.
افتح الصورة بالحجم الكامل ↗| الملاحظة | الفحص التالي |
|---|---|
| الحساب غير مؤكد | شكل المكان والمعلمات |
| الطريق موجود ولا حركة | جهة التحكم ومراحل الحركة |
| توقف في الطريق | النقطة والتغيير في المشهد |
| استبدل الهدف | الطريق والمعالجات القديمة |
المصادر الأصلية
Roblox Creator Hub — PathfindingRoblox Creator Hub — Path API
