Diаmond: Все сообщения за 16 Июля 2007 года

Насколько я помню, в вашем движке видимости весь мир поделен на горизонтальные полоски (если смотреть на карту сверху), для того чтобы избежать перебора всех обьектов в мире, при определении видимых обьектов. Вместо перебора всех обьектов в мире - перебирается несколько соседних полосок, ближайших к чару, и все обьекты внутри. LinearCellSize это ширина этих полосок, и от нее зависит расход памяти, скорость перебора, и погрешность при определении видимости.

Недостатки:
- сложности с переключением AI между активным и пассивным режимом, вплоть до того, что пришлось писать LightAI
- низкая скорость работы
- ненадежен, неудобен, постоянно давал сбои
Преимущества:
- высокая точность

В моем варианте - мир поделен на регионы (параллилепипеды), и перебираются соседние.

Недостатки:
- неточен, дает погрешность величиной в ширину региона. Если взять за размер региона 4000, то обьект виден, если он находится на расстоянии от 4000 до 8000. Но это не заметно игроку, и в принципе ничем не плохо. Кроме того, в случае необходимости, можно задействовать дополнительно проверку расстояния.

Преимущества:
- AI переключаются при включении/отключении региона, что не требует никаких дополнительных механизмов внутри самого AI. Т.е. вся эта путаница и тонна лишнего кода - просто ненужны В результате намного выше скорость работы, нет этих бесконечных глюков с зависшими мобами.
- скорость в несколько раз выше, проверено на практике. Даже при использовании обычных списков. Если же заюзать имитацию динамических массивов, как было сделано в первом варианте - скорость еще в несколько раз возрастет.
- очень надежен, и удобен, имеет кучу возможностей. Например с его помощью легко состряпал фэйкового чара для обсервинга, написав буквально пару строчек.

Расход памяти в обоих вариантах одинаков

•  инфо
•  инструменты
• Ответить на сообщение

Balancer> Гы. Вариант с квадратами (8000x8000) - это самый первоначальный (и сейчас используемый ими) вариант от SF. Отличается высокой ресурсоёмкостью при большой плотности объектов
Balancer> Собственно, вариант с "полосками" был введён из-за высокой нагрузки на сервер при осаде. На "полосках" же (в исходном варианте, сейчас - не знаю, там дофига некоторыми переписывалось) заметной нагрузки не возникало даже при 5000 активных объектов в одной области видимости. Клиент уже не справлялся с обработкой такого количества объектов, а на сервере загрузка была очень далека от 100%
Интересно, почему тогда твой двиг жрет в 5 раз больше ресурсов? И жрал так всегда, с момента его появления, уж я то помню.
Проблема двига SF была не в типе двига видимости, а в криворукости программистов, его написавших. Мой двиг сейчас не жрет вообще почти ничего, при любом возможном числе обьектов. Насчет 5000 незнаю, таких ситуаций на сервере не возникало и никогда не возникнет.

PS: или хочешь провести сравнительные тесты? Давай, я только за.

•  1
•  инфо
•  инструменты
• Ответить на сообщение

Drac> А я бы посмотрел что и у кого лучше работает. Тогда можно и будет выявить реально лучшего.
Только в нашем случае придется обфускатор заюзать
Или поднять сервер удаленно, например у абаддона

•  1
•  инфо
•  инструменты
• Ответить на сообщение