Зробити швидку річ повільно (Box2D)

Я працюю над грою, якою ви керуєте требушем, щоб кидати м'ячі супротивнику.

Це як гра під назвою «Середньовічна облога». Коли требушек розмахує рукою, гравцеві потрібно скористатися найкращим моментом, щоб натиснути кнопку і випустити м'яч. Тоді куля полетить під дотичним кутом. Моя проблема зараз полягає в тому, що рука требуше розгойдується занадто швидко, щоб гравець захопив потрібний момент. Тим часом це повинно бути таким швидким, інакше він не може кинути досить далеко. І є крихітна струна, що з'єднує м'яч і требушечку, якщо рука хитається занадто повільно, м'яч просто висить на струні, коли рука рухається.

Я вирішую проблему, змінюючи розмір кроку, щоразу, коли рука розмахується, я змінюю розмір кроку з 1/60 на 1/200. І як тільки гравець відпустить м'яч, він повернеться до 1/60.

Це працює дуже добре, за винятком того, що моя гра призначена для багатокористувацьких мереж. Тож зміна кроку може спричинити проблеми.

Ще одне рішення, про яке я можу подумати - це дозволити йому повільно розгойдуватися, але коли гравець відпускає м'яч, я вручну додаю швидкість на м'яч, зберігаючи його напрямок. Мені не дуже подобається це рішення, тому що воно виглядає підробним, і у мене все ще виникає проблема, що м'яч просто висить на струні, якщо я не роблю рядок дуже короткою.

Будь ласка, проліть трохи світла на це, дякую!

EDIT

Дякую за всі внески, я вирішую проблему, змушуючи повільно розмахувати рукою, і коли гравець відпускає м'яч, захоплює швидкість м'яча та два рази. Це виглядає точно так само, як і зміна розміру кроку. Мені потрібно зробити ще одну зайву річ. Оскільки рука розгойдується дуже повільно, м'яч просто висить на кінці руки, а не розгойдується. Я вирішив це, застосувавши силу, рівну силі гравітації на кульку під час і тільки під час гойдання. Тоді воно вже не висить там, а розгойдується разом із рукою.

Відповідь @MrCranky детальна і виглядає здійсненною, тому я б її прийняв. :)

Інстинктивно я б сказав, що нам не вистачає значної частини контексту, необхідного для відповіді. Це "чому багатокористувацький аспект заважає вам змінювати часовий крок?"

Якщо ви намагаєтеся поділитися фізичним моделюванням через мережеве з'єднання, ну, зазвичай це досить важко зробити. Моделювання розходяться дуже легко, і особливо з мережевими з'єднаннями, які можуть втратити пакети, дуже важко тримати речі разом.

Найпростіший і надійний відповідь на ваше запитання - використовувати змінний часовий крок. Коли ви наближаєтесь до моменту прийняття рішення, замість того, щоб оновлювати своє фізичне моделювання на одну секунду за кожну секунду реального світу, оновіть його на півсекунди або на інше відповідне число. Оскільки це ефект інтеграції, ви, ймовірно, зможете уникнути простого прискорення швидкості оновлення до нижчої ставки під час вікна рішення, але ви також можете швидко інтерполювати вниз до нижчої. Так чи інакше, ви по суті відтворюєте фізичне моделювання в повільному режимі. Він повинен вести себе абсолютно точно, досить повільно, щоб гравець міг прийняти своє рішення. Я б не вважав жодним іншим способом роздути фізику, щоб вона працювала, вони, швидше за все, будуть спрацьовувати жахливо і не відчувати себе «правильно».

Тож ми повертаємося до впровадження мереж. Без додаткової інформації, я думаю, у вас є два варіанти. По-перше, якщо ви працюєте в режимі замкового кроку з іншою мережевою стороною. Отже, коли одному гравцеві доводиться гальмувати, щоб прийняти своє рішення, сповільнити обох гравців однаково. Це, мабуть, буде дратувати і дивно для гравця, який не стріляє, оскільки це заплутає їх власну реакцію.

По-друге, уявіть, як два требушета стріляють один на одного. Требуше займає 10 секунд, щоб кинути, і вікно стрільби починається з T + 5s. P1 запускає цикл стрільби при T + 0s, а при T + 5s уповільнює їх локальне фізичне моделювання на 50%. Їм знадобиться 15 років, щоб грати протягом усього циклу. Тож у T + 5s P1 повідомляє P2 почати відтворювати цикл запуску 10с на повній швидкості. Таким чином, P1 бачить, що цикл требуше займає 15 секунд, P2 бачить, що він займає 10 секунд, але обидва гравці бачать закінчення циклу на T + 15s. Коли P1 насправді випускається, вони повідомляють P2, коли в умовному циклі вони вийшли. Тож якщо P1 випускається за T + 10s, це насправді в 7,5s через цикл запуску 10s. Потім P2 може показати випуск при T + 12,5s (7,5s в локальному відтворенні циклу), і обидва гравці симуляції повинні були запустити снаряд в одній фізичній точці циклу.

Тож у цьому другому підході ви більше не імітуєтеся в режимі замкового кроку. Ви працюєте з двома незалежними моделюваннями, але натомість відстежуєте дані гравця. Якщо обом кажуть, що гравця випустили в 7,5 с у цикл запуску, вони повинні домовитись про те, куди приземлиться снаряд. На практиці це, ймовірно, дуже швидко розходиться, і вам потрібно буде якось синхронізувати стан моделювання.

Чому б просто не скопіювати / адаптувати те, що вже існує і працює в подібних випадках?

Якщо ваш требуше рухається занадто швидко, очевидним рішенням буде масштабування часу, щоб зробити його повільніше. Тобто, за кожну секунду реального часу у фізичному моделюванні потрібно пройти лише 0,1 секунди. Тепер, з точки зору гравця, м'яч рухатиметься в 10 разів повільніше.

Насправді, є ще один спосіб досягти такого ж ефекту: замість того, щоб масштабувати час, просто масштабуйте всі фізичні константи, які знаходяться в одиницях, включаючи час. Наприклад, гравітаційне прискорення має одиниці швидкості / часу = відстань / час², тому якщо гравітація є єдиною константою у вашій грі, зменшення її на коефіцієнт 100 = 10 ² досягає такого ж ефекту, що і уповільнення часу на коефіцієнт 10 .

Звичайно, якщо у вашу фізичну модель входять інші константи з одиницями часу (або швидкість = відстань / час, або прискорення = відстань / час² тощо), вам доведеться також масштабувати їх, якщо ви хочете зберегти траєкторії однаковими .

Зауважте, що існує обмеження того, наскільки далеко ви можете досягти цього: якщо ви сповільнюєте час, скажімо, в 100 разів, ваш требуше буде дуже легко контролювати, але ваші гравці також можуть набриднути в очікуванні кульки повільно пливуть вниз після їх стрільби. Якщо це проблема, можливо, вам доведеться вдатися до більш вдосконалених хитрощів, таких як запропоновані в інших відповідях, таких як використання дійсно повільного масштабування часу, коли требуше стріляє, але перехід на швидший масштаб часу, як тільки м'яч буде запущений.