HaGe, так вот мы и не отрицаем, что можно. Мы просто говорим, что если комнат очень много, то проще расставлять такие объекты, а не заносить переменные в массив. Оба способа хороши и имеют право быть, дело лишь в том, что один саааааамую малость проще, а другой сааааааамую малость менее памятозатратный (...вот это слово вышло...).
HaGe, я думаю, все этим грешили/грешат (как в моём случае). Как никак, а для понимания это легче. Да и память это не так нагружает (хотя понятно, что там чуть-чуть нагрузил, здесь чуть-чуть нагрузил и всё лагает). В данном случае расстановка этих самых объектов гораздо легче и удобнее, ведь прописывать пачку координат каждой комнате довольно... эм... долго?..
Дофигища ошибок! Правда, еще на стадии прописывания перемещения персонажа я подумал "А как он будет делать передвижение по льду, если перемещение он делает через изменение координат?" Напомню, что hspeed в таком случае будет оставаться нулевым.
Также, прописывая place_meeting, надо указывать не просто х+1, а х+[число, на которое изменяется координата] или просто х+hspeed. (как у вас с гравитацией и vspeed сделано)
HaGe, Просто я не люблю через изменение координат делать. Только скорости! Через координаты, как по мне, можно делать лишь движение по графику. А, кстати, в своём коде забыл ещё кое-что учесть, сейчас подправлю...
Ну, способов много, надо учитывать множество других действий. Если это платформер, то управление должно быть совершенно другое (как уже было сказано - на стрелочках/WASD). Если под платформером вы имели в виду обычную бродилку, де не надо прыгать, то всё можно сделать по тому же принципу, что и в курсор в стратегиях:
(((Сразу предупрежу, что я работаю в ГМС, потому, если вы используете иную версию, код может не подойти))) 1)Создаём объект goto_cursor 2)В Global Left Pressed у ПЕРСОНАЖА пишем
Код
with(goto_cursor) instance_destroy() //Удаляется курсор, к которому должен направлять персонаж instance_create(mouse_x,mouse_y,goto_cursor //Создаёт объект-курсор, к которому должен двигаться персонаж
3)В Step персонажу пишем
Код
if instance_number(goto_cursor)>0 { if x<goto_cursor.x hspeed=4 if x>goto_cursor.x hspeed=-4 if distance_to_object(goto_cursor)<=hspeed { hspeed=0 } if hspeed=0 with(goto_cursor) instance_destroy() }
Замечу, что сам пока этот код не испытывал. А, ну и ещё момент - тут только передвижение по Х, так что он действительно не подойдёт, если надо будет прыгать/лазать по лестницам.
Сообщение отредактировал Overdrave - Среда, 11 Июня 2014, 11:15
randomize() i = irandom(4) audio_play_sound(track[i],1,0) last_track = i
timing=0
В Step
Код
randomize() timing+=1 if timing/room_speed>=audio_sound_length(track[i]) //Можно сделать задержку, если приписать к левой части равенства, например +2 (задержка в 2 секунды) { i = irandom(4) if(last_track = i){ i = irandom(4) }else{ timing=0 audio_play_sound(track[i],1,0) last_track = i } }
Быть может, есть другой объект, который меняет это значение? У меня была подобная проблема, но потом я вспомнил, что присваивал эту переменную через Creation code комнаты. Ну, а если это не помогло, то вот парочка советов: 1)ini_open('saves_set.ini') - строчка не только пытается считать, но и самостоятельно создаёт ini-файл (если его нет). Заморачиваться с этим не надо 2)global.music=ini_read_real('section','keymus',[то, какое значение примет переменная, если такого раздела в ини-файле не найдёт (например, при его создании)]) 3)ini_close() - не забывайте закрывать ini-файл. Просто так, для надёжности. 4)Надеюсь, считывание данных идёт до проверки. 5)Если что, объекты обрабатываются в порядке слева на право и сверху вниз. Это значит, что объект, который проводит считывание должен находиться левее и выше объекта, проводящего проверку и запуск музыки. 6)ini_write_real('section','keymus',global.music) - надеюсь, у вас верно написана запись?
"Read-only" означает, что эту переменную нельзя менять принудительно, она "только для чтения".
А вообще, могу предложить систему управления, выдернутую из моего скролл-шутера (если она тебе подойдёт).
Суть всей системы - приравнивание hspeed и vspeed нужного нам объекта (в моём случае - самолёта), пусть он будет называться Player, к переменной hmove и vmove специального объекта obj_touch, который появляется и исчезает при нажатии левой кнопки мыши. x и y объекта obj_touch приравниваются к координатам мыши (mouse_x и mouse_y). hmove и vmove вычисляется в Step'е как
Код
hmove=x-xprevious vmove=y-yprevious
Таким образом можно уже внутри Step'а Player'а проводить проверки столкновения по типу "if place_meeting(x+hspeed,y,solid_parent)"
Такого босса я делал 1 день. 98% работы - это разработка лазера и поведение ракет. Оставшиеся 2% - "хождение" главной части босса влево-вправо. В нужном тебе боссе может не быть лазеров и ракет. Тебе скинуть, как надо запрограммировать хождение влево-вправо?..
В итоге ничего не получилось, поэтому я добавил игроку событие Draw и вбил ему всего лишь "Draw_self()". Когда я запустил игру и нажал на паузу, появилось не только окно паузы и тайтлы, но отрисовался спрайт игрока! Я на радостях добавил событие Draw каждому из сотни своих объектов, вставляя "Draw_self()". Знаете, какая злость меня взяла, когда после всего этого НИЧЕГО не изменилось? Отрисовывался один лишь спрайт паузы, тайтлы и игрок... А ведь в нём не было, по-моему ничего особенного. Следующим этапом я решил проверить, вдруг дело в количестве операций отрисовки, поэтому я создал ещё один объект игрока. Оба отрисовывались прекрасно. Расскажите мне, дураку, почему не отрисовываются другие объекты?
Пауза в моей игре выглядит так: Игрок нажимает на шифт и все объекты в комнате зависают, посередине появляется полупрозрачная менюшка с надписью "пауза". Стрелочками игрок может выбрать нужный ему пункт меню. После давнешнего обновления команда, отвечающая за "фриз" объектов была заменена (всё было построено на deactivate'ах и create_sprite_from_screen'ах) на create_sprite_from_surface. Сурвейсы уже давно не могу освоить, поэтому очень прошу вашей помощи.
Ну, не надо так расстраиваться, что тебя посылали в яндекс искать, но ты правда тогда задал не конкретный вопрос. Я же свой вопрос построил, по-моему, весьма доходчиво, поэтому жду столь же ясного ответа.
Захотел сделать свою систему с блэкджеком и недо-тенями, но. увы, без помощи я не обойдусь... Вся система основана на проверке расстояния до родительского объекта Light_par, считывания его переменной look_stat (чем больше переменная - тем дальше от радиус видимости) и изменении спрайта (мобы работают аналогично, только меняют свою переменную "visible"). Персонаж стоит, ходит, свет есть, мобы отображаются, всё, кажется, прекрасно, но тут мною добавляется ещё один объект, свет от факела (спрайт для которого ещё не нарисован |D)... Так как объект пола берёт переменную look_stat непосредственно от Light_par, то он считывает этот параметр у ПЕРВОГО объекта с родителем Light_par. ПРИМЕР: Факел должен освещать блоки в радиусе 70-ти пикселей, а персонаж - 130. Параметр look_stat факела: 0,7, а у персонажа - 1,3. Блок-пол считывает переменную ФАКЕЛА, т.е. все источники света теперь будут освещать одинаково - на 70 пикселей.
Я попробовал использовать переменную a, считывающюю id ближайшего объекта, и пока объекты вдалеке друг от друга, всё в порядке, но когда подходят друг к другу...
Кстати, код Draw объекта пола:
Код
if instance_number(Player)>0 { if distance_to_object(a)<a.look_stat*100 and !collision_line(x,y,Light_Player.x+16,Light_Player.y+32,solid_parent,0,0) draw_sprite_ext(sprite9_snow_bricks_light,image_index,x,y,1,1,direction,c_white,1) else draw_sprite_ext(sprite8_snow_bricks_back,image_index,x,y,1,1,direction,c_white,1) } else draw_sprite_ext(sprite8_snow_bricks_back,image_index,x,y,1,1,direction,c_white,1)
Итак, как это исправить? Или же моя система настолько шлаковая, что её лучше заменить сразу?
Сообщение отредактировал Overdrave - Пятница, 27 Сентября 2013, 14:43
