У цій статті ми розглянемо використання фізики для імітації кидка снарядів (так, прямо як в Angry Birds). Ми звернемо увагу на основи використання 2D фізики, а також на створення фізичних тіл, імпульсів і сил. Не забудемо відзначити і найбільш популярні ігрові движки для симуляції фізичних 2D світів.
Функції фізичного движка
Навіщо нам використовувати якийсь фізичний движок? І що це таке насправді?
Б
Взагалі фізичний движок дуже корисний. Він дозволяє зробити за нас дві важливі речі:
- Виявлення зіткнень (колізій) між нашими ігровими об'єктами;
- Імітація сили і рухів в результаті зіткнень.
виявлення зіткнень
Ігри були б не дуже цікавими, якщо ваш персонаж провалився б крізь підлогу, не зробивши жодного кроку або стрибка. Або якби нога вашого персонажа пройшла б крізь ворога, якого ви хотіли штовхнути. Виявлення зіткнень дозволяє дуже точно визначати взаємодію двох тіл.
імітація сили
Що має статися після зіткнення? Можуть статися різні явища: може стрибнути персонаж, може стрибнути якийсь інший ігровий об'єкт, а може ви просто будете рухатися в якомусь напрямку. Все це виконується движком за кадром. Але сили, які може імітувати фізичний движок, не обмежені зіткненнями. Існують такі поняття, як гравітація і імпульс. Вони можуть застосовуватися до тіл, навіть якщо ті не стикалися. Також такі сили можуть впливати на дії, які відбуваються в грі, на рухи героїв і навіть на сам світ.
Отже, давайте подивимося коротко на пристрій фізичного движка, але спочатку звернемо свою увагу на їх різновиди та визначимося з вибором виходячи з наших потреб.
Вибір фізичного движка
На цьому етапі у вас є два варіанти. Обидва варіанти мають як переваги, так і недоліки:
- Використовувати існуючий фізичний движок;
- Написати свою реалізацію (з преферанс і куртизанками).
Використання існуючого движка
Існують кілька відмінних готових варіантів. Один з найпопулярніших движків для 2D ігор це, безумовно, Box2D. Написаний був спочатку на C ++, проте був портований практично на всі популярні мови програмування. Іншим досить відомим двигуном є Chipmink 2D. який використовується як основний у таких фреймворків, як Cocos2D.
Написання свого движка
У деяких іграх використання існуючого рішення - зайва розкіш. Справа в тому, що фізичний движок використовує чимало дорогоцінної пам'яті, і в простеньких іграх може викликати зайве навантаження, якої можна було б уникнути. Погодьтеся, в простих платформер або арканоїд нам не потрібно обчислювати місце контакту з точністю до пікселя. Ресурси, які доведеться витрачати на обчислення такої колізії, ми можемо витратити в іншому місці, де це було б доречніше.
Так, створення власного фізичного движка дасть вам більше гнучкості, ніж вже готовий продукт. Однак не забувайте і про те, що цей процес досить скрупульозний, і ви, врешті-решт, можете реалізувати щось більш складним способом, ніж це ж робиться в готовому движку.
Перш ніж розглядати властивості і деталі моделювання фізики, давайте подивимося на те, що відбувається в кожному ігровому кадрі при підході «в лоб»:
Типовий цикл гри для кожного кадру буде проходить чотири кроки в наступному порядку:
Зверніть увагу, що отрисовка кадру відбувається після симуляції фізики. Такий порядок, зрозуміло, не позбавлений сенсу.
Фіксована частота кадрів проти варьируемой
Давайте поговоримо про частоту кадрів: фіксованої (fixed rate) і варьируемой (frame dependent rate). Метод update викликається один раз за кадр ігровий сцени. Якщо ваш метод симуляції фізики викликається з методу update, то ваш фізичний світ буде залежати від частоти кадрів. Це може привести до нереалістичних поведінки фізичних тіл. В iOS цей ефект вирішується за рахунок використання булевского властивості usesPreciseCollisionDetection. Але що щодо інших операційних систем?
Розглянемо уривок коду:
Цей код призначений для компенсації проблем з дельта-значенням часу. Актуально це буде в тому випадку, якщо під час гри вам подзвонили. Тоді ви зможете за допомогою такого алгоритму відновити дельта-значення часу (для гри з 60 FPS).
Це насправді перший крок в понятті роботи фізичного движка. Так, попередній шматочок коду зробить нашу симуляцію більш стабільною, але всіх проблем він не вирішить. Для цього нам знадобиться видалити виклик функції моделювання фізики з циклу рендеринга ігрової сцени, а потім створити фіксований цикл. Протягом цього циклу і буде працювати симуляція фізики. Наприклад, якщо ваша гра розрахована на роботу в 60 кадрів в секунду, то ви встановлюєте частоту моделювання фізики в 60 разів в секунду. Такий поділ обов'язків дозволить нам усунути безліч проблем.
Підсумувавши, хочеться сказати, що якщо вже ви вирішили писати свій фізичний движок - будьте сумлінними і робіть все правильно. На цьому перша частина нашої статті закінчується. У наступній частині ми поговоримо про фізичних тілах і їх властивості, а також згадаємо типові обмеження фізичних движків.