Вариант редактора уровней с использованием Flash IDE и экспортом в XML

Для примера нам понадобится любой объект, пусть это будет балка. Создадим для нее компонент и парочку параметров:




Для получения всех параметров нашего компонента на слое physics в виде xml напишем небольшой JSFL скрипт, скрипт достаточно прост но я на всякий случай снабдил его небольшими пояснениями:


var doc = fl.getDocumentDOM();//текущий документ
var selection = doc.selection;//получаем текущее выделение
var layout = <level />;//создаем родительскую ноду
var elementsNum = selection.length;//счетчик вложенных элементов

for(var i = 0 ; i < elementsNum ; i++){
        
        //если объект на слое physics
        if(selection[i].layer.name == "physics")
        {

                layout.appendChild(<phys_object />);//создаем для него ноду

                layout.phys_object[i].@type = selection[i].layer.name; 
                
                if(selection[i].parameters) {
                        var j = 0;
                        var p = null;
                        while(j < selection[i].parameters.length && !p) {
                                if(selection[i].parameters[j].name == "name") {
                                        layout.phys_object[i].@name  = selection[i].parameters[j].value;
                                }
                                else if(selection[i].parameters[j].name == "density") {
                                        layout.phys_object[i].@density  = selection[i].parameters[j].value;
                                }
                                else if(selection[i].parameters[j].name == "elasticity") {
                                        layout.phys_object[i].@elasticity  = selection[i].parameters[j].value;
                                }
                                j++;
                        }

                }
                
                layout.phys_object[i].@x = selection[i].x;
                layout.phys_object[i].@y = selection[i].y;
                
                layout.phys_object[i].@rotation = Math.round(selection[i].rotation);

                //получаем реальную длину и ширину объекта с учетом его поворота
                var r = selection[i].rotation * Math.PI/180;
                var c = Math.abs( Math.cos( r ) );
                var s = Math.abs( Math.sin( r ) );
                var denominator = (c*c - s*s); 
                var w = (selection[i].width * c - selection[i].height * s) / denominator;
                var h = (selection[i].height * c - selection[i].width * s) / denominator;
                
                layout.phys_object[i].@width = Math.round(w);
                layout.phys_object[i].@height = Math.round(h);
        }
}

fl.trace(layout);//выводим xml в трейс

И в результате получаем:
<level>
  <phys_object type="physics" name="balk01" density="1" elasticity="0" x="136.6" y="53.05" rotation="179" width="122" height="39"/>
</level>


Ну а потом уже можно подцеплять результат в виде xml и парсить получившийся уровень в движок.
  • +7

Комментарии (23)

0
Если игра только для флеша, то можно все уровни хранить в клипах и потом также парсить их. И не нужно заморачиватся с xml.
0
Я для флэша именно так и делал, парсил прямо клипы. Но возможно захочется отдать игру стороннему левелдизайнеру)
0
А почему не указан класс спрайта, который используется для данного физ. обьекта?
0
Это просто небольшой пример, можно указать и класс спайта если так удобнее для создания объектов, почему бы и нет.
0
В каком смысле «если так удобно»? А как по другому?
Я например не пойму, вот мы парсим теги и встречаем тег <phys_object>, создаем физ. обьект, но откуда мы знаем, какой спрайт прицепить к нему? Или анализировать имя на вхождение в него ключевых слов типа: balk, box и т.д.?
0
Потому что не всегда на месте физ объекта нужен некий спрайт. Особенно если ты делаешь зону коллизий.
0
блин, точно, не подумал про это :)
0
ой, ай…

В таком случае лучше строить по набору точек, а не прямоугольниками. Скорее всего просто не обращаете внимание на то как тела ведут себя на таких стыках, когда это два разных шейпа.
0
Нормально они себя ведут на стыках. Таким методом сделаны тысячи игр с физикой.
А строить по точкам — только нажить себе геморрой на будущее потратив кучу времени. И начнутся проблемы с производительностью, когда нужно будет отключать тела не входящие в камеру и когда эти фигуры будут разбиваться на слишком много полигонов.
0
Окей делайте как вам удобно :) Так сделано много игр только потому что так делать проще с первого взгляда. Где больше проблем с производительностью в куче тел и шейпов или в 1 теле с более сложным шейпом? А то что в таком построение больше проблем я уверен. Пример — нейп, игра с машинками, ваш вариант построения ландшафта будет самый глючный, на таких стыках машинку будет подкидывать и проваливаться в середину она будет гораздо чаще чем при несколько больших шейпов по точкам.
0
Да хоть сто тел против одной фигуры. Всё равно всё разобьется на треугольники и будет обрабатываться. Еще раз пишу: большие шейпы не удобны в отключении. Скинь хоть одну игру где машинку подкидывает и она проваливается на середину:) Вон Mining Truck вроде по такой же схеме сделана, и всё норм, ничего не проваливается и не прыгает.
Главное нормально расставлять прямоугольники и помех почти не будет. (то что выше, я просто набросал за минуту)
0
А зачем такому ландшафту прямоугольники? Можно же треугольниками обойтись
0
В Mining Truck это не сильно заметно из-за криволинейности ланшафта, плюс амортизаторы компенсируют.
А вот в зомботроне уже приходилось кружочками стыковать:


