Это копия, сохраненная 11 ноября 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Обсуждаем, обмениваемся опытом, задаем вопросы.
Относительно недавно вышла вторая версия: GameMaker Studio 2, пиратки которой еще нет.
Стало НАМНОГО удобнее работать с тайлами, слои тоже помогают.
Так-то 1.4 может все то же, что и двойка, поэтому если жалко бабла, можно писать на старой версии. Но двойку будут развивать и она будет становиться только лучше.
Двойка - недоделанная параша. Лагающая, забагованная и неудобная.
А 1.4 я купил с кучей индюшатины на хамбл бандле за 15 бачей и не жалею.
> Лагающая
Обнови пеку для учебы
>забагованная
Список багов в студию
>неудобная
Хз. я после 1.4 просто кайфую от скорости своей работы.
>Обнови пеку для учебы
У меня на десятилетнем ПК летает.
>Список багов в студию
А вот один баг я лично отрепортил. Функция keyboard_key_press в step event при 60 fps вызывала утечку памяти, крашила игру через некоторое время и не позволяла запуститься дебагеру - крашила его сходу. Понять в чём причина было очень тяжело.
>Хз. я после 1.4 просто кайфую от скорости своей работы.
Я периодически открываю 1.4 для туториалов. 2 намного удобней. Но воркспейсы всё равно недобработаны. Должно быть как-то по другому. То что есть - годится только для драг-н-дроп даунов.
Так что шлём этого >>439595 нахуй уже вдвоём.
Чем тебе конкретно воркспейсы не угодили? Мне больше нравится, нежели каша из окон в 1.4
В основном тем, что из-за боковых окон на воркспейсе места мало. Соответственно и окошки очень маленькие. Постоянно возникает горизонтальная полоса прокрутки. Чтобы нажать на неё нужно либо вырубать нижнюю панель (которая всё равно влезает назад после каждого запуска игры) либо таскать окно. И боковая панель всё время вылезает, если у тебя где-то в таба комната открыта.
Ну и без правой панели всё равно не обойтись, ибо навигироваться по воркспейсу невозможно. С выкрученным зумом невозможно разобрать, что там в окошках. При основном масштабе нужно тянуть несколько экранов, чтобы найти нужный обхект с открытыми ивентами.
Даже на домашнем 40ка дюймовом монике постоянно такая проблема. На мелком рабочем мониторе - просто невозможно пользоваться.
Такие дела.
Странно, у меня 24 дюйма моник и мне нормально. Причем кода у меня достаточно и прыгаю по объектам бывает часто. Короче, мне зашло больше, чем в 1.4
Зачем обсуждать гамак здесь? Если есть какие-то вопросы - на них ответят на форуме yoyo.
Если просто потрындеть - нас здесь полтора игродела.
Разве что перекличку провести.
Да пусть будет, жалко что ли.
http://gms.yoyogames.com/ReleaseNotes.html
О, круто! Новый дебагер - это то, что мне нужно, т.к. я сегодня взялся ещё раз переделать систему пасфадинга и перемещения своих квадратов.
Ага, круто. Ну и где блеать теперь узнать значения переменных?
Пока не так много отличий на самом деле кроме удобства. А так я бы не стал переносить старый большой проект в двойку потому что импорт насоздает кучу скриптов совместимости. Нахуй надо.
Допустим у меня есть две комнаты room_01 и room_02
В create event первой комнаты записано: shadow_level = 0
В create event второй: shadow_level = 1
Как объекту фонарик, находящемуся внутри комнаты добраться до этих значений?
Если я пишу фонарику в create event:
shadow_level = room.shadow_level - нихера не работает
если я пишу
shadow_level = room_01.shadow_level - получаю 1, как и положено. Но мне нужен shadow_level не строго заданной комнаты, а текущей!
Я спрашиваю не про пути обхода, а про способ получения доступа к переменным текущей комнаты.
их нет
Теперь можно посмотреть значения переменных прямо в окне с кодом, можно залезть внутрь ds структуры. Можно менять значения переменных во время дебаганья.
Круто.
Почему не использовать код инициализации комнаты для инициализиции комнаты при переходе из комнаты в комнату?
Пока что я остановился на том, что пишу там
with obj_game {}
и задаю все нужные параметры.
Это лучше, что иметь в obj_game begin_step_event, следящий за сменой комнаты.
>room_start и room_end эвенты
Опа нихуя. Я о них даже и не знал.
Сначала идут create ивенты объектов, потом create event комнаты, потом начинаются begin_step ивенты.
А когда выполняется ивент room_start?
Ладно, ты ж не гугл. Можешь не отвечать.
https://files.64digits.com/tahnok100/Order_Of_Events_In_Game_Maker_Rev.1_Tahnok100_.pdf
Ну это для гм6.1 актуально, в гмс:2 может быть по-другому.
Как правильно ограничить вид чтобы он не выходит за пределы комнаты? Чтобы он как влитой останавливался у края комнаты а не резко "пружинил"
Единственное серьезное слабое место в 1.4 это редактор комнат. Ну и редактор кода можно подтянуть. Остальное можно вообще выпилить, только мешает. По мне так гамаку гуй вообще не нужен, особенно гуй объектов.
у тебя сначала идет clamp, а потом движение камеры
clamp должен быть в конце после всего кода
Спасибо, помогло!
Сполдинг норм, я с него и начинал. Но все его туториалы максимум поверхностные, для самых ньюфагов. Уже давно не интересно.
Но у меня уже появились идеи, почему у меня интерфейс колбасится при движении. Буду пробовать.
Любой формы, которая описывается мат. формулой очень легко.
Ознакомься:
https://forum.yoyogames.com/index.php?threads/on-slopes-and-grids-subpixel-perfect-topdown-movement-and-collision-line-without-objects.4073/
И дальше модифицируешь под свои нужды - объекты разного размера, тайлы разной формы.
У меня проще система. Объект коллизий, который я просто поверх тайлов стретчу.
Там, где у него получился нормальный экран с выставленным размером у меня получилось пикрелейтед. Что это за нахуй?
global.camera = camera_create();
var view_matrix = matrix_build_lookat(x,y,-10,x,y,0,0,1,0);
//var projection_matrix = matrix_build_projection_ortho(1280,768,1,10000);
var projection_matrix = matrix_build_projection_ortho(1920,1080,0,10000);
camera_set_view_mat(global.camera,view_matrix);
camera_set_proj_mat(global.camera,projection_matrix);
view_camera[0] = global.camera;
Ну и ешё спалдинг забыл views включить. Без этих строк просто чёрный экран:
//Enable the use of views
view_enabled = true;
//Make view 0 visible
view_set_visible(0,true);
Где в комнате поставил, такие и значения.
У него походу viewport через интерфейс настроен.
Добавил:
view_hport[0]= 1080;
view_wport[0] = 1920;
//Enable the use of views
view_enabled = true;
//Make view 0 visible
view_set_visible(0,true);
window_set_rectangle((display_get_width() - view_wport[0])0.5,(display_get_height() - view_hport[0])0.5,view_wport[0], view_hport[0]);
surface_resize(application_surface,view_wport[0],view_hport[0]);
заработало.
Хоспади, вчера за 2 часа, сидя с температурой 38 градусов, не имея никаких знаний, кроме кривого гайда, я сделал камеру лучше, чем у этих уёбков из One dog story.
Да, у меня бомбит от них.
Небось они по тому же гайду от Сполдинга и делали. У него так же тошнотворно кобасит камеру после остановки движения (но не так сильно, как в собаке, у них делитель скорости выше)
На ютубе примеры что я нашел рисовали окошки с помощью draw_rectangle или вообще draw_line, что мне не очень подхожит. Нужно чтобы окно создавалось именно из кусков спрайта.
Если по английски понимаешь, то рекомендую оффициальный мануал читать. Он у них лучше любого учебника написан. Я такое редко встречал, обычно мануалы больше для продвинутой аудитории подходят.
Ну во многих играх окно ui рисуется ж собираясь по кусочкам из спрайта а не с помощью функций движка..
Теоретически ты можешь на GUI слой пилить свои элементы и они будут скейлиться вместе с размером GUI и не надо будет нарезать.
Бери пикчу рамки (допустим, 9696), руби на мелкие(типа 3232), делай функцию, которая будет рисовать тебе рамки любого размера по кусочкам из твоего стрипа. На пикче чёрно-жёлтое говно - твоя рамка, красные перпендикулярные и прозрачные штуки - линии разреза.
Так и сделал. Спасибо за совет.
Требуется сделать прототип игры на Game Maker Studio 2. Ничего сверхъестественного - список фич, которые требуется реализовать скину. В основном это ходьба, менюшки и т.д. Ничего сложного.
Контакты -
Работа оплачивается
А по-моему это шин и суть /gd/
Рад за тебя, пили годноту.
Вот только на десктоп пилить никакого интереса нет.. по крайней мере у меня. А мобильные и хтмл5 модули стоят дорого.... очень дорого даже учитывая региональные цены в стиме. Учитывая что под боком юнити который во всем лучше.
Купи двойку
В гамаке недостаточно просто уничтожить data structure (например ds_grid) функцией ds_grid_destroy(name)
Необходимо также очистить указатель на неё
name = noone;
Иначе если какой-либо ещё объект создаст новую data structure, твоя переменная name может снова стать указателем на data structure, только уже другого объекта.
Этот долбаный баг преследовал меня месяц. Наконец я понял в чём дело. Может ещё кому-то пригодится.
>Сделали бы гм фрейморком и все настройки проекта в json.
В 1.4 так всё и есть, только проект хранится в xml.
Скачай сторонний редактор (их два, один хреновый, а второй тормозной и платный), или напиши свой.
В 2.0 вроде тоже хранится в xml, но формат другой.
К началу приходи, там все напишут.
Из всех 2д движков гамак наверн самый простой в освоении.
Главное не лениться и освоить его внутренний скриптовый язык, а не костылить конструктором.
Туториалов дохуя.
Ничем. Более того ты сможешь и на офф. сайте скачать не стимовскую.
А у них там детально расписано? Можно при помощи этого гайда узнать, как, например, создать систему инвентаря в игре?
Извиняюсь, если слишком много лишних вопросов.
Спасибо, посмотрю.
Создание инвентаря - это общий алгоритм. Зная как создавать инвентарь в целом ты сможешь это реализовать на любом движке.
783,145/|
/ |
/ |
/ |
/ |
/ ______|783,159
769,159
Для провеки коллизии с треугольником в точках 769,159 и 783,159 используем функцию point_in_triangle
point_in_triangle(769,159,783,145,783,159,769,159) - результат true
point_in_triangle(783,159,783,145,783,159,769,159) - результат false
Охуеть не встать. Нахуя вообще такие функции нужны?
Спрошу еще и тут, может знает кто.
Как масштабировать в гейммейкере в целое число раз в полноэкранном режиме. Если разрешение экрана не делится на цело на заданное то нужно, увеличить рабочую область максимально насколько возможно, а вокруг оставить черную рамку.
В любой ситуации с пропорциями экрана юзай виды. В твоём случае можно просто создать и увеличивать вид в целое число раз, пока он не будет по ширине или высоте больше самого экрана.
Виды не помогают. Если я в оконном режиме задам view_wport и view_hport, то да, гамак установит соответствующие размеры и у окна. Но в полноэкранном режиме он растягивает все на весь экран, а я могу только выбирать, сохранять пропорции или нет.
Я ковырялся с этим, ничего не получилось, и я забил. У игры разрешение 640x360, что идеально масштабируется на популярное разрешение 1080p, а для остальных добавлю возможность поиграть в окошке.
куда уж конкретнее. Хочу в экран настроек игры кроме локализации, которую уже запилил, ползунки громкости звука, а если быть еще конкретнее, то музыки игровой. В готовой решении могу сделать три ползунка: мастер, музыка, эффекты, и убрать два последних, но мне по сути нужен только второй, а из-за чудесного кода плугина это сделать не получится. Либо мириться и оставлять два ползунка, либо что-то еще придумать
https://forum.yoyogames.com/index.php?threads/how-to-properly-scale-your-game.995/
Я примерно так делаю.
Скопипастил тебе код из своего проекта.
https://pastebin.com/LfBif95f
Возможно, не оптимальный - несколько раз перекраивал, но работает и я не трогаю.
>>456125
Способ "в лоб" - юзать audio_sound_gain() для каждого звука с коэффициентом, устанавливаемым в настройках. Че-то типа:
bgm_sound_inst = audio_play_sound(bgm_level_1, 0, true)
audio_sound_gain(bgm_sound_inst, global.master_volume global.bgm_volume, 0)
sfx_jump_inst = audio_play_sound(sfx_jump, 0, false)
audio_sound_gain(sfx_jump_inst, global.master_volume global.sfx_volume, 0)
Придется так писать после каждого вызова audio_play_sound, но другого способа я пока не вижу.
Полетела разметка кода про звук из-за звездочек, которые макаба воспринимает как курсив.
https://pastebin.com/8KWrigJk
спасибо за ответ, но да, тут все-таки нагромождение, сам понимаешь. Буду думать дальше. И так стараюсь во второй игре избежать всех ошибок первой
Можно эту штуку обернуть в скрипт и вызывать вместо audio_play_sound(). Будет не громоздко, как по мне.
>https://forum.yoyogames.com/index.php?threads/how-to-properly-scale-your-game.995/
Я эту статью читал. Но у меня не рисуется application_surface. Пишет: Trying to use non-existing surface. Не понимаю, почему так, вроде application_surface должна всегда существовать.
Нет, все-таки рисуется. Это я невнимательный, использовал application_surface_enable() вместо application_surface_draw_enable(). А в твоем коде мне две вещи остались не ясны.
1. Зачем ты в событии Step изменяешь размер окна при переходе в полноэкранный режим? Это же вроде ни на что не влияет уже.
2. Почему рисуешь application_surface в PreDraw? Ведь все остальное отрисовывается после, а мы увидим предыдущий кадр таким образом, правильно?
Да всем похуй на тебя, дедуль.
1. Индусский код-анахронизм, оставшийся от предыдущих вариантов реализации. Сам убрал, когда перечитал его в очищенном от кучи закомменченного мусора виде. Уже после отправки на двач, лол.
2. Почему-то в свое время решил, что так надо. Сейчас прочитал вот этот док http://docs.yoyogames.com/source/dadiospice/002_reference/surfaces/the application surface.html и увидел, что действительно логичнее рисовать application surface в post-draw.
В общем, и для меня это дело оказалось полезным.
Пересмотрел свежим взглядом на код, который накостылил по наитию и боялся менять.
>>456404
4.3 была самая ламповая. Жаль, что игоры, сделанные в ней, нормально не идут на современные пеки.
таки реализовал. По своему, но работает. Все равно не откажусь почитать ваши варианты, если кто чего отпишет
Реально тупой вопрос. Как у тебя вообще дамагание реализовано?
У меня при мили ударе возникает объект, который существует до тех пор, пока проигрывается ударная анимация. Любой объект семейства enemy, столкнувшийся с этим объектом получает урон, но получает его только 1 раз.
Для этого в create event создаю список
targets = ds_list_create();
В евенте "столкновение с объектом enemy" пишу:
if ds_list_find_index(targets,other) = -1
{
нанести урон
}
ds_list_add(targets, other);
и не забываю уничтожить этот список в destroy event
ds_list_destroy(targets);
Если тебе нужен КД в пару секунд - очищай список целей каждые пару секунд.
Да оно у меня очень просто реализовано. Есть родительский объект врага и родительский объект оружия. Плюс есть объект, который хранит данные о здоровье босса. В итоге я просто подвязал уже имеющийся скрипт и при столкновении этих двух объектов запускается внутренний таймер с миганием спрайта того, кто словил дамаг
точно также делал, когда пилил игру типа нинджа гайдена
Таки пришлось вернуть этот код.
Почему-то если игра стартует в полноэкранном режиме, то если из него выйти, размер окна становится иногда неадекватно мелким. Почему-то этот баг не проявляет себя, если менять полноэкранный режим через Window_set_fullscreen() - только через alt+enter.
>>456421-кун
Хотел протестировать, но у меня на комбинацию alt+enter нет реакции.
Если я хочу писать бровзерные игори, то надо платить 149 бачей?
Я правильно понимаю, что gamemaker не дает сохранять файлы в папку с игрой, а только в общую папку <LOCALAPPDATA>/<GameName>? И теоретически, если на компе другая игра с тем же именем будет писать в тот же файл, то она всю сохраненку похерит. Как с этим бороться и нужно ли?
ты сам можешь выбрать, куда твоя игра будет сохранять данные
Никогда не юзал ГМ
GDevelop попробуй.
Подскажите мне, как правильно переносить камеру из комнаты в комнату? У меня при переходе из комнаты в комнату странным образом растягивается. Пока что я решил, что буду убивать камеру в room_end event и создавать новую камеру в room_start event. Но правильное ли это решение?
Лучше, чем Unity? Как производительность относительно phaser?
ну это пиздец конечно. Любая хуевая игра отобьет эти шесть тысяч с головой, а тут жлобство какое-то
Сомнительно, конечно, что отобьет. В Play market over 9000000 проектов с 5-10 установками...
А, если геймаркет, то да. А ежели стим, то все ок
Заодно может подскажете, из вашего опыта или вычитанных где-нибудь мудростей, каким количеством объектов на комнату следует ограничиваться?
Заодно может подскажете, из вашего опыта или вычитанных где-нибудь мудростей, каким количеством объектов на комнату следует ограничиваться?
Можно собирать из спрайтов посредством эвента draw, но это тот еще гемор.
Лучше писать контроллер, который бы собирал персонажа из объектов, проще манажить будет.
Не наебут
покажите САМЫЕ КРАСИВЫЕ игры на геймейкере
возьми и напиши им
Неебу как относительно Phaser, но производительность неплохая. Правда пришлось править сгенеренный html код ручками т.к. какого-то хуя канвас сглаживался по-умолчанию что пиксельной игре не нужно.
Да, там практически идентично все в плане кода (с небольшими исключениями).
Двойка просто сильно удобнее сама по себе.
Спасибо, друг.
Вопрос к специалистам. Как реализовать редактор уровней в gms?
Так-то ГМЛ норм на самом деле, хотя и не хватает нормального ООП конечно. Частично это компенсируется системой эвентов. Но приходится писать скрипты вне объектов, чтобы имитировать методы.
Итого жить можно, но можно и лучше.
Вот код:
x = obj_hero.x+11;
y = obj_hero.y+6;
x2=0;
if (obj_hero.sprite_index == spr_hero_idle_right or spr_hero_right)
{
x2 = x+1;
}
else if (obj_hero.sprite_index == spr_hero_idle_left or spr_hero_left)
{
x2 = x-1;
}
image_angle = point_direction(x,y,x2,y);
firingdelay = firingdelay - 1;
if (keyboard_check(vk_space)) and (firingdelay < 0)
{
firingdelay = 5;
with (instance_create_layer(x,y,"Bullets",obj_bullet))
{
speed = 10;
direction = other.image_angle;
image_angle = direction;
}
}
Вот код:
x = obj_hero.x+11;
y = obj_hero.y+6;
x2=0;
if (obj_hero.sprite_index == spr_hero_idle_right or spr_hero_right)
{
x2 = x+1;
}
else if (obj_hero.sprite_index == spr_hero_idle_left or spr_hero_left)
{
x2 = x-1;
}
image_angle = point_direction(x,y,x2,y);
firingdelay = firingdelay - 1;
if (keyboard_check(vk_space)) and (firingdelay < 0)
{
firingdelay = 5;
with (instance_create_layer(x,y,"Bullets",obj_bullet))
{
speed = 10;
direction = other.image_angle;
image_angle = direction;
}
}
1) Направление взгляда вынеси в отдельную переменную +1/-1, тогда просто будешь умножать на него и не нужно будет дублировать кучу кода.
2) Вместо A == B or C должно быть (A == B) or (A == C)
Спасибо за ответ, но я уже разобрался. И опять застрял, но теперь нет идеи.:(
Первый That Level Again на libgdx сделан. Что еще расскажешь ыксперд?
>>457498
На первый такая же цена. Мне он правда по акции достался за 25$ весь комплект. Проф-версия, андроид и все-все-все, кроме iOS. Правда без интеграции со стимом, но через год дали и её. Надо просто подождать распродажи.
как же вы заебали уже. Сами бы издались и профит был в несколько раз выше гарантированно. Хотя, если ты ленивое хуйло и тебе настолько похуй,что ты слил игру дагам, то может быть и нет.
То-то же. По поводу заработка, если ты вдруг не веришь - загугли nikita ghost rus. Есть такой говнодел в стиме, который клепает говно со скоростью света и издается сам. Вряд ли бы он стал делать то, что не окупается рака яиц ему
видел этого хуесоса. но с габендиректом он скорее всего обнищает такие суммы вливать.
да нихуя подобного, он через директ залил все, что через грин не пролезло и не думает останавливаться судя по всему
> That Level Again
То еще говнецо.
> Первый на libgdx сделан.
1/3. Автор понял какое это говно и съебал на другой движок
Говнецо не говнецо, а слушать будешь стоя а ЕМНИП больше 5кк скачиваний. Так что рассуждения о качестве продукта, имеющего такую оценку аудитории бессмысленно.
К тому же да, 2 и 3 были сделаны на Unity и, как следствие, оптимизированы гораздо хуже. Багов в них полно, в то время как в 1 части их не было вообще. Тут он скорее перескочил из-за удобства и скорости разработки, чем из-за чего-то еще.
Дык выставь условие, чтоб он за 2-3 пикселя до мыши останавливался. Координаты того и того у тебя есть, если векторную математику не прогуливал на первом курсе, то проблем не будет, а если прогуливал, то загугли.
Просто весь скрипт движения подпихни под условие.
Если сможешь сделать билд под андроид, то да. Но вряд ли ты сможешь, если он не лицензионный.
Во-первых забудь про DnD. Сделать что-то на этом говне на порядок сложнее, чем через нормальный код.
Во-вторых координата объекта выставляется в спрайте этого объекта. По умолчанию x,y объекта это x,y верхнего левого угла спрайта. Если ты хочешь координаты центра этого спрайта, тогда пиши:
x_center = object.x + object.sprite_width/2;
y_center = object.y + object.sprite_height/2;
Или, если у тебя пиксель-пёрфект движение (что разумней):
x_center = object.x + ceil(object.sprite_width/2);
y_center = object.y + ceil(object.sprite_height/2);
Ну или можешь в спрайте выставить центр на центр спрайта и тогда x,y объекта у тебя будет его центром.
Поймёшь, когда тебе понадобится что-то кроме центра спрайта.
Ну и соответственно при ресайзе окна было то же самое - растягиваешь окно, а у тебя не изображение растягивалось, а просто больший кусок игрового поля показывался.
Точно с камерой? Может надо как-то алгоритм стрельбы персонажа поменять?
так это самое. Если мне не изменяет память, в первом гамаке точно так же. Либо ты делаешь все на встроенной физике и пилишь все под нее, либо пишешь свою физику, либо пользуешься чужой
2й день юзаю гейм мейкер. Как так изъебнуться, чтобы объект летел в заданном направлении на встроенной физике?
хуй знает, этим говном не пользовался никогда, всегда либо сам, либо подсматривал у кого. Почитай документацию, мб там поймешь чего
Из документации я понял чуть больше чем нихуя... Где можно найти чью-ту физику? Форумы там какие
Там еще хуже чем на дваче. Мне предъявили, что я хуйню пощу и вежливо нахуй послали
так ты не пости, а просто поиском пользуйся, там да, как на дваче. В идеале как можешь делать - гугли на маркете гамака ассет под нужный тебе жанр игры (платформер, шмап и тд) , качаешь и разбираешь его по косточкам, там и найдешь самописные решения. Либо смотри туториалы пиксельпопа, heartbeast'a и шона сполдинга
Тебе там ясно сказали: либо используешь встроенный физический движок, либо передвигаешь объекты вручную - и даже дали ссылку.
Тщ майор, можете залогиниться
ты юзаешь movedir_x и movedir_y?
если да, то изменению параметров x и y на физоне делается не через x += и y+=, а через phy_position_x += и phy_position_y +=, параметры в твоем случае равнозначные
Ну я phy_poisition и юзаю всегда...
Ну только пули работают в моем понимании при отключенной физики в комнате, а phy_position не работает без физики
если пули физический объект, то без включенной физики в комнате они работать как надо НЕ будут
если не физический, то ты прописываешь координаты x += и y+=
я юзал move_towards_point, оно двигает в сторону курсора, но при x += не будет же лететь в указанном направлении
Для платформера вообще не нужна физика, начнём с этого. Если что-то перемещается, это не значит, что надо использовать физ. движок.
phy_position задается в коде один раз, а перемещение осуществляется приложением силы к объекту. Прочитай внимательно ссылку на статью, которую тебе дали.
Правильное решение: убери физику с персонажа и двигай его так же, как и пулю - изменением координат.
>Правильное решение: убери физику с персонажа и двигай его так же, как и пулю - изменением координат
А оно разве не будет как слайд шоу?
хуевый выбор, чую, если сдвинешь курсор, то пули тоже изменят направление
лучше высчитывай направление один раз исходя, например, из угла отрисовку спрайта оружия, если оно поворачивается, и используй lengthdir
>>461502
не будет, движение просчитывается каждый кадр, никакой разницы между физикой и её отсутствием тут нет
в любом случае физон тут лишний, если вызывает такие проблемы
умножаешь вертикальную скорость на число меньше 1, где-то 0.3 или 0.25
только gravity его не называй, это уже вшитое
тогда каждый фрейм скорость будет уменьшаться на 0.3, типа, стартовая -8, следующий кадр -7.7, -7.4 и так далее
Если согласен помогать 3м школьникам с охуительными амбициями и хуевыми знания гейм мейкера, за нихуя, ради призрачного профита ввиде стартапа на патреоне и последующей выгрузки игры в стим, то велком
/Чел, разосравшийся в этом треде с физикой
А что не так? Сейчас зайти могу
Блять у меня теперь вообще гг распидарасило. Он ебашит без остановки во все стороны и ему абсолютно поебать на все преграды и он пролетает сквозь все объекты
Почитай мануал, пройди несколько туториалов, скачай пример платформера и разбери - потом начинай делать своё.
Ну бля, работают же как-то люди. Вопрос в том, как.
Во второй хз, в первой если онли ARMV7 + x86 то 2мб
Хуя ты восторженный даун. В этом мире существуют тысячи игр и прочего контента с дрм, но это не мешает пиратам такую защиту снимать.
мимо
Ты блять в послание вникни, я блять написал про общедоступный аккаунт. Такая хуйня есть с играми на яблоки
в первом тоже была защита. просто второй никому не нужен, первого и так хватает
Да я уже и сам разобрался.
Ещё такой момент: с чем может быть связанно отталкивание игрока от стенки, если напирать на неё? Если медленно пододвинуть объект к стене и затем двинуть его, игрока вообще вытолкнет за стену.
У меня есть движущиеся платформы, которые не представляю, как сделать тайлами.
В связи с этим два вопроса.
1) Будет ли прирост производительности, если статические стены (коих 90%) заменить тайлами, а движущиеся оставить объектами?
Тогда, получается, мне нужно будет в коде проверять коллизию дважды - на тайлах и на объектах. Но ведь объектов-стен теперь будет на порядок меньше. Стоит ли пытаться?
2) Можно ли сделать движущиеся платформы тайлами?
заебись
Как я вилкой чистить буду?
Расскажи, что имеешь ввиду, а ещё лучше дай туториал на то, как это сделать в.
Простейший шейдер. Можешь навелосипедить с draw_sprite_part(), но будет совсем не гибко.
Вон в том же туториале, который ты смотришь, написано, что лучше шейдер использовать.
// a simple shader would be better/faster than setting the fog for each sprite drawn.
gpu_set_fog(true,i.silhouette_colour,1.0,1.0);
draw_sprite_ext( i.sprite_index, i.image_index, i.x,i.y, 1,1,0,i.silhouette_colour,1);
Но они там делают какое-то извращение, имхо.
Знаешь, я сейчас открыл их туториал и тоже прихуел. Но это не значит, что не надо изучать как там что сделано - у них есть решения, охуенно экономящие фпс. Я этот гайд ковырял когда освещением занимался. В конце концов сделал всё на порядок проще, но их приёмы с растягиваием и блуром сурфейса я запомнил.
Можно гораздо проще всё сделать.
Держи охуенный гайд по шейдерам ля начинающих гамакеров:
http://xorshaders.weebly.com/
Ну и как спрайт кусками рисовать - сам разберёшься.
Я решил сделать импорт старых сохранений, все по порядку разобрал, но в некоторых случаях ds_list_find_value получает не те значени, какие надо
Так, уже речь не про ds_list_create, значит?
Сделай ещё попытку, всё равно не получилось вопрос задать. И не забывай, ты всегда можешь заглянуть внутрь своих дата структур через дебагер.
Смотрю урок Make an RPG, там проблему бесконечного проигрывания анимации после начала движения решают через
if (!key_right and !key_left) {
image speed = 0
}
Я же хочу включать idle анимацию. Понятно, что надо просто прописать sprite_index = spr_player_idle; но у мня их две штуки, чтобы игрок оставался в левой idle анимации после того, как шел влево и в провой idle анимации после того, как шел вправо. Как это сделать?
if image_xscale > 0 {
sprite_index = idle_right
} else {
sprite_index = idle_left
Это если ты его разворачиваешь через скейл
Не бойся изобретать. Не бойся вводить новые переменные.
Зафигачь себе
if (!key_right and !key_left) {
sprite_index = spr_idle; //меняй спрайт с анимацией idle
image_speed = 0;
}
else{
sprite_index = spr_run; //меняй спрайт на спрайт бега
image_speed = 1;
}
тьфу ты.
if (!key_right and !key_left) {
sprite_index = spr_idle; //меняй спрайт на анимацией idle
image_speed = 1;
}
else{
sprite_index = spr_run; //меняй спрайт на спрайт бега
image_speed = 1;
}
Нет, не через скеил. У меня просто прописано
if (key_right) {
sprite_index = spr_player_run_right;
}
if (key_left) {
sprite_index = spr_player_run_left;
}
и соответственно загружено две разные анимации.
>>473099
>>473100
Я Game Maker Studio только этим утром установил. И не совсем понимаю твой код.
Алсо сейчас досмотрел этот урок https://youtu.be/72SWn4xr-0Q и вопрос по анимациям остался, т.к. он там удары не стал анимировать. С анимацией ходьбы/бега все понятно: нажимаешь вправо - проигрывается анимация вправо, нажимаешь влево - проигрывается анимация влево, а вот с ударами как? Как сделать, чтобы при нажатии одной и той же кнопки удара игра понимала, какую именно из анимаций проигрывать? Короче мне надо еще уроков по гейм мейкеру, в этой серии он многих вещей не касается.
Всякая фигня с лицензиями
да. Проблем нет, брат жив
>не совсем понимаю твой код.
В гамаке есть keyword- sprite_index - указывает на спрайт объекта. При помощи него ты можешь менять спрайт объекта когда захочешь, а не только при создании объекта.
В сети достаточно подробных туториалов для нубов, по которым даже человек абсолютно без опыта программирования может повторить шаг за шагом процесс создания игры в гамаке, но те что я видел, обычно для платформеров, изометрических рпг или топ-даун шутеров.
https://youtu.be/G90wXOwPPVE?t=6m6s
Нахуя он создает вериабл b = -1; ?
Получается он дальше пишет
if (image_xscale = 1)
-1.direction = 0;
} else {
-1.direction = 180;
}
что блядь это вообще должно означать?
Резервирует контейнер для пули.
Для того, чтобы не использовать b в каком-то другом месте.
Во-вторых, если вдруг ему нужно будет обратиться к пуле b в каком-то другом месте,он сможет сделать проверку
if instance_exists(b)
{
блаблабла
}
Если b задано не будет - получится критическая ошибка. Если же b будет иметь значение -1, то это соответствует ключевому слову noone в гамаке. Проверка будет пройдена.
Вообще, когда я создаю всякие пули, я задаю временную переменную.
var b = instance_create...
b.spd = ...
b.dirx = ...
b.dmg = ...
Но если бы мне понадобилось, например, управлять пулей используя для управления объект игрока, я бы в криэйт ивенте написал
b = noone;
И ты лучше пиши не
b = -1;
а
b = noone или b = false
В смысле не используй цифру -1 там, где должно быть ключевое слово. Не потому, что работать не будет, а потому что в последствии, вернувшись к своему коду через пару месяцев, тебе будет легче в нём разобраться.
>Получается он дальше пишет
Ты не понял что он делает.
Сначала у него была b = -1
Потом он написал
b = instance_create.. и b поменяла значение.
Фунция instance_create возвращает id созданного объекта.
Теперь b содержит ссылку на созданный им инстанс. (Ключевое слово гамака id)
Поэтому, когда ты дальше пишешь
b.direction = 0
Ты изменяешь параметр direction этого объекта на 0.
И тут важно, обрати внимание и запомни:
Когда создаётся объект при помощи instance_create
сразу же начинает выполняться его криэейт ивент. СРАЗУ ЖЕ.
Поэтому, когда ты следующей строкой пишешь
b.direction = 0
помни, что криэей ивент УЖЕ произошёл.
Ну и, соответственно, ты не можешь использовать в криэйт ивенте этого инстанcа данные от создателя. Если тебе нужно вычислить для пули скорость в зависимоти от направления, либо вычисляй её после instance_create и предавай объекту, либо у объекта делай "дополнительный приэйт ивент".
Но это уже другая история, этим ты будешь заниматься потом. Пока кури туториалы.
Ну и раз уж ты такие вопросы задаёшь:
переменная в гамаке - штука умная и универсальная.
Во-первых она сама определяет свой тип, когда ты используешь =
Если b = 1 то она - int
Если b = 1/3 то она сразу real
Если b = "hello wrold" То она string
Но это тебе не очень инересно.
А вот если
b = spr_player
и при этом spr_player - это название твоего спратйа игрока, то b становится ссылкой на это спрайт.
И ты можешь использовать её для анимации. Например
create event:
sprite_walk_right = spr_zombie_walk_right
sprite_walk_left = spr_zombie_walk_left
if dirx = 1{
sprite_index = sprite_walk_right
}
else{
wprite_index = sprite_walk_left
}
Зачем так делать? Да затем, что когда ты будешь создавать много врагов, ты сможешь использовать для них одни и те же скрипты, меняя лишь значение sprite_walk_right в create event. Ты просто child objects будешь создавать, у которых только криэйты разные. Удобно же!
b = room_index
И теперь b это ссылка на твою комнату.
И так далее.
Ну и раз уж ты такие вопросы задаёшь:
переменная в гамаке - штука умная и универсальная.
Во-первых она сама определяет свой тип, когда ты используешь =
Если b = 1 то она - int
Если b = 1/3 то она сразу real
Если b = "hello wrold" То она string
Но это тебе не очень инересно.
А вот если
b = spr_player
и при этом spr_player - это название твоего спратйа игрока, то b становится ссылкой на это спрайт.
И ты можешь использовать её для анимации. Например
create event:
sprite_walk_right = spr_zombie_walk_right
sprite_walk_left = spr_zombie_walk_left
if dirx = 1{
sprite_index = sprite_walk_right
}
else{
wprite_index = sprite_walk_left
}
Зачем так делать? Да затем, что когда ты будешь создавать много врагов, ты сможешь использовать для них одни и те же скрипты, меняя лишь значение sprite_walk_right в create event. Ты просто child objects будешь создавать, у которых только криэйты разные. Удобно же!
b = room_index
И теперь b это ссылка на твою комнату.
И так далее.
Спасибо. Я едва ли что-то из этого понял вчера когда прочитал, но сейчас немного разобрался, когда делал удар врага по игроку.
Переменную можно привязать к объекту и это удобно тем, что можно создавать этот объект с уже заданными параметрами в коде его создателя.
var enhit = 0;
//enemy attack
if (alarm[0] <= 0) {
enhit = instance_create (x,y+30,obj_enemy_hit);
enhit.image_xscale = image_xscale;
alarm[0] = 60;
}
можно придать заданное направление (например для удара), скорость (для пули) и т.д.
Послушай совет:
Никогда. Не. Используй. Алармы.
Во-первых их всего 12.
А если у твоего игрока куча разных механик? Тебе не хватит.
Во-вторых порядок исполнения кода. Ты знаешь когда они выполняются? В тот самый момент, когда оттикал таймер. А когда тикает этот таймер? В начале шага, в конце, в самом шаге? А в какой последовательности у разных объектов он тикает? А если твой игрок неуязвим, а на тебе ДоТ, который сделан на аларме, а аларм тикает у врага? НАХУЙ! Это самое главное.
В-третьих без алармов код проще и понятней.
То, что у тебя написано превращается в:
В криэйт ивент пишеш:
enemy_hit_timer = 0;
enemy_hit_time = 60
В степ ивенте меняешь аларм на:
enemy_hit_timer ++
if enemy_hit_timer > enemy_hit_time{
enemy_hit_timer = 0;
enhit = ...
бла бла бла }
И не думаешь через месяц "а за что у меня отвечает alarm[8]?" и не вспоминаешь "а я этот же аларм использовал для кулдауна регенерации здоровья, надо поменять." У тебя всё в криэйт ивенте хранится.
Нахрена тебе эта ересь?
Послушай совет:
Никогда. Не. Используй. Алармы.
Во-первых их всего 12.
А если у твоего игрока куча разных механик? Тебе не хватит.
Во-вторых порядок исполнения кода. Ты знаешь когда они выполняются? В тот самый момент, когда оттикал таймер. А когда тикает этот таймер? В начале шага, в конце, в самом шаге? А в какой последовательности у разных объектов он тикает? А если твой игрок неуязвим, а на тебе ДоТ, который сделан на аларме, а аларм тикает у врага? НАХУЙ! Это самое главное.
В-третьих без алармов код проще и понятней.
То, что у тебя написано превращается в:
В криэйт ивент пишеш:
enemy_hit_timer = 0;
enemy_hit_time = 60
В степ ивенте меняешь аларм на:
enemy_hit_timer ++
if enemy_hit_timer > enemy_hit_time{
enemy_hit_timer = 0;
enhit = ...
бла бла бла }
И не думаешь через месяц "а за что у меня отвечает alarm[8]?" и не вспоминаешь "а я этот же аларм использовал для кулдауна регенерации здоровья, надо поменять." У тебя всё в криэйт ивенте хранится.
Нахрена тебе эта ересь?
За совет спасибо. Про timer я вообще не знал, про алармы узнал из туториалов в связи с этим и использовал. В принципе конкретно в этом случае с врагом у меня это временная мера, пока враг представляет собой красный прямоугольник который бьет меня оранжевым прямоугольников. В будущем планирую привязать obj_enemy_hit к кадру анимации, в которой враг будет бить, так что этот аларм можно будет спокойно вырезать.
Но на всякий пожарный уточню, алармов всего 12 ведь не на всю игру, а на конкретный объект? То-есть alarm[0] прописанный для obj_player не имеет никакого отношения к alarm[0] прописанного для obj_enemy, гейммейкер путать их не будет и они прекрасно живут своей жизнью независимо друг от друга?
На объект.
>о-есть alarm[0] прописанный для obj_player не имеет никакого отношения к alarm[0] прописанного для obj_enemy,
И даже alarm на одном obj_enemy не имеет отношения к alarm На другом obj_enemy.
Это просто встроенный неудобный таймер гейммейкера. лучше таймеры делать самостоятельно.
if (instance_exists(obj_player)) and (key_use) {
room_goto(rm_f1_garage);
obj_player.x = 180;
}
Только после того, как все опробовал и убедился, что плеер перемещается и хп у него остается ровно тоже количество что и было в предыдущей комнате, задумался а почему оно вообще работает. Ведь этот коллижн ивент запускается из самой двери, почему room_goto перемещает именно плеера в другую комнату, а например не саму дверь? Такой код вообще нормальный или я потом с ним наебусь?
Потому что это не объект игрок перемещается куда-то, а исчезает одна комната и на её месте появляется другая.
Если на каком-то объекте стоит галочка persistent, этот объект остаётся на своём месте.
Остальные обхекты исполняю свой room_end event и исчезают.
Затем появляются объекты новой комнаты.
Строкой obj_player.x = 180; ты меняешь ккординату x игрока. Камера перемещается за ним. Она у тебя сейчас автоматическая, от гейммейкера, и ты её должным образом не контролируешь. Но и комната у тебя, скорее всего, в один экран, поэтому странного поведения камеры ты не видишь.
>Ведь этот коллижн ивент запускается из самой двери
Читай мануал:
Note that calling this function does not instantly change rooms, and the room will not change until the end of the current game frame (meaning that any code after this function will still be run, as will some events). This function will also trigger the Room End event.
Команда room_goto поднимает флаг перехода в другую комнату.
Но переход этот происходит только после окончания текущего фрейма.
Также эта команда выполняет room_end event всех объектов.
Порядок выполнения кода такой:
В step event у тебя где-то срабатывает команда room_goto. После этой команды всё продолжается как обычно.
Выполняются step event всех объектов, потом их draw event на самом деле ивентов больше. но сейчас это не важно
После исполнения draw event начинается, собственно, переход в другую комнату.
Сначала выполняется room_end event комнаты вот с ивентами комнаты могу ошибаться
Затем для каждого объекта исполняется room_end event, после чего объект, если он не persistent, уничтожается.
Потом выполняется room_start event новой комнаты. Затем create event всех объектов в новой комнате, затем room_start event всеъ объектов в новой комнате, затем create event новой комнаты, затем room_start event новой комнаты.
Я надеюсь ты понял мысль.
>Такой код вообще нормальный или я потом с ним наебусь?
Вот это хорошо:
if (instance_exists(obj_player))
Если сразу привыкнешь это писать при обращении к объекту, потом будет легче.
>Потому что это не объект игрок перемещается куда-то, а исчезает одна комната и на её месте появляется другая.
>Если на каком-то объекте стоит галочка persistent, этот Теперь все понятно, на obj_player у меня как раз стоит persistent. Makes total sence.
>>474289
Из этого поста пока мало что понял, но не буду рашить. У меня еще много базовых вещей впереди на освоение. Вернусь к этому чуть позже.
Step Event:
if (mouse_check_button(mb_left)) {
if (mouse_x < x) {
image_yscale = -1;
} else {
image_yscale = 1;
}
image_angle = point_direction(x, y, mouse_x, mouse_y);
}
И еще при нажатии спрайт выворачивается, но я юзал похожую функцию для поворотов. Если нажать в левую часть, то после нажатия кнопок вправо и влево используется противоположное направление
Рисуй в draw event два спрайта.
Основной объект рисуй как
draw_self();
Дополнительный рисуй как
draw_sprite_ext(....) - и вводи для него отдельные переменные
sprite_hands_sprite_index =
sprite_hands_image_number =
sprite_hands_rotation =
sprite_hands_image_xscale =
и так далее. В мануале всё написано.
>>477115
Разжёвывать никто тебе не будет. Ты задаёшь ЭЛЕМЕНТАРНЫЕ вопросы, ответ на них есть в мануале.
Тебе показали способ как это сделать,и подсказали, про что читать. Иди и читай мануал.
пункт draw_sprite_ext
мимонуфак
Хотел побыть хорошим полицейским и по-доброму ответить на твой вопрос. Но просто не могу.
Ты написал хамский, потребительский пост, который даже не содержит в себе вопроса.
Попробуй задать вопрос ещё раз, при этом опиши то, что ты хочешь сделать, что именно у тебя не получается, опиши свои варианты подхода к проблеме и почему они не сработали.
И ты ожидаешь, что я тебе тут книгу напишу про то, как это делать, или дам ссылку на гайд "как сделать заебись"?
При том, что ты даже сам не можешь написать, что ты хочешь сделать.
> Не знаю ничего.
Тогда запускай самые первые туториалы по гамаку от Спалдинга и делай астероиды.
>И ты ожидаешь, что я тебе тут книгу напишу про то, как это делать, или дам ссылку на гайд "как сделать заебись"?
Я какбэ в первом посте писал, что мне нужны гайды по тбрпг, блять. Почему харкачеры так привыкли искажать всё.
>При том, что ты даже сам не можешь написать, что ты хочешь сделать.
Я бы описал концепт, если бы беседовал с кем-нибудь индивидуально, но меня в первую очередь интересуют базовые механики, о которых я уже говорил.
>Тогда запускай самые первые туториалы по гамаку от Спалдинга и делай астероиды.
Зачем мне аркадные механики в турн бэйсед рпг, объяснишь мне? Все эти коллизии и прочую хуйню я и так освоил, меня интересуют углублённые знания.
>Зачем мне аркадные механики в турн бэйсед рпг, объяснишь мне? Все эти коллизии и прочую хуйню я и так освоил, меня интересуют углублённые знания.
Видимо не освоил, иначе знал бы, как работать с объектами.
>Я какбэ в первом посте писал, что мне нужны гайды по тбрпг, блять. Почему харкачеры так привыкли искажать всё.
Может не харкачеры искажают, а у тебя не получается вопрос задать?
Попробуй поставить себя на место собеседника. Допустим тебя спрашивают:
"Посоветуйте гайды по созданию мобильных приложений."
или
"Посоветуйте гайды по созданию головоломок."
Что ты ответишь?
А представь себе, если тебя спросят:
"как мне сделать так, чтобы мой враг в игре выполнял какое-то действие только тогда, когда я нажимаю на кнопку "конец хода"?"
Тогда тебе ответят:
Воткни в начало степ ивента объекта obj_enemy такую конструкцию:
if !turn_is_over
{turn_is_over = false;}
else
{exit;}
Дальше пиши код как обычно.
Потом создай кнопку, после нажатия на которую она будет выполнять следующий код
with obj_enemy
{turn_is_over=true}
Теперь после нажатия на эту кнопку у всех твоих врагов флаг turn_is_over станет true. Они выполнят step event один раз и снова установят у себя флаг turn_is_over = false.
>Я бы описал концепт, если бы беседовал с кем-нибудь индивидуально
Ты /gd с /b попутал. Тут всего 15 человек сидит. В общей сложности.
Я всё ещё добрый полицейский. Но это в последний раз.
>Зачем мне аркадные механики в турн бэйсед рпг, объяснишь мне? Все эти коллизии и прочую хуйню я и так освоил, меня интересуют углублённые знания.
Видимо не освоил, иначе знал бы, как работать с объектами.
>Я какбэ в первом посте писал, что мне нужны гайды по тбрпг, блять. Почему харкачеры так привыкли искажать всё.
Может не харкачеры искажают, а у тебя не получается вопрос задать?
Попробуй поставить себя на место собеседника. Допустим тебя спрашивают:
"Посоветуйте гайды по созданию мобильных приложений."
или
"Посоветуйте гайды по созданию головоломок."
Что ты ответишь?
А представь себе, если тебя спросят:
"как мне сделать так, чтобы мой враг в игре выполнял какое-то действие только тогда, когда я нажимаю на кнопку "конец хода"?"
Тогда тебе ответят:
Воткни в начало степ ивента объекта obj_enemy такую конструкцию:
if !turn_is_over
{turn_is_over = false;}
else
{exit;}
Дальше пиши код как обычно.
Потом создай кнопку, после нажатия на которую она будет выполнять следующий код
with obj_enemy
{turn_is_over=true}
Теперь после нажатия на эту кнопку у всех твоих врагов флаг turn_is_over станет true. Они выполнят step event один раз и снова установят у себя флаг turn_is_over = false.
>Я бы описал концепт, если бы беседовал с кем-нибудь индивидуально
Ты /gd с /b попутал. Тут всего 15 человек сидит. В общей сложности.
Я всё ещё добрый полицейский. Но это в последний раз.
Ну, в таком случае мне нужен анон, с которым я смогу работать индивидуально. Тогда я уже смогу задавать ему конкретные вопросы, но один хуй никто не захочет этим заниматься.
Здесь нет никого, кроме меня. Захочу ли я тебе что-то объяснять зависит только от тебя.
Мог бы, но не хочу палить концепт. Могли бы обменяться мылами и поговорить наедине.
>Мог бы, но не хочу палить концепт.
Смирись с тем, что твой концепт не интересен никому.
>Могли бы обменяться мылами и поговорить наедине.
Я сижу на анонимном форуме не потому, что хочу меняться мылами и говорить с кем-то наедине.
>Мог бы, но не хочу палить концепт.
Ну бля, ну так хотелось спиздить у тебя идею очередной рпгшки, ну чо вы опять обламываете(9(
Ага, скоро ведь девяностые, рпг на пике своей популярности
Ну раз ты так сказал.
Ты определись, тебе стрельбу нужно реализовывать или повороты рук?
У тебя 2д или 3д? Вектор? Руки - отдельный объект? С вот этим всем определись.
А лучше всего - нарисовать каждый кадр положения рук и тела для стрельбы, иначе будет выглядеть как говно.
Повороты рук во время стрельбы. Рисовать каждый кадр смысла нету, потому что тогда нельзя будет поворачиваться и стрелять одновременно
>>потому что тогда нельзя будет поворачиваться и стрелять одновременно
Чтоблять?
Ты сначала объясни, что ты хочешь, картинки запости. Понять что-то из твоего лепета невозможно.
Да хуле непонятно-то? Мне надо чтобы при стрельбе можно было вертеть руками во все стороны и это не выглядело по-уебански. Я пытался сделать это отдельным спрайтом рук и получилась хуйня. Вот я и спрашиваю другие способы сделать это
Делай 3д хуле. Как ещё можно сделать не рисуя отдельные кадры для каждого положения, еблан?
У тебя 2d вид сбоку? Или 3d? Или изометрия? Ты не способен видео залить на двач? Иди учись.
Если 2d вид сбоку - рисуй.
Ты из автомата стреляешь или из пистолета?
Где ты видел, чтобы кто-то за спину себе стрелял? Как ты вообще себе это представляешь?
Посмотри как в ghost 1.0 сделано. Она наклоняется вперёд и назад туловищем, сгибает руки, отставляет назад ногу, опускает и поднимает голову и стреляет только в передней полусфере. Если надо стрелять назад - разворачивается.
Она векторная, состоит из кусков, но каждый кадр стрельбы отрисован. Каждые 10 градусов поза чуть-чуть меняется, а в пределах 10 градусов ходят только руки.
Если ты хочешь тупо вращать неанимированный спрайт рук - у тебя и получится тупо. Чтобы было хорошо нужно много работать.
>Каждые 10 градусов поза чуть-чуть меняется
Ну и это будет выглядеть дёргано и будет ощущение, что пуля летит не из дула
>Где ты видел, чтобы кто-то за спину себе стрелял? Как ты вообще себе это представляешь?
Ну так за спиной у меня спрайт меняется на противоположный
>Ну и это будет выглядеть дёргано и будет ощущение, что пуля летит не из дула
Ты жопой читаешь? Поза меняется каждые 10 градусов. В пределах этих 1- градусов перемещаются руки. Открой ghost 1.0 да посмотри как там сделано.
Чтобы это повторить мне, например, нужно недели две рисовать. У меня уже опыт некоторый есть со спайном. Тебе - два месяца понадобится. Готов? Вперёд!
https://rutracker.org/forum/viewtopic.php?t=5528246
ЙАРРРРРРРРРР
Я сидел на раздаче, но у меня она перестала идти
Да че ты врежч, скорость около 1мб
посижу на раздаче с недельки две, если дадите докачать до фулла
Всё скачалось (скорость 1мб), сижу на раздаче.
Код:
obj_player
create
w_spd = 2;
n_spd = 3;
r_spd = 6;
spd = 3;
draw
draw_self();
step
//UPDATE INPUT
input_left = keyboard_check(vk_left);
input_right = keyboard_check(vk_right);
input_up = keyboard_check(vk_up);
input_down = keyboard_check(vk_down);
input_walk = keyboard_check(vk_control);
input_run = keyboard_check(vk_shift);
//ALTER SPEED
if(input_walk or input_run) {
spd = abs((input_walkw_spd) - (input_runr_spd));
} else {
spd = n_spd;
}
//RESET MOVE VARIABLES
moveX = 0;
moveY = 0;
//INTENDED MOVEMENT
moveY = (input_down - input_up) spd;
if(moveY == 0){ moveX = (input_right - input_left) spd; }
//COLLISION CHECK
//Horizontal
if(moveX != 0){
if(place_meeting(x+moveX, y, obj_collision)){
repeat (abs(moveX)){
if(!place_meeting(x+sign(moveX), y, obj_collision)){ x += sign(moveX);}
else { break; }
}
moveX = 0;
}
}
//Vertical
if(moveY != 0){
if(place_meeting(x, y+moveY, obj_collision)){
repeat (abs(moveY)){
if(!place_meeting(x, y+sign(moveY), obj_collision)){ y += sign(moveY);}
else { break; }
}
moveY = 0;
}
}
//APPLY MOVEMENT
x += moveX;
y += moveY;
Код:
obj_player
create
w_spd = 2;
n_spd = 3;
r_spd = 6;
spd = 3;
draw
draw_self();
step
//UPDATE INPUT
input_left = keyboard_check(vk_left);
input_right = keyboard_check(vk_right);
input_up = keyboard_check(vk_up);
input_down = keyboard_check(vk_down);
input_walk = keyboard_check(vk_control);
input_run = keyboard_check(vk_shift);
//ALTER SPEED
if(input_walk or input_run) {
spd = abs((input_walkw_spd) - (input_runr_spd));
} else {
spd = n_spd;
}
//RESET MOVE VARIABLES
moveX = 0;
moveY = 0;
//INTENDED MOVEMENT
moveY = (input_down - input_up) spd;
if(moveY == 0){ moveX = (input_right - input_left) spd; }
//COLLISION CHECK
//Horizontal
if(moveX != 0){
if(place_meeting(x+moveX, y, obj_collision)){
repeat (abs(moveX)){
if(!place_meeting(x+sign(moveX), y, obj_collision)){ x += sign(moveX);}
else { break; }
}
moveX = 0;
}
}
//Vertical
if(moveY != 0){
if(place_meeting(x, y+moveY, obj_collision)){
repeat (abs(moveY)){
if(!place_meeting(x, y+sign(moveY), obj_collision)){ y += sign(moveY);}
else { break; }
}
moveY = 0;
}
}
//APPLY MOVEMENT
x += moveX;
y += moveY;
Ёбаный курсив. Там в двух местах есть звёздочки, если что.
if(moveY == 0){ moveX = (input_right - input_left) spd; }
Вообще это пиздец - то что ты написал. Надеюсь ты первый день просто как кодить учишься.
>Ты же сам пишешь, что у тебя движение по х возможно только если нет движения по у.
Бля, точно. Спасибо, не заметил.
>Вообще это пиздец - то что ты написал. Надеюсь ты первый день просто как кодить учишься.
Учусь по гайдам.
Гд, родимый, помоги пожалуйста забороть ошибку:
############################################################################################
FATAL ERROR in
action number 1
of Step Eventunit1
for object obj_unit_effector:
Variable <unknown_object>.<unknown variable>(100007, -2147483648) not set before reading it.
at gml_Object_obj_unit_effector_Collision_2de17de7_8960_48b4_917c_ea87cd83c070 (line 5) - if (creator.allie_status != other.allie_status)
############################################################################################
--------------------------------------------------------------------------------------------
stack frame is
gml_Object_obj_unit_effector_Collision_2de17de7_8960_48b4_917c_ea87cd83c070 (line 5)
Бьюсь уже кучу времени с ней. Соль в том, что описываю юнит для стратежки, у юнита раз в кол-во кадров (число задается параметром кулдаун) при подходе на расстояние для атаки создается инстанс (обджект эффектор), который считает колижн с недружественным объектом и отнимает у него хп. Собственно при попытке скомпайлить вылезает эта сранина. Скажите, какие куски кода нужно скинуть, чтобы разобраться, ток помогите.
Рандомпик
Скорее всего ты не проверяешь существуют ли инстансы перед тем как ими манипулировать. Или не назначаешь или неправильно назначаешь переменную creator. Или у другого объекта просто нет такой переменной как allie status. Или ты случайно назначил юнит родителем эффектора или еще какие-нибудь проблемы с наследованием.
В общем показывай весь код и общий вид объекта эффектора и заодно скрипт который его создает.
Вот. Только не пугайся кода, я в гмс всего два дня сижу.
Ну вот смотри, насколько я вижу создаешь ты эффектор однозначно, но создателя ему назначаешь ситуативно, а потом переменную хозяина спрашиваешь однозначно, при этом создаешь эффектор там где гарантированно срабатывает Collision. Creator в таком случае получается инициализированной, но пустой переменной.
Перенеси создание эффектора под скобки боевого статуса и посмотри станет ли лучше.
Да, я так как раз делал, когда пытался сам баг выловить, в таком случае ошибка все равно вылетает, но позже. Сейчас сделаю и покажу.
В этот раз игра хотя бы открылась, хоть и не надолго.
(Алсо, можешь поподробнее объяснить, почему получается, что я ситуативно назначаю, но однозначно спрашиваю? Или какой-нибудь урок/статью может посоветуешь, чтобы разобраться)
>можешь поподробнее объяснить
Что там объяснять, получается так потому что ты не назначаешь создателя сразу же при создании (и не проверяешь назначен ли он перед тем как запросить статус, но это в данном случае было бы необязательно). То есть effector.creator=id дожно быть на следующей строчке после instance_create(effector), а не по разную сторону фигурных скобок двух-трех разных if else, у которых вся суть в том что код срабатывает только в зависмости от ситуации.
Да и вообще делать это в step не самая лучшая идея, ты создаешь допустим 60 объектов в секунду, а нужен из них только один, только когда срабатывает alarm, соотвественно лучше и перенести в аларм.
Вау, сейчас сделал как ты сказал, и все заработало. Спасибо тебе огромное, родина не забудет твоего подвига!
Есть объект игрока, который имеет спрайт 200x200 в виде белого квадрата, но с коллизией и центровкой персонажа. В коде:
obj_player
create
x_frame = 0;
y_frame = 0;
draw
var anim_length = 10;
var frame_size = 200;
var anim_speed = 3;
draw_sprite_part(charlist,0,floor(x_frame)звёздочкаframe_size,y_frame,frame_size,frame_size,x,y);
if (x_frame < anim_length -1) {
x_frame += anim_speed/60;
} else {
x_frame = 0;
}
В итоге получается хуйня, как на пикриле: посередине квадрат, за которым в углу находится персонаж. Жёлтое - коллизия. В чём подвох?
UPD: отключил родителя, который отвечал за глубину объектов, и квадрат исчез, но персонаж всё ещё в углу.
>В чём подвох?
>NOTE: When drawing with this function, the sprite x offset and y offset are ignored and the sprite part will be drawn with the top left corner at the specified x / y position in the room.
Отнимай соответствующие оффсеты из координатов x и y в draw_sprite_part.
Объясни, пожалуйста, про какой именно оффсет идёт речь. Первый кадр анимации расположен в левом верхнем углу.
> Где-то читал, что для gms2 будет поддержка Нинтендо Сыча. Но ведь Nintendo не дают левым разработчикам выкладываться? Или как?
Как и со всеми соснулями - пишешь заявление с приложенным диздоком нинтенде, что ты такой хороший и нинтендо обязательно должна разрешить разрабатывать тебе твою игру про корованы. Далее если соне одобрит - подписываешь NDA и покупаешь девкит. Уведомляешь нинтенду что будешь писать на свитч.
Теперь ты илита и грезишь о феррари как у кармака, с единственным обязательством - никому не говорить о бойцовском клубе не разглашать никаких сведений о внтренней кухне свитча без разрешения нинтенды - иначе сгуха и суд.
После чего с полученным разрешением идешь на форум юнити в закрытый от простого быдла раздел где по ссылке качаешь закрытые компоненты юньки для свитча (нужна версия про, если что).
Ну и да, в данном варианте, не забывай что нинтенда по-факту становится твоим издателем и ты будешь обязан выполнять все её пожелания, зарубать по её прихоти свои безумные идеи, реализовывать одно охуительнее другого пожелания нинтенды оптимизировать код и.т.д.
@
А ТЫ И НЕ ПРОТИВ
Кстати, парни, в GML можно как-то объявлять свои функции? Хочу, например апдейт состояния персонажа вынести в отдельный блок и вызывать его при определённых обстоятельствах (внутри step ивента, но не каждый раз)
Переформулирую вопрос, ибо я даун. Я наю, что скрипт вызывается как функция. А как работает передача туда значений? Нужно ли это вообще?
>А как работает передача туда значений?
Слегка через жопу. При вызове скрипта стандартно -- пишешь аргументы в скобках через запятую. А в самом скрипте будет что-то вроде
var xyz=argument0
var qwe=argument1
и так далее.
>Нужно ли это вообще?
Естественно, и возвращать из них значения тоже нужно.
всё, на самом деле я и сам разобрался. Не привык я к тому, что в документации действительно ВСЁ написано. Я такое наверное только к РенПаю видел, и то там пользовательские вики, а не официалка.
Но всё равно большое спасибо. Я рад что у вас тут дружелюбное коммьюнити.
Идея была проста:
два массива, в одном символы допустимые для данной сложности, во втором символы нагенерированные для уровня.
После генерации спавнятся блоки на которые наносятся эти символы по порядку.
Но я э... Видимо, где-то что-то проебал по фактике и мне пришлось перезагружать компьютер, потому что он чуть не загорелся, так и не запустив окошко. Но он так и не выдал ошибки. Я боюсь открывать этот проект у себя :(
чё делать?
> мне пришлось перезагружать компьютер, потому что он чуть не загорелся
> если бы волшебники были погромистами
Проиграл чет с этого.
братан, причин множество. кривой 3д-режим, который не справляется с переходами из него, depth объекта выше задника, прочее говно с view, alpha в 0, крч тонны их. я не смогу угадать. это как если бы ты спросил "почему у меня моделька в юнети не импортируется".
Альфа на единичке. Всё что могу сказать.
Если в subimg выставить -1, то спрайт тупо начнёт быстро пролистываться, хотя у меня скорость анимации на единице.
Можешь хотя бы объяснить, как это проворачивать с нуля?
>Можешь хотя бы объяснить, как это проворачивать с нуля?
берешь и без задней мысли отрисовываешь.
draw_sprite(x,y, sprite_index, image_index); и всё.
в том то и проблема что инфы от тебя мало вата
Хорошо, распишу подробнее.
Нужно, чтобы фон растягивался по всей комнате. То есть наверное нужно брать начало в 0,0, плюс высоту-ширину обоев, плюс скейлить. Но как ебануть нормальную анимацию с нужной скоростью?
Ты словил бесконечный цикл.
Запускай игру в режиме дебага, можешь даже без брекпоинтов. Когда начнёт адски тормозить дави, переключайся в окно дебагера и дави на паузу.
Вуаля. Далее жамкай f9 пока не поймёшь, где же ошибка.
draw_sprite_ext прекрасно работает.
create event:
animation_timer = 0;
animation_speed = 0.08;
bg_sprite_ = spr_background
bg_max_frame = sprite_get_number(bg_sprite) - 1;
bg_alpha = 0.5;
bg_xscale, bg_yscale = вычисляешь сам
draw_event
var frame = animation_timer хпишу Х вместо звёздочки animation_speed;
if frame > bg_max_frame {animation_time = 0; frame = 0;}
draw_sprite_ext(bg_sprite, frame, x, y, bg_xscale, 0, c_white, bg_alpha)
Вот тебе счастье
draw_event
var frame = animation_timer хпишу Х вместо звёздочки animation_speed;
animation_timer ++; пропустил строчку
if frame > bg_max_frame {animation_time = 0; frame = 0;}
draw_sprite_ext(bg_sprite, frame, x, y, bg_xscale, 0, c_white, bg_alpha)
1600x900, 0:19
Здарова, игроделы. Хуй знает, может кто сталкивался с проблемой. Когда объект движется по диагонали, то камера начинает дергаться. В чем проблема то может быть.
Подкрути в настройках камеры границы с 200 до 198 и посмотри стало ли лучше. Подгони там же аспект порта под аспект камеры, пусть будет 800х800 например.
А я тебе лучше совет дам, чтем этот >>493578
Не используй встроенную гамаковскую камеру. Делай свою.
В этом треде есть всё, что нужно:
https://forum.yoyogames.com/index.php?threads/guide-meet-the-new-camera-system.12269/
Вот здесь.
https://docs2.yoyogames.com/index.html?page=source/_build/2_interface/2_extras/debugging.html
А вообще пиши сам, как этот >>493579 советует. Будет удобней.
Благодарю. Но я вообще нихуя не шарю пока что в этом. Так что будет сложновато в коде разобраться.
Алсо вопрос. Запарно ли сделать так, чтобы спрайт врага изменялся в зависимости от положения? Например у меня 8 сторон движения и соответственно 8 спрайтов. Какая вообще должны быть логика изменения спрайтов? Мол if direction = значение градуса {
sprite_index = spr_move_top;
}
или что то вроде такого.
Всё будет так, как захочешь лично ты. Нет такой логики, которая "должна" быть.
Я бы сделал так:
Ввёл бы врагу две переменных dirx и diry.
Сделал бы 3 вот таких переключателя:
if dirx == 1
{
switch diry
{
case -1: sprite_index = sprite_walk_right_top; break;
case 0: sprite_index = sprite_walk_right; break;
case 1: sprite_index = sprite_walk_right_bot; break;
}
}
if dirx == 0
{
switch diry
{
case -1: sprite_index = sprite_walk_top; break;
case 1: sprite_index = sprite_walk_bot; break;
}
}
if dirx == -1
{
switch diry
{
case -1: sprite_index = sprite_walk_left_top; break;
case 0: sprite_index = sprite_walk_left; break;
case 1: sprite_index = sprite_walk_left_bot; break;
}
}
Можно даже свитч из свитчей, но так код, имхо, более читаемый.
Всё будет так, как захочешь лично ты. Нет такой логики, которая "должна" быть.
Я бы сделал так:
Ввёл бы врагу две переменных dirx и diry.
Сделал бы 3 вот таких переключателя:
if dirx == 1
{
switch diry
{
case -1: sprite_index = sprite_walk_right_top; break;
case 0: sprite_index = sprite_walk_right; break;
case 1: sprite_index = sprite_walk_right_bot; break;
}
}
if dirx == 0
{
switch diry
{
case -1: sprite_index = sprite_walk_top; break;
case 1: sprite_index = sprite_walk_bot; break;
}
}
if dirx == -1
{
switch diry
{
case -1: sprite_index = sprite_walk_left_top; break;
case 0: sprite_index = sprite_walk_left; break;
case 1: sprite_index = sprite_walk_left_bot; break;
}
}
Можно даже свитч из свитчей, но так код, имхо, более читаемый.
не уверен в синтаксисе, давно на GML не писал
while true {
var num = irandom_range(0, 60);
if (num < 20 || num > 40) break;
}
Господа, я тут недавно начал осваивать сурфейсы. Собсна вопрос, как на сурфейсе отрисовывать анимированный спрайт?
Отбой, уже сам разобрался
Не работает нихуя.
У меня есть хуйня, при помощи которой можно выкидывать предметы из инвентаря. Выкидываются они по окружности, как на рисунке, но в красные области по бокам выкидывать нельзя, потому что предмет там застревает с нихуя и его нельзя подобрать. Следовательно мне нужно исключить области от 330 до 30 и от 150 до 210 градусов. Если я пишу
var itemdir;
if(irandom(30)){
itemdir = irandom(150);
} else {
itemdir = irandom_range(210, 330);
}
, то нихуя не работает.
Ёбаный высер Абу не может нормально показывать табы. Вот лучше:
var itemdir;
if(irandom(30)){
itemdir = irandom(150);
} else {
itemdir = irandom_range(210, 330);
}
Конечно не работает, ты же хуйню написал, а я не знал куда оно тебе нужно и сделал для твоего примера.
Для нового примера сойдет такой код:
rand = irandom_range(30, 270);
if(rand >= 150)
rand += 60;
Уже нашёл, спасибо.
enum item {
item1 = 1,
item2 = 2,
...
item100 = 100,
}
Как мне в irandom_range(1, 100) убрать, скажем, тридцатый номер?
Можно сделать
var item = choose(irandom_range(1,29),irandom_range(31,100))
или просто
item = choose(item.item1,item.item2,item.item5)
если веще мало.
1920x1012, 0:43
Ты не о том паришься.
Разбивай на скрипты и регионы смело.
Я тоже долго парился о такой фигне.
Да я все время блять не о том парюсь из-за своего ебаного перфекцеонизма. Тем более я еще даже на стадии прототипирования, где по идее велосипедить и костылить вполне норма, но нет блять, мне нужно сразу все в финальной архитектуре и с минимальной нагрузкой на железо. Но в принципе так, как ты скинул, я себе все это дело и представлял. Мде, работа прогером явно не для меня.
Вот нашел чем удивить. Когда я только начинал, точно так же пытался всё сделать максимально эффективно. Например по мтнимуму вводил новые переменные, они же память занимают! Лучше я одну и ту же переменную буду использовать как таймер для всех фаз и всех состояний. Но это же полная хуйня.
Сейчас уже во-первых меньше парюсь, а во-вторых на автомате многие действия делаю. Типо того, чтобы в for цикле не вычислять одно и то же каждый раз, шаблонно инициализирую скрипты, сравниваю друг с другом квадраты расстояний и т
Д.
И всё равно, когда требуется написать что-то не требующее оптимизаций (инвентарь например, или эффект в паузе) просто кайфую. Писать получается в три раза быстрее, а код, по сути, такой же точно выходит.
>Как заставить скрипт выполняться несколько раз?
https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml language overview/401_11_for.html
Ну то есть 2 вариант. Жаль. Было бы прикольно, если бы была команда по типу "повторить" выполнение скрипта и писать ее в самом скрипте.
>если бы была команда по типу "повторить" выполнение скрипта
так у тебя степ каждый кадр это делает
Но мне это нужно не в степе, а внутри самого скрипта, пока степ "спит". А кстати, можно ли вызвать скрипт в теле его самого?
>внутри самого скрипта
а почему бы и нет?
>To execute a script from an object or a time line you can use the Execute Script action , but you can also call it in a code box using the actual script name as if it were a function or even by using the GML function script_execute.
script_execute(scr, arg0, arg1, arg2, ...);
Да, я уже проверил, правда оказалось, что это не совсем то, что нужно, потому что без степа теперь скрипт не будет учитывать столкновения, которые могут возникнуть во время движения в скрипте. Так что буду все же вызывать скрипт степом несколько раз.
Кинешь игру заценить?
>как Gamemaker экспортирует в html5
Очень хорошо, он из GML генерирует аналогичные функции на js и потом обфусцирует их. Правда, некоторые функции иногда могут не работать.
Можно использовать скелетные анимации.
Он это делает весьма непредсказуемо. В моей игре он например отрубил партиклы к хуям. Плюс почему-то добавился статтеринг и хуй ты пойми откуда.
Было играбельно, но как-то вот не радовало.
Переписал на фазере и стало заебись.
Анон, выручай.
Проснулся из глубокого сна, лол.
В 2011 баловался с GM 8.0., в 2012 купил в стиме game maker stuido за даллары, но так нихуя и не сделал, но потом узнал, что моя лицензия походу стала бесплатной.
Что там сейчас в 1.4? Можно ли на ней делать и релизить бесплатные игры в том же стиме? Можно ли монетизировать рекламой внутри игры?(да, влажные фантазии, просто не смог найти адекватной лицензии). В том же юнити все просто, получаешь больше 100к $ - покупай лицензию.
Или для все этого нужно покупать анальную 2.0 студию?
Смотрю гайди, часто пишут. По логике нарисовать объект, но он и так сука есть. Зачем нужно это?
Потому что draw_self изначально есть у всех объектов, но создав даже пустой скрипт в событии draw, оно продает и тебе необходимо указать его явно, не сделав этого и запустив игру у тебя просто не будет рисоваться тот спрайт который ты указал в настройках объекта
пропадает*
Благодарю
А как же мне быть? Тратить тонну бабла особо не охота, пока я не получу хоть какой-то играбельный результат из своих копаний с этим движком.
Писать свои алгоритмы поиска пути..? Да нет, спасибо.
Есть ещё какие-то варианты? Или, мб, ломаная версия (только на период разработки. Как только я начну собирать проект я обязательно куплю лицензию)
>Тратить тонну бабла особо не охота
Берешь коммерческий продукт для разработки. Говоришь что тратить бабла не охота. Логика?
>Есть ещё какие-то варианты?
Дохрена. От взять старую ломаную пиратку гамака до фришных инструментов типа с++. Выбирай на вкус.
>взять старую ломаную пиратку гамака до фришных инструментов типа с++
и через какой отрезок времени будет готов прототип на гмл и через какой на цпп?
ну конечно если это не match3 :3
>тратить бабла не охота
Не охота, до тех пор, пока то, что я делаю не оформится в играбельный вид. Я же говорю, в целом, я более чем готов платить за лицензию. Но какой смысл покупать её, если, я не знаю, я где нибудь в середине пойму, что мне не хватает возможностей? Или, там, что всё лагает как кусок говна.
Потом я, в любом случае, купил бы лицензию чтоб собрать проект
Ну вот написал я допустим прототип сайдскроллера, в котором можно бегать, прыгать, эйрдешаться и даже умирать от падения со слишком большой высоты. Появилось некое вдохновляющее чувство законченности. Но нутром я понимаю, что код еще можно в сто раз удобоваримее переписать (хоть он и сейчас практически идеально работает, не нашел пока каких-то видимых багов), а также боюсь, что через неделю, когда у меня будет настроение вернуться к коду, я могу все позабывать уже (хотя это вряд ли).
Пока что сам себя обнадеживаю, что это прототип, так что над качеством кода можно не париться. Но когда дело дойдет до "чистовика", как подойти к этому вопросу? Нет у меня особо глубокого понимания, чем принципиально отличается "релизный" код от препродакшенового, и когда я смогу сказать себе "вот так и оставь". Хотя мб это во мне перфекционизм играет (он мне в сосничестве всю жизнь поломал, сейчас каждый день живу, сражаясь с ним), я хз.
В общем, тл;др - через что чаще всего должен пройти прототипный код, чтобы стать релизным? А то боюсь пока дальше новые механики писать, боюсь, что будет такая каша, что потом либо все переписывать придется, либо будет неоптимизированная параша.
> расскажите, когда кодер понимает, что его код
как только он написан. тут, понимаешь, без реальных образцов разного кода не обойтись. лаконичность (DRY, KISS) очень растяжимое понятие. кто-то жарит красивые однострочники, чтобы вместо 500 строчек было 100, а кому-то надо 100 строк без извратов с синтаксисом, третий напишет 1500 строчек с очень продуманным api и максимально высокой отчуждаемостью, а четвертый жахнет в 20 строк, но с миллионом тормозных зависимостей и "небольшим" сайд-эффектом. и автор каждого решения будет считать свой код правильным и хорошим. важно иметь опыт в каждом из этих подходов - тогда код становится инструментом. чем длиннее инструкция к молотку (комментов к коду) - тем больше он говно. и еще важно пройти этап тяжелых задач (кодеры постоянно комплексуют из-за тривиальных задач). чтобы желание "все переписать" отбилось, чтобы не плодить лишние классы... чтобы не было оверинжиниринга, чтобы у написание кода была прозрачная цель. и вот когда оба этих "важно" пройдены - только тогда ты можешь смастерить честный молоток, а не ходить по галочкам "меньше строчек" и "полное покрытие тестами". хороший код пишется медленно (пусть и быстрее из раза в раз), плохой быстро. сила в том, чтобы стараться везде засунуть говнокод, но угадывать места, где этого делать не стоит.
> через что чаще всего должен пройти прототипный код, чтобы стать релизным
через зеленую кнопочку "релиз" в админке стима, например.
с опытом
например я елси посмотрю свой код год назад у меня рукалицо, и я уверен что через год у меня будет такое же чувство если я буду смотреть на свой код в текущий момент
но вообще не еби мозги, прототип всегда может быть таким, если работает то заебись, потом отрефакторишь, когда общая картина появится
Поясните за компиляцию?
https://www.youtube.com/watch?v=BPJ4hCfTZEM
Лично у меня в игре где мало объектов и сложной логики разницы нет, но собираю в yyc
И это я только две анимации впихнул. Хуль так сложно? Как белые люди это делают, что у них ничего не застревает? А я еще наивный дебил хотел хитбоксами все захуярить, я ж ебанусь это вручную хуярить все.
1392x868, 0:16
Неправильный подход.
Сделай прямоугольник вокруг персонажа и считай коллизии по нему. Для всех его анимаций. Да, при этом у тебя какая-нибудь вытянутая вверх рука будет в потолок заходить в некоторых местах. Ну и что? Все так делают, никого не напрягает.
Я задал своему персонажу width и height и считаю коллизии по ним. Они не меняются вообще никогда. По колижн маскам считаю только столкновения с другими объектами.
единственный момент, когда рамка в стену уходит - залезание на препядствия. Для этого костыли стоят.
Школу прогуливал.
теорема Пифагора
А вообще зачем тебе рассчитывать ее, если ты задаешь hspeed и vspeed, и объект автоматически движется?
>зачем тебе рассчитывать ее, если ты задаешь hspeed и vspeed, и объект автоматически движется?
Затем, что он как раз таки начинает автоматически двигаться, и движение врядли как-то можно отменить не приравняв эту самую скорость к нулю. Мне нужен был именно расчет без движения.
А вообще сейчас хорошенько прогулялся по городу и понял что скорость можно найти по принципу point_distance(x, y, x+hspeed, y+vspeed).
Надеюсь подводных камней в таком методе нету.
Ты действительно поехавший.
У меня маска была в самой сердцевине персонажа, иногда игнорировала голову и конечности и пр. Думал, что при обволакивании будут слишком большие зазоры между препятствиями и персонажем. Окей, спасибо, попробую обволакивать. Прямоугольник, кстати - отдельный объект или в дро отрисовываешь?
Я просто его в draw event нарисовал, для наглядности.
У меня есть энное количество отдельных спрайтов, которые должны быть соединены друг с другом и вращаться как-то так, чтобы красиво было. Как автомат с магазином и лежащими на нем руками.
Но как только я начинаю эту ебалу вращать, она расплывается по всему экрану. Я понимаю, что для этого надо смещать все добро через тригонометрические функции, плюс появилась идея учитывать оффсеты спрайтов, но я не могу обволочь эти мысли в какую-то понятную для всех, для гейммейкера и для себя самого форму.
Есть ли где-то видеоуроки или хотя бы текст об этом? Во всех туториалах на ютубе пилят очередную говноспрайтовую РПГ, а у меня система анимации ближе к флешевой, многокадровые спрайты мне не подходят никак.
Пытаюсь сделать параллакс скроллинг в GMS2.
Все бы ничего, но во время движения с краю экрана появляется вот такая полоска, а когда персонаж останавливается, бэкграунд резко дергается на ширину этой самой полоски. Объект, на котором висит код параллакса загружается самым первым, код находится в Step Event, пробовал пихать его в End Step и Begin Step, но ноль эффекта
1. Если я верно понял, триалка не ограничена по времени и можно хоть до усрачки изучать триал, и даже полноценно пилить в нём своего игоря?
2. Что там с физикой, есть хоть какие-нибудь зачатки?
У тебя какого размера БГ? Сдаётся мне, что ширина у него с твой экран. Поэтому если ты его сдвигаешь, то остаётся неочищенный участок старого application_surface.
Ты попробуй галочку поставить в свой бэкграунд Horizontal Tile. Что изменится?
Триал не полноценный.
Я полную версию купил, когда обнаружил, что в триале нельзя создать больше одного тайлсета. Знаю что какие-то функции path в триале ограничены, какие-то gpu.
Что там с физикой - без понятия. Она там есть. Я использую свою.
Ничего не меняется. Попробовал использовать в два раза более широкое изображение — то же самое.
Скачал, посмотрел, некоторые вещи осваиваются интуитивно, это очень хорошо.
Вопрос такой. Есть объект, который постоянно должен "падать", ибо гравитация. Как это реализовать? Порылся в ивентах, не нашёл "пустого" события, которое должно выполняться всегда, без условий.
Ну или ткните в ссыль с такими вот базовыми туториалами.
А инди-песочницу гамак2 осилит? Пример - Stardew Valley.
Подозреваю, что этот экспортер делает некислую прибыль, так что вряд ли забесплатно сделают. Но если они выкатывают при этом такой продукт, то не жалко.
По-моему, легче спросить, что он НЕ осилит. В 2д, разумеется.
Осилит. Но мне в гамаке сложновато работать с большими проектами.
В GMS2 (и в более ранних версиях роде тоже) есть встроенный туториал в духе "шаг за шагом делаем первую примитивную игру". Там делов на полчаса, и практически все базовые вещи научишься делать. Это гораздо лучше, чем видосы-туториалы, где бородатый хер два часа чавкает в микрофон, объясняя 2 строки кода смотреть.
Не могу этого сделать по ряду причин, но проблему я более-менее решил.
Я пришел к выводу, что переменная, которая получается из команды camera_get_view_x(view_camera[0]) все время отстает на один фрейм от настоящего положения камеры. Тогда я поставил условие, что бэкграунд двигается только при условии, что скорость персонажа не равна нулю. Это, конечно, как-то костыльно, и вылезла еще пара проблем, но их оказалось легко решить, и все работает. Наверное, есть какой-то более изящный путь, если найду, то поменяю систему, конечно.
Хочу запилить Монополию, но никак не могу придумать - как лучше реализовать улицы? Делать как отдельные объекты или как?
Вариантов куча. Первое, что приходит в голову - завести массив / словарь / список, и в процедуре генерации карты заводить в него нужные данные с тем же индексом, что у тайла в тайлмапе. Обращение к тайлам организовать через геттер, в котором эти данные будут доставаться.
А разве не подходит вариант сделать 40 объектов для каждого поля, и у каждого объекта - свои переменные?
Просто мне такой способ кажется очевидным, но при этом - костыльным. Не может же все быть настолько просто. Или может? И нет смысла изъебываться, если можно все сделать просто?
И то верно. Спасибо, анон.
Проблема в гамаке, в геймпаде или во мне?
Безотносительно: зачем игре видеть геймпад когда она свёрнута?
Она клавиатуру-то не видит, когда ты табнулся в другое окно. И это правильно.
Просто таким образом можно было бы намеренно или случайно вызвать ошибку, свернув игру в определенный момент, но уже вроде нашел, как это исправить.
Для поворота модельки я сделал вот:
var mouse_angle = point_direction(x, y, mouse_x, mouse_y);
if (mouse_angle > 310 || mouse_angle < 50)
image_angle = mouse_angle;
Как сделать подобное ограничение для пуль, которые вылетают. Пробовал часа три и нихуя не придумал, собсна. Вот мои самые удачные идеи (пикрилы)
Есть функция clamp, которая позволит сделать все то же самое, но в одну строчку.
И я не понял, в чем твоя проблема. Все должно работать. Скорость пули можно записать через speed ее экземпляра, направление через direction, которое ограничить через clamp.
Я пробовал делать через clamp, но это не даёт никакого эффекта. Хотя может быть просто я криворукий (что более вероятно) и попробую ещё, как приду домой, спасибо. Если не получится, спрошу ещё раз, надеюсь на помощь :3
А да. Не дало эффекта, это значит, что она просто не работала, и камы-пули продолжали лететь из очка вертолета, будто ограничения и вовсе нет. Но скорее всего я просто жиденько обосрался и попробую еще раз переписать.
Попробовал вот так:
direction = clamp(point_direction(x,y,mouse_x,mouse_y),310,50) + random_range(-4,4);
Не работает ниже 0, пробовал через -50, пробовал через кламп 310,0 + кламп 0,50 — ни в какую.
var куда_стрелять = point_direction(x, y, mouse_x, mouse_y);
if ((куда_стрелять < 180) {
куда_стрелять = clamp(куда_стрелять, 0, 50);
} else {
куда_стрелять = clamp(куда_стрелять, 310, 360);
}
Не держись за гамак. Если чувствуешь, что тебе тесно в игровом конструкторе - переходи на полноценный движок. Базарю, чем позже перейдешь, тем больше пожалеешь о потраченном на все эти гамаки времени впоследствии.
Сложные вопросы задаёшь.
В GMS2 есть возможность подключать какие-то явовские списки. Я сильно не вникал, т.к. меня ds полностью устраивают.
По ООП фигово, только самому имитировать скриптами. Функции нормально строятся.
Странные вещи говоришь.
Я лично я в гамаке совершенно не вижу игрового конструктора. Да, в нём можно включить физику "искаропки", заставить объекты перемещаться по путям и делать прочие примитивные вещи.
Но это только верхушка айсберга. На самом деле с гамаком можно сделать намного больше. Абсолютно всё, что может понадобиться для хорошей 2д игры.
Там ак нужно регать, меня по опи не вычислют?
Насколько юнити сложнее чем гамак, что лучше изучать: гамак или юнити?
Программирование изучай, даун.
Гамак легче чем Юнити. 2D в Юнити это особая форма извращенства, когда есть гейммейкер (есть ещё Годот, но зочем).
Исправление будет в ГМС3, можете оформить предзаказ за $80 уже сейчас.
Про удобство. Внешний вид - ну да, типо современно
Вкратце вопрос звучит так - как сделать чтобы импортируемые спрайты не выглядели как дерьмо на фулскрине с 1920х1080?
Развернуто - импортирую спрайты для своего платформера, и они выглядят как параша, даже в оконном режиме на 640х320.
Притом что в комнате при редактировании они выглядят хорошо? Что я делаю не так? Дрочился с настройками в опциях к платформе (в данном случае шиндовс) - нехуя не помогло.
Нагуглил посты на форме гмс и хелруме, часть из них помогла решить проблема с бекграундами (хуярил слишком большие картинки) но вот с обычными объектами я хз че делать. Пробовал уменьшать через image_xscale - не работает.
Натыкался на https://forum.yoyogames.com/index.php?threads/scaling-resolution-and-aspect-ratio-management-for-gms1-gms2.7106/ но по его уроку нехера не вышло, даже с учетом адаптации кода под текущую версию гамака.
Вообще я так понял есть магические surface которые как-то это все должны хендлить, но мои вялые попытки написать чето используя данную функцию не дали ровным счетом нехуя. Шо делать
Почему качество спрайта так убивается, еще даже не в полноэкранном режиме?
Разрешение вьюпорта в первой загружаемой комнате (или самой комнаты, если вьюпорты отключеры) задают разрешение всей игры. Разрешение остальных комнат масштабируется под него. Может в этом проблема?
Снимай штаны, буду сосать. Именно в этом была трабла, писос я дебич.
да не надо
имею ввиду,что можно ли за 48 часов на нем что-то сносное склепать,если есть желание и идеи
da
Есть смысл париться, если в крупнопиксельной игре разрешение монитора не делится нацело на разрешение игры. Тогда появятся некрасивые деформации пикселей.
Эх, ну да, беспокоясь о бомжах на старых пеках, я и забыл, что уже есть челики с разрешениями больше 1080р, но меньше 2160р. Сука, у меня в игре дохуя геометрии даже в банальных игровых действиях, вот чего мне блять для полного штанов счастья не хватало, так это рескейлить игру под другие разрешения.
Как это вообще делают? Новый комплект ассетов рисуют или что? Это ж ебануться можно. Лучше уж тогда в рамку нахуярить. Или просто каждый ассет вручную растягивают до нужных пропорций и потом ретушируют?
Дешевый и сердитый вариант, который в гамаке легко реализуется, это если у игрока нестандартный монитор, то дать ему возможность либо играть в полноэкранном режиме и наблюдать пиксельные деформации, либо запустить игру в окне с подходящим разрешением. К тому же, чем больше разрешение, тем меньше эти деформации заметны. Самое плохое - это когда скейлить надо в 1.5 раза. Еще была идея рисовать все на текстуре 2160p, а потом уменьшать ее до нужного разрешения со сглаживанием. В графическом редакторе результат нормальный, а в гамаке не пробовал, удобно ли это делать.
Я вот думаю насчет варианта либо полноэкран с деформациями, либо полноэкран нормальный, если человек настраивает разрешение у себя или у него оно само по себе подходящее, либо сделать полноэкран с рамочками, обрамленными каким-нибудь артом. Это, кстати, в гамаке можно сделать как-то? Я видел это у некоторых игр, и смотрелось вполне неплохо.
Галочки "сделать полноэкран с рамкой" в настройках гамака нет, можно только черные полоски. Хотя странно, почему они такую фичу не добавили, вроде эта идея сама собой напрашивается. Наверно, это можно сделать с помощью своих костылей.
Ну я и не думал, что в гамаке есть для этого галочка, конечно костылями.
Есть платформа, которая движется вертикально вверх
create
vdist=6;
direction=90;
vspeed = 6
alarm[0]=1;
alarm0
direction=90;
alarm[0]=vdist*vspeed;
Все коллизии рассчитываются по отдельной маске в объекте игрока, через присоединение твердых объектов к родительской группе oParSolid.
Есть две проблемы:
1. Игрок застревает в вертикально двигающейся платформе при прыжках на ней. Причем такого нет на горизонтальных платформах, больше он не застревает нигде, от слова совсем.
Пробовал делать отдельные группы, и писать для них костыли, но не помогает.
Как это пофиксить? В какую сторону копать?
2. Есть код который описывает врезание в потолок игрока (в степе игрока)
if (place_meeting(x,y-1,oParSolid) and (v >=0))
{
hp = 0
}
Поэтому при прыжках по вертикально движущейся платформе, когда он застревает в платформе, его хп становится равным 0, игра рестартуется. Я понимаю что наговнокодил, но как сделать иначе - хз.
Есть платформа, которая движется вертикально вверх
create
vdist=6;
direction=90;
vspeed = 6
alarm[0]=1;
alarm0
direction=90;
alarm[0]=vdist*vspeed;
Все коллизии рассчитываются по отдельной маске в объекте игрока, через присоединение твердых объектов к родительской группе oParSolid.
Есть две проблемы:
1. Игрок застревает в вертикально двигающейся платформе при прыжках на ней. Причем такого нет на горизонтальных платформах, больше он не застревает нигде, от слова совсем.
Пробовал делать отдельные группы, и писать для них костыли, но не помогает.
Как это пофиксить? В какую сторону копать?
2. Есть код который описывает врезание в потолок игрока (в степе игрока)
if (place_meeting(x,y-1,oParSolid) and (v >=0))
{
hp = 0
}
Поэтому при прыжках по вертикально движущейся платформе, когда он застревает в платформе, его хп становится равным 0, игра рестартуется. Я понимаю что наговнокодил, но как сделать иначе - хз.
Ты используешь какие-то безумные функции искаропки, не зная толком, как они работают.
Я тебя умоляю, не пользуйся алармами, ибо ты не знаешь, в какой момент тикает их таймер.
Это раз.
Два. Про платформы.
Хуй знает, что ты там наворотил но скорее всего проблема в очерёдности выполнения кода. Если ты хочешь, чтобы платформы двигали игрока, то пусть все перемещения платформ и двигание ими игрока происходят в begin step а все самостоятельные перемещения игрока происходят в step.
Про врезание в потолок.
Во ты нахуевертил. Place meeting это во-первых ресурсозатратная функция, во-вторых в её работе есть много нюансов. Использовать её следует только в самых простых случаях.
Для проверки столкновения с потолком лучше напиши свою функцию, которая будет проверять, есть ли в определённых точках над игроком потолок или нет.
Например как делаю я:
У меня есть функция "gridcol_line", которая проверяет: если провести линию из точки А в точку Б, будет ли коллизия на этой линии.
Чтобы понять, есть ли земля под ногами, мне достаточно сделать
var ground_check = gridcol_line(x-width/2,y+height/2+1,x_width/2,y+height/2+1)
На самом деле для этого у меня просто функция ground_check() и использую я её типа "if !ground_check() , это я тебе для примера расписал.
Поэтому я не перепутаю землю с потолком никогда. Тебе рекомендую то же самое. Проверяй только то, что тебе необходимо и только тогда, когда тебе необходимо.
Ты же каждый шаг одновременно проверяешь, не двигаешься ли ты вверх и при этом проверяешь все коллизии со всеми объектами препятствий во всех точках игрока. Ты в коде перемещения установи проверки типа
мои скорости vx и vy
Если в точке x+vx и y+vy place_meeting даёт false - перемещаюсь в точку x+vx и y+vy
Иначе начинаю перемещаться по одному пикселю по x пока не встречу препятствие, затем по одному пикселю по y.
Вообще корень зла у тебя, видимо, в коде перемещения (А он у тебя есть вообще? Ты походу vspeed hspeed используешь - а это тоже искаропки). Гугли на ютубе game maker pixel perfect movement. И одновременно изучай вот это невероятно полезный туториал : https://forum.yoyogames.com/index.php?threads/on-slopes-and-grids-subpixel-perfect-topdown-movement-and-collision-line-without-objects.4073/
В первую очередь ты должен научиться делать ТОЧНЫЕ до пикселя коллизии и перемещения.
А ты в курсе, что если у тебя препятствие с координатами левой стороны 0 и правой стороны 10, а твой игрок это. например, точка размером 1*1 пиксель, то для твоего игрока
var check_left = place_meeting(0,0, obj_collision) даст true
а
var check_right = place_meeting(10,0, obj_collision) даст false
и то же самое с низом и верхом.
Ты используешь какие-то безумные функции искаропки, не зная толком, как они работают.
Я тебя умоляю, не пользуйся алармами, ибо ты не знаешь, в какой момент тикает их таймер.
Это раз.
Два. Про платформы.
Хуй знает, что ты там наворотил но скорее всего проблема в очерёдности выполнения кода. Если ты хочешь, чтобы платформы двигали игрока, то пусть все перемещения платформ и двигание ими игрока происходят в begin step а все самостоятельные перемещения игрока происходят в step.
Про врезание в потолок.
Во ты нахуевертил. Place meeting это во-первых ресурсозатратная функция, во-вторых в её работе есть много нюансов. Использовать её следует только в самых простых случаях.
Для проверки столкновения с потолком лучше напиши свою функцию, которая будет проверять, есть ли в определённых точках над игроком потолок или нет.
Например как делаю я:
У меня есть функция "gridcol_line", которая проверяет: если провести линию из точки А в точку Б, будет ли коллизия на этой линии.
Чтобы понять, есть ли земля под ногами, мне достаточно сделать
var ground_check = gridcol_line(x-width/2,y+height/2+1,x_width/2,y+height/2+1)
На самом деле для этого у меня просто функция ground_check() и использую я её типа "if !ground_check() , это я тебе для примера расписал.
Поэтому я не перепутаю землю с потолком никогда. Тебе рекомендую то же самое. Проверяй только то, что тебе необходимо и только тогда, когда тебе необходимо.
Ты же каждый шаг одновременно проверяешь, не двигаешься ли ты вверх и при этом проверяешь все коллизии со всеми объектами препятствий во всех точках игрока. Ты в коде перемещения установи проверки типа
мои скорости vx и vy
Если в точке x+vx и y+vy place_meeting даёт false - перемещаюсь в точку x+vx и y+vy
Иначе начинаю перемещаться по одному пикселю по x пока не встречу препятствие, затем по одному пикселю по y.
Вообще корень зла у тебя, видимо, в коде перемещения (А он у тебя есть вообще? Ты походу vspeed hspeed используешь - а это тоже искаропки). Гугли на ютубе game maker pixel perfect movement. И одновременно изучай вот это невероятно полезный туториал : https://forum.yoyogames.com/index.php?threads/on-slopes-and-grids-subpixel-perfect-topdown-movement-and-collision-line-without-objects.4073/
В первую очередь ты должен научиться делать ТОЧНЫЕ до пикселя коллизии и перемещения.
А ты в курсе, что если у тебя препятствие с координатами левой стороны 0 и правой стороны 10, а твой игрок это. например, точка размером 1*1 пиксель, то для твоего игрока
var check_left = place_meeting(0,0, obj_collision) даст true
а
var check_right = place_meeting(10,0, obj_collision) даст false
и то же самое с низом и верхом.
Это мой первый проект, я стараюсь чето учить + использовать это.
Про алармы не совсем понял - я читал документацию и кажется понимаю. Там же все подвязано на скорости комнаты, утрировано.
Про гайды спасибо, обмажусь.
Еще вопрос, чем плох vspeed hspeed?
>Про алармы не совсем понял - я читал документацию и кажется понимаю.
Тогда скажи, в какой момент тикает таймер аларма? Что произойдёт раньше, room_end event или тик аларма? Или аларм тикает в начале фрейма а не в конце? Я вот, например, не в курсе. Если погуглить, то наверняка найду. Но в любом случае, таймер, который тикает вне твоего кода - это очень, очень плохо. Может привести к тяжёлым последствиям.
>Еще вопрос, чем плох vspeed hspeed?
То же самое. Когда происходит это перемещение? Твои платформы тоже перемещаются при помощи vspeed hspeed? Значит ты не контролируешь того момента, когда перемещается игрок, а когда платформа.
Допустим платформа создана раньше игрока. Тогда, возможно, сначала гамак будет двигать платформу, а потом игрока.
Тогда, если игрок стоит на платформе, которая едет вверх что будет?
Платформе же пофигу на коллизии с игроком? Она просто двинется вверх.
Потом начнёт своё движение игрок. А у него вертикальная скорость меньше, чем у платформы или нулевая. И он окажется внутри платформы.
Потом будет степ ивент. Если платформа создана раньше, и именно платформа перемещает игрока, то она его передвинет куда надо и игрок ничего не заметит.
А если игрок создан раньше? Тогда его код будет исполнен первым и он заметит коллизию и самоуничтожится.
Это раз.
Два: у тебя все скорости целочисленные? Наверняка нет. Тогда перемещение искаропки будет ставить твоего игрока в дробные координаты. И ты, для вычисления коллизий, будешь работать с float переменными. И это может привести к неожиданным для тебя результатам.
Приведу пример из моей практики - когда я делал лазерный прицел, который мог светить под произвольным углом и должен был прерываться на препятствиях, я заметил, что в некоторых редких случаях луч начинает светить сквозь препятствие. Разбирался долго пока не открыл для себя, что есть такая штука, как точность вычислений. И если сравнивать float который должен быть 0 с настоёщим int 0, то float 0 может оказаться больше или меньше, а может быть и равен. Поэтому иногда коллизия просто не засчитывалась.
Поэтому всегда лучше использовать для координат int.
>Про алармы не совсем понял - я читал документацию и кажется понимаю.
Тогда скажи, в какой момент тикает таймер аларма? Что произойдёт раньше, room_end event или тик аларма? Или аларм тикает в начале фрейма а не в конце? Я вот, например, не в курсе. Если погуглить, то наверняка найду. Но в любом случае, таймер, который тикает вне твоего кода - это очень, очень плохо. Может привести к тяжёлым последствиям.
>Еще вопрос, чем плох vspeed hspeed?
То же самое. Когда происходит это перемещение? Твои платформы тоже перемещаются при помощи vspeed hspeed? Значит ты не контролируешь того момента, когда перемещается игрок, а когда платформа.
Допустим платформа создана раньше игрока. Тогда, возможно, сначала гамак будет двигать платформу, а потом игрока.
Тогда, если игрок стоит на платформе, которая едет вверх что будет?
Платформе же пофигу на коллизии с игроком? Она просто двинется вверх.
Потом начнёт своё движение игрок. А у него вертикальная скорость меньше, чем у платформы или нулевая. И он окажется внутри платформы.
Потом будет степ ивент. Если платформа создана раньше, и именно платформа перемещает игрока, то она его передвинет куда надо и игрок ничего не заметит.
А если игрок создан раньше? Тогда его код будет исполнен первым и он заметит коллизию и самоуничтожится.
Это раз.
Два: у тебя все скорости целочисленные? Наверняка нет. Тогда перемещение искаропки будет ставить твоего игрока в дробные координаты. И ты, для вычисления коллизий, будешь работать с float переменными. И это может привести к неожиданным для тебя результатам.
Приведу пример из моей практики - когда я делал лазерный прицел, который мог светить под произвольным углом и должен был прерываться на препятствиях, я заметил, что в некоторых редких случаях луч начинает светить сквозь препятствие. Разбирался долго пока не открыл для себя, что есть такая штука, как точность вычислений. И если сравнивать float который должен быть 0 с настоёщим int 0, то float 0 может оказаться больше или меньше, а может быть и равен. Поэтому иногда коллизия просто не засчитывалась.
Поэтому всегда лучше использовать для координат int.
Не подумал о проблеме с этой стороны, спасибо, так стало в разы понятнее.
Пойду думать как переписать все это дерьмо, чтобы работало в одной вселенной.
1024x768, 0:11
Платформа и игрок движутся с одинаковым ускорением и одинаковой максимальной скоростью, но фактически у игрока ускорение чуть меньше и чем дольше движется платформа, тем больше отстаёт от неё игрок.
Проблема решилась переносом кода платформы в begin step event
>Place meeting это во-первых ресурсозатратная функция
С чего это проверка пересечения прямоугольников стало ресурсозатратным?
С того, что во-первых это далеко не всегда пересечение прямоугольников. Гамак поддерживает precise per frame collisions.
А во-вторых объектов коллизий может быть много, а проверка коллизий может происходить много раз за фрейм.
Коллизии это то, что стоит держать в узде.
А твоя gridcol_line как работает, проверяет пересечение линии только с тайлами? А с движущимися объектами как проверяешь столкновения, если не place_meeting?
Моя движущаяся платформа это совершенно отдельный от коллизий объект.
Моя игра не плаформер и движущиеся платформы и препятствия не являются в ней основой геймплея. Поэтому я сделал принципиально другую механику.
Если в комнате есть плаформа, в скрипте ground_check() включается дополнительная проверка, которая работает только при движении вниз. Она проверяет две точки в основании ног игрока на столкновение с плаформой.
if(instance_exists(obj_platform) && (position_meeting(x-sprite_width/2,y+sprite_height/2,obj_platform) || position_meeting(x+sprite_width/2-1,y+sprite_height/2,obj_platform)))
{
return 1;
}
Если такое столкновение есть, у игрока, в дополнение к флагу "я на земле" загорается флаг "я на платформе" и запомнает id платформы, на которой он находится.. Если флаг "я на платформе горит" игрок проверяет, находится ли он всё на той же платформе, и если да, то сообщает именно этой платформе, что он на ней, зажигая на ней флаг "на мне игрок".
Сама платформа перемещается в begin step. Если на платформе горит флаг "на мне игрок". то она передаёт игроку на сколько пикселей она переместилась по горизонтали и вертикали в начале шага.
В свою очередь игрок в середине шага, обладая знаниями о том, на сколько пикселей переместилась платформа под ним при помощи скрипта gridcol_move перемещает себя на столько же пикселей. И только после этого при помощи того же скрипта gridcol_move перемещает себя в соответствии со своими скоростями vx и vy.
>>522685
Я очень долго ломал над этим голову, аноне.
В конце концов я решил "делаю игру с увеличенным в 2 раза пикселем". Все интерфейсы, меню, диалоговые окна сделаны так, чтобы если у монитора игрока разрешение 720р они умещались на экране. Все координаты заданы в процентах от ширины или высоты монитора. на мониторах с бОльшим разрешением эти интерфейсы разъезжаются друг от друга или отдаляются.
Соответственно у мониторов с большим разрешением видно большее пространство игрового поля. Поэтому даже на Ultra wide пониторе смотрится отлично.
На мониторах с разрешением меньше 720р в мою игру уже будет нипаиграть. Можно для них сделать костыль, чтобы убрать увеличение пикселя в 2 раза. Но зачем? Разве остались в мире ещё такие мониторы?
Чтобы было понятней вот:
https://2ch.hk/gd/res/476891.html#496629 (М)
Здесь меню в 1080р и в 720р.
Вот инитиализация моей камеры в room_start ивенте
global.camera = camera_create();
width = round(display_get_width()/2);
height = round(display_get_height()/2);
var view_matrix = matrix_build_lookat(x,y,-10,x,y,0,0,1,0);
var projection_matrix = matrix_build_projection_ortho(width,height,0,10000);
view_camera[0] = global.camera;
view_hport[0] = height;
view_wport[0] = width;
camera_set_view_mat(global.camera,view_matrix);
camera_set_proj_mat(global.camera,projection_matrix);
//Enable the use of views
view_enabled = true;
//Make view 0 visible
view_set_visible(0,true);
//Resize and center
//we are fullscreen
surface_resize(application_surface,view_wport[0],view_hport[0]);
if (follow != noone)
{
x_to = follow.x;
y_to = follow.y;
}
x = x_to;
y = y_to;
border_x = view_wport[0]/2;
border_y = view_hport[0]/2;
Моя движущаяся платформа это совершенно отдельный от коллизий объект.
Моя игра не плаформер и движущиеся платформы и препятствия не являются в ней основой геймплея. Поэтому я сделал принципиально другую механику.
Если в комнате есть плаформа, в скрипте ground_check() включается дополнительная проверка, которая работает только при движении вниз. Она проверяет две точки в основании ног игрока на столкновение с плаформой.
if(instance_exists(obj_platform) && (position_meeting(x-sprite_width/2,y+sprite_height/2,obj_platform) || position_meeting(x+sprite_width/2-1,y+sprite_height/2,obj_platform)))
{
return 1;
}
Если такое столкновение есть, у игрока, в дополнение к флагу "я на земле" загорается флаг "я на платформе" и запомнает id платформы, на которой он находится.. Если флаг "я на платформе горит" игрок проверяет, находится ли он всё на той же платформе, и если да, то сообщает именно этой платформе, что он на ней, зажигая на ней флаг "на мне игрок".
Сама платформа перемещается в begin step. Если на платформе горит флаг "на мне игрок". то она передаёт игроку на сколько пикселей она переместилась по горизонтали и вертикали в начале шага.
В свою очередь игрок в середине шага, обладая знаниями о том, на сколько пикселей переместилась платформа под ним при помощи скрипта gridcol_move перемещает себя на столько же пикселей. И только после этого при помощи того же скрипта gridcol_move перемещает себя в соответствии со своими скоростями vx и vy.
>>522685
Я очень долго ломал над этим голову, аноне.
В конце концов я решил "делаю игру с увеличенным в 2 раза пикселем". Все интерфейсы, меню, диалоговые окна сделаны так, чтобы если у монитора игрока разрешение 720р они умещались на экране. Все координаты заданы в процентах от ширины или высоты монитора. на мониторах с бОльшим разрешением эти интерфейсы разъезжаются друг от друга или отдаляются.
Соответственно у мониторов с большим разрешением видно большее пространство игрового поля. Поэтому даже на Ultra wide пониторе смотрится отлично.
На мониторах с разрешением меньше 720р в мою игру уже будет нипаиграть. Можно для них сделать костыль, чтобы убрать увеличение пикселя в 2 раза. Но зачем? Разве остались в мире ещё такие мониторы?
Чтобы было понятней вот:
https://2ch.hk/gd/res/476891.html#496629 (М)
Здесь меню в 1080р и в 720р.
Вот инитиализация моей камеры в room_start ивенте
global.camera = camera_create();
width = round(display_get_width()/2);
height = round(display_get_height()/2);
var view_matrix = matrix_build_lookat(x,y,-10,x,y,0,0,1,0);
var projection_matrix = matrix_build_projection_ortho(width,height,0,10000);
view_camera[0] = global.camera;
view_hport[0] = height;
view_wport[0] = width;
camera_set_view_mat(global.camera,view_matrix);
camera_set_proj_mat(global.camera,projection_matrix);
//Enable the use of views
view_enabled = true;
//Make view 0 visible
view_set_visible(0,true);
//Resize and center
//we are fullscreen
surface_resize(application_surface,view_wport[0],view_hport[0]);
if (follow != noone)
{
x_to = follow.x;
y_to = follow.y;
}
x = x_to;
y = y_to;
border_x = view_wport[0]/2;
border_y = view_hport[0]/2;
Что-то пошло не так. Вот правильная ссылка на пост.
https://2ch.hk/gd/res/476891.html#499433 (М)
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine java version from '10.0.2'.
ЧЯДНТ?
SDK и NDK в порядке, версия GM 1.4
Еще есть такой вопрос - в паинте я рисую пиксели обычного размера, т.е. рисунок получается очень маленьким, если не приближать его. Вопрос такой - можно ли его будет потом четко, без размытия увеличить для игры? Или лучше сразу делать в нужном размере? Или это вообще не так происходит?
>как импортировать пиксели из паинта в игру?
Нажимаешь alt+s для создания спрайта.
Там увидишь кнопочку импорт, жамкаешь на неё и импортируешь.
Хочешь перетащить спрайт в комнату? Создай в комнате assets layer и таскай спрайты мышкой из ресурсов в комнату на этот слой.
>можно ли его будет потом четко, без размытия увеличить для игры?
Можно. Для этого тебе придётся научиться работать с камерой.
>Или лучше сразу делать в нужном размере?
Хуй его знает, что лучше. Когда спрайты маленькие, они занимают гораздо меньше памяти, рисуются быстрее, в дальнейшем все спецэффекты, такие как свет и тень, меньше ресурсов тратят.
Зато всега присутствует скейлинг всего. Насколько я понимаю скейлить менее затратно, чем рисовать сурфейс во весь экран.
Пиксельные спрайты отлично масштабируются в графических редакторах. Выбираешь изменение размеров без сглаживания и всё.
Это нужно делать именно в редакторе, чтобы движок не тратил ресурсы на лишнее масштабирование, хотя зависит от того как много текстур ты собираешься использовать, если минимализм, то большой просадки не будет, но если куча объектов на сцене, то тормоза гарантированы, хотя они будут и без текстур, так как сегодня тонкое горлышко всех игроделов это слабые процессоры, которые почти перестали увеличивать производительность где-то с 2013 года.
Так не надо масштабировать каждый спрайт движком, это действительно затормозит игру.
Достаточно растянуть финальный сурфейс на весь экран подкрутив настройки камеры.
Собственно сами jojo games в своих туториалах рекомендуют растягивать сурфейсы вместо создания сразу больших сурфейсов. Это экономичнее.
В первую очередь, убери нахуй пейнт и возьми редакторы нормального человека по типу aseprite или pro motion ng (первый очень простой и интуитивный и в целом покрывает все нужды в пикселях, второй более профессионален и поначалу ты будешь в нем плавать, но зато потом ты сэкономишь себе тучу времени)
Разница будет только в занимаемом месте на диске, при этом памяти будет сжирать всё равно столько же, но минус твоего способа в том, что если это java или c# машина или браузер, то предложенный тобой способ хуже так как сборщик очистит кэш и после снова придётся подгружать изображение и проводить масштабирование, тогда как в случае с заранее отрисованными текстурами просто будет подгрузка в кэш без лишних действий.
Разница заметна на слабых мобильных устройствах, где использование масштабирования считается крайне плохим тоном и практически нигде не используется, по крайней мере в 2D играх.
Казалось бы косметика, но изменений больше чем кажется.
Вот вопрос возник.
изучил например пользователь гамак, сделал успешно игру, естественно в триальной версии.
Решил выпустить игру на мобилки.
И тут случается пикрил, что в перерасчете на деревянные, более 20к.
Т.к. выпускать с пиратской версии не особо то законно (скорее всего), но покупать за 20 с лихуем лицензию для того, чтобы получиться возможность заработать на детище - бред.
Есть ли законные (или может даже не очень) выходы из этой ситуации
>но покупать за 20 с лихуем лицензию для того, чтобы получиться возможность заработать на детище - бред.
Действительно, такая бредятина - вкладывать средства в свой бизнес, кто этим вообще занимается?
Да, есть. Нужно брать бесплатные проги, если ты нищебродина и боишься сгухи. Есть годот и юнити, а ты сука сухари суши, или денюжку плоти.
Давай начнем с того, что бизнеса как такового (именно в гамак-геййдеве) быть и не может без покупки лицензии (исключая обходные пути)
Я и не говорил о том, что вкладывать деньги в бизнес - это бред.
Порог вхождения уж очень велик для этой страны. Нет никакой гарантии, что твой проект хоть частично окупит вложения (а проверить как-либо это, без покупки лицензии не кажется реальным)
>>524468
>>Нужно брать бесплатные проги, если ты нищебродина
Вот тут ты и обосрался молодой человек. Твои слова как-раз таки и выдают в тебе нищука, который сразу потратит свои сбережения на иллюзорный вклад в будущее, который еще не факт что хоть как-то окупиться, и как я написал выше проверить это ты увы не сможешь.
>нищука, который сразу потратит свои сбережения на иллюзорный вклад в будущее
Какой вклад, ослина, я на бесплатных прогах сижу.
Похоже что таких нет. Была какая-то софтина в которой можно было лепить примитивные шейдеры для гамака, но есть подозрение что фишай там не сделоть.
Я такие вопросы в glsl треде задавал, мне отвечали.
Сам я только самые примитивные шейдеры умею делать.
Тьфу. в Opengl треде.
Ты вопрос задай как следует, тогда и получишь нормальный ответ.
Если ты не ставишь тайл в клетку, то tilemap_get(tilemap_id,cx,cy) в этой клетке вернёт 0.
Если ты сканируешь tilemap_get_at_pixel() то если у тебя размер тайла 16, то например tilemap_get_at_pixel(tilemap_id,0,0) вернёт значение первого тайла, а tilemap_get_at_pixel(tilemap_id,16,0) уже значение второго.
Дано два состояния объекта - скольжение и бег.
Для бега коллизии считываются по отдельно заданному спрайту.
Я решил сделать отдельную маску для скольжения (потому как при выполнении анимации объект становится меньше по вертикали) и тут возникло несколько проблем. Я пробовал mask index и object set mask.
mask index делает все как нужно с точки зрения столкновений, но при этом объект начинает проваливаться в твердые объекты при выполнении анимации скольжения.
Обернуто это вот так:
есть скрипт где задана переменная отвечающая за нажатие клавиши
в степе объекта
if (kSlide ) //&& onGround ) - закоментил переменную чекающую коллизии с твердым объектом, для теста, иначе анимация проигрывается 2 раза с разрывом, это тоже проблема.
{
h=maxH;
hp -= 1 / room_speed
state = SLIDE
if (colRight) colRight - это переменная чекающая коллизия справа
{
oPlayer_t.hp = 0
}
}
ниже в стейт машине, тоже в степе:
switch (state) {
// тут перечисление всех состояний - бег, айдл
case SLIDE:
image_speed = 1.0
mask_index = sPlayerMaskSlide
if kSlideRelease это отпущенная клавиша скольжения
{
mask_index= sPlayerMaskSlide
}
sprite_index = sPlayerSlide
break
Куда стоит копать для решения проблемы? Есть идеи?
Дано два состояния объекта - скольжение и бег.
Для бега коллизии считываются по отдельно заданному спрайту.
Я решил сделать отдельную маску для скольжения (потому как при выполнении анимации объект становится меньше по вертикали) и тут возникло несколько проблем. Я пробовал mask index и object set mask.
mask index делает все как нужно с точки зрения столкновений, но при этом объект начинает проваливаться в твердые объекты при выполнении анимации скольжения.
Обернуто это вот так:
есть скрипт где задана переменная отвечающая за нажатие клавиши
в степе объекта
if (kSlide ) //&& onGround ) - закоментил переменную чекающую коллизии с твердым объектом, для теста, иначе анимация проигрывается 2 раза с разрывом, это тоже проблема.
{
h=maxH;
hp -= 1 / room_speed
state = SLIDE
if (colRight) colRight - это переменная чекающая коллизия справа
{
oPlayer_t.hp = 0
}
}
ниже в стейт машине, тоже в степе:
switch (state) {
// тут перечисление всех состояний - бег, айдл
case SLIDE:
image_speed = 1.0
mask_index = sPlayerMaskSlide
if kSlideRelease это отпущенная клавиша скольжения
{
mask_index= sPlayerMaskSlide
}
sprite_index = sPlayerSlide
break
Куда стоит копать для решения проблемы? Есть идеи?
Честно пытался помочь тебе, и даже понял примерно что и для чего тебе это нужно.
Даже есть несколько предположений, в первую очередь связанных с тем, что у тебя центровка спрайтов разная. Ещё я бы обратил внимание на то, что ты СНАЧАЛА меняешь маску, а ПОТОМ меняешь спрайт.
mask_index= sPlayerMaskSlide
sprite_index = sPlayerSlide
Должно быть наоборот.
О предложенных решениях уже думал, но они не решают проблему, хех. Буду дальше ковырять.
Нужно это для того чтобы успешно проезжать под препятствиями.
А чего думать? Напиши дебагескую тулзу, которая будет рисовать тебе маску спрайта каждый шаг и смотри что происходит по шаг за шагом.
Так и сделал. Это помогло понять и пофиксить некоторые мелочи, и основную проблему я решаю костылем - поставил у второй маски центр по верхнему краю и добавил мини прыжок после после перехода из состояния скольжения в бег - по какой-то причине маска застревает после этого перехода. Показал на картинке.
А теперь я бы порекомендовал тебе всё же разобраться, в какой момент твой персонаж съезжает на пиксель вниз и пофиксить это.
Коллизии - это основа основ и это очень просто. Костыли в коллизиях повлекут за собой непредвиденные проблемы, когда ты будешь добавлять разнообразные механики.
Купи через стим, там гораааздо дешевле
скорее нет чем да.
Так и сделал тащемта.
УРА НАКОНЕЦ-ТО ВЫПУСТИЛИ КРЯК БЕЗ ПОДКЛЮЧЕНИЯ К ИНТЕРНЕТУ
ТЕПЕРЬ БЕЗ ПЕРДОЛЛИНГА ПРИ КАЖДОМ ЗАПУСКЕ
Нужно:
1. Несколько ветвлений сценария.
2. Мини-игра «затарься в супермаркете». Ходишь по магазу, собираешь дешевую продуктовую корзину, от ее содержимого зависят некоторые ветвления «сюжета».
3. Ходьба, поездки на метро/ автобусе, диалоги.
4. Чтобы он смог выдержать толпу идущих прохожих без лагов. Ну, штук 20 хотя бы
И каков гамак в сравнении с юнити?
Не знаю что ты имеешь ввиду под "собирать", но то что ты описал сделать весьма просто.
Лаги зависят в основном не от движка а от того, как ты всё реализуешь. Можно и один объект написать так, что игра не запустится, можно и 1000 обхектов двигать без всяких лагов.
Гамак гораздо проще юнити и заточен под 2д. Юнити сложнее, мощнее, в нём больше ассетов и специализован на 3д.
Короче, я глянул туториалы и решил, что гамак мне идеально подходит.
Вообще сначала была идея пилить новеллу на ренпае, но потом я понял, что это какой-то маразм и пора бы завязывать со шквалом маня-новеллок лучше создам маня-изометрию.
Кстати. У вас нет своей ламповой конфочки в телеге?
При погибании персонажа, комната перезагружается, соответственно перезагружаются и враги, и игрок и все остальное. А как сделать, чтоб, например, уже собранные бонусы не перезагружались, чтобы игрок раз за разом халявные патроны не находил, например? Или без перезагрузки комнаты придется пердолиться с каждым отдельным врагом?
Вот не знаю, как через них сделать. Потому что, например, лежат на уровне две идентичных коробки с говном (один и тот же объект), одну игрок подобрал, вторую — нет. глобальная переменная же не различит, какую коробку он взял.
Идентификаторы для кого придумали?
Я делаю следующим образом:
У меня есть obj_game
permanent объект, в котором хранится самая важная информация.
В нём я создал ds_grid со списком всех вещей, которые есть в игре.
У каждой вещи есть параметры "уникальная?" и "игрок уже подобрал меня?"
Все коробки в игре одинаковы. различаются только дополнительным room_create_event, который идёт после create_event объекта. кликни на предмет в комнате два раза и выбери create_event - это оно.
В нём я указываю парамер item, который сообщает коробке, какой предмет в неё лежит.
В step event коробки я пишу.
if !init
{
init = true;
if ds_grid_game(obj_game.items, item, уникальная) == true
{
if ds_grid_game(obj_game.items, item, игрок уже подобрал меня) == false exit
else
{
instance_destroy();
exit;
}
}
}
Таким образом коробка самоуничтожается, если в ней уникальный предмет, который игрок уже подобрал.
Я делаю следующим образом:
У меня есть obj_game
permanent объект, в котором хранится самая важная информация.
В нём я создал ds_grid со списком всех вещей, которые есть в игре.
У каждой вещи есть параметры "уникальная?" и "игрок уже подобрал меня?"
Все коробки в игре одинаковы. различаются только дополнительным room_create_event, который идёт после create_event объекта. кликни на предмет в комнате два раза и выбери create_event - это оно.
В нём я указываю парамер item, который сообщает коробке, какой предмет в неё лежит.
В step event коробки я пишу.
if !init
{
init = true;
if ds_grid_game(obj_game.items, item, уникальная) == true
{
if ds_grid_game(obj_game.items, item, игрок уже подобрал меня) == false exit
else
{
instance_destroy();
exit;
}
}
}
Таким образом коробка самоуничтожается, если в ней уникальный предмет, который игрок уже подобрал.
пускает слюни
>Юнити действительно под 2Д плохо катит
Потамушта пиксельные игры это прошлый век и нахуй они нужны когда есть ахуенный графон почти как в жизни вон посмотри на нового асасина
Простой пример - есть объект игрока, есть аптека. В скрипте отвечающим за смерть есть room_restart и после смерти игрока комната перезагружается но аптек нет. В гамаке так и задумано? Как это обойти? Записывать айди всех аптек в комнате и ресать их? Или например сделать видимость 0 после того как их взяли? Вернуться к ним у игрока в рамках комнаты возможности не будет.
Я, честно говоря, не пользовался никогда room_restart
В мануале написано, что работает так, как будто ты только что зашёл в комнату.
Т.е. должны создаваться все не persistent объекты по новой, выполняться все create events и room create events.
А сама комната не persistent?
Да, она была persistent, помогло, спасибо.
Ну, например, чтобы сплит скрин сделать.
Один анон в ньюфаготреде сделал миникарту, повесив вторую камеру, которая показывала полностью всю комнату в уменьшенном виде. Но я не рекомендую такой способ.
Отрисовка в гамаке по умолчанию происходит на application_surface
https://docs.yoyogames.com/source/dadiospice/002_reference/surfaces/the application surface.html
1600x900, 0:21
Вот как я задаю камеру в своей игре:
Создаётся камера, определяются view и projection матрицы.
global.camera = camera_create();
width = round(display_get_width()/2);
height = round(display_get_height()/2);
var view_matrix = matrix_build_lookat(x,y,-10,x,y,0,0,1,0);
var projection_matrix = matrix_build_projection_ortho(width,height,0,10000);
Задётся, что view_camera[0] транслируются в созданную мной камеру
view_camera[0] = global.camera;
Его размеры подгоняются под размеры projection матрицы камеры.
view_hport[0] = height;
view_wport[0] = width;
Затем устанавливаем view и projection матрицы в камеру
camera_set_view_mat(global.camera,view_matrix);
camera_set_proj_mat(global.camera,projection_matrix);
Включаем view
//Enable the use of views
view_enabled = true;
//Make view 0 visible
view_set_visible(0,true);
А потом подгоняем размеры application surface под размеры view 0
surface_resize(application_surface,view_wport[0],view_hport[0]);
Ты можешь заметить, что размеры этого view у меня 1/2 от размеров дисплея. А выводится он на весь экран. Таким образом получаем пиксель с зумом х2.
В webm мы можешь увидеть, как я копирую aplication surface на отдельный surface, снимая скриншот, потом рисую интерфейс и рисую этот скриншот в нужном мне месте с нужным мне скейлом.
1600x900, 0:21
Вот как я задаю камеру в своей игре:
Создаётся камера, определяются view и projection матрицы.
global.camera = camera_create();
width = round(display_get_width()/2);
height = round(display_get_height()/2);
var view_matrix = matrix_build_lookat(x,y,-10,x,y,0,0,1,0);
var projection_matrix = matrix_build_projection_ortho(width,height,0,10000);
Задётся, что view_camera[0] транслируются в созданную мной камеру
view_camera[0] = global.camera;
Его размеры подгоняются под размеры projection матрицы камеры.
view_hport[0] = height;
view_wport[0] = width;
Затем устанавливаем view и projection матрицы в камеру
camera_set_view_mat(global.camera,view_matrix);
camera_set_proj_mat(global.camera,projection_matrix);
Включаем view
//Enable the use of views
view_enabled = true;
//Make view 0 visible
view_set_visible(0,true);
А потом подгоняем размеры application surface под размеры view 0
surface_resize(application_surface,view_wport[0],view_hport[0]);
Ты можешь заметить, что размеры этого view у меня 1/2 от размеров дисплея. А выводится он на весь экран. Таким образом получаем пиксель с зумом х2.
В webm мы можешь увидеть, как я копирую aplication surface на отдельный surface, снимая скриншот, потом рисую интерфейс и рисую этот скриншот в нужном мне месте с нужным мне скейлом.
Так, вопросик. Планирую вкатиться в ГМ. Помимо встроенного языка GML можно использовать какие-либо языки программирования? Или онли GML?
Но в принципе ты мог бы использовать для того же эффекта несколько view, нарисовав интерфейс в одном месте и выводя его на экран, сначала камеру, которая смотрит на интерфейс, а потом камеру. которая смотрит на уровень. Изменяя вторую камеру ты мог бы добиться того же самого.
Тэкс, посмотрел синтаксис, очень похоже на js с различными костылями.
Я уже глянул на тот пиздец с DnD. Да, проще кодить.
The depthproperty is necessary. This property can be any real integer value. It controls
which objects are drawn in front of other objects. Lower values are brought to the front
and higher values are pushed to the back. If you have a tree object that you want to be
in the background (behind the player), you might give it a depth value of 5 and your
player a depth value of 10. This would draw the player object in front of the tree object
because 10 is lowerthan 5
Хуита какая-то. В том же вебе слои движутся в сторону пользователя, т.е. Если персонажу задать depth z-index 10, а дереву depth 5, то на переднем плане будет персонаж. А тут наоборот.
А, ну да, само название depth означает глубину, то есть, насколько глубоко от пользователя находится слой. Мде
Всё равно ты будешь работать со слоями.
В room_start event записывай id слоёв в переменные а потом работай с ними. Иначе запутаешься.
Блять. Я уж обосрался, что на 2 гамак скидка 80%, и меня неплохо наебали со скидкой по факту владения 1 версией.
В чём отличие двойки от 1.4, помимо той хуйни с тайлами и соплеразмазки ресурсов по экрану?
всего доброго
Пиздец, как они такое делают на гамаке?
Ну прост я привык в качестве "3д на гамаке" видеть говние уровня бластеркопа. А тут что-то интересное и даже по своему красивое.
Потому что у тебя, как и у большинства посетителей гдача, неправильное понимание движков: ты считаешь (и наверняка готов это отстаивать), что графон в игре обеспечивает движок. Но нет, графон обеспечивает разработчик, а движок обеспечивает среду для создания игор и более ничего.
Я как-то весной заикнулся об этом, так на меня целая толпа нубья слетелась, с пеной у рта доказывать мне, как я неправ.
Напомню, речь шла о том, что крупная студия при желании может сделать ААА-игру на любом из известных движков. Нубы усирались, доказывая, что нет, ты што, только на топовых движках, тычё!
И ещё.
Это твоё забуждение основано на тех образцах и примерах, что поставляются с движками. Есть ряд движков (не будем конкретизировать), которые поставляются с уёбищными и/или неоптимизированно-тормозящими демками. У людей, далёких от геймдева, складывается впечатление, что это предел возможностей движка. На самом деле демки - это предел творческих возможностей их создателей, не более.
Ты прав.
слечусь пожалуй на тебя.
>графон в игре обеспечивает движок
в видеосике статичная модель с запеченными лайтмапами. там даже свет очень всрато поддерживатся, чего уж говорить о современных шейдерах.
можно усраться, но даже готику первую на нем не сделать — нет костной анимации.
>крупная студия при желании может сделать ААА-игру на любом из известных движков
нет, не на любом, а лишь на паре десятков. игрострой это не только качество, это еще и возможность правильно отрисовывать это качество. напомните, сурс энжайн уже научился в pbr?
>На самом деле демки - это предел творческих возможностей их создателей, не более.
в юнети нет SSS и индирект лайт скаттеринга. точнее есть, но фейковые и от васянов с сопутствующим пакетом всякой вич-инфекции. почему ты считаешь что топовые студии могут обходиться без этих новомодных приблуд?
>можно усраться, но даже готику первую на нем не сделать — нет костной анимации
https://www.youtube.com/watch?v=_IC1OnTrkpE
Первый день в гмс, как очистить нахуй вот эту хуйню, оставшуюся от передвижения персонажа? Олсо, ответьте, куда лучше подобную хуйню задавать: в gm тред или помощь ньюфагам? Так как я предполагаю, что ближайшие пару месяцев буду часто хуйню спрашивать.
Здесь пиши. Я всегда отвечаю на адекватные вопросы. В ньюфаготред почти не хочу.
Твой вопрос не особо адекватен - что за хуйню ты вообще сделал?
Ты рисуешь не на application surface? Тогда делай каждый шаг в begin_draw_event surface_clear_alpha своему сурфейсу.
Первый день в гм, анон. Я вообще нихуя не знаю.
>application surface
Не ебу, что это. Как понял - отрисовка на отдельном слое
Сделал новую комнату, создал несколько слоев. В одном слое - инстансы объектов, другой - тайлсет.
Белая хренота по центру - персонаж, управляемый пользователем, коллизии обрабатываются таким образом(пикрил 2)
Кроме этого события ничего не писал.
Проблема в том, что при передвижении остаются предыдущие полупрозрачные отрисовки персонажа.
Как я понял, я должен чистить буфер после каждой отрисовки, как ты говоришь. Вот только я не знаю, как это сделать.
Благодарю.
Отсюда вытекает другой вопрос: Получается, все предыдущие draw сохранены и очищения не происходит?
Когда ты рисует по умолчанию - ты рисуешь на application_surface
По умолчанию она не очищается, так что всё нарисованное остаётся на ней.
Когда ты включаешь фон, то в начале каждого шага на твоём application_surface рисуется фон в режиме gpu_set_blendmode(normal). Если фон непрозрачный, он соответсвенно заменяет собой каждый пиксель твоего application_surface, таким образом происходит его очищение. Потом, поверх этого фона, рисуется всё остальное.
Спасибо
Себе же хуже делаешь, запутаешься в меню, сверяя их с английскими эквивалентами. Даже если язык не знаешь, лучше англюсик ставить.
Вроде пермач
Я больше охуеваю, как в геймдеве - области, где все от и до сделано пиндосами, есть люди, которые от них отбрыикваются. Вы блять им ноги целовать должны. Хотя это вообще практически на все ойти распространяется.
>Вы блять им ноги целовать должны
За то что они спиздили технологии немцев и русских?)) А ты знал что идея интернета сначала в ссср появилась?))
https://youtu.be/R3fw5y9VoQo
Отвечаю передергиванием на передергивание, если человек такими категориями размышляет, хули нет. Употреблять англицизмы - это закос под клятых пиндосов, ага.
>спездели!1!11!
Ну да, это такая уникальная разработка, да. То, что совок не смог реализовать интернет для общего доступа это значит, что он и не разработал его вообще. Я тоже могу сделать сотни прототипов уникальной игры, но это не значит, что это законченный продукт.
Я придумал в своей голове некстген игру и даже знаю как ее реализовать, теперь когда такую игру игру сделают, это значит, что у меня спиздили!!!!!
ебать ты ебнулся
Ты реально думаешь, что на такую жирноту кто-то поведется? инбифайв азаза ты же ответил значит повелся
Новый вопрос. По поводу объектов. Вот, допустим, есть у меня объект персонаж. и есть стена. Я могу эту стену сделать в виде простого тайла читай, нарисовать на отдельном слое, а могу сделать в виде объекта со спрайтом. Как лучше сделать эту стену, чтобы потом обработать коллизии персонажа и стены.
Олсо, насколько я понял, в physics не рекомендуется создание большого количества объектов. Тогда, получается, придется пилить свою физику. Но не будет ли это костыльной хуетой, ведь можно использовать уже готовую физику. Также интересует, какое именно количество объектов в physics является критичным для средней системы.
Проще всего объектом.
Производительнее - тайлом.
По тайловым коллизиям рекомендую гайд - https://forum.yoyogames.com/index.php?threads/on-slopes-and-grids-subpixel-perfect-topdown-movement-and-collision-line-without-objects.4073/ - если разберёшься - многое поймёшь о коллизиях и перемещениях.
Как там physics работает - вообще без понятия. Гравитацию и соударения я сам сделал. Пользоваться чем-то, что я не знаю как работает и в каком месте поставит мне подножку не было желания изначально.
Сколько объектов потянет? Ну накидай в комнату объектов да посмотри на fps_real.
> где все от и до сделано пиндосами
Шизик и не лечишься.
Напомнил мне какую-то либерашку или какла верефицированного в твиттере, который на полном серьезе рассуждал о том, что латиница - "пиндосское изобретение".
Только после того, как ты мне покажешь "швейцарский" язык Швейцарии)) Раз у тебя все страны говорят на одноимённом языке)
А хотя, вот тебе из гугла:
>Лаций (лат. Latium) — регион в античной Италии, прародина современных романских языков. Здесь же зародились римляне. Его территория в настоящее время входит в состав более крупного административно-территориального образования современной Италии — Лацио.
>Вы блять им ноги целовать должны.
А ты целуешь или облизываешь? Про Пентковского и прочих слышал что или в школе не проходили?
Есть объект игрок и в определенном состоянии
должны вызываться эффекты искры.
В общем и целом они вызываются,и так получается что за объектом дорожка из зачаточного состояния эффекта (пучок искр) вместо одного длинного снопа. ЧЯДНТ?
create
//Spark on slide //----------------------------------------//-------------------------------------------//
//Creating Particle Types
//sparks
global.pt_sparks = part_type_create();
part_type_shape(global.pt_sparks, pt_shape_explosion);
part_type_size(global.pt_sparks, 0.50, 1, 0, 0);
part_type_scale(global.pt_sparks, 0.20, 0.03);
part_type_orientation(global.pt_sparks, 157, 189, 0, 0, 0);
part_type_color3(global.pt_sparks, 13828095, 4320254, 3132923);
part_type_alpha3(global.pt_sparks, 1, 0.81, 0.69);
part_type_blend(global.pt_sparks, 0);
part_type_life(global.pt_sparks, 10, 50);
part_type_speed(global.pt_sparks, 2, 5, 0, 0);
part_type_direction(global.pt_sparks, 170, 185, 0, 0);
part_type_gravity(global.pt_sparks, 0.09, 180);
//Creating Emitters
global.pe_sparks = part_emitter_create(SLIDE_PART);
var xp, yp;
xp = x;
yp = y;
//part_emitter_region(SLIDE_PART, global.pe_sparks, xp-2, xp+2, yp-2, yp+2, ps_shape_rectangle, ps_distr_gaussian);
part_emitter_stream(SLIDE_PART, global.pe_sparks, global.pt_sparks, 3);
step
if (проверка нажатия клавиши) //тут пробовал проверять по состоянию нажатия клавиши или "состоянию" объекта
{
part_particles_create(SLIDE_PART,x, y, global.pt_sparks, 1);
if (проверка того что клавиша отжата)
part_particles_clear(SLIDE_PART)
Есть объект игрок и в определенном состоянии
должны вызываться эффекты искры.
В общем и целом они вызываются,и так получается что за объектом дорожка из зачаточного состояния эффекта (пучок искр) вместо одного длинного снопа. ЧЯДНТ?
create
//Spark on slide //----------------------------------------//-------------------------------------------//
//Creating Particle Types
//sparks
global.pt_sparks = part_type_create();
part_type_shape(global.pt_sparks, pt_shape_explosion);
part_type_size(global.pt_sparks, 0.50, 1, 0, 0);
part_type_scale(global.pt_sparks, 0.20, 0.03);
part_type_orientation(global.pt_sparks, 157, 189, 0, 0, 0);
part_type_color3(global.pt_sparks, 13828095, 4320254, 3132923);
part_type_alpha3(global.pt_sparks, 1, 0.81, 0.69);
part_type_blend(global.pt_sparks, 0);
part_type_life(global.pt_sparks, 10, 50);
part_type_speed(global.pt_sparks, 2, 5, 0, 0);
part_type_direction(global.pt_sparks, 170, 185, 0, 0);
part_type_gravity(global.pt_sparks, 0.09, 180);
//Creating Emitters
global.pe_sparks = part_emitter_create(SLIDE_PART);
var xp, yp;
xp = x;
yp = y;
//part_emitter_region(SLIDE_PART, global.pe_sparks, xp-2, xp+2, yp-2, yp+2, ps_shape_rectangle, ps_distr_gaussian);
part_emitter_stream(SLIDE_PART, global.pe_sparks, global.pt_sparks, 3);
step
if (проверка нажатия клавиши) //тут пробовал проверять по состоянию нажатия клавиши или "состоянию" объекта
{
part_particles_create(SLIDE_PART,x, y, global.pt_sparks, 1);
if (проверка того что клавиша отжата)
part_particles_clear(SLIDE_PART)
Во-первых опиши что ты хочешь и что у тебя есть. Со скриншотами и рисунками. Я тебе телепат, угадывать что там у тебя в голове?
Во-вторых хочешь чтобы партиклы вылетали из движущегося объекта - двигай эмиттер.
В step event изменяй параметры part_emitter_region
Ну и вот это в каждом шаге part_particles_clear не даёт твоим партиклам "развиться". Что ты хотел-то?
Хотел нечто подобное запилить, типа молнии при скольжении. Вчера как раз emitter_region подвигал и добился вот такого эффекта, но чет есть подозрение что я все равно не так это делаю лол
part_emitter_clear в степе чистит эмитер если объект не в нужном состоянии.
>
>https://marketplace.yoyogames.com/assets/4574/geon-fx-particle-editor
Ты не поверишь, но купил на недавней распродаже
Так то спасибо, хех.
Есть примеры таких игр? Можешь посоветовать какой-нибудь курс уроков по созданию многопользовательской ио игры на гейммейкере?
Хочу сделать игру, похожую на starve.io
Под его определение попадают мультиплеерные крестики-нолики с динамично изменяющимся полем.
Динамично изменяющаяся карта - наверно, таким образом я описал возможность строить и сносить здания, сажать и рубить деревья, вот это всё.
> таким образом я описал возможность строить и сносить здания, сажать и рубить деревья
Очередной выживач с 0 онлайна чтоле?
Это можно сделать на чем угодно, но с твоими познаниями максимум что ты сделаешь - нечто, запускающееся только на суперкомпьютерах.
>Очередной выживач с 0 онлайна чтоле?
Да, типа того.
А почему моя поделка заработает только на суперкомпьютерах? Подобные игры очень требовательны к чистоте коде и вычислительным ресурсам?
> А почему моя поделка заработает только на суперкомпьютерах?
Потому что тебе нужно будет писать код не только как рубить деревья и перемещать персонажа, а с оглядкой на то, чтобы у тебя весь твой огромный мир работал одновременно и не засорял память лишними вычислениями.
Да, есть такое. Пофиксить не получится, насколько я знаю. Но в настройках можно задать размер шрифта, если тебя не устраивает дефолтный и тебе приходится сильно приближать окно для работы.
Да с кодом я решил проблему настройкой его открытия в новом окне. А вот все остальное просто раздражает.
Удобнее работать с тайтлами. Появляется возможность нормального переиспользования, если карта большая - лучше оптимизация
Там пиздец какие баги.
Ананас, хочу вкатиться в GMS ибо самому с нуля каждый раз писать дико удручает и выматывает, а тут будет как мне кажется несколько проще.
С чего начать? Опыта в программировании достаточно.
Если ты про "изучить интерфейс" и "как создавать объекты и размещать их в комнате" то начинай с
https://www.youtube.com/channel/UCn7FE3Tx391g1tWPv-1tv7Q
Нихера себе.
Допустим у меня есть гуи с хп, и я заебенил клевый эффект мерцания при определенных обстоятельствах (подбор апетеки) но т.к. сейчас я рисую его в объекте игрока эффект как будто растекается по поверхности за игроком (считай скорость появления спрайтов в партикле х еденица времени).
Можно их как-то рисовать относительно вида? Или сделать объект который будет рисоваться относительно вида, или камеры?
Для начала сформулируй вопрос так, чтобы его поняли другие.
Что значит фраза "партиклы рисуются от объекта"? Ты упоротый?
Партиклы создаются эмиттером в зоне, заданной тобой.
После создания партикла ты никак не можешь на него повлиять, он будет только выполнять заложенную в него при создании программу. Т.е. если ты переместишь камеру, партикл не переместится вслед за ней.
"рисовать относительно вида" чё блять? но я примерно понимаю, что ты имеешь ввиду.
Отключи автоматическую отрисовку партиклов
part_system_automatic_draw(ind, automatic);
Затем создай какой-нибудь объект-контроллер частиц, который будет заниматься их рисованием.
И через его draw_event работай с ними используя функци. part_system_drawit(ind)
Установи своему эмиттеру фиксированные координаты. Создай сурфейс так, чтобы координаты были в его центре. Потом
surface_set_target(surf)
part_system_drawit()
surfcae_reset_target()
А можешь камеру двигать, прежде чем частицы отрисовать, а потом возвращать назад.
matrix_set( matrix_world, matrix_build( -30, -30, 0, 0, 0, 0, 1, 1, 1 ) );
part_system_drawit()
matrix_set( matrix_world, matrix_build_identity() );
>>533582
>Что значит фраза "партиклы рисуются от объекта"? Ты упоротый?
Я имел в виду что координаты для имитера мы задаем в объекте.
>"рисовать относительно вида" чё блять? но я примерно понимаю, что ты имеешь ввиду.
Как еще объяснить что они постоянно должны быть на экране но их не разносило от скорости движения камеры дядь?
За советы спасибо, попробую накатить.
Модешь ещё попробовать в ивенте draw_gui рисовать свой интерфейс и в этом же ивенте использовать функцию
part_system_drawit()
Не знаю, что получится. Но по-идее должно быть именно то, что тебе нужно.
draw_gui это такой ивент, когда все координаты считаются не относительно верхнего левого угла комнаты, а относительно верхнего левого угла экрана.
Вроде запилил, учитывая что я до этого на сурфейсы вообще не смотрел. Сейчас хоть разобрался что да как
Во второй версии геймейкера присутствует такая функция: instance_create_depth, которой нет в версии 1.4, на которой я работаю.
Мне нужно написать что-то типа этого
if (keyboard_check_pressed(ord("")))
instance_create_depth(x, y, 0, object);
через функции 1.4, подскажите как
Ничего не перепутал?
Вроде в 1.4 нету layer зато есть depth. А в 2 есть и то и другое.
И в чём проблема-то? Ну заменяешь depth на layer, содаёшь instance_layer на нужной тебе глубине и создаёшь инстанс в него.
поставил объекту вертикальную скорость hspd = sign(obj_player,y-y)* spd
но при достижении одного уровня высоты его начинает немного трясти
проверки уровня высоты и ограничения скорости не помогают, что я делаю не так?
Начнём с того, что ты скажешь, как ты хочешь чтобы было?
Хочешь чтобы объект занял один эшелон с игроком? Делай так:
diry = sign(obj_player.y-y)
if diry = 0 diry = 1 всегда ставлю такое условие, чтобы не проебаться с анимацией
if abs(obj_player.y-y) > abs(vy) если объект ещё не достаточно приблизился к игроку
{
vy = diry *spd
}
else
{
vy = 0;
y = obj_player.y
}
Вчера прошел свежевышедший сиквел Ундертале, и так вдохновился заебенить что-нибудь эдакое (благо идея есть), что начал гуглить, в чем игру делали. Оказалось - Гейммейкер.
Скажите, если я пиратку поюзаю, а потом нет-нет да и решу серьезно заняться проектом для выкатывания его на всеобщий суд, мне же придется покупать лицуху или как? Там типа строго с этим, от каждого юзера требуют какой-нибудь лицензионный код в качестве пруфа или что?
И главное: можно же будет потом все свои недоделки с пиратки на лицуху перекинуть? Читать-то двиглу в теории один хуй те же самые файлы.
>все свои недоделки с пиратки на лицуху перекинуть? Читать-то двиглу в теории один хуй те же самые файлы.
перекинуть - да, остальное хз
Берёшь бесплатную триалку и делаешь.
К тому моментку, как ты хорошенько освоишься с гамаком, вопрос покупать/не покупать у тебя отпадёт.
На самом деле хз.
Я понял, что у триалки функицонал урезан тогда, когда обнаружил, что больше одного тайлового слоя в ней нельзя создавать.
Но можно загрузить в триалке проект, в котором уже несколько тайловых слоёв создано и работать с ним. Например туториальный проект.
Можно только порадоваться, что ещё кто-то решил взяться за дело. Зачем сразу пугать?
Потому что даже горящие геймдевом долгое время люди приходят и обсираются. А тут ребенок, который жил себе не тужил, вдруг поиграл в очередное оверхайпнутое говно для детей и решил в геймдевелопера поиграть, ну так, в перерыве между каточками в фортнайте. Какой багаж базовых знаний ему нужен, ребенок, конечно же, не удосужился узнать, думая, что двигло сделает все за него по нажатию кнопки "зделоть пиздато", да и местые шизики ведь уверяют, что "нада тока начать и будет крута атвичаю!", ну точно все заебись должно быть! В чем же заключается цепляемость того же ундерсраля, у ребенка есть только призрачные (и те неверные) представления, но у него уже есть "идея" своей слезодавильной говноистории, которая, конечно же, взорвет весь игропром (нет). При получении все большего и большего количества помощи и сурсов для чтения по движку у ребенка начнут затухать его горящие глаза творца, пока окончательно не потухнут и он не пойдет дальше брать топ-1 в своем фортнайте. Проходили уже.
А еще этот ребенок выкладывает свой пост в гамако-треде, хотя замени в нем гамак на любое другое двигло - и ему место только в ньюфаготреде, а здесь должны быть обсуждения по конкретным фичам конкретного движка и решения вопросов по коду и прочим непонятным штукам, а подобные посты лишь разбавляют концентрацию полезных постов своей бесмыссленностью.
Мне это ты зачем объясняешь?
А ты в курсе, что самые фанатичные и упорные как раз таки тоже дети? В определённом возрасте ребёнок может определить для себя интерес на всю жизнь. Нужно только поддержать.
И по поводу поддержания треда в чистоте ты не совсем прав. Этот тред по большей части бессмыслен. Уровень вопросов от неофитов тут вот такой: >>535521
Какая ещё концентрация полезных постов? Её даже на yoyo форуме нет.
Ебать тут обиженке сракотан половой жопы разворотило, аж стену высрал, проецируя свои боли и обиды на взрослого и успешного человека.
Он ебанутый? Че он с ними делает?
Есть такая хуйня.
Он делает 3 виртуальных диск, в каждом из которых содержимое гамакерской AppData.
Зачем - ни малейшего представления. Но если у него вдруг не получится это сделать - приложение не запустится.
Посмотрел вот это:
https://www.youtube.com/watch?v=izNXbMdu348
Если до конца все было понятно, то с прыжка я охуел.
Почему vertical speed была выставлена на -7? Почему минус 7? Ось координат поменяла свои значения? Вроде вверх — это плюс.
Но что я точно не понимаю — это каким хуем вообще здесь работает прыжок. Почему спрайт прыгает вверх, замирает, а потом падает вниз? Чем это вообще обусловлено? Почему прыжок плавный? Судя по коду, после нажатия пробела спрайт должен телепортироваться на 7 пикселей вверх и вроде бы даже замереть в воздухе. Почему он, сука, падает?
Почему я такой тупой?
Он присваивает -7 вертикальной скорости, которая потом увеличивается из-за гравитации, и получается плавный прыжок.
И там ниже он делает y=y+vsp, что ставит вертикальную координату.
Потому что начало координат обычно считается от верхнего левого угла поля и ось Y направлена вниз.
Привыкнуть не легко.
После нажатия прыжка спрайт подпрыгивает вверх на 7 пикселей 60 раз в секунду (или 30 раз, смотря какой фреймрейт выставлен).
Плюс идёт работа гравитации, которая плавно обнуляет скорость прыжка а потом разворачивает её в другую сторону. Почему ты этого не заметил?
v=at
Это, вроде, пятый класс.
>Почему минус 7?
Очевидно, ось Y направлена вниз. В разных движках могут оси располагать как создателям вздумается.
>Почему спрайт прыгает вверх, замирает, а потом падает вниз?
Действует гравитация. Тело движется с ускорением. Смотри внимательнее.
>vsp = vsp + grv;
vsp сохраняет свое значение каждый кадр, и его немного изменяет grv.
Это я понял. Я даже примерно могу представить, что высота прыжка именно в vsp = -7 и устанавливается. Я не понимаю, где в коде указано, что спрайт должен падать при достижении этой отметки.
Вот здесь:
vsp = vsp + grv;
Каждый шаг к скорости прибовляется 0.1
В момент нажатия кнопки "прыжок" скорость мгновенно становится -7 и персонаж летит вверх.
Затем в течении 70 шагов скорость увеличивается до 0, и персонаж останавливается. Это высшая точка прыжка. Потом скорость продолжает увеличиваться по 0.1, скорость становится положительной и персонаж с ускорением летит вниз.
0.1 это ускорение, начальная скорость в -7 каждый фрейм "увеличивается" на 0.1, т.е. за 60 фреймов скорость станет -1, за 120 фреймов станет 5, т.е. объект в обратную сторону по игреку двигаться начнёт.
На 70 фрейме скорость будет 0 - это и есть та точка, где спрайт зависнет в воздухе, а на 71 фрейме начнёт падать из-за скорости в 0.1
Да внезапно чел постучался и грит, мол другнейм говорит, ты можешь игори делать, а мне как раз нужна небольшая перда.
В итоге сделал ему его раннер и получил баблеца.
дил
Прикольно, а что, всю разработку, включая арт и музыку, ты сам ебашил?
Как к цене такой пришли, с самого начала договорились, или ты почасовую озвучил, или в конце просто сказал: дай стописят штукарей, а заказчик такой: "Че ахуел?))) вот те сто и радуйся епта"?
И так, и сяк ебался, лупы тут просто не работают, потому что луп покадровый и так запущен.
Анимация проигрывается нормально только для зажатой клавиши.
Create Event:
rotating = false;
rotating_counter= 36;
Step Event:
if (!rotating && keyboard_check_pressed(vk_space)) {
rotating = true;
}
if (rotating) {
image_angle += 10;
rotating_counter -= 1;
if (rotating_counter == ) {
rotating = false;
rotating_counter = 36;
}
}
Я старпёр 30+ который уже отработал на разных работках. Несколько лет назад меня это задобало, и я решил уйти в геймдев, благо накопил нехило денег пока работал. Пообщался с разными людьми, прокачал свои скиллы (рисование/анимация, в код не могу, ибо окологуманитарий), поработал за еду в котрке которая пилила мобилки что бы понять как это работает изнутри, и в итоге открыл свою компанию. Естеественно начал пилить игру мечты, и вполне закономерно провалились, потеряв попутно почти всё что заработал за 10 лет.
Поскольку я необучимый, решил побпробовать снова. Нашёл с горем пополам инвестора по своим старым связям, бюджет хоть какой то, но есть. Но не хочу наступать на старые грабли, а одни из самых зубастых из них было что я был один горем-директором, а большая часть работы выполнялась на аутсорсе, людьми котрым было в принципе пофиг на сам проект, и просто выполняли мои ТЗ, не взирая на их уровень бредовости. Ну и вторая проблема, в то что я всю жизнь работал фрилансером-консультантом, и опыта руковождения команды у меня чуть меньше чем ноль.
Короче говоря, ищю партнёра на новый проект. Особенно если у тебя уже есть опыт в игрострое (дополнително, если ты погромист будем более менее друг друга дополнять). Хотелось бы вовлечёного человека (то есть с долями в компании), ну и желательно не моложе 25и и с достаточном количеством свободного времени. Так как бюджет есть, то будет скорее всего и зарплата. Короче всё обсудимо.
Понимаю что не лучшее место для такого поиска, но я пробую все варианты, если интересно пиши на фейко мэйл:
И потому ты зашёл на двач. Уж тут-то ты найдёшь адекватных сотрудников.
И стесняешься дать ссылку на запиленную игру мечты, да? Да ещё такой подробный рассказ о новом проекте, что прям заболели все вокруг и готовы н энтузиазме тебя поддерживать.
Сдаётся мне, ты очередной шизик.
У нас в последнее время просто наплыв директоров. Школа бизнес молодости где-то протекла?
Дополнительная переменная, которую нужно понижать до нуля с каждым поворотом. Ну конечно!
Грасиас, синьор.
На почту-то будешь отвечать?
>Есть различные наработки, хотелысь бы вместе выбрать.
Я в констракте профи, гамак даже не открывал ни разу.
> Нашёл с горем пополам инвестора
Чот кринжанул.
Инвесторы на 2д перделки сделанные на гамаке.
Так и представляю очередную группу присосавшихся к деньгам долбоебов, которые пол года нихуя не делают, проебыват деньги, а потом пишут о закрытии проекта.
А так оно каждый раз и бывает, когда вы свою инди поеботу начинаете делать с серьезными ебалами напялив свои засаленные колхозные пинжаки как в ностоящих фирмах!
Не помню ни единого завершенного проекта, который бы начинался так. А вся инди годнота вообще была сделана на коленке одним-двумя людьми, которые просто проверяли свои силы в игрострое.
>которые просто проверяли свои силы в игрострое.
>а потом подняв бабла в полную силу пилили ИГРУ и получалось только говно и моча
Блэать, только что дошло что изначально запостил не в тот тред. Гамак или негамак не похер одходило бы только к игре.
>Не помню ни единого завершенного проекта, который бы начинался так
Stardust Valley, Armello, World of Goo, Minecraft...Нет не слышал про такое.
Ну что, ты нашел "партнера"?
>Stardust Valley
Stardew Valley
Создан одним человеком, который и рисовал, и кодил, и писал музыку. Начал делать игру спонтанно, пытался лишь воссоздать более старую игру Harvest Moon, как проверку своих сил после обучения программированию.
> World of Goo
Создан двумя друзьями в свободное время от основной работы в EA.
> Minecraft
Создан одним человеком. Спонтанно, как попытка возродить более древнюю и уже дохлую на тот момент игру Infiniminer.
Я вижу у тебя познания на уровне.
Hollow Knight тебе в ебало.
> А вся инди годнота вообще была сделана на коленке одним-двумя людьми, которые просто проверяли свои силы в игрострое.
Инди-годнота типично сделана адовыми профи с десятком лет за плечами увидевшими что издатели уходят из рыночной ниши малых и средних игр.
Вопрос теоретического порядка. Есть игра на ведра https://www.youtube.com/watch?v=5G7Xb5gFa80
Как наиболее оптимально реализовать похожую механику поведения пловцов?
Рассчитывать шаг исходя из того что в игре все клетки одного размера и добавлять условия при встрече с бортами? Как вообще реализуют такого рода игры с хождением по клетке? вот еще пример ходьбы по клеткам https://youtu.be/ptYwMwxP7ho
А в чём вообще проблема заключается?
Сам-то подход пытался придумать?
Я бы сделал ds_grid, задающую координатную сетку.
В каждую ячейку поместил бы массив, описвающий её содержимое.
Тип клетки, соответсвующий спрайт, всякие дополнительные параметры типа "рассыпанные камни" или "в зоне действия водоворота". И естественно ссылки на объекты, которые в ней находятся.
Для всего этого дела создал бы контроллер, который бы в ds_queue собирал от объектов запросы на перемещение из одной клетки в другую.
Ввёл бы параметр отвечающий за "ход". За один ход один обхект может отправить столько запросов на перемещение, сколько клеток за ход он может пройти.
Затем в конце каждого хода выключал бы контроллер игрока, и двигал объекты в соответствии с ds queue, проигрывая анимацию движения.
Понел, пойду читать документацию потому как до этого касался ds_grid только теоретически.
>ds_grid
Да, вопрос в подходе. В этом проекте хочется попробовать не говнокодить со старта а сделать нормальную базу.
Можешь ещё всунуть в каждую ячейку ds_grid ссылку на ds_map вместо массива.
И для каждой клетки свой ds_map вести.
Нужно сильно шо пиздец
Видел на итче какую-то тему связанную с импортом видео в гамак, погугли. Не знаю правда поможет или нет.
Вроде как на маркете есть ассет, который это делает. Но он вроде как платный.
Потому что не знал про божественный CopperCube!
У гамака есть огромная проблема. При мало-мальском усложнении проекта вся структура кода идет по пизде из-за того, что ГМЛ очень и очень слаб.
То есть вместо того, чтобы писать человеческие классы с нужными методами, ты постоянно плодишь скрипты, которые лежат хуй знает где и ты начинаешь охуевать от говнокода.
Плюс отсутствие нормальных человеческих структур данных вымораживает. ds_list, ds_map - это ебаный ад и израиль.
Т.е. пилить всякие платформеры/раннеры несложные гамак позволяет очень легко и быстро. Но как только ты делаешь что-то с механиками посложнее - начинается пиздец.
Люблю гамак всей душой, но я его перерос.
Добавлю что из скрипта можно, например, вернуть только одну переменную, когда хотелось бы, например, вектор.
Но перекатываться всё же пока не планирую.
Из скрипта можно вернуть массив (или дс лист) с нужным кол-вом переменных. Но это треш все равно.
С туториалов Спалдинга.
Пилю крч платформер со случайно генерируемыми платформами по которым надо прыгать. И фишка в том что при соприкосновении с платформой снизу или сбоку объект игрока прилипает к ней. И соответственно платформа начинает двигаться с игроком. Как фиксить? От чего может быть? Вот говнокод в столкновении с игроком
if (vspeed > 0 && !place_free(x,y+vspeed))
{
move_contact(270);
vspeed = 0;
jumpCount = jumpCountAspect;
}
if (vspeed < 0 && !place_free(x,y-vspeed))
{
move_contact(0);
vspeed = 0;
}
if !place_free(x+30,y)
{
move_contact(360);
vspeed = 20;
// x = x+(global.levelSpeed+10)
}
пытался запилить костыль hspeed = o_platform.hspeed; в последней проверке чтобы объект игрока принимал скорость платформы и она не сдвигалась но все равно. Платформа спавнится с hspeed=(0-global.levelSpeed)
В create у контролера global.levelSpeed = 6
Пилю крч платформер со случайно генерируемыми платформами по которым надо прыгать. И фишка в том что при соприкосновении с платформой снизу или сбоку объект игрока прилипает к ней. И соответственно платформа начинает двигаться с игроком. Как фиксить? От чего может быть? Вот говнокод в столкновении с игроком
if (vspeed > 0 && !place_free(x,y+vspeed))
{
move_contact(270);
vspeed = 0;
jumpCount = jumpCountAspect;
}
if (vspeed < 0 && !place_free(x,y-vspeed))
{
move_contact(0);
vspeed = 0;
}
if !place_free(x+30,y)
{
move_contact(360);
vspeed = 20;
// x = x+(global.levelSpeed+10)
}
пытался запилить костыль hspeed = o_platform.hspeed; в последней проверке чтобы объект игрока принимал скорость платформы и она не сдвигалась но все равно. Платформа спавнится с hspeed=(0-global.levelSpeed)
В create у контролера global.levelSpeed = 6
У тебя ещё гравитация работает? Направление vspeed учитываешь?
Скорее всего у тебя вот это (vspeed < 0 && !place_free(x,y-vspeed)) в правду превращается, когда vspeed обнуляется, а потом срабатывает гравитация. Хуй знает короче.
Запускаешь игру в режиме дебага, когда объект прилип к платформе табаешься в ide и ставишь брекпоинт в step event объекта. И шаг за шагом смотришь, что у тебя срабатывает.
Запостил какой-то кусок кода без коментов, без объяснений. Мы угадывать должны, как оно у тебя работает?
Безотносительно твоего вопроса - не рекомендовал бы использовать вот эту шнягу искаропки: move_contact, place_free и т.д. Особенно если пишешь платформер. Напиши свои функции, о работе которых ты будешь знать всё. А то тебя ждут весёлые провливания сквозь пол, застревания, прилипания. Вот это всё.
Ну и ещё по движущимся платформам совет.
Обрабатывай движения игрока в step а движения платформ в end_step или begin_step.
Нехорошо когда объекты двигают друг друга в произвольном порядке.
А как ты хочешь, чтобы она выглядела? Можешь 3д кубик нарисовать и бросать.
Можешь нарисовать каждую грань отдельным спрайтом а потом на едином шаблоне рисовать отдельные спрайты.
Тебе 6 лет? Пшел в садик!
нет ли каких-то демо проектов с чем-то похожим? Чтоб посмотреть?
На самом деле мне не принципиально, каким именно образом
>На самом деле мне не принципиально, каким именно образом
Ну вот тебе 2d кубик на 4.
https://drive.google.com/open?id=1hwj8sHL90HCjP7OVacbJTZGzzKjBXuLp
<3
Перекат в процессе, заодно хапнул заказик, чтобы училось лучше.
Юнька-таки гораздо удобнее конечно, если в ней разобраться. На гме у меня правда все делалось в 1.5 - 2 раза быстрее, но чем дальше в проект, тем больше пизда рулю в плане организации кода.
Человеческое ООП решает все-таки.
>>539990
>можно, например, вернуть только одну переменную
>можно вернуть массив (или дс лист) с нужным кол-вом переменных
А что с этим не так? Деды возвращали из функций всегда по одной переменной, и ты так делай. Чем отдельные скрипты принципиально отличаются в этом плане? Нужно много данных вернуть - заворачиваешь их в объект/структуру/массив/небо.
Да
Причем после переходов через комнаты все становится норм.
В чем косяк? Сталкивался кто? ибо я упорно не понимаю чому слои не работают как надо
чому то глубина одинакавая выставлялась.
Выставил для каждого объекта отдельно - пофиксилось
Спасибо геймдевач-помогач
Вопрос №1: Можно ли на нём пилить RTS, 3d/2d масштабом в 25-50 юнитов на экране?
Вопрос №2: Можно ли на нём пилить (TBS), 3d/2d масштабом в 50-100 юнитов на экране?
Вопрос N3: Возможно ли на нём прописать аи противника?
я кончил.
да
3д в гамаке хуевый, не стоит даже пробовать.
В 2д в принципе можно делать что угодно, но если у тебя планируется ложная логика проекта, то быстро упрешься в ограничения GML/
1048x1050, 0:40
Здесь:
Пасфайдинг.
Система классов: маг/вор/воин
Система квестов
Система принятия решений.
Система нанесения урона.
Сдлано за два вечера.
В том числе 1.4.9999.
По результатам гугла моя ошибка описана здесь, только у меня ХР:
https://gcup.ru/forum/36-29024-1
>Установочник запускается,установка успешно проходит,а вот сама прога не катит! sad
>Все просто и сложно одновременно. Была такая же проблема. В Appdata есть файлик trace там ошибка твоего запуска. У меня ругался на framework. Исправил версию в файле .config и все распаковалось. Поправил версию framework в распакованном studio и все заработало.
Но у меня папка проги в appdata пуста. Что написать в конфиге?
Уже ни в чем, я ебси в глаза и не мог найти раздел Game play в главе GML в справке.
Раньше просто записывал все в переменную, но теперь когда делаю игру с охуеть каким колличеством текста понимаю что на локализации ебнусь даже с двумя языками. У меня всякие диалоги, реплики, прочая срань.
Храни в ini файлах, один файл на свой язык.
640x508, 0:10
Понял, что зря у меня весь код в степ ивенте, наверно не так надо было начинать.
А вы настраиваете один ивент и в нем пишете все основное или делаете по скрипту на фичу? Есть рекомендации как лучше их организовать?
Всё что можно - в скрипты.
Всё разбиваю на регионы.
Для каждой фичи - свой объект. За параллакс фонов отвечает obj_bg, за свет obj_light, за интерфейс obj_gui
Есть ли какие обходные пути, или, например, пиратские версии.
Ясен хуй, на стим/прочее не выложишь с взломанной версии, но в любом случае, есть ли какие обходные пути.
Или возможно ли без последствий, сделать проект на взломанной версии, а потом, когда уже готовый проект пихнуть в купленную версию? Возникают ли какие-нибудь несоответствия или артефакты/ошибки?
upd://
где-то читал, что тут платишь и всё, ты вроде как разработчику ничего не должен, и если смотреть в перспективе - с отчислений разработчику отдашь намного больше, чем эти 6к.
Меня интересует безпроблемный перенос со взломанной версии на купленную
Пили на юнити
Тоже запарился, но у меня не с анимации, а движение на 360. Есть два объекта - снаряд и препятствие. При расчете столкновения по х, у снаряда его маска вообще игнорируется, хоть так >>499296 хоть точно по спрайту, а происходит столкновение центра снаряда с границей препятствия. Хотя все настройки у обоих объектов одинаковые.
Из такого описания не понять, в чём твоя проблема.
Код в студию.
Может ты вместо place_meeting instance_position используешь.
Или prec false поставил.
Или у тебя снаряд прыжками двигается по 20 пикселей за кадр.
>place_meeting
Спасибо за подсказку, маска заработала. Я использовал collision_point ставя prec=true, почему-то в этом случае он все равно считает маску центральной точкой.
Пока это увидел, перебрал имитации маски через collision_circle и collision_rectangle. Решил, что в этом случае столкновения вообще лишние, сделаю снаряду превентивный круиз-контроль.
point_direction(x1,y1,x2,y2) возвращает направление в градусах. 0 справа, против часовой стрелки.
Работаю на первой же скаченной с рутрекера версии, проблем вообще никаких. ГМ 2, да, если что. Не знаю, как вы находите проблемы с этой прогой.
Хули оно такое неточное?
Даже у васянов с ютуба при расчетах всегда неточные числа получаются, а они на это реагируют мол: "Да неточно и хуй с ним чо)) результат на пару десятых отличается каждый раз, да и пох)))) лойс подписка))"
При длинных расчетах вообще же вся физика по пизде идет.
Должен же быть какой-то метод чтобы игра не была фиксированная на 60фпс и при этом выполняла точные расчеты вплоть до пикселя.
Ну вот, держи, первое же видео с гугла.
https://www.youtube.com/watch?v=NVfrAPos88k
8:35 неточный расчет и реакция на это васяна.
Падажжи, дельта тайм и не должен быть одинаковым. Он всегда разный, хоть убейся. Поэтому его и юзают для того, чтобы на него множить условную скорость и получать опять уже условно константную скорость перемещения объекта вне зависимости от фреймрейта.
Если нужны равные промежутки, то велкам в юнити, там есть FixedUpdate
Так это в видео отображается и не дельта тайм, а результат на основании перемножения дельтатайма на другие переменные.
При использовании дельта тайм у тебя объект одно и то же расстояние преодолевает каждый раз за разное количество времени. Каждый раз разница в ноль-целых-хуй-десятых и автор видео говорит что подобная мелочь в общем-то хуйня и случилась она просто из-за перепада фпс.
На деле же эта крошечная единичка запускает у тебя в коде цепную реакцию и провидит к полному пиздецу в физике, стоит твоей игре просто хотя бы дропнуть пару фпс в каком-нибудь моменте.
И в чем смысл тогда этого дельта-тайма, если из-за перепадов фпс и неточности расчета у тебя, к примеру, персонаж начинает прыгать на пару пикселей ниже положенного, в то время как у тебя код написан чтобы персонаж прыгал вверх исключительно на N игровых блоков, да аж с точностью до пикселя.
Ты путаешь назначение дельта тайма просто. Он никогда не служил инструментом для того, чтобы что-то делать через разные промежутки времени.
Ты там чет загнался совсем с
>в то время как у тебя код написан чтобы персонаж прыгал вверх исключительно на N игровых блоков, да аж с точностью до пикселя.
Посмотри тутор сполдинга, он рассказывает о том, как это все реализовать.
Спрайт - вертикальная линия.
После наложения этого шейдера я рассчитываю получить наклонную линию, у которой верхняя точка остаётся на месте, а нижняя смещается на 20 пикселей вправо.
(PixelW - это размер пикселя в масштабе текстуры)
varying vec2 v_vTexcoord;
varying vec4 v_vColour;
uniform float PixelW;
vec2 Coord = v_vTexcoord;
void main()
{
vec2 Coord = v_vTexcoord + PixelW20.0vec2(v_vTexcoord.y, 0.0);
gl_FragColor = v_vColour * texture2D( gm_BaseTexture, Coord);
}
Но получаю я вертикальную прямую линию, каждый пиксель которой сдвинут на 5 пикселей влево.
Чому? Разве v_vTexcoord.y не должно варьироваться от 0.0 до 1.0 ?
Ну как всегда, сам спросил, сам ответил.
v_vTexcoord.y - видимо изменяется от 0 до 1 не при прохождению по спрайту. а при прохождении по той texture_page на которой нарисован спрайт.
Тогда я беру uvs координаты низа спрайта, верха спрайта и передаю их в шейдер.
var tex = sprite_get_uvs(sprite_index,image_index);
zero_level = tex[3];
Сдвигаю х координату так:
vec2 Coord = v_vTexcoord + PixelWFrevec2((Zero_Level-v_vTexcoord.y)/(Zero_Level-One_Level) , 0.0);
То, что нужно. Бля, пол дня голову ломал, пока буквами не написал.
Правда? Если да то благодарствую)
Планирую выпустить где-то в начале весны, если все сложится.
Где то сам. Какие то функции по описанию/справочникам изучаю. Если совсем не могу додуматься то гайды ищу схожие по теме.
Например есть объект o_enemy1 и o_enemy2, но объект будет двигаться к тому, который ближе.
Вот тут и начинаются проблемы. У всех этих объектов уже есть родительский объект.
Вставь между ними ещё один родительский объект.
Функция будет находить объекты ниже по иерархии данные ей.
Например у меня есть родитель obj_living у него child obj_enemy у него child obj_rat
Могу обращаться ко всем живым, обращаясь к obj_living или ко всем врагам obj_enemy
Работает, спасибо.
Ты ещё и коллизии с объектами используешь. Никто тебе не виноват что ты кривой.
Ошибка из за камеры которая таскает за собой вид. Все равно не понятно почему лагает, раньше не лагало
Погоди, сейчас придут телепаты и расскажу тебе, как оно у тебя было раньше и что изменилось.
var lerp_amt = (time - keu_previous/number_of_key_times)* number_of_key_times;
/////////////////
color_mix= [lerp (color[key_previous,0],color[key_next,0],lerp_amt),
lerp (color[key_previous,1],color[key_next,1],lerp_amt),
lerp (color[key_previous,2],color[key_next,2],lerp_amt)];
Конечно, делали, ну ищи.
Отключай шейдер до того, как начинаешь рисовать интерфейс.
Может ты и прав, глянул щас, там нужно YоYо 400 долларов отдать, чтобы получить право размещать своё поделие в апсторе.
Уж сколько раз твердили миру - берите юньку, дауны;
но только все не впрок,
И снова ныть в гд приходит гамакодолбоеб.
>Размещение в апсторе $99 долларами за iOS Developer Program
Бвстрофикс. Но это от Хуана уже не зависит.
Все гайды и туториалы есть. Нет смысла пересказывать их ИТТ. Если английского не знаешь, то у пети сканера на ютубе есть подробный туториал по сборке приложения под андроид, с иосом примерно так же, не ебу. Не фанат эппла.
Не за что. Убедительная просьба к тебе. Если что-то получится, и даже если что-то не получится - отпишись о результатах в годотред.
Юнька для 2Д избыточна. А в гамаке еще и охуенная заточенность под работу с тайлами.
Делал себе игру, но буквально на неделю где-то пришлось сделать перерыв. Все работало нормально.
А сейчас открыл Гейм Мейкер, он обновился, я запустил Run и происходит какой-то пиздец: половина слоев не рендерится, половина мелькает и моргает, и полная жопа. Я ничего не изменял в коде. Почему такое могло произойти?
Потому что не взял юнити, а ведь тебя предупреждали
Ради эксперимента тупо сделал пустую комнату и пихнул туда какой-то ничего не делающий, но видимый объект: он вообще не рендерится.
Ложная тревога: дело оказалось в том, что я нечаянно забил жесткий диск до отказа за эту неделю, что и привело к таким результатам. Освободил место и все стало нормально.
Следите за своим жестким диском друзья, а юнитипидорам перо под ребро и хуй в сраку
Поясню за суть.
Моим дипломным проектом является игра. пишу аркадку на с++ в UE4, и до меня доебался куратор по димпломке с вопросом, А зачем А нахуя твоя игра и дипломка?
Лично я делаю для опыта и интереса, она хочет чтобы я раскрыл сокральный смысл моей работы, чтобы она спасла детей в африке, но я не ебу как это описать для чего работа
Глянь что пишут других дипломах на похожую тему, в чем проблема вообще?
Был научным руководителем у выпускника, мы с ним на юнити сделали игру ака вотч догс 2д про мамкиного хакера, взламывающего здание.
Приплели как анализ инф. безопасности систем. Когда игрока ловили охранники итд итп показывалась статья с описанием. По мере прохождения ГГ говорил о том, почему текущая организация плохо защищена.
Студент учился по этой специальности, сдал на 4(хотя мог изи на 5 сдать,он сам начал запинаться во время выступления).
Как вариант советую тебе взять какой-то процесс из жизни по твоей специальности и воспроизвести его с использованием твоего же УЕ4. А аркада абсолютно не связанная с твоей специальностью да, нахуй не вперлась никому. Пожумай сам своей головой,в комиссии будут сидеть 40+ дяди и тети, которым твои игрушки не интересны, им интересно, чтобы ты с умными щами заливал про важность предварительного анализа и моделирования hueta.Name , и именно твоя убогая программа позволяет это сделать.
Если будут еще вопросы, пиши.
Читаю это все и понимаю, какая же рашкинское образование галимая фикция и натужная попытка создавать видимость работы. Неудивительно, что все в стране по такому же подобию функционирует (если вообще функционирует).
>А зачем А нахуя твоя игра и дипломка?
Чтобы выпуститься наконец-то из вашего говновузика, Будто бы, блядь, дипломные работы вообще должны что-то решать, а не быть просто бумажкой для подтирания.
Я бы ответил как-то так.
Забей, они сами не знают чего хотят, поэтому им лучше более универсальный двиг. А если знаешь, что двадэ, то гамак наиболее удобный в плане отсутствия всяких "прелюдий" для начала работы. Берешь и рисуешь/кодишь. Изи.
Да не переживай, это не только в рашке.
Во всяких стэнфордах и берклях та же самая хуета с ещё большим попилом грантов.
https://www.youtube.com/watch?v=LVsqIjAeeXw
Вспомнил, когда учился в институте, нам физик сказал - напишите программу, которая моделировала бы наглядно какое-нибудь явление, поставлю зачёт. Я (как удивительно) - угорал по играм, написал на паскале простенькую программку, которая рисовала луч, отражающийся и преломляющийся от поверхности. Нарисовал (в пиксельном редакторе) транспортир, красивую поверхность, сделал управление кнопками, чтобы углом полосочки-луча управлять и по кнопке чтобы транспортир это вылетал и прикладывался к лучу, лол.
Получил зачёт автоматом.
По крайней мере если ты хочешь делать игры - там ты идешь тупо в институт, который, блять, охуеть!, учит делать игры, а не дрочишь 4-5 лет бесполезную хуету, чтобы иметь возможность как-то уцепиться по одной из профильных тематик и сделать игру как диплом, и то не факт что проканает, а без диплома тебя развернут.
Зато нет факультетов журналистики и полно факультетов богословия.
>А если знаешь, что двадэ, то гамак наиболее удобный
>гамак
У тебя пять ошибок в слове "годот".
Я второкурсникам когда преподавал структуры данных, сказал им самим выбирать тему курсовой, подготовил около 10 тем по играм от крестиков ноликов до тетрисов(они на тот момент по программе только консольные писали).
Почти все принесли игры и им понравилось, месяца полтора я их консультировал, каждому помог составить план разработки. Ну, как план, помог каждому разбить на этапы и каждую неделю приносить и показывать результат.
Они были очень благодарны, хэх.
А потом я дропнул преподавание, когда меня хотели заставить снова читать хуйню по информационной безопасности, в которой я не работаю. Ибо нахуй плодить необразованность.
Ты - хороший человек, добра тебе.
Опять прилетаешь РАШКУ? В Казани например на базе КФУ (в одном из его зданий) есть факультет, в котором учат твоему любимому гейдеву, на вторых курсах или позже начинается целенаправленное изучение сисярпа с Юнити. В Штатах тоже не на каждом углу учат игры делать, но да, факультетов там немного больше.
Понапаступают в сельские шараги, а потом удивляются.
Да и например PyGame в школах с 11 класса по профильной программе изучают, в Яндекс Лицеях с 8-9 классах могут.
макаронить говнокод - последнее, что нужно в геймдеве
геймдизайну учат полтора человека на всю страну, и я не про наёбку от вышкопидоров
Прочитал весь этот тред, и хочу сказать, что тут сидит один из самых адекватных и помогательных анонов на этой борде.
Если ты ещё сюда заходишь - добра тебе и удачи (если не заходишь - то всё равно удачи и добра). Смотрел, скольким ты тут помог и диву давался. Респект и уважуха.
просто-решил-высказать-своё-очень-важное-мнение-кун
>Два раза пытался в юнити, не осилил. Решил попробовать в гамак.
Тебе все равно придется его осилить, лучше не трать время зря.
Вот реально хотел бы выслушать плюсы и минусы, что выбрать вкатывающемуся в 2д-игростроение.
Давай порассуждаем.
distance_to_object будет искать ближайшее расстояние от объекта до объекта
distance_to_point будет искать ближайшее расстояние от объекта до точки
point_distance ищет показывает между двумя точками и ничего не ищет
Значит, оно быстрее всего
Даю добрый совет - если много текста, используй бесплатное дополнение, которое есть на маркете. Работает с текстом просто на ура, используя кучу сложных скриптов. HappyTearParacoopa
С гамака все уходят, он бесперспективный, не развивается, содержит фатальные дизайнерские ошибки, которые не дадут тебе сделать сколь-нибудь крупную игру.
Из годота может что-то хорошее и выйдет. А может и нет.
А юнити уже сейчас готовый продукт, стабильный, популярный и продолжающий активно развиваться.
не знаю, я просто так написал, я юнити не пользовался
ну там же наверняка нет окошечек, где прописан код отдельно на create, отдельно на step, отдельно на collision и т.д.
наверняка на юнити нет комнаты, куда можно мышкой перетаскивать объекты
наверняка на юнити нельзя делать анимированные спрайты прямо во вкладке sprites
ты толстишь что-ли?
create -> Start
step -> Update
collision -> OnCollisionEnter
комнта -> сцена
редактора спрайтов в юнити нет, но есть вкладка редактора анимаций
тем более гейммейкер не на языке С, который похож на джаву, которая мне не нравится
В новом гамаке только косметические изменения. Лучше сразу на другой движок переходи.
1500 стоит возможность экспорта на мак линух и шинду. Там за 500р продается только экспорт на шиндовс.
скидка 20% оч много конечно.
>меня бесит слово override, которое там есть. Что оно значит, я не знаю
Ты странный. Оно позволяет перезаписывать одну и ту же функцию, как угодно, в рамках наследуемого класса.
Спасибо, понял
>Лучше сразу на другой движок переходи.
Здравствуйте! Я бы хотел предложить вам молодой, развивающийся движок ПЩВЩЕ. Опенсорсный!
>только экспорт на шиндовс
Как что-то плохое. Аудитория на маках и линухах стремится к нулю, а те кому очень нужно могут под вайном запустить.
Так вот, как со всем этим сейчас дела обстоят? Правильно понимаю что уже имеются компиляторы под пс4,хуящ,свитч? Как с пиратством?
В принципе восьмёрка еще пашет, но, бля, это всё же говно мамонта и пора обновиться.
не знаю, есть пиратская версия для компиляции под десктоп. Но если найдешь под андроид или html пиратку, буду благодарен и скину денежку
Нашёл только такую, не ебу какие компиляторы работают.
https://thepiratebay.org/torrent/23041242/Game_Maker_Studio_2.1.4.285
актуальный кряк практически всегда можно найти тут в обсуждении(на нынешнюю кста там тоже есть),сам пользовался пока не купил (ведройд аштимель и шиндовс робочие проверял сам)
https://gmsc-97507.firebaseapp.com/
спасибо, анон. Под андроид же потом нужно будет всякие sdk устанавливать, лааадно
ну разок поеаться с сдк придется ,но достаточно прочитать оф гайд на сайте йойо ,там все написано, только на пендоском , но даж по картинкам удет понятно
какая есть, но и без слоев можно обойтись, глубина все так же работает ,как раньше
Зато таймер одной строчкой, лол.
А то у меня вопрос появился по организации данных в коде. Делаю игру нелинейную, в которой есть несколько персонажей и линейный прогресс его истории. Проходить истории каждого можно в любой момент.
Так вот, вопрос заключается в следующем:
Для каждой комнаты должен иметься список персонажей и их параметров (координаты, текущий спрайт и прочее подобное), триггеров катсцен и всего того, что может появляться и удаляться через прогресс истории.
Как и где их лучше хранить? Я предполагаю пока, что для этого хорошо подойдет json. Если через json делать, то для этого нужно использовать ds_map()? Как быстро гамак работает с ним вообще? Есть ли способы быстрее/оптимальнее?
Да, все стрктуры данных в гамаке делаются через ds_list, ds_map, что пиздец как неудобно.
Ну, выбора особо и нет, а изобретать велосипед вряд ли выйдет производительно. Буду работать с тем, что дают.
мимо анон, храню в ини файле все что есть, тому что проще. А массивы нахуй нахуй
Юнити, если новичок констракт. Ну можно и на гамаке, но он говно бесперспективное.
На том же, на чем делалась Лиза — RPG Maker.
Хммм, ну вот смотри, меня интересуют платформы: десктоп, мобилы, хтмл5 - на годоте я смогу создавать свои поделия бесплатно. Чтобы аналогичное сделать на гамаке, мне потребуется 99+149+199 = 400 баксов.
Итак, что такого крутого мне сможет предложить гамак, чего у меня нет в годоте?
Сходи в годотред, там тебя покормят ссылками на игры прямо из шапки и ты сможешь в 100500й раз сказать что "игры по ссылкам не игры, дайте игры на эртэ".
Бля, ну вот серьёзно. Ну хватит уже эти движкосрачи. Лучший движок тот, который лично ты лучше знаешь.
Если анон не знает ни одного - для него лучше будет тот, что проще изучить.
А с учётом того, что ему нужно 2D - стрелка указывает на два варианта: Construct2 или GameMaker.
>я смогу создавать свои поделия бесплатно
Не бесплатно. Ты не учитываешь своё время. Если ты вложил полгода (1000 часов примерно), то ты потратил минимум 1000*10=10000 долларов. 400 долларов - это 0,4 от всей суммы затрат. Или 40 часов.
Насколько дольше ты будешь разбираться в годоте/юнити/дельфи/уече и насколько быстрее(медленнее) ты тоже самое сделаешь в гамаке? Ответь на эти вопросы и ты поймёшь, что дешевле - годот или гамак.
Но это, опять же, будут твоя личная стоимость.
>игры по ссылкам не игры
Тетрис и марио можно и без движков запилить и бегать верещать - ВОТ ИГРЫ ВООООТ, ДВИЖКИ НЕ НУЖНЫЫЫ!
Нужно уже отдельный термин вводить "годотовская игра" как символ кала, высранного школьником на какай-нибудь конкурс школьников - высри хуйню за 48 часов!
Спасибо.
>опенсорсность бесплатнасть
Это значит, что один аргентинский велосипедист, лежа на пляже в перерывах между написанием чиптюновой музычки и поревом жены будет делать фичи к движку очень долго с огромным количеством багов, не доводя ни одну до конца. Донатят им 10500 долларов в месяц на двоих.
Он правильно сказал, не надо портить ламповейший тред вашими срачами. Пожалуйста, проследуйте оба в годо-тред.
Ты мне еще расскажи что мне делать.
это пока ты не решишь прикрутить к игре что-нибудь сложнее стреляющего бегающего спрайта
нет спасибо я не голодный
>А зачем мне 3д?
За тем, что все долбоебы думают - 3д сложна, сделаю 2д говно на мобилки! - И теперь на мобилках такой поток хуйни, что никак не пробиться. Следующий этап осознания - на мобилках ловить нечего, сделаю 2д хуйню для стимы... Но там тоже самое...
В итоге придешь к тому, что 3д делать сложно, но конкуренция меньше и деваться некуда.
>Мне и в юнити кривого 2д хватило
Узнаю гэдэ. Заебавшись с двадэ в тридэдвижке, гдачер идёт в двадэдвижок и ебётся там уже с тридэ.
Так и живу, на гамаке 3д, а если полезу в юнити/анрил, буду в 2д. Иначе не интересно.
Пробовал через lenghtdir_x/y но безуспешно
тут какое-то хитрое 3д, сел-шейдинг или вроде того. Хотя можно навелосипедить, что уж.
Спасибо анончик.
Все оказалось намного проще. Нужно было просто растянуть сурфейс.
как то пиздец проблематично это все было гуглить. с таким трудном нашел то, что нужно
попробуй выключить интерполяцию
Красота. Это несколько спрайтов, которые врашаются и смещены по вертикали друг относительно друга?
ГМ со второй версии в говно скатился. Бери либо Юнити, либо Годот, либо ещё что.
что такое сплайн?
Когда хочешь сделать визуальный эффект, который не получается без них.
Когда тебе нужно искажать весь экран, либо делать что-то со всей картинкой в каждом кадре на уровне пикселей.
я-с-дивана-не-пинайте
>ГМ со второй версии в говно скатился
Почему? Я запускал ГМ2 и у меня вообще вопросов не возникло. Все удобно и понятно (с помощью ютуба). Черт, там даже встроенные туториалы есть.
Потому что годотошкольник срёт в треде. ГМ - отличный движок.
потому что гм для людей сделан ,чтоб все понятно было
Интерфейс слили в абсолютное говнище. Вместо нормальных вкладок или окошек, как в прошлой версии, какие-то обоссаные сплайны с воркспейсами. Сами элементы интерфейса увеличились раза в полтора, так что реального полезного пространства стало гораздо меньше чем было.
Сам же гмл порос каким-то говном -- добавили слои, которые на самом деле обёртка глубины (которую убрали, удачи теперь с depth = -y), с конвертацией строк намутили какой-то ёбаный пиздец с тысячей различных поведений вместо простого автокаста числа в строку.
При этом все, кто купил ГМС1, идут нахуй покупать это чудо заново. И ладно, добавили бы какие-то хорошие фичи, так нет же, сговнили интерфейс, глубину и добавили анимированные тайлы.
И буквально только сейчас, после трёх лет с релиза ГМС2, ЁЁ таки подняли с жопы и впиливают структы в гмл - то, что у них просили ещё со времён ГМ8. Хотя ещё надо посмотреть, как они их впилят - не мал шанс, что просрут так же, как просрали каст чисел в строки.
Я писал игорьки на гм порядка шести лет, но после такой хуйни свалил от него подальше - и ни капельки не жалею.
>Интерфейс слили в абсолютное говнище.
Вкусовщина. Я после интерфейса гмс2 не могу воспринимать интерфейс гмс1 вообще.
>(которую убрали, удачи теперь с depth = -y)
Так и делаю, всё абсолютно нормально. Совмещаю слои и depth. Слои удобны в room editor. Слой это просто ссылка на глубину.
>автокаста числа в строку
О чём ты, я не понимаю?
А вот дебагер в гмс2 сделали просто роскошным. Ещё бы дали возможность зумировать текстуры в предпросмотре и дебагать шейдеры.
>Так и делаю, всё абсолютно нормально. Совмещаю слои и depth. Слои удобны в room editor. Слой это просто ссылка на глубину.
Там для этого новый слой создаётся на каждое новое значение depth. Ты себе так игру повалишь к чертям.
>О чём ты, я не понимаю?
В ГМЛ чтобы в строку пихнуть число, надо делать вот так:
"value: " + string(someValue) + "."
Во всех нормальных языках это давно делается вот так:
"value: " + someValue + "."
Люди просили сделать нормальный автокаст, так эти долбоёбы устроили какую-то джаваскриптовую парашу и впилили наоборот. Теперь строки конверируются в числа. Иногда. А иногда не ковертируются, а вылетают. Например, 1 + "2" выдаст 3, а "1" + 2 - ошибку, нахуй.
Сурс: https://forum.yoyogames.com/index.php?threads/gml-consistency-in-gms2-v2-2-2.59856/
Я в курсе. И что? Для gui у меня слои вверху, для обхектов на карте набор слоёв ниже. В room_start я забираю минимальное и максимальное значение глубины для объктов (из первого и последнего слоёв, предназначенных для объектов), вычисляю шаг глубины, соответствующий шагу по y и каждому объекту добавляю room_start event с одной строкой
depth = obj_game.zero_depth + obj_game.depth_step*y;
Так на старте комнаты все объекты занимают свою глубину. Очень удобно, т.к. на карте их куча, но все распределены по слоям. Можно выключить все кусты, или все деревья и т.д.
>В ГМЛ чтобы в строку пихнуть число, надо делать вот так:
>"value: " + string(someValue) + "."
Я вообще не вижу в этом никакой проблемы. Наоборот, это, сука, нормально.
>Люди просили сделать нормальный автокаст
Со временем я начинаю понимать, что автоматическая конвертация переменных - это не очень хорошо. float должен быть float, real должен быть real, int не должен внезапно превращаться в real и т.д. Прибавлять к строке число не правильно.
Вытащить число из строки.. Это иногда может быть полезным.
Но
> 1 + "2"
блять, не надо так.
>Я в курсе. И что? Для gui у меня слои вверху, для обхектов на карте набор слоёв ниже. В room_start я забираю минимальное и максимальное значение глубины для объктов (из первого и последнего слоёв, предназначенных для объектов), вычисляю шаг глубины, соответствующий шагу по y и каждому объекту добавляю room_start event с одной строкой
Хуйня это. Не должны слои плодиться сотнями. Собственно, одна из причин, по которой с ГМ свалил - если не хочешь следовать идиотским решениям разработчиков, придётся сильно говнокодить, либо заглотить как есть.
>>590095
>Со временем я начинаю понимать, что автоматическая конвертация переменных - это не очень хорошо. float должен быть float, real должен быть real, int не должен внезапно превращаться в real и т.д. Прибавлять к строке число не правильно.
Приветики, ты на гмл пишешь. У тебя там только два типа данных - дабл и строка, да ещё и строгой типизации нет. Вот это действительно неправильно, а автокаст в строку ни к чему плохому не приведёт.
> Вытащить число из строки.. Это иногда может быть полезным.
Конечно. Только это должно быть выполнено в фиде отдельной функции, а не автокастом, который ещё и работает только в половине случаев.
Твой пост пропитан синдромом утенка. "Раньшибылалудше, Дуров, верни стену", ага. Каждый твой аргумент — "вот тогда было так, а щас вот так и мне не нра". Все с тобой ясно.
Так дело-то в том, что и у ГМС1 интерфейс был говном. Ужасно дёрганный и глючный. Это реально надо было поменять, но не в ущерб реальному рабочему пространству. Более того, на нотубуке с трекпадом воркспейсы - вообще какой-то пиздец.
Слои же - это классная концепция, которую давно пока было ввести. Но не так убого, как это сделали ЁЁ. Ведь можно же было оставить сортировку по глубине внутри слоя, и всё было бы круто. Даже дело не в том, что оно в принципе поменялось и это хуёво - дело в том, что текущая реализация ставит палки в колёса если хочешь depth = -y. ЁЁ просто поленились сделать по-нормальному, а обычным юзерам теперь это расхлёбывать
>>590138
На твою маму.
Программисты на такой хуйне даже за деньги пилить не будут, все правильно разрабы делают.
Почему же? Видел много программистов, ковыряющих ГМ. Даже сейчас. Под ГМС2 даже нормальный редактор кода запилили, без обоссаных сплайнов и со вкладками.
так все эти сплайны вырубаются в настроках ,а так да ,сижу на этот самом редакторе
На стриме у галенкина издатель говорил, что если к нему приходят с годной игрой на гамаке то ее перепиливают на юнити сами потом.
А чего жоскаво-то? Все современные движки сделаны по одному шаблону: майнлуп с колбеками и сиподобный синтаксис скрипта.
Тебе один раз нужно сделать образец для переноса игор с движка А на движок Б, в котором будут имитированы нюансы движка А с реализацией на движке Б. Например, встроенные функции-хелперы. В движке А допустим есть функция lerp(vec2 from, vec2 to, float step) и код игры завязан на неё, а в движке Б это метод вектора vec2.lerp(vec2 to, float step). Зная это, ты один раз пишешь примерно такую функцию-обёртку:
lerp(vec2 from, vec2 to, float step) { return from.lerp(to, step); }
И далее исходный код пихаешь без изменений. Ну это самый простой случай. На деле инди разрабы могут дичайшую дичь издателям приносить.
Не вижу обсыка. Анон сделал прототип на движке, в котором ему удобно делать прототип. Студия издателя перекинула прототип на профессиональный движок и сделала релиз.
нпросто в аргумент текста пишешь "%" ,если там квадрат ,то шрифт не поддреживает этот знак ,а можешь вот так string(значение) + "%"
Да, тупанул, действительно в шрифте просто не было символа. Вот все символы есть, а % нету.
> синдромом утенка.
Школьник детектед.
За гм не скажу, но очень часто бывает, что программы с новыми версиями становятся всё хуже и хуже.
Ты не понял, я это не для ёбнутых опущенцев писал, так что проходи мимо.
Без задней мысли
Вероятнее всего потому, что всем всё понятно.
Но крайней мере тем, кто пилит свои игры на гамаке.
Если что-то не понятно - спрашивай. Но не забудь перед этим прочитать мануал.
Тебе платят что ли за это, ебанутый?
840x524, 0:43
Процедурную генерацию на потом отложил, я ее за час сделаю (не выёбуюсь, опыт есть и ворлд генерации и данжей), сейчас enviroinmental dangers, инвентарь, сейв/лоад, такое.
>Делимся опытом
Пишу на gmEdit, еле-еле нашел работу 10$ в час на удаленке, так вышло что из Unity3D, Cocos Creator'a и Phaser самая доходная работа именно на платформе game maker studio 2.
Остальные gms'ы лучше даже не трогать, они мертвы и не поддерживаются. gmEdit позволяет делает такие вещи как лямбды, даже какие-то корутины и фэйковые типы данных (аж через точку будут показываться, но само собой для такого трюка нужны энамы). Также помогает с аргументами скрипта, больше никаких грязных argument0, argument1,
просто пишешь #args val, foo, bar (а если в конце добавить запятую тогда уже можно работать с argument count для бесконечных аргументов)
Что могу сказать о том что такое game maker и почему он может быть интересен, в нем достаточно развитое сообщество, есть свои звезды программирования которые накодили к нему сторонних инструментов и библиотек, lazyLoad, gmEdit, gmLife, gmsTweens, Scrimblе, HaxeToGML, был еще какой-то для более интерактивной справки
Плюс к этому он позволяет писать логику игры местами даже лучше и быстрее чем на каком-нибудь lua.
Для меня этих плюсов достаточно чтобы покрыть его минусы. Но само собой есть игры, в которых я гмс никогда бы не выбрал (но блин он такой халявный местами, что если честно через скрежет открывал юнити, но что поделать, это жизнь, а я программист, который должен решать задачу)
Также хочется добавить к этому сообщению, что я стал ценить свое время. Поэтому не желаю денег на инструменты, чтобы заработать их еще больше. Нет смысла искать пиратские версии, просто даже из-за обновлений и поддержки авторов, которых можно донимать, потому что купил их инструмент)
в некоторых случаях и инвентарь требует оптимизации, потому что по итогу в некоторых случаях 180 или больше ячеек инвентаря быстрее работают в объектах, чем в фейковых структурах)
Но быстрее они будут работать только если не будут каждый шаг обновлять свою позицию по центру, а только при открытии например.
Есть кейсы когда важно оптимизировать, а иногда нафиг не нужно.
Это копия, сохраненная 11 ноября 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.