Организация перемещений персонажей

[Vansimar]

Вот смотрите ,у меня есть класс врага ,допустим Enemy_per, в нем я добавляю слушатель событий ENTER_FRAME и там прописываю код на перемещение персонажа,те постоянное движение,от одного края до другого ,разворачивается и обратно и так все время.. Потом я наследую от него еще класса 4, и добавляю на сцену их, да,персонажи ходят,но это вешает производительность , все тормозит еле двигается, есть ли какая нибудь альтернатива ENTER_FRAM'у чтоб не так вешало..

[Genzo]

1 - Enemy_per , не по принятым стандартам лучше EnemyPer
2 - используйте tweener для таких вещей , есть много реализаций (родную лучше не используйте) поищите информацию на тему TweenerLite ,например.

[Vansimar]

это http://www.greensock.com/tweenlite/ ?

[Inet_PC]

Да он.

[Vansimar]

ну ладно посмотрю)спасибо

Добавлено через 8 минут
а вот допустим у меня главный игрок постоянно перемещается(управление с клавиатуры) а у нему идут противники, у твинера есть метод TweenMax.to(mc, 1, {x:65, y:117}); те он двигает к определенной точке,а персонаж то постоянно ходит,получается чтоб противник постоянно следовал за игроком нужно это опять же в ENTER_FRAME все делать?

[Genzo]

вешайте на завершение анимации персонажа (передвижение) или на начало нового движение события которые будут направлять противников к игроку , вообще это сложная логика все зависит от конкретной реализации - способов много

[stweet]

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

Как правило, если бороться за производительность, то и greensock не поможет. Причина в том что на каждый твин он так же использует по своему таймеру.

выход из вашей ситуации:
не использовать на каждого перса по индивидуальному двигателю!
значит получается: Пишем у каждого перса (и во всей игре целиком - желательно) общие методы к примеру "moveObject();" а в основном классе игры регистрируем таймер и в цикле пробегаем по всем динамическим объектам. К примеру обходим в цикле объекты враги:

private function allMoveObject (e:TimerEvent):void
{
for (var i:int = 0; i < allEnemyNum; i ++)
{
if (allEnemy[i] != kill)
{
// всякие проверки на столкновение и т.п. манипуляции с объектом
allEnemy[i].x ++;
}
}
}

// такой манёвр значительно ускорит приложение и снизит загрузку памяти.


Добавлено через 4 минуты
а персонаж то постоянно ходит,получается чтоб противник постоянно следовал за игроком нужно это опять же в ENTER_FRAME все делать?

так же в приведённом выше примере можно проверять какая клавиша зажата для движения героем, проверять дистанцию от героя до врага и в случае попадания в область видимости, врагу сообщать новое движение по напровлению к герою, ох, столько всего замутить можно =)))

[Vansimar]

те получается каждый шаг времени функция будет проверять какая кнопка зажата, каких игровых объектов двигать, какие сталкиваются,кто умер,и так далее?

[stweet]

ессессеенноо)))

[Genzo]

тогда уже лучше иметь 2 контроллера : персонажа и скопа врагов , а то получается что-то сродни :

while(true) readln

[Vansimar]

У меня вот есть класс для каждого уровня, Level_1,Level_2...Level_n , и так же классы для персонажей и так далее.. получается в конструкторе например класса Level_1 нужно добавить объекты, и там же в конструкторе зарегистрировать таймер ,и в этом классе создать функцию private function allMoveObject (e:TimerEvent):void ?

[stweet]

public function moveAllObject (e:TimerEvent):void
{
var killEnemy:Array = [];

var i:int;

for (i = 0; i < counterEnemy; i ++)
{
// типа проверили дистанцию между врагом и героем
if (needDistancion < maxDistancion)
{
// допустим герой убивает в ближнем бою врага
killEnemy.push(i);
} else {

allEnemy[i].x += vx;
allEnemy[i].y += vy;

// далее можно проверить достиг ли враг
// припятствия и стоит ли ему сменить вектор движения

// ...
}
}

// проверяем есть ли мёртвые враги?
if (killEnemy.length > 0) {

for (i = 0; i < killEnemy.length; i ++)
{
// удаляем объекты из массива врагов.
removeChild(allEnemy[killEnemy[i]]);
allEnemy.splice(killEnemy[i], 1);
}
}

// Двигаем героя.
if (onLeftDown) hero.x --;
if (onRightDown) hero.x ++;

if (onTopDown) hero.y --;
if (onBottomDown) hero.y ++;

// Проверяем путь героя.
if (hero.distancion < warDistancion)
{
// меняем направление гироя или запрещаем идти.
// ...
}

// и так далее ...

// дале ...
detectPositionNext01();

// можно даже продолжать выполнять статические методы из абстрактных классов.
if (globalMethod != null) globalMethod.call();

// Перерисовываем экран после всех манипуляций ...
e.updateAfterEvent();
}



