Чи слід писати власний двигун фізики через інтеграцію в мережу?

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

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

Моя проблема полягає в тому, що мій поточний двигун фізики JBox2D (в основному порт Box2D) не підтримує відкочування світу, і, мабуть, не так просто серіалізувати світові дані. У мене є 2 рішення, я можу або змінити / розширити свій поточний двигун фізики, або написати своє.

Причини написання мого власного фізичного двигуна -

• Я можу видалити непотрібні функції. У грі зверху вниз мені дуже потрібні лише механіки зіткнення та керованість. Ніякої сили тяжіння не бере участь.
• Я можу зрозуміти код краще, і було б [швидше за все] легше реалізувати функції відкоту

Причини розширення / модифікації JBox2D

• Написання власного двигуна фізики було б значною роботою, яка могла б бути громіздкою
• JBox2D має широку підтримку спільноти, яка може допомогти мені з моїм розробником
• JBox2D має спеціальні оптимізації для таких речей, як виявлення зіткнень, які роблять його корисним
• Деякі роботи, як уже зроблено над цим, але ділилися мало коду

То які ваші думки. Це моя перша гра, і я аж ніяк не професійний розробник ігор. Якщо хтось може надати кілька посилань на роботу, вже виконану в цьому районі (бажано, використовуючи JBox2D / Box2D / Java).

Виявлення зіткнень у 2D настільки проклято, що я не знаю, чому ви б взагалі заважали використовувати двигун фізики. А оскільки всі сили управління прямими вперед або на кривій (без падіння, зміни діагнозів і т. Д.) Особисто мені це не потрібно, щоб вибрати. Зробити своє самостійно просто. Зіткнення:

врахуйте 3 можливі зіткнення, які можуть статися у двох прямокутниках:

1. Край до краю: Досить просто, ви отримуєте вісь одного краю, а іншої, і ви вирішуєте, займають вони або той самий простір, або досить близько до нього.
2. Край до кута: це легко стане найпоширенішим, якщо у вас обертові форми. На щастя, це також досить просто здійснити.
3. Куточок до кута: це трапляється так рідко, що навіть не варто їх застосовувати. Причиною цього є те, що дві речі повинні рухатися в абсолютно протилежних напрямках на тій самій точній осі вниз до останніх обчислених вами двигунів. Тепер, якщо все обертається на 45 або 90 градусів, це МОЖЕ (навіть все ще, мабуть, не варто) включати

EDIT: Як коментується, я набагато менш знайомий з цією справою, і не слід консультуватися з приводу зіткнення кулі / снаряду.

Коли я працював з кулями в двовимірному просторі, я використав своєрідний шлях, який працював як по прямій, так і в кривій частині, де я б кинув снаряд за допомогою двигуна фізики (що я не робив з нуля) і використовував стандартне зіткнення.

Про будівництво цього з нуля читайте в коментарях.

Редагувати: * Повірте мені, * незалежно від того, вам знадобиться якась форма мертвих рахунків у вашому ігровому двигуні, через снаряди та скільки снарядів може бути на екрані в будь-який момент часу. Ви АБСОЛЮТНО не хочете оновлювати кожну кулю на екрані за кадром у вказаному місці. Але це прекрасний спосіб зробити гру незвично повільною: D! Вам слід коли-небудь оновлювати ці речі:

• Кидається снаряд
• Напрямок, в який його кидають
• Зігнутий він чи ні
  • І якщо так, то яка функція кривої
• Що це снаряд (це пояснює графіку, ефекти, пошкодження, все)

Тепер оновіть дані в двигуні відповідно до цих даних, а не на сервері для кожного проклятого снаряда і надсилайте пакетні дані для кожної кулі. (Уявіть, що ви робите це навіть із 2-х кулеметів на екрані! Ісусе!)