Обсуждаем, обмениваемся опытом, задаем вопросы.
Относительно недавно вышла вторая версия: GameMaker Studio 2, пиратки которой еще нет.
Стало НАМНОГО удобнее работать с тайлами, слои тоже помогают.
Так-то 1.4 может все то же, что и двойка, поэтому если жалко бабла, можно писать на старой версии. Но двойку будут развивать и она будет становиться только лучше.
Двойка - недоделанная параша. Лагающая, забагованная и неудобная.
А 1.4 я купил с кучей индюшатины на хамбл бандле за 15 бачей и не жалею.
У меня на десятилетнем ПК летает.
>Список багов в студию
А вот один баг я лично отрепортил. Функция keyboard_key_press в step event при 60 fps вызывала утечку памяти, крашила игру через некоторое время и не позволяла запуститься дебагеру - крашила его сходу. Понять в чём причина было очень тяжело.
>Хз. я после 1.4 просто кайфую от скорости своей работы.
Я периодически открываю 1.4 для туториалов. 2 намного удобней. Но воркспейсы всё равно недобработаны. Должно быть как-то по другому. То что есть - годится только для драг-н-дроп даунов.
Так что шлём этого >>439595 нахуй уже вдвоём.
В основном тем, что из-за боковых окон на воркспейсе места мало. Соответственно и окошки очень маленькие. Постоянно возникает горизонтальная полоса прокрутки. Чтобы нажать на неё нужно либо вырубать нижнюю панель (которая всё равно влезает назад после каждого запуска игры) либо таскать окно. И боковая панель всё время вылезает, если у тебя где-то в таба комната открыта.
Ну и без правой панели всё равно не обойтись, ибо навигироваться по воркспейсу невозможно. С выкрученным зумом невозможно разобрать, что там в окошках. При основном масштабе нужно тянуть несколько экранов, чтобы найти нужный обхект с открытыми ивентами.
Даже на домашнем 40ка дюймовом монике постоянно такая проблема. На мелком рабочем мониторе - просто невозможно пользоваться.
Такие дела.
Зачем обсуждать гамак здесь? Если есть какие-то вопросы - на них ответят на форуме 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, следящий за сменой комнаты.
Ладно, ты ж не гугл. Можешь не отвечать.
https://files.64digits.com/tahnok100/Order_Of_Events_In_Game_Maker_Rev.1_Tahnok100_.pdf
Как правильно ограничить вид чтобы он не выходит за пределы комнаты? Чтобы он как влитой останавливался у края комнаты а не резко "пружинил"
Единственное серьезное слабое место в 1.4 это редактор комнат. Ну и редактор кода можно подтянуть. Остальное можно вообще выпилить, только мешает. По мне так гамаку гуй вообще не нужен, особенно гуй объектов.
Любой формы, которая описывается мат. формулой очень легко.
Ознакомься:
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]);
заработало.
На ютубе примеры что я нашел рисовали окошки с помощью draw_rectangle или вообще draw_line, что мне не очень подхожит. Нужно чтобы окно создавалось именно из кусков спрайта.
Требуется сделать прототип игры на Game Maker Studio 2. Ничего сверхъестественного - список фич, которые требуется реализовать скину. В основном это ходьба, менюшки и т.д. Ничего сложного.
Контакты - forgm@list.ru
Работа оплачивается
Ничего себе просрали. Гет в ГД взяли игрой. Это ли не вин?
Я сделал это за один день.
В гамаке недостаточно просто уничтожить data structure (например ds_grid) функцией ds_grid_destroy(name)
Необходимо также очистить указатель на неё
name = noone;
Иначе если какой-либо ещё объект создаст новую data structure, твоя переменная name может снова стать указателем на data structure, только уже другого объекта.
Этот долбаный баг преследовал меня месяц. Наконец я понял в чём дело. Может ещё кому-то пригодится.
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
Охуеть не встать. Нахуя вообще такие функции нужны?
Спрошу еще и тут, может знает кто.
Как масштабировать в гейммейкере в целое число раз в полноэкранном режиме. Если разрешение экрана не делится на цело на заданное то нужно, увеличить рабочую область максимально насколько возможно, а вокруг оставить черную рамку.
куда уж конкретнее. Хочу в экран настроек игры кроме локализации, которую уже запилил, ползунки громкости звука, а если быть еще конкретнее, то музыки игровой. В готовой решении могу сделать три ползунка: мастер, музыка, эффекты, и убрать два последних, но мне по сути нужен только второй, а из-за чудесного кода плугина это сделать не получится. Либо мириться и оставлять два ползунка, либо что-то еще придумать
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
>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%20application%20surface.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-кун
Если я хочу писать бровзерные игори, то надо платить 149 бачей?
Я правильно понимаю, что gamemaker не дает сохранять файлы в папку с игрой, а только в общую папку <LOCALAPPDATA>/<GameName>? И теоретически, если на компе другая игра с тем же именем будет писать в тот же файл, то она всю сохраненку похерит. Как с этим бороться и нужно ли?
Никогда не юзал ГМ
Подскажите мне, как правильно переносить камеру из комнаты в комнату? У меня при переходе из комнаты в комнату странным образом растягивается. Пока что я решил, что буду убивать камеру в room_end event и создавать новую камеру в room_start event. Но правильное ли это решение?
Лучше, чем Unity? Как производительность относительно phaser?
Заодно может подскажете, из вашего опыта или вычитанных где-нибудь мудростей, каким количеством объектов на комнату следует ограничиваться?
Заодно может подскажете, из вашего опыта или вычитанных где-нибудь мудростей, каким количеством объектов на комнату следует ограничиваться?
покажите САМЫЕ КРАСИВЫЕ игры на геймейкере
Вопрос к специалистам. Как реализовать редактор уровней в gms?
>2
Язык-то добавили или так на ЖМЛ и сидите?
Вот код:
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;
}
}
Первый That Level Again на libgdx сделан. Что еще расскажешь ыксперд?
>>457498
На первый такая же цена. Мне он правда по акции достался за 25$ весь комплект. Проф-версия, андроид и все-все-все, кроме iOS. Правда без интеграции со стимом, но через год дали и её. Надо просто подождать распродажи.
То еще говнецо.
> Первый на 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);
Ну и соответственно при ресайзе окна было то же самое - растягиваешь окно, а у тебя не изображение растягивалось, а просто больший кусок игрового поля показывался.
так ты не пости, а просто поиском пользуйся, там да, как на дваче. В идеале как можешь делать - гугли на маркете гамака ассет под нужный тебе жанр игры (платформер, шмап и тд) , качаешь и разбираешь его по косточкам, там и найдешь самописные решения. Либо смотри туториалы пиксельпопа, heartbeast'a и шона сполдинга
Для платформера вообще не нужна физика, начнём с этого. Если что-то перемещается, это не значит, что надо использовать физ. движок.
phy_position задается в коде один раз, а перемещение осуществляется приложением силы к объекту. Прочитай внимательно ссылку на статью, которую тебе дали.
Правильное решение: убери физику с персонажа и двигай его так же, как и пулю - изменением координат.
хуевый выбор, чую, если сдвинешь курсор, то пули тоже изменят направление
лучше высчитывай направление один раз исходя, например, из угла отрисовку спрайта оружия, если оно поворачивается, и используй lengthdir
>>461502
не будет, движение просчитывается каждый кадр, никакой разницы между физикой и её отсутствием тут нет
У меня есть движущиеся платформы, которые не представляю, как сделать тайлами.
В связи с этим два вопроса.
1) Будет ли прирост производительности, если статические стены (коих 90%) заменить тайлами, а движущиеся оставить объектами?
Тогда, получается, мне нужно будет в коде проверять коллизию дважды - на тайлах и на объектах. Но ведь объектов-стен теперь будет на порядок меньше. Стоит ли пытаться?
2) Можно ли сделать движущиеся платформы тайлами?
Вон в том же туториале, который ты смотришь, написано, что лучше шейдер использовать.
// 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/
Ну и как спрайт кусками рисовать - сам разберёшься.
Смотрю урок Make an RPG, там проблему бесконечного проигрывания анимации после начала движения решают через
if (!key_right and !key_left) {
image speed = 0
}
Я же хочу включать idle анимацию. Понятно, что надо просто прописать sprite_index = spr_player_idle; но у мня их две штуки, чтобы игрок оставался в левой idle анимации после того, как шел влево и в провой idle анимации после того, как шел вправо. Как это сделать?
Нет, не через скеил. У меня просто прописано
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 и вопрос по анимациям остался, т.к. он там удары не стал анимировать. С анимацией ходьбы/бега все понятно: нажимаешь вправо - проигрывается анимация вправо, нажимаешь влево - проигрывается анимация влево, а вот с ударами как? Как сделать, чтобы при нажатии одной и той же кнопки удара игра понимала, какую именно из анимаций проигрывать? Короче мне надо еще уроков по гейм мейкеру, в этой серии он многих вещей не касается.
В сети достаточно подробных туториалов для нубов, по которым даже человек абсолютно без опыта программирования может повторить шаг за шагом процесс создания игры в гамаке, но те что я видел, обычно для платформеров, изометрических рпг или топ-даун шутеров.
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 это ссылка на твою комнату.
И так далее.
Спасибо. Я едва ли что-то из этого понял вчера когда прочитал, но сейчас немного разобрался, когда делал удар врага по игроку.
Переменную можно привязать к объекту и это удобно тем, что можно создавать этот объект с уже заданными параметрами в коде его создателя.
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]?" и не вспоминаешь "а я этот же аларм использовал для кулдауна регенерации здоровья, надо поменять." У тебя всё в криэйт ивенте хранится.
Нахрена тебе эта ересь?
За совет спасибо. Про 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 новой комнаты.
Я надеюсь ты понял мысль.
>Потому что это не объект игрок перемещается куда-то, а исчезает одна комната и на её месте появляется другая.
>Если на каком-то объекте стоит галочка persistent, этот Теперь все понятно, на obj_player у меня как раз стоит persistent. Makes total sence.
>>474289
Из этого поста пока мало что понял, но не буду рашить. У меня еще много базовых вещей впереди на освоение. Вернусь к этому чуть позже.
Рисуй в 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 человек сидит. В общей сложности.
Я всё ещё добрый полицейский. Но это в последний раз.
У тебя 2d вид сбоку? Или 3d? Или изометрия? Ты не способен видео залить на двач? Иди учись.
Если 2d вид сбоку - рисуй.
Ты из автомата стреляешь или из пистолета?
Где ты видел, чтобы кто-то за спину себе стрелял? Как ты вообще себе это представляешь?
Посмотри как в ghost 1.0 сделано. Она наклоняется вперёд и назад туловищем, сгибает руки, отставляет назад ногу, опускает и поднимает голову и стреляет только в передней полусфере. Если надо стрелять назад - разворачивается.
Она векторная, состоит из кусков, но каждый кадр стрельбы отрисован. Каждые 10 градусов поза чуть-чуть меняется, а в пределах 10 градусов ходят только руки.
Если ты хочешь тупо вращать неанимированный спрайт рук - у тебя и получится тупо. Чтобы было хорошо нужно много работать.
>Каждые 10 градусов поза чуть-чуть меняется
Ну и это будет выглядеть дёргано и будет ощущение, что пуля летит не из дула
>Где ты видел, чтобы кто-то за спину себе стрелял? Как ты вообще себе это представляешь?
Ну так за спиной у меня спрайт меняется на противоположный
>Ну и это будет выглядеть дёргано и будет ощущение, что пуля летит не из дула
Ты жопой читаешь? Поза меняется каждые 10 градусов. В пределах этих 1- градусов перемещаются руки. Открой ghost 1.0 да посмотри как там сделано.
Чтобы это повторить мне, например, нужно недели две рисовать. У меня уже опыт некоторый есть со спайном. Тебе - два месяца понадобится. Готов? Вперёд!
https://rutracker.org/forum/viewtopic.php?t=5528246
Код:
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;
}
В итоге получается хуйня, как на пикриле: посередине квадрат, за которым в углу находится персонаж. Жёлтое - коллизия. В чём подвох?
>В чём подвох?
>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 и покупаешь девкит. Уведомляешь нинтенду что будешь писать на свитч.
Теперь ты илита и грезишь о феррари как у кармака, с единственным обязательством - никому не говорить о бойцовском клубе не разглашать никаких сведений о внтренней кухне свитча без разрешения нинтенды - иначе сгуха и суд.
После чего с полученным разрешением идешь на форум юнити в закрытый от простого быдла раздел где по ссылке качаешь закрытые компоненты юньки для свитча (нужна версия про, если что).
Ну и да, в данном варианте, не забывай что нинтенда по-факту становится твоим издателем и ты будешь обязан выполнять все её пожелания, зарубать по её прихоти свои безумные идеи, реализовывать одно охуительнее другого пожелания нинтенды оптимизировать код и.т.д.
Форма заявления на анальное рабство здесь:
https://developer.nintendo.com/register/create
>А как работает передача туда значений?
Слегка через жопу. При вызове скрипта стандартно -- пишешь аргументы в скобках через запятую. А в самом скрипте будет что-то вроде
var xyz=argument0
var qwe=argument1
и так далее.
>Нужно ли это вообще?
Естественно, и возвращать из них значения тоже нужно.
всё, на самом деле я и сам разобрался. Не привык я к тому, что в документации действительно ВСЁ написано. Я такое наверное только к РенПаю видел, и то там пользовательские вики, а не официалка.
Но всё равно большое спасибо. Я рад что у вас тут дружелюбное коммьюнити.
Идея была проста:
два массива, в одном символы допустимые для данной сложности, во втором символы нагенерированные для уровня.
После генерации спавнятся блоки на которые наносятся эти символы по порядку.
Но я э... Видимо, где-то что-то проебал по фактике и мне пришлось перезагружать компьютер, потому что он чуть не загорелся, так и не запустив окошко. Но он так и не выдал ошибки. Я боюсь открывать этот проект у себя :(
чё делать?
братан, причин множество. кривой 3д-режим, который не справляется с переходами из него, depth объекта выше задника, прочее говно с view, alpha в 0, крч тонны их. я не смогу угадать. это как если бы ты спросил "почему у меня моделька в юнети не импортируется".
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)
Вот тебе счастье
Здарова, игроделы. Хуй знает, может кто сталкивался с проблемой. Когда объект движется по диагонали, то камера начинает дергаться. В чем проблема то может быть.
А я тебе лучше совет дам, чтем этот >>493578
Не используй встроенную гамаковскую камеру. Делай свою.
В этом треде есть всё, что нужно:
https://forum.yoyogames.com/index.php?threads/guide-meet-the-new-camera-system.12269/
Вот здесь.
https://docs2.yoyogames.com/index.html?page=source%2F_build%2F2_interface%2F2_extras%2Fdebugging.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;
}
}
Можно даже свитч из свитчей, но так код, имхо, более читаемый.
Господа, я тут недавно начал осваивать сурфейсы. Собсна вопрос, как на сурфейсе отрисовывать анимированный спрайт?
Не работает нихуя.
У меня есть хуйня, при помощи которой можно выкидывать предметы из инвентаря. Выкидываются они по окружности, как на рисунке, но в красные области по бокам выкидывать нельзя, потому что предмет там застревает с нихуя и его нельзя подобрать. Следовательно мне нужно исключить области от 330 до 30 и от 150 до 210 градусов. Если я пишу
var itemdir;
if(irandom(30)){
itemdir = irandom(150);
} else {
itemdir = irandom_range(210, 330);
}
, то нихуя не работает.
enum item {
item1 = 1,
item2 = 2,
...
item100 = 100,
}
Как мне в irandom_range(1, 100) убрать, скажем, тридцатый номер?
Ты не о том паришься.
Разбивай на скрипты и регионы смело.
Я тоже долго парился о такой фигне.
Да я все время блять не о том парюсь из-за своего ебаного перфекцеонизма. Тем более я еще даже на стадии прототипирования, где по идее велосипедить и костылить вполне норма, но нет блять, мне нужно сразу все в финальной архитектуре и с минимальной нагрузкой на железо. Но в принципе так, как ты скинул, я себе все это дело и представлял. Мде, работа прогером явно не для меня.
Вот нашел чем удивить. Когда я только начинал, точно так же пытался всё сделать максимально эффективно. Например по мтнимуму вводил новые переменные, они же память занимают! Лучше я одну и ту же переменную буду использовать как таймер для всех фаз и всех состояний. Но это же полная хуйня.
Сейчас уже во-первых меньше парюсь, а во-вторых на автомате многие действия делаю. Типо того, чтобы в for цикле не вычислять одно и то же каждый раз, шаблонно инициализирую скрипты, сравниваю друг с другом квадраты расстояний и т
Д.
И всё равно, когда требуется написать что-то не требующее оптимизаций (инвентарь например, или эффект в паузе) просто кайфую. Писать получается в три раза быстрее, а код, по сути, такой же точно выходит.
>Как заставить скрипт выполняться несколько раз?
https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/401_11_for.html
>внутри самого скрипта
а почему бы и нет?
>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, ...);
Анон, выручай.
Проснулся из глубокого сна, лол.
В 2011 баловался с GM 8.0., в 2012 купил в стиме game maker stuido за даллары, но так нихуя и не сделал, но потом узнал, что моя лицензия походу стала бесплатной.
Что там сейчас в 1.4? Можно ли на ней делать и релизить бесплатные игры в том же стиме? Можно ли монетизировать рекламой внутри игры?(да, влажные фантазии, просто не смог найти адекватной лицензии). В том же юнити все просто, получаешь больше 100к $ - покупай лицензию.
Или для все этого нужно покупать анальную 2.0 студию?
Смотрю гайди, часто пишут. По логике нарисовать объект, но он и так сука есть. Зачем нужно это?
Потому что draw_self изначально есть у всех объектов, но создав даже пустой скрипт в событии draw, оно продает и тебе необходимо указать его явно, не сделав этого и запустив игру у тебя просто не будет рисоваться тот спрайт который ты указал в настройках объекта
А как же мне быть? Тратить тонну бабла особо не охота, пока я не получу хоть какой-то играбельный результат из своих копаний с этим движком.
Писать свои алгоритмы поиска пути..? Да нет, спасибо.
Есть ещё какие-то варианты? Или, мб, ломаная версия (только на период разработки. Как только я начну собирать проект я обязательно куплю лицензию)
>тратить бабла не охота
Не охота, до тех пор, пока то, что я делаю не оформится в играбельный вид. Я же говорю, в целом, я более чем готов платить за лицензию. Но какой смысл покупать её, если, я не знаю, я где нибудь в середине пойму, что мне не хватает возможностей? Или, там, что всё лагает как кусок говна.
Потом я, в любом случае, купил бы лицензию чтоб собрать проект
Ну вот написал я допустим прототип сайдскроллера, в котором можно бегать, прыгать, эйрдешаться и даже умирать от падения со слишком большой высоты. Появилось некое вдохновляющее чувство законченности. Но нутром я понимаю, что код еще можно в сто раз удобоваримее переписать (хоть он и сейчас практически идеально работает, не нашел пока каких-то видимых багов), а также боюсь, что через неделю, когда у меня будет настроение вернуться к коду, я могу все позабывать уже (хотя это вряд ли).
Пока что сам себя обнадеживаю, что это прототип, так что над качеством кода можно не париться. Но когда дело дойдет до "чистовика", как подойти к этому вопросу? Нет у меня особо глубокого понимания, чем принципиально отличается "релизный" код от препродакшенового, и когда я смогу сказать себе "вот так и оставь". Хотя мб это во мне перфекционизм играет (он мне в сосничестве всю жизнь поломал, сейчас каждый день живу, сражаясь с ним), я хз.
В общем, тл;др - через что чаще всего должен пройти прототипный код, чтобы стать релизным? А то боюсь пока дальше новые механики писать, боюсь, что будет такая каша, что потом либо все переписывать придется, либо будет неоптимизированная параша.
> расскажите, когда кодер понимает, что его код
как только он написан. тут, понимаешь, без реальных образцов разного кода не обойтись. лаконичность (DRY, KISS) очень растяжимое понятие. кто-то жарит красивые однострочники, чтобы вместо 500 строчек было 100, а кому-то надо 100 строк без извратов с синтаксисом, третий напишет 1500 строчек с очень продуманным api и максимально высокой отчуждаемостью, а четвертый жахнет в 20 строк, но с миллионом тормозных зависимостей и "небольшим" сайд-эффектом. и автор каждого решения будет считать свой код правильным и хорошим. важно иметь опыт в каждом из этих подходов - тогда код становится инструментом. чем длиннее инструкция к молотку (комментов к коду) - тем больше он говно. и еще важно пройти этап тяжелых задач (кодеры постоянно комплексуют из-за тривиальных задач). чтобы желание "все переписать" отбилось, чтобы не плодить лишние классы... чтобы не было оверинжиниринга, чтобы у написание кода была прозрачная цель. и вот когда оба этих "важно" пройдены - только тогда ты можешь смастерить честный молоток, а не ходить по галочкам "меньше строчек" и "полное покрытие тестами". хороший код пишется медленно (пусть и быстрее из раза в раз), плохой быстро. сила в том, чтобы стараться везде засунуть говнокод, но угадывать места, где этого делать не стоит.
> через что чаще всего должен пройти прототипный код, чтобы стать релизным
через зеленую кнопочку "релиз" в админке стима, например.
с опытом
например я елси посмотрю свой код год назад у меня рукалицо, и я уверен что через год у меня будет такое же чувство если я буду смотреть на свой код в текущий момент
но вообще не еби мозги, прототип всегда может быть таким, если работает то заебись, потом отрефакторишь, когда общая картина появится
Поясните за компиляцию?
https://www.youtube.com/watch?v=BPJ4hCfTZEM
Лично у меня в игре где мало объектов и сложной логики разницы нет, но собираю в yyc
И это я только две анимации впихнул. Хуль так сложно? Как белые люди это делают, что у них ничего не застревает? А я еще наивный дебил хотел хитбоксами все захуярить, я ж ебанусь это вручную хуярить все.
Неправильный подход.
Сделай прямоугольник вокруг персонажа и считай коллизии по нему. Для всех его анимаций. Да, при этом у тебя какая-нибудь вытянутая вверх рука будет в потолок заходить в некоторых местах. Ну и что? Все так делают, никого не напрягает.
Я задал своему персонажу width и height и считаю коллизии по ним. Они не меняются вообще никогда. По колижн маскам считаю только столкновения с другими объектами.
единственный момент, когда рамка в стену уходит - залезание на препядствия. Для этого костыли стоят.
>зачем тебе рассчитывать ее, если ты задаешь hspeed и vspeed, и объект автоматически движется?
Затем, что он как раз таки начинает автоматически двигаться, и движение врядли как-то можно отменить не приравняв эту самую скорость к нулю. Мне нужен был именно расчет без движения.
А вообще сейчас хорошенько прогулялся по городу и понял что скорость можно найти по принципу point_distance(x, y, x+hspeed, y+vspeed).
Надеюсь подводных камней в таком методе нету.
У меня маска была в самой сердцевине персонажа, иногда игнорировала голову и конечности и пр. Думал, что при обволакивании будут слишком большие зазоры между препятствиями и персонажем. Окей, спасибо, попробую обволакивать. Прямоугольник, кстати - отдельный объект или в дро отрисовываешь?
У меня есть энное количество отдельных спрайтов, которые должны быть соединены друг с другом и вращаться как-то так, чтобы красиво было. Как автомат с магазином и лежащими на нем руками.
Но как только я начинаю эту ебалу вращать, она расплывается по всему экрану. Я понимаю, что для этого надо смещать все добро через тригонометрические функции, плюс появилась идея учитывать оффсеты спрайтов, но я не могу обволочь эти мысли в какую-то понятную для всех, для гейммейкера и для себя самого форму.
Есть ли где-то видеоуроки или хотя бы текст об этом? Во всех туториалах на ютубе пилят очередную говноспрайтовую РПГ, а у меня система анимации ближе к флешевой, многокадровые спрайты мне не подходят никак.
Пытаюсь сделать параллакс скроллинг в GMS2.
Все бы ничего, но во время движения с краю экрана появляется вот такая полоска, а когда персонаж останавливается, бэкграунд резко дергается на ширину этой самой полоски. Объект, на котором висит код параллакса загружается самым первым, код находится в Step Event, пробовал пихать его в End Step и Begin Step, но ноль эффекта
1. Если я верно понял, триалка не ограничена по времени и можно хоть до усрачки изучать триал, и даже полноценно пилить в нём своего игоря?
2. Что там с физикой, есть хоть какие-нибудь зачатки?
Скачал, посмотрел, некоторые вещи осваиваются интуитивно, это очень хорошо.
Вопрос такой. Есть объект, который постоянно должен "падать", ибо гравитация. Как это реализовать? Порылся в ивентах, не нашёл "пустого" события, которое должно выполняться всегда, без условий.
Ну или ткните в ссыль с такими вот базовыми туториалами.
А инди-песочницу гамак2 осилит? Пример - Stardew Valley.
В GMS2 (и в более ранних версиях роде тоже) есть встроенный туториал в духе "шаг за шагом делаем первую примитивную игру". Там делов на полчаса, и практически все базовые вещи научишься делать. Это гораздо лучше, чем видосы-туториалы, где бородатый хер два часа чавкает в микрофон, объясняя 2 строки кода смотреть.
Не могу этого сделать по ряду причин, но проблему я более-менее решил.
Я пришел к выводу, что переменная, которая получается из команды camera_get_view_x(view_camera[0]) все время отстает на один фрейм от настоящего положения камеры. Тогда я поставил условие, что бэкграунд двигается только при условии, что скорость персонажа не равна нулю. Это, конечно, как-то костыльно, и вылезла еще пара проблем, но их оказалось легко решить, и все работает. Наверное, есть какой-то более изящный путь, если найду, то поменяю систему, конечно.
Хочу запилить Монополию, но никак не могу придумать - как лучше реализовать улицы? Делать как отдельные объекты или как?
Вариантов куча. Первое, что приходит в голову - завести массив / словарь / список, и в процедуре генерации карты заводить в него нужные данные с тем же индексом, что у тайла в тайлмапе. Обращение к тайлам организовать через геттер, в котором эти данные будут доставаться.
Проблема в гамаке, в геймпаде или во мне?
Для поворота модельки я сделал вот:
var mouse_angle = point_direction(x, y, mouse_x, mouse_y);
if (mouse_angle > 310 || mouse_angle < 50)
image_angle = mouse_angle;
Как сделать подобное ограничение для пуль, которые вылетают. Пробовал часа три и нихуя не придумал, собсна. Вот мои самые удачные идеи (пикрилы)
Странные вещи говоришь.
Я лично я в гамаке совершенно не вижу игрового конструктора. Да, в нём можно включить физику "искаропки", заставить объекты перемещаться по путям и делать прочие примитивные вещи.
Но это только верхушка айсберга. На самом деле с гамаком можно сделать намного больше. Абсолютно всё, что может понадобиться для хорошей 2д игры.
Насколько юнити сложнее чем гамак, что лучше изучать: гамак или юнити?
>Годот, но зочем
Кубики в дырку кидать.
Вкратце вопрос звучит так - как сделать чтобы импортируемые спрайты не выглядели как дерьмо на фулскрине с 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 часов на нем что-то сносное склепать,если есть желание и идеи
Есть смысл париться, если в крупнопиксельной игре разрешение монитора не делится нацело на разрешение игры. Тогда появятся некрасивые деформации пикселей.
Эх, ну да, беспокоясь о бомжах на старых пеках, я и забыл, что уже есть челики с разрешениями больше 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, игра рестартуется. Я понимаю что наговнокодил, но как сделать иначе - хз.
Ты используешь какие-то безумные функции искаропки, не зная толком, как они работают.
Я тебя умоляю, не пользуйся алармами, ибо ты не знаешь, в какой момент тикает их таймер.
Это раз.
Два. Про платформы.
Хуй знает, что ты там наворотил но скорее всего проблема в очерёдности выполнения кода. Если ты хочешь, чтобы платформы двигали игрока, то пусть все перемещения платформ и двигание ими игрока происходят в 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
и то же самое с низом и верхом.
>Про алармы не совсем понял - я читал документацию и кажется понимаю.
Тогда скажи, в какой момент тикает таймер аларма? Что произойдёт раньше, room_end event или тик аларма? Или аларм тикает в начале фрейма а не в конце? Я вот, например, не в курсе. Если погуглить, то наверняка найду. Но в любом случае, таймер, который тикает вне твоего кода - это очень, очень плохо. Может привести к тяжёлым последствиям.
>Еще вопрос, чем плох vspeed hspeed?
То же самое. Когда происходит это перемещение? Твои платформы тоже перемещаются при помощи vspeed hspeed? Значит ты не контролируешь того момента, когда перемещается игрок, а когда платформа.
Допустим платформа создана раньше игрока. Тогда, возможно, сначала гамак будет двигать платформу, а потом игрока.
Тогда, если игрок стоит на платформе, которая едет вверх что будет?
Платформе же пофигу на коллизии с игроком? Она просто двинется вверх.
Потом начнёт своё движение игрок. А у него вертикальная скорость меньше, чем у платформы или нулевая. И он окажется внутри платформы.
Потом будет степ ивент. Если платформа создана раньше, и именно платформа перемещает игрока, то она его передвинет куда надо и игрок ничего не заметит.
А если игрок создан раньше? Тогда его код будет исполнен первым и он заметит коллизию и самоуничтожится.
Это раз.
Два: у тебя все скорости целочисленные? Наверняка нет. Тогда перемещение искаропки будет ставить твоего игрока в дробные координаты. И ты, для вычисления коллизий, будешь работать с float переменными. И это может привести к неожиданным для тебя результатам.
Приведу пример из моей практики - когда я делал лазерный прицел, который мог светить под произвольным углом и должен был прерываться на препятствиях, я заметил, что в некоторых редких случаях луч начинает светить сквозь препятствие. Разбирался долго пока не открыл для себя, что есть такая штука, как точность вычислений. И если сравнивать float который должен быть 0 с настоёщим int 0, то float 0 может оказаться больше или меньше, а может быть и равен. Поэтому иногда коллизия просто не засчитывалась.
Поэтому всегда лучше использовать для координат int.
Платформа и игрок движутся с одинаковым ускорением и одинаковой максимальной скоростью, но фактически у игрока ускорение чуть меньше и чем дольше движется платформа, тем больше отстаёт от неё игрок.
Проблема решилась переносом кода платформы в begin step event
С того, что во-первых это далеко не всегда пересечение прямоугольников. Гамак поддерживает precise per frame collisions.
А во-вторых объектов коллизий может быть много, а проверка коллизий может происходить много раз за фрейм.
Коллизии это то, что стоит держать в узде.
Моя движущаяся платформа это совершенно отдельный от коллизий объект.
Моя игра не плаформер и движущиеся платформы и препятствия не являются в ней основой геймплея. Поэтому я сделал принципиально другую механику.
Если в комнате есть плаформа, в скрипте 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 с лихуем лицензию для того, чтобы получиться возможность заработать на детище - бред.
Есть ли законные (или может даже не очень) выходы из этой ситуации
Давай начнем с того, что бизнеса как такового (именно в гамак-геййдеве) быть и не может без покупки лицензии (исключая обходные пути)
Я и не говорил о том, что вкладывать деньги в бизнес - это бред.
Порог вхождения уж очень велик для этой страны. Нет никакой гарантии, что твой проект хоть частично окупит вложения (а проверить как-либо это, без покупки лицензии не кажется реальным)
>>524468
>>Нужно брать бесплатные проги, если ты нищебродина
Вот тут ты и обосрался молодой человек. Твои слова как-раз таки и выдают в тебе нищука, который сразу потратит свои сбережения на иллюзорный вклад в будущее, который еще не факт что хоть как-то окупиться, и как я написал выше проверить это ты увы не сможешь.
Ты вопрос задай как следует, тогда и получишь нормальный ответ.
Если ты не ставишь тайл в клетку, то 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= 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;
}
}
}
Таким образом коробка самоуничтожается, если в ней уникальный предмет, который игрок уже подобрал.
пускает слюни
Простой пример - есть объект игрока, есть аптека. В скрипте отвечающим за смерть есть room_restart и после смерти игрока комната перезагружается но аптек нет. В гамаке так и задумано? Как это обойти? Записывать айди всех аптек в комнате и ресать их? Или например сделать видимость 0 после того как их взяли? Вернуться к ним у игрока в рамках комнаты возможности не будет.
Я, честно говоря, не пользовался никогда room_restart
В мануале написано, что работает так, как будто ты только что зашёл в комнату.
Т.е. должны создаваться все не persistent объекты по новой, выполняться все create events и room create events.
А сама комната не persistent?
Отрисовка в гамаке по умолчанию происходит на application_surface
https://docs.yoyogames.com/source/dadiospice/002_reference/surfaces/the%20application%20surface.html
Вот как я задаю камеру в своей игре:
Создаётся камера, определяются 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, нарисовав интерфейс в одном месте и выводя его на экран, сначала камеру, которая смотрит на интерфейс, а потом камеру. которая смотрит на уровень. Изменяя вторую камеру ты мог бы добиться того же самого.
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, то на переднем плане будет персонаж. А тут наоборот.
Пиздец, как они такое делают на гамаке?
Потому что у тебя, как и у большинства посетителей гдача, неправильное понимание движков: ты считаешь (и наверняка готов это отстаивать), что графон в игре обеспечивает движок. Но нет, графон обеспечивает разработчик, а движок обеспечивает среду для создания игор и более ничего.
Я как-то весной заикнулся об этом, так на меня целая толпа нубья слетелась, с пеной у рта доказывать мне, как я неправ.
Напомню, речь шла о том, что крупная студия при желании может сделать ААА-игру на любом из известных движков. Нубы усирались, доказывая, что нет, ты што, только на топовых движках, тычё!
И ещё.
Это твоё забуждение основано на тех образцах и примерах, что поставляются с движками. Есть ряд движков (не будем конкретизировать), которые поставляются с уёбищными и/или неоптимизированно-тормозящими демками. У людей, далёких от геймдева, складывается впечатление, что это предел возможностей движка. На самом деле демки - это предел творческих возможностей их создателей, не более.
слечусь пожалуй на тебя.
>графон в игре обеспечивает движок
в видеосике статичная модель с запеченными лайтмапами. там даже свет очень всрато поддерживатся, чего уж говорить о современных шейдерах.
можно усраться, но даже готику первую на нем не сделать — нет костной анимации.
>крупная студия при желании может сделать ААА-игру на любом из известных движков
нет, не на любом, а лишь на паре десятков. игрострой это не только качество, это еще и возможность правильно отрисовывать это качество. напомните, сурс энжайн уже научился в pbr?
>На самом деле демки - это предел творческих возможностей их создателей, не более.
в юнети нет SSS и индирект лайт скаттеринга. точнее есть, но фейковые и от васянов с сопутствующим пакетом всякой вич-инфекции. почему ты считаешь что топовые студии могут обходиться без этих новомодных приблуд?
>нет костной анимации
https://www.youtube.com/watch?v=C1SCb9ajsXM
>можно усраться, но даже готику первую на нем не сделать — нет костной анимации
https://www.youtube.com/watch?v=_IC1OnTrkpE
Первый день в гмс, как очистить нахуй вот эту хуйню, оставшуюся от передвижения персонажа? Олсо, ответьте, куда лучше подобную хуйню задавать: в gm тред или помощь ньюфагам? Так как я предполагаю, что ближайшие пару месяцев буду часто хуйню спрашивать.
Здесь пиши. Я всегда отвечаю на адекватные вопросы. В ньюфаготред почти не хочу.
Твой вопрос не особо адекватен - что за хуйню ты вообще сделал?
Ты рисуешь не на application surface? Тогда делай каждый шаг в begin_draw_event surface_clear_alpha своему сурфейсу.
Первый день в гм, анон. Я вообще нихуя не знаю.
>application surface
Не ебу, что это. Как понял - отрисовка на отдельном слое
Сделал новую комнату, создал несколько слоев. В одном слое - инстансы объектов, другой - тайлсет.
Белая хренота по центру - персонаж, управляемый пользователем, коллизии обрабатываются таким образом(пикрил 2)
Кроме этого события ничего не писал.
Проблема в том, что при передвижении остаются предыдущие полупрозрачные отрисовки персонажа.
Как я понял, я должен чистить буфер после каждой отрисовки, как ты говоришь. Вот только я не знаю, как это сделать.
Когда ты рисует по умолчанию - ты рисуешь на 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)
Во-первых опиши что ты хочешь и что у тебя есть. Со скриншотами и рисунками. Я тебе телепат, угадывать что там у тебя в голове?
Во-вторых хочешь чтобы партиклы вылетали из движущегося объекта - двигай эмиттер.
В step event изменяй параметры part_emitter_region
Хотел нечто подобное запилить, типа молнии при скольжении. Вчера как раз emitter_region подвигал и добился вот такого эффекта, но чет есть подозрение что я все равно не так это делаю лол
part_emitter_clear в степе чистит эмитер если объект не в нужном состоянии.
>
>https://marketplace.yoyogames.com/assets/4574/geon-fx-particle-editor
Ты не поверишь, но купил на недавней распродаже
Так то спасибо, хех.
> А почему моя поделка заработает только на суперкомпьютерах?
Потому что тебе нужно будет писать код не только как рубить деревья и перемещать персонажа, а с оглядкой на то, чтобы у тебя весь твой огромный мир работал одновременно и не засорял память лишними вычислениями.
Там пиздец какие баги.
Ананас, хочу вкатиться в 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, подскажите как
поставил объекту вертикальную скорость 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 форуме нет.
Посмотрел вот это:
https://www.youtube.com/watch?v=izNXbMdu348
Если до конца все было понятно, то с прыжка я охуел.
Почему vertical speed была выставлена на -7? Почему минус 7? Ось координат поменяла свои значения? Вроде вверх — это плюс.
Но что я точно не понимаю — это каким хуем вообще здесь работает прыжок. Почему спрайт прыгает вверх, замирает, а потом падает вниз? Чем это вообще обусловлено? Почему прыжок плавный? Судя по коду, после нажатия пробела спрайт должен телепортироваться на 7 пикселей вверх и вроде бы даже замереть в воздухе. Почему он, сука, падает?
Почему я такой тупой?
Потому что начало координат обычно считается от верхнего левого угла поля и ось Y направлена вниз.
Привыкнуть не легко.
После нажатия прыжка спрайт подпрыгивает вверх на 7 пикселей 60 раз в секунду (или 30 раз, смотря какой фреймрейт выставлен).
Плюс идёт работа гравитации, которая плавно обнуляет скорость прыжка а потом разворачивает её в другую сторону. Почему ты этого не заметил?
v=at
Это, вроде, пятый класс.
>Почему минус 7?
Очевидно, ось Y направлена вниз. В разных движках могут оси располагать как создателям вздумается.
>Почему спрайт прыгает вверх, замирает, а потом падает вниз?
Действует гравитация. Тело движется с ускорением. Смотри внимательнее.
>vsp = vsp + grv;
vsp сохраняет свое значение каждый кадр, и его немного изменяет grv.
Вот здесь:
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и и с достаточном количеством свободного времени. Так как бюджет есть, то будет скорее всего и зарплата. Короче всё обсудимо.
Понимаю что не лучшее место для такого поиска, но я пробую все варианты, если интересно пиши на фейко мэйл: serapis@yahoo.com
И потому ты зашёл на двач. Уж тут-то ты найдёшь адекватных сотрудников.
И стесняешься дать ссылку на запиленную игру мечты, да? Да ещё такой подробный рассказ о новом проекте, что прям заболели все вокруг и готовы н энтузиазме тебя поддерживать.
Сдаётся мне, ты очередной шизик.
У нас в последнее время просто наплыв директоров. Школа бизнес молодости где-то протекла?
> Нашёл с горем пополам инвестора
Чот кринжанул.
Инвесторы на 2д перделки сделанные на гамаке.
Так и представляю очередную группу присосавшихся к деньгам долбоебов, которые пол года нихуя не делают, проебыват деньги, а потом пишут о закрытии проекта.
А так оно каждый раз и бывает, когда вы свою инди поеботу начинаете делать с серьезными ебалами напялив свои засаленные колхозные пинжаки как в ностоящих фирмах!
Не помню ни единого завершенного проекта, который бы начинался так. А вся инди годнота вообще была сделана на коленке одним-двумя людьми, которые просто проверяли свои силы в игрострое.
>кринжанул
>О, одноклассники протекли :)
Ыыы, бля
Блэать, только что дошло что изначально запостил не в тот тред. Гамак или негамак не похер одходило бы только к игре.
>Не помню ни единого завершенного проекта, который бы начинался так
Stardust Valley, Armello, World of Goo, Minecraft...Нет не слышал про такое.
>Stardust Valley
Stardew Valley
Создан одним человеком, который и рисовал, и кодил, и писал музыку. Начал делать игру спонтанно, пытался лишь воссоздать более старую игру Harvest Moon, как проверку своих сил после обучения программированию.
> World of Goo
Создан двумя друзьями в свободное время от основной работы в EA.
> Minecraft
Создан одним человеком. Спонтанно, как попытка возродить более древнюю и уже дохлую на тот момент игру Infiniminer.
Я вижу у тебя познания на уровне.
Вопрос теоретического порядка. Есть игра на ведра https://www.youtube.com/watch?v=5G7Xb5gFa80
Как наиболее оптимально реализовать похожую механику поведения пловцов?
Рассчитывать шаг исходя из того что в игре все клетки одного размера и добавлять условия при встрече с бортами? Как вообще реализуют такого рода игры с хождением по клетке? вот еще пример ходьбы по клеткам https://youtu.be/ptYwMwxP7ho
А в чём вообще проблема заключается?
Сам-то подход пытался придумать?
Я бы сделал ds_grid, задающую координатную сетку.
В каждую ячейку поместил бы массив, описвающий её содержимое.
Тип клетки, соответсвующий спрайт, всякие дополнительные параметры типа "рассыпанные камни" или "в зоне действия водоворота". И естественно ссылки на объекты, которые в ней находятся.
Для всего этого дела создал бы контроллер, который бы в ds_queue собирал от объектов запросы на перемещение из одной клетки в другую.
Ввёл бы параметр отвечающий за "ход". За один ход один обхект может отправить столько запросов на перемещение, сколько клеток за ход он может пройти.
Затем в конце каждого хода выключал бы контроллер игрока, и двигал объекты в соответствии с ds queue, проигрывая анимацию движения.
Нужно сильно шо пиздец
У гамака есть огромная проблема. При мало-мальском усложнении проекта вся структура кода идет по пизде из-за того, что ГМЛ очень и очень слаб.
То есть вместо того, чтобы писать человеческие классы с нужными методами, ты постоянно плодишь скрипты, которые лежат хуй знает где и ты начинаешь охуевать от говнокода.
Плюс отсутствие нормальных человеческих структур данных вымораживает. 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
У тебя ещё гравитация работает? Направление vspeed учитываешь?
Скорее всего у тебя вот это (vspeed < 0 && !place_free(x,y-vspeed)) в правду превращается, когда vspeed обнуляется, а потом срабатывает гравитация. Хуй знает короче.
Запускаешь игру в режиме дебага, когда объект прилип к платформе табаешься в ide и ставишь брекпоинт в step event объекта. И шаг за шагом смотришь, что у тебя срабатывает.
Запостил какой-то кусок кода без коментов, без объяснений. Мы угадывать должны, как оно у тебя работает?
Безотносительно твоего вопроса - не рекомендовал бы использовать вот эту шнягу искаропки: move_contact, place_free и т.д. Особенно если пишешь платформер. Напиши свои функции, о работе которых ты будешь знать всё. А то тебя ждут весёлые провливания сквозь пол, застревания, прилипания. Вот это всё.
>На самом деле мне не принципиально, каким именно образом
Ну вот тебе 2d кубик на 4.
https://drive.google.com/open?id=1hwj8sHL90HCjP7OVacbJTZGzzKjBXuLp
Перекат в процессе, заодно хапнул заказик, чтобы училось лучше.
Юнька-таки гораздо удобнее конечно, если в ней разобраться. На гме у меня правда все делалось в 1.5 - 2 раза быстрее, но чем дальше в проект, тем больше пизда рулю в плане организации кода.
Человеческое ООП решает все-таки.
>>539990
>можно, например, вернуть только одну переменную
>можно вернуть массив (или дс лист) с нужным кол-вом переменных
А что с этим не так? Деды возвращали из функций всегда по одной переменной, и ты так делай. Чем отдельные скрипты принципиально отличаются в этом плане? Нужно много данных вернуть - заворачиваешь их в объект/структуру/массив/небо.
Причем после переходов через комнаты все становится норм.
В чем косяк? Сталкивался кто? ибо я упорно не понимаю чому слои не работают как надо
https://www.youtube.com/watch?v=f7KOOp80VJY
ебать охуенно
Вопрос №1: Можно ли на нём пилить RTS, 3d/2d масштабом в 25-50 юнитов на экране?
Вопрос №2: Можно ли на нём пилить (TBS), 3d/2d масштабом в 50-100 юнитов на экране?
Вопрос N3: Возможно ли на нём прописать аи противника?
я кончил.
Здесь:
Пасфайдинг.
Система классов: маг/вор/воин
Система квестов
Система принятия решений.
Система нанесения урона.
Сдлано за два вечера.
Моя геймдев-карьера: установил украденную версию 1.4, не смог запустить.
В том числе 1.4.9999.
По результатам гугла моя ошибка описана здесь, только у меня ХР:
https://gcup.ru/forum/36-29024-1
>Установочник запускается,установка успешно проходит,а вот сама прога не катит! sad
>Все просто и сложно одновременно. Была такая же проблема. В Appdata есть файлик trace там ошибка твоего запуска. У меня ругался на framework. Исправил версию в файле .config и все распаковалось. Поправил версию framework в распакованном studio и все заработало.
Но у меня папка проги в appdata пуста. Что написать в конфиге?
Раньше просто записывал все в переменную, но теперь когда делаю игру с охуеть каким колличеством текста понимаю что на локализации ебнусь даже с двумя языками. У меня всякие диалоги, реплики, прочая срань.
Понял, что зря у меня весь код в степ ивенте, наверно не так надо было начинать.
А вы настраиваете один ивент и в нем пишете все основное или делаете по скрипту на фичу? Есть рекомендации как лучше их организовать?
Есть ли какие обходные пути, или, например, пиратские версии.
Ясен хуй, на стим/прочее не выложишь с взломанной версии, но в любом случае, есть ли какие обходные пути.
Или возможно ли без последствий, сделать проект на взломанной версии, а потом, когда уже готовый проект пихнуть в купленную версию? Возникают ли какие-нибудь несоответствия или артефакты/ошибки?
Тоже запарился, но у меня не с анимации, а движение на 360. Есть два объекта - снаряд и препятствие. При расчете столкновения по х, у снаряда его маска вообще игнорируется, хоть так >>499296 хоть точно по спрайту, а происходит столкновение центра снаряда с границей препятствия. Хотя все настройки у обоих объектов одинаковые.
>place_meeting
Спасибо за подсказку, маска заработала. Я использовал collision_point ставя prec=true, почему-то в этом случае он все равно считает маску центральной точкой.
Пока это увидел, перебрал имитации маски через collision_circle и collision_rectangle. Решил, что в этом случае столкновения вообще лишние, сделаю снаряду превентивный круиз-контроль.
Хули оно такое неточное?
Даже у васянов с ютуба при расчетах всегда неточные числа получаются, а они на это реагируют мол: "Да неточно и хуй с ним чо)) результат на пару десятых отличается каждый раз, да и пох)))) лойс подписка))"
При длинных расчетах вообще же вся физика по пизде идет.
Должен же быть какой-то метод чтобы игра не была фиксированная на 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);
То, что нужно. Бля, пол дня голову ломал, пока буквами не написал.
Вставь между ними ещё один родительский объект.
Функция будет находить объекты ниже по иерархии данные ей.
Например у меня есть родитель 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)];
Делал себе игру, но буквально на неделю где-то пришлось сделать перерыв. Все работало нормально.
А сейчас открыл Гейм Мейкер, он обновился, я запустил Run и происходит какой-то пиздец: половина слоев не рендерится, половина мелькает и моргает, и полная жопа. Я ничего не изменял в коде. Почему такое могло произойти?
Поясню за суть.
Моим дипломным проектом является игра. пишу аркадку на с++ в UE4, и до меня доебался куратор по димпломке с вопросом, А зачем А нахуя твоя игра и дипломка?
Лично я делаю для опыта и интереса, она хочет чтобы я раскрыл сокральный смысл моей работы, чтобы она спасла детей в африке, но я не ебу как это описать для чего работа
Был научным руководителем у выпускника, мы с ним на юнити сделали игру ака вотч догс 2д про мамкиного хакера, взламывающего здание.
Приплели как анализ инф. безопасности систем. Когда игрока ловили охранники итд итп показывалась статья с описанием. По мере прохождения ГГ говорил о том, почему текущая организация плохо защищена.
Студент учился по этой специальности, сдал на 4(хотя мог изи на 5 сдать,он сам начал запинаться во время выступления).
Как вариант советую тебе взять какой-то процесс из жизни по твоей специальности и воспроизвести его с использованием твоего же УЕ4. А аркада абсолютно не связанная с твоей специальностью да, нахуй не вперлась никому. Пожумай сам своей головой,в комиссии будут сидеть 40+ дяди и тети, которым твои игрушки не интересны, им интересно, чтобы ты с умными щами заливал про важность предварительного анализа и моделирования hueta.Name , и именно твоя убогая программа позволяет это сделать.
Если будут еще вопросы, пиши.
Да не переживай, это не только в рашке.
Во всяких стэнфордах и берклях та же самая хуета с ещё большим попилом грантов.
https://www.youtube.com/watch?v=LVsqIjAeeXw
Вспомнил, когда учился в институте, нам физик сказал - напишите программу, которая моделировала бы наглядно какое-нибудь явление, поставлю зачёт. Я (как удивительно) - угорал по играм, написал на паскале простенькую программку, которая рисовала луч, отражающийся и преломляющийся от поверхности. Нарисовал (в пиксельном редакторе) транспортир, красивую поверхность, сделал управление кнопками, чтобы углом полосочки-луча управлять и по кнопке чтобы транспортир это вылетал и прикладывался к лучу, лол.
Получил зачёт автоматом.
По крайней мере если ты хочешь делать игры - там ты идешь тупо в институт, который, блять, охуеть!, учит делать игры, а не дрочишь 4-5 лет бесполезную хуету, чтобы иметь возможность как-то уцепиться по одной из профильных тематик и сделать игру как диплом, и то не факт что проканает, а без диплома тебя развернут.
Я второкурсникам когда преподавал структуры данных, сказал им самим выбирать тему курсовой, подготовил около 10 тем по играм от крестиков ноликов до тетрисов(они на тот момент по программе только консольные писали).
Почти все принесли игры и им понравилось, месяца полтора я их консультировал, каждому помог составить план разработки. Ну, как план, помог каждому разбить на этапы и каждую неделю приносить и показывать результат.
Они были очень благодарны, хэх.
А потом я дропнул преподавание, когда меня хотели заставить снова читать хуйню по информационной безопасности, в которой я не работаю. Ибо нахуй плодить необразованность.
Опять прилетаешь РАШКУ? В Казани например на базе КФУ (в одном из его зданий) есть факультет, в котором учат твоему любимому гейдеву, на вторых курсах или позже начинается целенаправленное изучение сисярпа с Юнити. В Штатах тоже не на каждом углу учат игры делать, но да, факультетов там немного больше.
Понапаступают в сельские шараги, а потом удивляются.
Да и например PyGame в школах с 11 класса по профильной программе изучают, в Яндекс Лицеях с 8-9 классах могут.
Прочитал весь этот тред, и хочу сказать, что тут сидит один из самых адекватных и помогательных анонов на этой борде.
Если ты ещё сюда заходишь - добра тебе и удачи (если не заходишь - то всё равно удачи и добра). Смотрел, скольким ты тут помог и диву давался. Респект и уважуха.
просто-решил-высказать-своё-очень-важное-мнение-кун
Вот реально хотел бы выслушать плюсы и минусы, что выбрать вкатывающемуся в 2д-игростроение.
С гамака все уходят, он бесперспективный, не развивается, содержит фатальные дизайнерские ошибки, которые не дадут тебе сделать сколь-нибудь крупную игру.
Из годота может что-то хорошее и выйдет. А может и нет.
А юнити уже сейчас готовый продукт, стабильный, популярный и продолжающий активно развиваться.
ну там же наверняка нет окошечек, где прописан код отдельно на create, отдельно на step, отдельно на collision и т.д.
наверняка на юнити нет комнаты, куда можно мышкой перетаскивать объекты
наверняка на юнити нельзя делать анимированные спрайты прямо во вкладке sprites
>не иметь 64битную винду
>не пиратить
Так вот, как со всем этим сейчас дела обстоят? Правильно понимаю что уже имеются компиляторы под пс4,хуящ,свитч? Как с пиратством?
В принципе восьмёрка еще пашет, но, бля, это всё же говно мамонта и пора обновиться.
Нашёл только такую, не ебу какие компиляторы работают.
https://thepiratebay.org/torrent/23041242/Game_Maker_Studio_2.1.4.285
>>583024
актуальный кряк практически всегда можно найти тут в обсуждении(на нынешнюю кста там тоже есть),сам пользовался пока не купил (ведройд аштимель и шиндовс робочие проверял сам)
https://gmsc-97507.firebaseapp.com/
А то у меня вопрос появился по организации данных в коде. Делаю игру нелинейную, в которой есть несколько персонажей и линейный прогресс его истории. Проходить истории каждого можно в любой момент.
Так вот, вопрос заключается в следующем:
Для каждой комнаты должен иметься список персонажей и их параметров (координаты, текущий спрайт и прочее подобное), триггеров катсцен и всего того, что может появляться и удаляться через прогресс истории.
Как и где их лучше хранить? Я предполагаю пока, что для этого хорошо подойдет json. Если через json делать, то для этого нужно использовать ds_map()? Как быстро гамак работает с ним вообще? Есть ли способы быстрее/оптимальнее?
>Годотошизика >>588572 шли на хуй.
Там юнитишизик ващет.
А этот ваш гамак может похвастаться опенсорсностью?
мимо-гододик-шизик-годаун
Хммм, ну вот смотри, меня интересуют платформы: десктоп, мобилы, хтмл5 - на годоте я смогу создавать свои поделия бесплатно. Чтобы аналогичное сделать на гамаке, мне потребуется 99+149+199 = 400 баксов.
Итак, что такого крутого мне сможет предложить гамак, чего у меня нет в годоте?
Бля, ну вот серьёзно. Ну хватит уже эти движкосрачи. Лучший движок тот, который лично ты лучше знаешь.
Если анон не знает ни одного - для него лучше будет тот, что проще изучить.
А с учётом того, что ему нужно 2D - стрелка указывает на два варианта: Construct2 или GameMaker.
>я смогу создавать свои поделия бесплатно
Не бесплатно. Ты не учитываешь своё время. Если ты вложил полгода (1000 часов примерно), то ты потратил минимум 1000*10=10000 долларов. 400 долларов - это 0,4 от всей суммы затрат. Или 40 часов.
Насколько дольше ты будешь разбираться в годоте/юнити/дельфи/уече и насколько быстрее(медленнее) ты тоже самое сделаешь в гамаке? Ответь на эти вопросы и ты поймёшь, что дешевле - годот или гамак.
Но это, опять же, будут твоя личная стоимость.
>игры по ссылкам не игры
Тетрис и марио можно и без движков запилить и бегать верещать - ВОТ ИГРЫ ВООООТ, ДВИЖКИ НЕ НУЖНЫЫЫ!
Нужно уже отдельный термин вводить "годотовская игра" как символ кала, высранного школьником на какай-нибудь конкурс школьников - высри хуйню за 48 часов!
>опенсорсность бесплатнасть
Это значит, что один аргентинский велосипедист, лежа на пляже в перерывах между написанием чиптюновой музычки и поревом жены будет делать фичи к движку очень долго с огромным количеством багов, не доводя ни одну до конца. Донатят им 10500 долларов в месяц на двоих.
>годот полное говно, вот четкие неопровержимые аргументы...
>а вот ты, а ты сам!...
>А зачем мне 3д?
За тем, что все долбоебы думают - 3д сложна, сделаю 2д говно на мобилки! - И теперь на мобилках такой поток хуйни, что никак не пробиться. Следующий этап осознания - на мобилках ловить нечего, сделаю 2д хуйню для стимы... Но там тоже самое...
В итоге придешь к тому, что 3д делать сложно, но конкуренция меньше и деваться некуда.
Пробовал через lenghtdir_x/y но безуспешно
>>589562
https://www.youtube.com/watch?v=NDH_UoQBToI#t=5m
нужно вот такое вращение
Спасибо анончик.
Все оказалось намного проще. Нужно было просто растянуть сурфейс.
как то пиздец проблематично это все было гуглить. с таким трудном нашел то, что нужно
Интерфейс слили в абсолютное говнище. Вместо нормальных вкладок или окошек, как в прошлой версии, какие-то обоссаные сплайны с воркспейсами. Сами элементы интерфейса увеличились раза в полтора, так что реального полезного пространства стало гораздо меньше чем было.
Сам же гмл порос каким-то говном -- добавили слои, которые на самом деле обёртка глубины (которую убрали, удачи теперь с 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
На твою маму.
А чего жоскаво-то? Все современные движки сделаны по одному шаблону: майнлуп с колбеками и сиподобный синтаксис скрипта.
Тебе один раз нужно сделать образец для переноса игор с движка А на движок Б, в котором будут имитированы нюансы движка А с реализацией на движке Б. Например, встроенные функции-хелперы. В движке А допустим есть функция 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); }
И далее исходный код пихаешь без изменений. Ну это самый простой случай. На деле инди разрабы могут дичайшую дичь издателям приносить.
Процедурную генерацию на потом отложил, я ее за час сделаю (не выёбуюсь, опыт есть и ворлд генерации и данжей), сейчас 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 или больше ячеек инвентаря быстрее работают в объектах, чем в фейковых структурах)
Но быстрее они будут работать только если не будут каждый шаг обновлять свою позицию по центру, а только при открытии например.
Есть кейсы когда важно оптимизировать, а иногда нафиг не нужно.