PDA

Просмотр полной версии : Как правильнее организовать класс пули


Black Soviet
12.03.2013, 19:29
Ребят, всем приветы. Нужен стоящий совет.
От нечего делать делаю игру Space Invaders.
29268

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

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

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

samana
12.03.2013, 19:37
Передайте классу пули ссылку на игрока.

caseyryan
12.03.2013, 20:11
Зачем пуле ссылка на игрока? Не надо этого делать.
Сделать отдельный класс, в котором просчитывается и движение игроков и движения пуль. И там же проверять что и куда попало.
Пуля должна знать только свои свойства

И тем более не должен у каждой пули быть слушатель enterFrame. Он должен быть один на все приложение.

iflamberg
12.03.2013, 20:36
Почему бы вам не разобрать готовый туториал? Что-нибудь типа http://asgamer.com/2009/as3-flash-games-for-beginners-scores-huds-and-user-interface . Тогда, уже разобравшись в базовых принципах, будет легче добавить что-то свое, не надо будет придумывать велосипеды.

cleptoman
12.03.2013, 21:08
И тем более не должен у каждой пули быть слушатель enterFrame. Он должен быть один на все приложение.
кто такое сказал?
соглашусь, что экономнее сделать одного "рассылальщика" события..а слушатели то чем помешали ?..контроллер пули вполне себе может чекать колизии с игроком внутри себя, если добавить, скажем границы пересекая которые он начинает это делать, чтоб зря не потреблять ресурсы на весь полет пули

iflamberg
12.03.2013, 21:20
кто такое сказал?
Здравомыслие и логика. Много слушаетелей - много мороки с удалением слушателей. Пуля знает о сцене и объектах с которыми происходит коллизия - морока с удалением ссылкок на эти объекты. И в целом, проблемы производительности.

cleptoman
12.03.2013, 21:36
ну, ессно, полезней будет сунуть все в "глобальный" обработчик и через if решить все свои проблемы производительности.

iflamberg
12.03.2013, 21:46
Ты серьезно считаешь, что всплывающая система событий, которая генерирует кучу лишних объектов Event и все-такое, будет быстрее чем цикл перебирающий массив пуль? И, скажи на милость, где лишние if'ы то?

caseyryan
12.03.2013, 21:56
кто такое сказал?
соглашусь, что экономнее сделать одного "рассылальщика" события..а слушатели то чем помешали ?..контроллер пули вполне себе может чекать колизии с игроком внутри себя, если добавить, скажем границы пересекая которые он начинает это делать, чтоб зря не потреблять ресурсы на весь полет пули
Лёх, ты не прав. Проведи тест с энтерфреймами на куче объектов и сам убедишься.

cleptoman
12.03.2013, 21:57
И, скажи на милость, где лишние if'ы то?
ну, вероятно , там же где и баблинг у ентерфрейма )..думаю, на этом можно закончить

Добавлено через 19 минут
хотя..может тест некорректен, но:
import flash.events.Event;
import flash.display.MovieClip;

var mc:MovieClip;
var i:uint;
var len:uint =10000;
var t:Number;
var arr:Array = [];
var tick:Number;

function destroyMCs():void{
for(i = 0; i < len; i++){
mc = arr[i];
mc.removeEventListener(Event.ENTER_FRAME,mc.onEF);
}
arr.length = 0;
this.removeEventListener(Event.ENTER_FRAME,onEF);
}


function onEF(e:Event):void{
tick++;
if(tick == 100){
trace(getTimer() - t);
destroyMCs();
}
}


function createMCs(withHandler:Boolean = false):void{
tick = 0;
for(i = 0; i< len; i++){
mc = new MovieClip();
if(withHandler){
mc.onEF = function(e:Event):void{};
mc.addEventListener(Event.ENTER_FRAME,mc.onEF);
}
arr[i] = mc
}
this.addEventListener(Event.ENTER_FRAME,onEF);
t = getTimer();
}

//createMCs(); // 4112
//createMCs(true); //4124

Добавлено через 31 минуту
я к чему это все, собсно веду - не там мы тормоза ищем )

iflamberg
12.03.2013, 22:32
А что, нормалный тест. Увеличь кол-во мувиков до 50000.
Уже 4000 против 8000. Ну, по крайней мере на моем компе не первой свежести. Но он все равно побыстрее среднестатистического компа, на котором офисный планктон режется в флешки.

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

Котяра
12.03.2013, 23:32
Вот когда будет у тебя 50000 мувиков, тогда и оптимизируй.

iflamberg
12.03.2013, 23:39
Ну, т.е. ты хочешь сказать, что автор, скажем, TweenLite зря вместо событий использует костыли типа onComplete, onCo mpleteParams?

Котяра
13.03.2013, 01:22
Да. Gtween и eazy вполне хорошо себя и с событиями чувствуют.
а onComplete, onCompleteParams
наследие as2 прошлого.

ChuwY
13.03.2013, 10:06
Ну не обязательно только лишь наследие.
Я, например, (да и многие, думаю) через completeParams в onComplete зачастую передаю параметры для завершения\продолжения цикла анимации, которые могут генериться при его начале.
Впрочем, признаю, что это только ради скорости кодинга, и метод с сохранением в полях будет попрозрачнее\помодифицируемее.

caseyryan
13.03.2013, 14:14
Ну, т.е. ты хочешь сказать, что автор, скажем, TweenLite зря вместо событий использует костыли типа onComplete, onCo mpleteParams?
А с каких пор колбэки у нас называются костылями?
Я часто колбэки юзаю вместо событий, и вполне доволен.

iflamberg
13.03.2013, 14:23
Я, это, забыл слово callback =))))))