начну с того, что вообще я планировал в скриптах хранить только индексы объектов в глобальных списках... потому как я считаю, что так безопаснее. нечего скриптам знать что-то большее, чем индекс объекта! передав этот индекс в движок, он уже разберется, как достать нужный объект!
проблемы, конечно же, начнутся, когда дело обстоит со списками, количество и индексы объектов в которых постоянно меняется. вариантов решения несколько:
проблемы, конечно же, начнутся, когда дело обстоит со списками, количество и индексы объектов в которых постоянно меняется. вариантов решения несколько:
- а) можно заново вычислять индексы объектов после перестраивания списка
- б) можно привязываться не к индексу в списке, а к некоему ID объекта
- в) можно при убийстве объекта не изменять количество ссылок в списке, оставляя на том месте nil. таким образом количество ссылок в списке будет всегда накапливаться.
- г) можно резервировать места для объектов при старте уровня (то есть при старте по некоторым ссылкам в списке будет nil), при необходимости же добавить заведомо известный объект - указывается также индекс, зарезервированный под объект. при удалении этого объекта, надо будет всего лишь убить сам объект, не изменяя количества объектов в списке.
достоинства (д) и недостатки (н) очевидны:
- а) д: скрипты остаются такими же, их программирование прозрачно; н: движок обрастает различными методами типа ReassociateIndexes()... время выполнения которых зависит от кол-ва объектов и индексов
- б) д: скрипты остаются теми же; н: при каждом доступе к объекту по ID, надо бегать по всем элементам списков, что неудобно
- в) д: скрипты остаются такими же; н: количество объектов может вырасти до огромных значений, пробежка для общих методов типа DoUpdate() по тысячам объектов не радует глаз
- г) д: скорость работы не меняется, никаких трудозатратных перестановок, ассоциаций или увеличение количества объектов в списке; н: чуть меняются скрипты, придется выполнять резервирование индексов для будущих объектов, нежелательно создавать объектов больше, чем было зарезервировано при инициализации уровня.
Когда вариант г) я уже начал реализовывать, тогда начал понимать, что я не хочу делать заново всю работу по протаскиванию методов по созданию объектов в скрипт с новым параметром - зарезервированным индексом, куда надо положить вновь созданный объект.
В итоге всех этих попыток я решил перейти от хранения индексов к хранению прямых ссылок... конечно, это многое решает, но теперь надо быть аккуратнее)) с индексами было как-то поспокойнее. зато отпадают различные вопросы по поводу того, "а из какого списка данный индекс?" или "а не сместятся ли индексы при удалении этого объекта?"... в общем, посидел я тут часок и перевел все на ссылочный способ хранения объектов в луа(рад, что в итоге все быстро получилось)))
В итоге всех этих попыток я решил перейти от хранения индексов к хранению прямых ссылок... конечно, это многое решает, но теперь надо быть аккуратнее)) с индексами было как-то поспокойнее. зато отпадают различные вопросы по поводу того, "а из какого списка данный индекс?" или "а не сместятся ли индексы при удалении этого объекта?"... в общем, посидел я тут часок и перевел все на ссылочный способ хранения объектов в луа(рад, что в итоге все быстро получилось)))
0 коммент.:
Отправить комментарий