|  |
14.11.2011, 17:18
Закончена реализация системы динамической видимости. Шикарная вещь, я вам скажу, получилась. В посте про нее я выложил небольшой лог ее работы. Суть ее в том, что некоторые объекты могут видеть другие, а наоборот - нет. Живой пример - роги, их не видно, но они видят. Благодаря этой системе можно реализовывать различные игровые сценарии, связанные с видимостью объектов. Видимость, разумеется, можно изменять на лету, т.е. увеличив ее - сразу стать видимым для окружающих в некотором радиусе. Или, например, огромные высокорослые мобы должны быть (могут быть) видны издалека. Или например в инсте blackrock depths ворота-мост видны через весь инстанс. Так же решилась проблема с вагонами метро, которые скрываются в подземке будучи видимыми и только потом дестроятся наблюдающим. В общем вырисовывается уже неплохой API управления юнитами.
Но как всегда постоянно возникают новые препятствия на пути к победе :) Собственно проблема возникла в обновлении пассажиров транспорта, когда те передвигаются по нему. Наконец стало понятно, зачем нужны относительные координаты плеера. Они нужны не только для рассылки окружающим, как предполагалось ранее (впрочем это чисто клиентская сторона вопроса и для этого они нужны тоже), а еще и для серверных расчетов, что бы эти обновления выполнить правильно.
Положение модели транспорта в пространстве задано кватернионом, который передается в А9 (те самые PARENT_ROTATION). В частности вагоны в метро располагаются в разном направлении на одной из веток. Грубо говоря два вагона смотрят вперед по ходу движения, третий против движения. Зачем это было сделано остается загадкой, т.к. это повлекло за собой во первых - разные кватернионы в А9, а во вторых - разные дельты в transport_animation.dbc для разных вагонов (точнее разные направления). Единственным объяснением может стать то, что разработчики внедряя эту систему таким образом тестировали правильность ее работы, а после деливери кода все так и осталось, работает же.
Во время движения плеера по транспорту от него приходят абсолютные координаты как обычно, плюс блок относительных координат на транспорте. Главное понять, что не важно как транспорт ориентирован в пространстве, относительные координаты будут всегда в его (транспорта) системе координат. Т.е. если мы бежим с кормы корабля к носу, то будет изменяться относительная координата Y и только она, назависимо от того, как плывет корабль относительно абсолютной системы координат.
Таким образом получаем классическую задачу движения одной системы координат внутри другой. При перемещении одного из пассажиров апдейт системе нужно знать местоположения остальных в абсолютной системе координат для коррекной работы. Здесь у нас две проблемы: первая - транспорт движется, вторая - остальные стоят и соответственно не присылают свои абсолютные координаты.
Задача сводится к нахождению абсолютных координат транспорта, используя абсолютные и относительные координаты перемещающегося плеера. Затем можно вычислить абсолютные координаты других пассажиров, используя вычисленные абсолютные координаты транспорта и зная относительные координаты этих пассажиров. После получения абсолютных координат пассажиров все расчеты с видимостью будут корректными. Они, кстати, должны выполняться по тем же правилам, что и на земле (тесты с оффа, спасибо Energy).
Пока мы не будем реализовывать поворот одной системы координат относительно другой за неимением достаточного опыта, посему эта активность пока отложена на позднее время. Перемещаться на транспорте стало возможным, хоть и с небольшими проблемами - визуально это выглядит как постоянные destroy/create окружающих пассажиров и только в тех случаях, когда один из плееров имеет низкий detect area, например рога в стелсе. В обычном режиме визуализация перемещения плееров нормальная.
В этом спринте мы решили закончить всё остальное по транспортной системе. Из оставшегося - 15ый тип транспорта, который телепортирует с одной карты на другую. Собственно весь вопрос в телепорте и синхронизации движений с одной и с другой карты. Напомню, пока разные карты (WorldServer) работают на одной машине - никаких проблем нет. Кластерная архитектура позволяет запускать разные Миры на разных машинах и у них могут быть разные процессорные времена (TickCount).
Нет комментариев.
|
| |