все выше приведенные переменные вымышленные, любое сходство в реальной жизни случайное совпадение! Удачи =)

[Vansimar]

А не будет ли это все тормозить?и какой лучше шаг времени указать?

[Inet_PC]

А не будет ли это все тормозить?
Вот заодно и проверьте. Тем более точно сказать трудно, ибо производительность зависит от многих факторов, и тормоза могут быть в другом участке кода.

[2Sun]

Тормозить скорее всего будут сами мувики персонажей , если не оптимизированы или сделаны вектором.

[stweet]

А не будет ли это все тормозить?и какой лучше шаг времени указать?

1. проц Е5200, оперативы 3.5 г. смело держит до 300 объектов с просчётами на столкновение друг с другом с разрешением рендера 1024х768. Тут правильно подметили, всё зависит от оптимизации кода и формат используемой графики. Плюсом будит если объекты выходящие за рамки рендера станут не активными что тоже снизит потребляемость памяти, т.е. не надейтесь что объекты которых вы не видите на экране но добавленные на стейдж исключены из просчётов, желательно рисовать и просчитывать только то что попадает в видимую область.

2. Всегда выставляю делай на "0", но использую счётчики, это позволяет в случаях перегруза метода оттянут тот или иной просчёт на потом что бы не прерывать операцию таймера.

вывод, делая игры думать надо как "сишник" о памяти, т.е. взял-отдал. И если знать все тонкости машинного кода, то можно огогого как творить))) Помни, машине твоей легче умножить а не разделить!

[Vansimar]

А можно когда добавляю их на сцену прежде делать cacheAsBitmap , это поможет?

[2Sun]

А можно когда добавляю их на сцену прежде делать cacheAsBitmap , это поможет?

Если изначально графика векторная и не будет вращения или маштабирования - то да. В противном случае станет еще хуже. Если у вас при 4 моделях начинает тормозить - это явно проблема в моделях. Расчетная часть, хоть там сто проверок будет стоять не нагрузит так. Копайте с сторону моделей.

[Vansimar]

Вот помоему решение производительности анимации http://blog.touchmypixel.com/2008/04/as3-bitmap-cached-animations/ и еще спросить хотел cacheAsBitmap лучше использовать для фона например и вобще статических картинок?

[Inet_PC]

Вот помоему решение производительности анимации
Я бы так не сказал, простая небольшая (по времени) анимация легко может сожрать 500 метров и больше оперативы, и вот тут тормоза то точно будут.

[Vansimar]

AntKarlov в своем блоге писал что ему эти классы помогли сделать нормальную оптимизацию и избавиться от тормозов,и в самом примере видно что с этими классами фпс == 50; а без у меня примерно фпс ==7.

[2Sun]

Вот помоему решение производительности анимации
Это путь в ниТуда. Лучше расскажите как у вас сделаны модели - как там организована анимация. (Кстати, уберите, если есть все коды из кадров управляющие лупами, перенесите это в контролер). Тогда будет понятно что вам посоветовать. Я использую конвертор, который клипы превращает в виртуальный тайловый битмап на инициализации, а потом плееру его очень легко через copyPixel() рендерить. Реально такая сцена на 200 персонажах размером 100х100пх с одновременной проверкой коллизий держит фпс 50.

Добавлено через 4 минуты
Схема в принципе похожа, только реализация по компактнее. :)

[Vansimar]

Ну я код еще не писал,пока просто обдумываю все,а вот анимация так--

-Контейнер персонажа
-три кадра
-Хотьба
-Состояние покоя
-Умирание

Потом сам мувик так разбирается
- Контейнер для персонажа
- Контейнер для туловища головы и ног
-в нем мувики всех этих частей
- Контейнер для рук с оружием //чтоб можно было менять оружие
-оружие с руками

Добавлено через 30 секунд
а что за конвертер?

[ChuwY]

Вот помоему решение производительности анимации http://blog.touchmypixel.com/2008/04/as3-bitmap-cached-animations/

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

[Vansimar]

а тот класс что я линк кидал не нужно использовать?

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

ну у меня анимация не сложная,так что я наверно этим классом воспользуюсь