Математическая модель игры

[s8000_1]

Проектирую игру. Ее суть примерно такая:
на игровом поле (вид сверху) присутствуют N машинок. Игрок управляет половиной из них. Его задача протаранить вражеские машинки. Вражеская машинка, управляемая AI, уничтожается только, когда ее таранишь сбоку.
Управление машинкой организовано так - выделяем юнит, тыкаем место на карте, она туда едет. Машинка должна ускоряться до максимальной скорости, а когда подъезжает к месту - плавно тормозить. При резких поворотах на скорости ее должно слегка заносить (движение не по ходу колес, а перпендикулярно).

Столкнулся с проблемой, как все это математически лучше описать и накодить.

Мои мысли примерно такие - характеризовать каждый юнит положением, вектором скорости, собственным радиусом и целью, куда ехать. Цель не обязательный параметр. В каждом enterFrame делаем расчет положений юнитов и рассчитываем столкновения. Столкновения это отдельная тема, больше интересует расчет положений юнитов.

Прикинул алгоритм расчета положения для постоянной скорости:

1) Положение машинки характеризуется множеством {x;y}. Скорость в полярных координатах {V;phi} (V - абсолютное значение, phi - угол по отношению к горизонтали).
2) Предположим, машинка до появления цели стояла на месте. Появилась цель с координатами {targetX;targetY}. Делаем V=V+1, вычисляем угол цели. phi выставляем равной этому углу.
3) В следующем кадре переводим полярные координаты скорости в декартовы {Vx, Vy}, делаем x = x+Vx, y=y+Vy.
4) Повторяем пункт 3, пока машинка не доедет до цели, остановим ее.

2а) Если у машинки до появления цели, уже была скорость, то поворачиваем phi на какой-то градус, и в каждом шаге вычисляем угол до цели, пока углы phi и угол до цели не совпадут.

Теперь основные вопросы.

1) Не будет ли расчет угла до цели в каждом кадре накладным процессом? Перевод полярных в декартовы координаты?
2) Я все описал для постоянной скорости, а как для ускорения/торможения контролировать абсолютное значение скорости? Как узнать, когда пора "тормозить"? Например, машинка движется вправо, а цель строго под ней. Пока она повернет, опишет дугу. Но в какой-то момент движения по дуге, надо будет сбавлять скорость. Как это ненакладно вычислить, я не представляю. Нужно как минимум в каждом кадре высчитывать расстояние до цели, решать уравнение, и вычислять "через сколько" машинка доедет, и не пора ли сбавлять газ.

Для 10 юнитов на карте, это может серьезно все затормозить, или я ошибаюсь?

3) Может быть, это вообще все по-другому делается?

[Tr1te]

1) Не будет.

2) Если реалистичная физика, то как в жизни, человек заранее знает примерную траекторию движения, и перед поворотом начинает тормозить. Тоесть по сути тебе надо описать примерную траекторию. По 3 точкам определяешь определяешь 2 вектора, определяешь между ними угол. При повороте на больше, чем определенный угол, начинаешь тормозить, ведь если угол поворота 5 градусов, то зачем тормозить.

Возможно будет тяжко для компа считать каждый раз траекторию. По этому можно подумать как можно сделать поаркадней.

[Division]

Сколько ни писал, всегда считал все в декартовых координатах, полярные никогда не юзал) Хранил угол движения машинки и скорость[UPD: упс, кажется это взаимоисключающие параграфы (: Ну да ладно в любом случае ИМХО лучше думать векторами]. Вектор движения можно получить как

moveVec = new Vector2(Math.cos(moveAngle)*speed, Math.sin(moveAngle)*speed);

То есть скорость скалярная величина просто.
Направление на цель лучше считать не углом, а нормализованным вектором. Что может сделать машинка? Повернуть с сторону цели направо или налево. Ну или прямо ехать.
Чтоб понять направо поворачивать или налево, что нужно сделать?
Так вот, есть у нас два вектора: dir - куда в данный момент движется машинка(считается так же как moveVec, только без домножения на скорость)
и второй - targetVec - направление на цель.
Если мы их векторно перемножим, то знак компоненты z результата будет указывать на то, влево поворачивать в сторону цели или вправо.
Чтоб получить угол между dir и targetVec, достаточно вспомнить что скалярное произведение нормализованных векторов равно косинусу угла между ними. Так вот если этот угол меньше некоторого заданного значения, машинка пускай едет прямо)
Ну чтоб в бок таранить там надо много подкручивать ИИ методом проб и ошибок.
Для машинок я б вообще порекомендовал или Box2D заюзать или на верлетовой физике сделать. У меня как-то были гоночки на верлете, очень даже ничего вышло.
Удачи!)

PS тормозить или не тормозить - зависит от того как напишешь)

[Хемуль]

2 s8000_1:
Могу порекомендовать книгу "Programming Game AI by Example". Автор - Mat Buckland. К PDF'у прилагаются примеры на Flash. Там вам нужно отыскать раздел про "steering behaviors". Это одна из наиболее понятных для новичка книг по steering behaviors. Я думаю, они больше всего подходят вам.

Либо, если не хочется копаться, посмотрите сюда: http://cheezeworld.com/steering-behaviors-librar/
Тут есть библиотека на AS3 для этого дела. Плюс демо-флешка на странице. Пощёлкайте, посмотрите. Чтобы помочь, подскажу, что вам нужна комбинация двух базовых steering behaviors - Seek + Arrive. От этого и танцуйте.

[VovkaMorkovka1]

2 Хемуль.
Там поиск пути нужен особого рода. Называется метод потенциальных полей, причем интересно, что метод виртуальных отталкивающих клеток не подойдет

[Хемуль]

Сообщение от VovkaMorkovka1

Там поиск пути нужен особого рода.

Где "там"?

[s8000_1]

Спасибо за инфу.

А кто-нибудь flash.geom.Vector3D использовал? Как оно по сравнению с "ручными" классами просчета 2D векторов?