Всё равно всё разобьется на треугольники и будет обрабатываться
Не совсем верно, обычно для коллижена используется GJK,V-Clip и прочие алгоритмы, которые работают с выпуклыми многоугольники. Невыпуклые, разумеется, предварительно разбиваются на несколько выпуклых, и в частном случае могут получится треугольники, конечно.
0
*ландшафта
*многоугольниками
0
Кружки видимо чтобы не забуксовать и сгладить движение. Ведь персонаж = прямоугольник+круг с маленькой скоростью. Я тоже хотел добавить кругов, но статья как бы не об этом.

Кстати вот и пример. Зомботрон тоже сделан из кучи тел, на ноуте подтормаживает. Представьте тормоза которые будут при монолитных фигурах физики.
+2
Нет тормозов на монолитных фигурах. Вся статика (красная) по контуру уровня, сделана всего 2 разными шейпами. Зеленый прямоугольник это 640х480, представляете какого размера монолитные фигуры? Если что и подглючивает то явно не эти тела.
+1
В простеньких физ пазлах и платформерах особых проблем нет. Не считая что создается больше шейпов и тел. Но в гонках мы достаточно сильно ощутили разницу. Пробовали много разных способов построения дороги. Вариант 1 примерно то что у вас, много прямоугольников, но в то же время они не налаживаются один на другой (если бы налаживались на стыках было еще больше проблем). Вариант 2 с большими шейпами, машинки ведут себя стабильней. Проблем с большими шейпами не наблюдается, в то же время никто не мешает строит больше шейпов но размером поменьше. Используем Nape.
+1
Кружки, чтобы тело самопроизвольно не прыгало на стыках, о чем FlashRush говорил выше.



Вот небольшое обсуждение.
0
Да, именно такая проблема была. ССD — помогает не провалится в шейп, но используем его лишь в воздухе для правильного приземления автомобиля, после некоторого времени отключаем.
0
FlashRush, извини, но у меня твоя игра на ноуте рывками идет. Ноут не старый. Уж не знаю что там должно грузить, но у вас ни врагов, ни всяких соединений, разлетающихся объектов нету (по крайней мере я играл первые 2 уровня).
Claymore, ты сейчас издеваешься?:) Кто ж будет делать такие физ тела по 5px и гонять на такой скорости?
Я не спорю, что проблемы есть. Но попробуй построить в нэйпе прямоугольники хотя бы по 50-100px шириной и прокатиться по ним со скоростью обычного персонажа. На глаз даже и не заметишь этих скачков. А уж как утверждал FlashRush, что еще и проваливаться на середину, так этого вообще нету.

И вообще давайте закроем эту тему, т.к. изначально я объяснял человеку «Почему не нужно на каждый физ объект отдельный спрайт».
0
ReMind, глючит из за больших битмап тайлера, не разбитых на области, которые еле влазят в допустимые размеры битмапок для 10 плеера, есть косяки (( К сожалению увеличение размера блока 50-100 практически не даст результата, будет точно так же. К примеру мы увеличиваем физ мир в раза 3 по отношению к графическому отображению. А проваливается при приземление автомобиля, падение с большой высоты. Тут основная проблема много стыков разных шейпов разных тел. Согласен, пора завязывать:) Ты все правильно сказал про «отдельные спрайты».
0
Там игра наподобие Bumpy Road, Solipskier, это видео из обсуждения по ссылке. Но описанные проблемы все-таки имеют место быть, в боксе для их решения ввели ломанные поверхности b2EdgeChain, но во флешевой версии они как-то криво портированы. В общем, проблема обозначена, кому нужно, те сделают выводы.
0
По name=«balk01» цеплять соответствующий спрайт например)
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.