نفس السفينة على كل شاشة
لوحة الصدارة اليومية عادلة فقط إذا كان الطيران في نفس مقطع الكهف بنفس الصعوبة على هاتف قديم صغير، وجهاز لوحي بمعدل 144 هرتز، ومتصفح سطح مكتب. إليك ما تطلبه ذلك، وما لم أستطع جعله متساويا.
كان مقال الكهف اليومي يتحدث عن جعل العالم متطابقا لكل لاعب. هذا المقال عن النصف الآخر من العدالة: جعل السفينة تتصرف بشكل متطابق. هناك طريقتان منفصلتان يمكن للجهاز أن يغير بهما طريقة لعب اللعبة، وتحتاجان إلى إصلاحين منفصلين. إحداهما مدى تكرار تحديث الشاشة. والأخرى حجم الشاشة.
المشكلة الأولى: معدل التحديث
للسفينة موضع وسرعة. في كل إطار، تغيّر الجاذبية أو الدفع السرعة، وتغيّر السرعة الموضع. الطريقة الواضحة لكتابة ذلك هي:
vy += accel * dt; // update velocity
py += vy * dt; // then move by the NEW velocityيبدو الأمر غير ضار، لكنه خاطئ بشكل دقيق. يتظاهر السطر الثاني بأن السفينة قضت الإطار بأكمله بالفعل وهي تتحرك بسرعتها في نهاية الإطار. إذا كانت السفينة تتسارع، فإن هذا يتجاوز بمقدار نصف accel × dt² في كل إطار. المشكلة أن dt، طول الإطار، مختلف على كل جهاز، لذا فإن مقدار التجاوز مختلف أيضا، وكانت السفينة تطير على مسار مختلف قليلا مع كل معدل تحديث.
قست ذلك بدفع مستمر لمدة نصف ثانية. الإجابة الدقيقة هي 225 بكسل. أعطى المُكامِل القديم 228 عند 144 هرتز، و232 عند 60 هرتز، و240 عند 30 هرتز. ثلاثة أجهزة، ثلاث مسافات مختلفة، من نفس المدخل.
الحل هو قاعدة شبه المنحرف، التي تستخدم متوسط السرعة قبل الإطار وبعده:
const vyPrev = vy;
vy += accel * dt;
py += (vyPrev + vy) * 0.5 * dt; // average speed over the frameبالنسبة للتسارع الثابت، هذا دقيق مهما كان طول الإطار. إعادة تشغيل جدول مدخلات متطابق يعطي الآن انتشارا قدره 0.000 بكسل عبر 12 إلى 144 هرتز. كان 4.1 بكسل من قبل. يتحقق اختبار من الأمرين معا: أن المُكامِل الجديد يتفق عبر جميع معدلات التحديث وأن القديم كان يتباعد فعلا، لذا إذا أعاد أحدهم هذا التغيير، يفشل الاختبار بدلا من أن تنحرف لوحة الصدارة بصمت.
تحفظان صادقان
لم يغلق هذا فجوة النقاط بين معدلات التحديث. كنت أتوقع ذلك. ظل طيار محاكى يسجل نحو ثلث نقاط أكثر عند 144 هرتز مقارنة بـ60 هرتز بعد ذلك. هذه الفجوة ليست فيزياء. إنها دقة الإدخال: لا يمكن للإبهام أن يتحول من الضغط إلى عدم الضغط إلا عند حدود الإطار، لذا فإن الشاشة الأسرع تمنح فعلا تحكما أدق. لا يمكن لأي مُكامِل إصلاح ذلك، وأي روبوت يعكس مدخله كل إطار يبالغ في ذلك مقارنة بإنسان. النصف الفيزيائي أصبح الآن دقيقا، والباقي خاصية للعتاد.
إنه إضعاف طفيف جدا عند 60 هرتز. يغطي الصعود لنصف ثانية الآن 225 بكسل بدلا من 232. تركت ذلك دون تعويض. إذا وجد اختبار على جهاز حقيقي يوما أن السفينة بطيئة، فالرافعة هي ثابت الدفع، حوالي 3% أكثر سيعيد المناورة القديمة لنصف ثانية. وهذه لحظة جيدة لأقول إن الدفع تم تغييره مرتين من قبل بناء على ملاحظات اللاعبين، وتلك القصة هي سبب حذري في المساس به.
المشكلة الثانية: ارتفاع الشاشة
الجاذبية بوحدة بكسل في الثانية تربيع تعني أشياء مختلفة جدا على هاتف ارتفاعه 375 نقطة وجهاز لوحي ارتفاعه 520 نقطة. لو كانت الثوابت نفسها، لكان نفس الصعود يعبر جزءا أصغر بكثير من الشاشة على الجهاز اللوحي، وكانت اللعبة ستبدو أثقل.
لذا تُعرَّف الثوابت بالنسبة إلى ارتفاع مرجعي قدره 440 نقطة، وهو ارتفاع الوضع الأفقي لأكبر آيفون، حيث تم ضبط شعور اللعبة واختباره. على أي شاشة أخرى، تُضرب الجاذبية والدفع والسرعة النهائية جميعا في H / 440. ولأن نصف فجوة الممر يتغير حجمه مع الارتفاع أيضا، فإن كل مسار يشبه هندسيا المسار المرجعي: نفس جزء الممر المقطوع في الثانية، نفس الوقت للانتقال من جدار إلى آخر، نفس الاستجابة المحسوسة. تحصل الشاشة الأكبر على تسارع أكثر حدة بالبكسل، والأصغر على تسارع أكثر لطفا، عن قصد.
يأتي هذا مع قاعدة لكل الشيفرة المستقبلية: يجب أن يعتمد كل ما يستدل على الحركة الرأسية على النسب. جزء من السرعة النهائية، جزء من الارتفاع. أبدا ثابت خام بوحدة بكسل في الثانية يُقارن بسرعة السفينة، لأن ذلك الرقم صحيح على جهاز واحد فقط. إذا كان الرقم الحرفي لا مفر منه، يُضرب في نفس المقياس.
تتبع نسخة الويب نفس القاعدة. تحصر بنية المتصفح لوحة الرسم في 956 في 440، بنفس أبعاد ذلك الهاتف المرجعي، لذا فإن اللعبة في المتصفح نسخة دقيقة منه من حيث البكسل والفيزياء. كان لبنية ويب سابقة مضاعف شعور خاص بها، وُجد فقط لمكافحة الليونة الناتجة عن حد مختلف، وحُذف بمجرد أن تطابق الحد.
المشكلة الثالثة: عرض الشاشة
الارتفاع هو المحور الرأسي. العرض هو المحور الأفقي، وهو أدق. توضع العوائق على مسافات ثابتة في العالم. يتمرر الكهف بسرعة تتضمن معاملا لعرض الشاشة. لذا على شاشة أعرض، تمر نفس العوائق بشكل أسرع من حيث الشاشة، وينخفض الوقت المتاح لك للتفاعل مع كل واحدة بما يتناسب مع العرض.
كانت هذه ثغرة حقيقية. كان جهاز لوحي أندرويد كبير بعرض نحو 1280 نقطة يواجه الكهف المشترك بسرعة أكبر بنحو 1.75 مرة من هاتف صغير. لذا فإن العرض محدود بـ956 نقطة على كل منصة، وهو عرض أوسع آيفون في الوضع الأفقي. يحصل أي جهاز أعرض من ذلك على شريطين أسودين على اليسار واليمين. هذا لا يؤثر على آيفون ويحدّ فقط من أجهزة أندرويد الكبيرة ومتصفحات سطح المكتب.
للحد بقية لم أصلحها. يتغير حجم نصف قطر تصادم اللاعب مع العرض بينما يتغير الممر مع الارتفاع، لذا على جهاز لوحي أقرب إلى المربع تكون السفينة أصغر قليلا نسبيا إلى الفجوة مما هي عليه على الهاتف، أي أكثر تسامحا بنحو 20%. إصلاح هذا يعني تغيير منطقة الاصطدام، وهو تغيير في الشعور يحتاج اختبار لعب خاصا به، وهو يخطئ في اتجاه التسامح، لذا يمكن أن ينتظر.
اختبار العدالة بدلا من افتراضها
لا شيء من هذا مرئي أثناء اللعب. لا يمكنك الشعور ببضعة بكسلات من الانحراف، ولا أحد يلعب نفس الكهف على ستة أجهزة في وقت واحد. لذا فإن لكل ادعاء اختبارا يعيد تمثيله: يدمج اختبار الفيزياء مدخلا ثابتا عند معدلات تحديث من 12 إلى 144 هرتز، ويعيد اختبار الكهف تشغيل المولدات الحقيقية على ستة أحجام أجهزة ويقارن النتيجة بايتا ببايت. أي خاصية عدالة لا تختبرها قد انكسرت بالفعل بصمت، بحسب خبرتي.
باختصار، TUNL عادلة بين الشاشات بثلاث طرق منفصلة (معدل التحديث والارتفاع والعرض)، لكل منها سبب مختلف وإصلاح مختلف وبقية مختلفة. يمكنك رؤية النتيجة بنفسك، على أي جهاز تملكه، في كهف اليوم.