Платформинг та фізика
Ці крайові випадки численні. Хороші веселі платформи не ведуть себе фізично точно, а контроль та поведінку, на які гравці очікують через роки «ідеальних» платформерів, як Маріо, надзвичайно складно реалізувати із загальними методиками, такими як ви отримуєте з Box2D або іншими двигунами фізики. Більшість хороших платформерів не використовують будь-якої родової фізики чи реакції на зіткнення у своїх контролерах програвачів.
Створюють корпуси
Що стосується вашого конкретного питання, найкращим рішенням є припинення використання ящиків як вашої землі. Використовуйте ряд з’єднаних відрізків ліній (корпус). Це дозволяє двигуну виявлення зіткнень зосередитись лише на фактично поверхових поверхнях, а не дивитися на "підроблений" край, який існує між AB та BC. Саме це і робить Box2D. Форми використовуються для генерування зовнішніх поверхонь, які з'єднані між собою і утворюють корпус.
Це вам потрібно навіть в іграх на основі плитки або в ситуаціях, коли у вас є два об'єкти AABB поруч з іншими, що виступають в якості підлоги. Двигун зіткнення підхопить ці вертикальні кромки і призведе до того, що гравець зачепить їх. Є хаки, які можуть допомогти, але не усунути проблему. Рішення полягає в тому, щоб просто мати однорядний сегмент, що представляє поверхню, а не повний 2D-ящик.
Ви можете створити корпуси в загальному випадку, обрізаючи багатокутники один проти одного і з'єднавши точки кліпу в крайній список.
Похилі поверхні
Оскільки ваш приклад включає схил і ви згадуєте про реституцію та інші фізичні властивості, я зазначу кілька інших проблем, які ви незабаром помітите, що додатково ілюструє, чому загальне виявлення та реагування на зіткнення не працює добре для платформерів. Спочатку спробуйте стояти на кутовій платформі, підскочіть, а потім приземліться. Ви, ймовірно, помітите, що персонаж при посадці трохи "ковзатиме". Проблема полягає в тому, що звичайний контакт, який ви генеруєте, зазвичай буде вказуватися з кутової поверхні. Потім, вирішуючи зіткнення, гравця виштовхують у тому напрямку. Незважаючи на те, що персонаж упав прямо вниз, під час посадки він буде штовхнутий трохи вправо, що призведе до слайду. Це можна зламати, враховуючи відносні швидкості,
Друга проблема, яку ви помітите, яку набагато важче виправити, - це те, що відбувається, коли ви намагаєтесь швидко бігти по рампі. Гравець збирається "скакати" по рампі. Це дуже добре видно навіть у більшості ігор AAA сьогодні. Це не тільки виглядає нерозумно, але якщо ваша гра вимагає, щоб гравець тримався на землі, щоб стрибати, це ускладнює біг по рампі та стрибок на півдорозі, тому що гравець контактує з пандусом лише протягом невеликої частини час, витрачений на спуск. Більш просте виправлення полягає в тому, щоб просто зробити кілька випромінювань, коли гравець рухається, і перенести позицію гравця вниз до найближчої поверхні (якщо вона дуже близька до гравця), якщо гравець не стрибає і раніше був на землі.
Ви також можете виявити, що гравець запускається у повітря під час руху по рампі, якщо ви спробуєте моделювати швидкість, тертя та реституцію гравця, як ніби він був нормальним жорстким тілом. Рух гравця має обмежуватися горизонтальним рухом, якщо не падає / стрибає. Звичайно, якщо ви граєте старших платформерів золотого віку, ви можете помітити, що горизонтальна швидкість гравця часто постійна між горизонтальною та похилою поверхнями. Це потрібно враховувати і під час ходіння по схилах вгору / вниз.
Існує ряд інших випадкових кутових випадків, з якими ви, зрештою, також зіткнетесь. Якщо ви намагаєтеся зробити хорошого платформера, це дійсно найкраще реалізувати контролер платформерного плеєра, окремо від фізики, і жорсткий код поведінки руху та управління, а не покладаючись на загальний алгоритм фізики та реакції на зіткнення.
