Всё ещё учусь работать в Game Maker (GMS 1.4.9), параллельно участвуя в конкурсе на GCup.
1)Немного неприятно, то что разрешение экрана и FPS нужно менять в каждом уровне отдельно,
по логике это должно выноситься в опции и быть общим для всех уровней.
2)Также немного прокачал рисование персонажа для кастомизации, хотя возможно это всё будет лагать при 60 FPS на слабом ПК, я не уверен:
- 18 июня 2020, 17:21
- 04
Понял чем ещё плохи переменные автоскорости: hspeed/vspeed
Их не только сложно на паузу поставить, но также и если я захочу добавить замедление времени,
то лучше избавляться от таких автопеременных и делать переменные вручную, типа:
x += SpeedX*timeSpeed;y += SpeedY*timeSpeed;Да, только так и нужно делать замедление времени. Таких изи-штук как в юнити в гамаке увы нет. В юньке это одной переменной делается, в.т.ч. и пауза.
Да в принципе, нормальный способ. Просто решил полностью отказаться от использования в GMS переменными hspeed и vspeed, ибо чтобы ими управлять нужны всё равно дополнительные переменные, когда можно сразу
сделать 2 дополнительные переменные типа SpeedX и SpeedY и вручную скорость делать)
Вообще иногда эти переменные полезны. Когда нет слоумо, например. То вся кинематика уже заложена в speed,vspeed,hspeed,direction,friction,gravity,gravity_direction. И функционал типа motion_add. Всё это бывает полезно на понятных кинематических задачах. В платформерах и аркадах этого бывает хватает за глаза.
Не вижу причин не использовать vspeed и hspeed как тупо переменные в самописной физике как у тебя, при условии, что после обсчета координат добавлять строку speed = 0, чтобы скорость не меняла координаты повторно. Плюс в том, что у тебя остается доступ к актуальной speed и direction.
Я немного не понимаю как работает hspeed/vspeed и speed. Если
speed=0сделать и если при этом hspeed не поменяется, то это было бы решение с паузой, надо потестить взаимозависимы ли эти переменные или нет, и как они вообще друг на друга влияют.Каждый раз как ты меняешь hspeed ИЛИ vspeed, меняются также speed И direction. Верно и наоборот - меняешь speed ИЛИ direction, меняются hspeed И vspeed. Но я же уже тебе говорил - не юзай эти перееменные совсем, а для перевода расстояния в его компоненты по осям используй lengthdir_x / y.
Щас вы его научите - не юзай hspeed, не юзай self.
Переменные speed и direction, в совокупности, являются направленным вектором движения. Соответственно hspeed и vspeed - это горизонтальный и вертикальный компоненты этого вектора. Когда ты меняешь что-то одно, меняется и все остальное. Ты можешь нарисовать вектор на бумаге, а потом посмотреть как он изменится, если изменить, скажем, горизонтальный компонент вектора. Меняется и длинна вектора (скорость) и его направление.
Ты можешь использовать все, что пожелаешь. Все это удобные инструменты предоставленные нам разработчиками из Yoyo. Помогают ли они решать технические задачи или просто делать код более читабельным, не стоит ими пренебрегать.
Ты прав. Просто Алексу хоть убей в текущем проекте нужно сделать такую паузу, чтоб скорости где-то хранились, но при этом не использовались движком автоматически. И ладно бы просто деактивацию инстансов делать - нет, ему надо чтоб они ещё и рисовались на паузе! И решение со скриншотом, успешное применяемое, например, в Aborigenus и в Pixel Gladiator, почему-то смущает тоже.
Это у него такой авторский уникальный случай, нехарактерный для большинства игр которые прекрасно делаются на ГМе.
Не иначе как делает убийцу Pause Ahead
То вы - лох. Смотрите видеопрохождение:
...займитесь некромантией и воскресите у себя флэш.
Мне интересно, а почему надо делать скриншот уровня чтобы поставить игру на паузу?
Нельзя ли просто deltatime сделать 0 чтобы все объекты перестали обновляться?
В GMS-е нет deltaTime. Есть room_speed, но... В общем вряд ли у тебя что-то с этим получится. Можешь поизучать вопрос если хочешь.
Есть ещё всякие хитрые штуки. В GMS1 точно есть. Есть keyboard wait или что-то типа такого. И можно в step сделать цикл - тогда игра подвисает до тех пор пока не нажмёшь кнопку.
А почему ты хочешь сделать паузу именно так? Это какой-то элемент геймплея или просто твой дизайнерский изыск?
P.S. В юнити это вроде не delta_time, а что-то типа timeScale.
keyboard_wait() туфта, он obsolete ещё в GMS1 и не подходит для геймпадов. Больше никаких хитрых штук нет.
Прикольно что вы отсутствие какой-то элементарной паузы в этом вашем гакаме объясняете "зачем тебе это надо?".
Мне нужна нормальная пауза.
В love2d это делается элементарно. Как это сделать в ваша гамаке без костылей?
Переводишь комнату в состояние persistent, переходишь в другую комнату с паузой. Можешь с application_surface предварительно спрайт создать и подложить в новой комнате в качестве фона.
Ещё можно через instance_deactivate_all и instance_activate_all.
Не понимаю почему это сразу костыль. В гамаке есть функции которых нет в юнити, в юнити есть функции, которых нет в гамаке. Это вообще нормально.
Если тебе ТАКАЯ пауза прям critical feature - так делай на love2d, в чём проблема?
Ты же сам движок подбираешь под свои задачи =)
P.S. Чисто технически это как раз костыль в юнити, потому что там у тебя события объектов отрабатывают с нулевым delta_time, а в гамаке ты можешь сделать паузу легковесной, т.к. деактивированные объекты и объекты в другой комнате в рассчётах не участвуют.
Так там нет редактора уровней.
Вы с Кситилоном постоянно утверждаете что гамак лучше юнити и love2d, и что это вообще чудо чудное - я вижу что не совсем.
Твой вариант с комнатой - тоже костыль, эмуляция паузы. А вся проблема в том что для разработчика вся игра на гамаке вертится вокруг объектов. Хочешь паузу - создавай объект в комнате. Хочешь меню - создавай объект в комнате. В то время как ни то ни другое - объектом уровня не является. В гамаке нет глобальной сущности, управляющей всей игрой разом, все делается только через объекты.
Какие? Гамак - конструктор, юнити - движок, априори во втором возможностей будет больше.
Бред несёшь. Почему ты считаешь что истинная пауза - это только timeScale в ноль убрать? Только потому что так сделано в юнити и лёве?
ЛОЛ, при том что все объекты в юнити - это тоже объекты, отнаследованные от MonoBehaviour, насколько я помню =) И вроде ты не можешь написать скрипт просто так в вакууме, его нужно к объекту приаттачить.
Нужна управляющая сущность - создай. Я всегда создаю o_resources_controller с галкой persistent для этих целей. Это чисто практика программирования, а не отсутствие возможностей.
Начнём с того что Гамак слабо типизирован и ты можешь всякие штуки с переменными делать. А самое главное - не протаскивать весь каскад встроенной иерархии объектов чтобы сделать элементарные вещи. Когда в юнити был JS то можно было, а в шарпах нельзя, увы.
Названия ресурсов в юнити нельзя использовать напрямую (раньше так было по крайней мере), передавай в скрипт как аргумент. Настаёт момент когда это начинает заёбывать.
Прописывание событий - редактирования довольно длинной портянки с кучей синтаксического мусора. В то время как в GMS - это наглядный список событий. Скрипты хранятся отдельно от объектов. Типа на случай переиспользования, ага, что реально на практике всего в 1 объекте из 100 пригодится. А искать каждый раз какой скрипт к каким объектам подвязан тот ещё гемор.
Работа с глобалами в юнити мне не понравилась. Это нужно писать скрипт со статическими переменными, который потом непонятно к какому объекту прикреплять. Или как советуют - создавать синглотон. И это ты мне рассказываешь потом что дескать в ГМ всё крутится вокруг объектов. Ха-ха. В GM в любом месте globalvar сделал и потом обращаешься к ней из любого места без неймспейсов и прочего.
Редактор сцены. ууууу. Если сравнивать в плане 2Д игр, то в GM есть крутая фишка со слоями, а в юнити лишь иерарахия в которой навалено всё в кучу без элементарной группировки. Ах да, там можно создать пустой объект и внутрь него поместить что нужно. Но это же ни разу не костыль, "потомуштаюнити", видимо XD
Про Pixel perfect много было сказано. Его в юнити попросту нет. Или он достигается лютыми костылями.
Как выяснилось, в гамаке не нужна сортировка спрайтов для адекватной орисовки, там всё автоматом сортируется как нужно.
Я могу довольно долго продолжать список того что мне не нравится в юнити. Так же как и список того что мне в юнити нравится. Но т.к. я делаю 2Д игры то выбираю GMS, т.к. именно 2Д игры делать в нём проще, быстрее и практически без костылей.
Потому что только в этом случае игра полностью останавливается.
Можешь. Статические функции. Только его код тоже придется из другого объекта вызывать, как в гамаке со скриптами.
Вот! Чтобы тебе не требовалось сделать - надо создать объект внутри какой-нибудь комнаты.
А потом таскать его все время с собой.
LUA тоже слабо типизирован.
В Юнити есть яваскрипт, во всяком случае был.
И где-то читал что его поддержку никуда не убрали, а только удалили возможность создать JS-файл.
Во всяком случае с Boo - точно.
Никуда прикреплять не надо, создаешь статический класс и в нем - обьявляешь публичные статические переменные.
И по мне это лучше - все глобальные переменные в одном файле, а не разбросаны по объектам.
И чем тебе это не группировка? Тем что используется иерархия объектов, которой нет в GM? Если бы была, то уверен, так же сделали как в Юнити.
Ну нет же. Нет гарантий что где-то нет кода, на который timeScale не действует. В случае со скриншотом у тебя эти гарантии есть.
Тогда в чём отличие? Если тебе всё равно где-то в какой-то левой сущности нужно его вызвать. И объект этот поди ещё должен быть на сцене чтобы это запустилось? В чём отличие от:
Тоже не верно. Ассеты и тайлы я могу располагать в комнате без объектов. А так то мы живём в мире ООП и мыслим объектами, не вижу проблемы в выделении объекта на конкретную функциональность. В любом движке сделано именно так.
ЛОЛ, ты сам себя слышишь? В юнити есть яваскрипт, вы только не можете скрипты на нём создавать и код писать, а так он есть XD
То же самое можешь сделать и в гамаке. Создать persistent объект и в нём переменные и обращаться через его имя. При том что в Юнити нельзя сделать как а гамаке - объявить глобал в любом месте и обращаться в нему напрямую. Мы же говорим о том что ЧТО МОЖНО СДЕЛАТЬ В ГАМАКЕ ЧЕГО НЕЛЬЗЯ НА ЮНЬКЕ =)
А дальше уже твоя самоорганизация кода. Мне удобно различать глобалы по капсу, а не по наличию приставки global или названию класса. Код чище и читается легче.
Группировка со своими плюсами и минусами. Только вот слоёв в юнити нет, а в гамаке есть. У тебя был конкретный вопрос
У меня конкретный ответ. Вопрос закрыт? Нашли то что может делать гамак чего не может юнити?
Слои отстой*, depth был лучше. Его ещё не выпилили, но всё к этому идёт.
* не пригождались в моих проектах никогда
К слову, не помню в какой игре (на love2d, не на гамаке конечно), делал 2 иерархии для объектов.
Одну - для обновлений (от корня к ветвям), вторую - для отрисовки (просто списки 1, 2, 3).
Это можно сделать и в ГМе тоже, просто чем обосновать это решение?
А причем тут гамак, я же сказал "к слову".
Понадобилось сделать так чтобы один объект мог двигаться вместе с другим и при этом могли отрисоываться в нужном порядке.
Ты упускаешь уточнение - "для двухмерных игр". Повторюсь, что тот тип паузы и таймскейла на который ты и Алекс почему-то рассчитываете, разбалованные Юнитями, не характерен для двухмерных игр вообще. Подавляющее большинство двухмерных игр делаются проще в Гамаке чем в Юнити, это попросту факт.
Потому что в ГМе есть драг-н-дроп, а в Юнити нет? Тогда смотри, в Анриале есть блюпринты - это тоже конструктор по-твоему? А как тогда?
И да, нет ни в жизни, ни в софте, никаких "бОльших возможностей", возможности есть только "разные".
Блин, я об этом даже не подумал. То есть это уже где-то четвёртый способ сделать то что нужно.
Не какой-то элементарной, а конкретного изощрённого подвида паузы трёхмерных игр, которого нет практически ни в одной двухмерной игре (мы ведь о них говорим?) - пауза, в которой остаётся прорисовка кадра, да ещё и пассивные анимации. Обычная пауза это ты вышел в главное меню и ничего в игре не видишь, такую паузу в нём делали ещё в те времена когда не было никакого Юнити, Лава и вот этого всего новомодного.
Нельзя ли просто сказать: "Горшочек, не вари!"?
Алекс сейчас занят именно деланием своего дельта-тайма, хотя возможность паузы именно с сохранением отображения всего на экране, да ещё и с анимациями - это далеко не кор-геймплей, да и вообще не геймплей игры. Любить игру будут не за анимированную паузу, и не за наличие оконного режима.
Сим-салабим, делайся игра сама без человеческого вмешательства! Хачу убийцу фортнайта!
И кнопочка такая "Сделать всё заебись"
Чувак хочет сделать анимированную паузу. Нафига вы его отговариваете?
Либо помогите ему это сделать, либо прямо скажите что в гамаке это невозможно.
Да я уже и забил, раз в GMS это сложно.
Можно и не анимированную, просто для меня непривычно подставлять скриншот во время паузы,
никогда так раньше не делал в других движках и за всю мою практику геймдева в: BlitzMax, Blitz 3d, Unity, Stencyl, Construct, MMF, Tic-80, Pico-8. Но попробую разобраться со скриншотом)
Если чо, в love2d это делается элементарно:
В этом примере как раз отключается обновление всей игры, кроме того фрагмента, который тебе нужен, а объекты при этом продолжают отрисовываться.
Покажи ещё, как делается "элементарно" весь остальной функционал GMS, за который его и любят.
То есть вам нечего ответить?
Сказали бы - "да, увы, пауза в гамаке делается через жопу, ничего не поделаешь".
Что мешает в гамаке отдельной функцией или переменной остановить все step? Или сделать room_speed = 0, почему нельзя?
А потому что это конструктор, а не движок и там можно только то что разработчик конструктора реализовал. Не реализовал - значит пиши плагин, ковыряйся сам в кишочках конструктора без исходных кодов или просто смирись с этим.
Насколько я понимаю, только теми методами, которые выше описали, "через жопу". Более знакомые с GMS люди, надеюсь, ответят тоже.
Но это не приговор для GMS, я вот что имел ввиду комментарием выше. То что в love2d есть дельтатайм не делает его суперудобным движком.
В love2d можно не вызывать update и ввод когда надо, и целиком, и выборочно.
Что мешает автору гамака сделать такую простую вещь как пауза? Или, хотя бы разрешить room_speed = 0?
Только то что игроделы научились делать это сами через костыли?
Допустим, есть анимированная пауза.
Вот есть эффект взрыва, который сделан не частицами, а анимированным спрайтом. Как правило, такой объект должен удаляться после завершения анимации. Что будет во время паузы? анимация взрыва отыграется и объект удалится? Или она зациклится?
Если она отыграется - значит это не честная пауза! Если она зациклится - это будет выглядеть как баг. Если фризить анимацию для врзывов - это менеджить твой геймлуп как раз и, во-первых выглядит как РЕАЛЬНЫЙ костыль(обработка одного кейза из множества), во-вторых часть спрайтов анимированных вовремя паузы, а часть - нет - это выглядит хуёвенько, нет единообразия в решении.
Как ты решишь эту задачу?
Во время паузы все анимации остановятся, время будет обновляться только для объектов, для которых не вызывается update.
А как ты тогда сделаешь анимированную паузу на гамаке чтобы при этом все остальные спрайты рисовались, но перестали обновляться?
Опа-па. Что за костыли пошли? Теперь тебе нужно менеджить объекты на те для которых вызывается update и для тех у которых не вызывается. Это ты называешь "простой метод"?
Если во время паузы все анимации остановятся, то всё-таки не нужна пауза с анимациями объектов? Тогда чем плох метод со скриншотом?
Я бы сделал скриншот, деактивировал бы всё кроме объекта паузы и рисовал бы скриншот а поверх него UI.
А если бы мне вдруг зачем-то понадобилось сделать как в юнити с timeScale, то я бы делал так:
0) Заведу глобал TIMESCALE
1) Сделаю объект o_timescalable
2) Заведу в нём Variables в духе t_speed, t_direction и т.д. Так же потребуется заменить массив t_alarm, причём на сколько угодно таймеров.
3) В End Step добавлю их обработку с учётом TIMESCALE
4) Всё то что должно зависеть от TIMESCALE я унаследую от моего o_timescalable и дальше буду работать как обычно но для кинематики буду использовать свои переменные.
5) Объект паузы будет делать TIMESCALE=0
Наверное то что пауза с видимыми анимациями никак не влияет на продажи игр, когда уже есть обычная пауза всех устраивающая? Назовите игру где именно такая пауза. Ты думаешь разрабы Гамака просто сидят на печи и делают что попало? Нет бизнес-обоснования для этой блажи, без которой обошлись и UnderTale, и Katana Zero, и ещё тысячи других игр на Гамаке.
Ксит, у меня наверное самая главная претензия, если есть автоскорость hspeed/vspeed, то почему нет паузы этой скорости, например для физики они сделали паузу, но для этой функции нет,
это немного странно:
physics_pause_enable(flag)Но в остальном, если не будет автоскорости, то и не будет проблемы, сделал давно вручную метод управления, хотя через небольшой костыль)
Костыль в последних двух строках) я запускаю пулю как будто работаю с hspeed/vspeed,
чтобы было легче угол направления делать, а потом забираю сразу всю скорость у этих переменных, переводя на ручное управление, потом может подумаю, как сделать вручную расчёт угла скорости, чтобы вообще не юзать hspeed/vspeed/speed/direction
Хотя возможно из-за того что я только начал изучать GMS и устал, тут некоторые строки реально лишние, потом на свежую голову попробую переписать код.
Может потому что эта фича непопулярна? Йойо делают в Гамаке то, о чём 1) долго и 2) много людей просят. И не надо думать что в Юнити поступают как-то иначе, просто там другие люди с другими хотелками (ну и в 100 раз больше сотрудников, соответственно они могут делать в 100 раз больше хотелок но вместо большинства из них продолжают делать кватернионы вместо матриц и скриптаблобджекты вместо простых скриптов).
Установка всех скоростей в 0 одной командой тебя не спасла бы, потому что помимо неё тебе нужно чтобы и Step перестал выполняться, но что самое главное - тебе нужно чтобы отрисовывательная часть Draw-событий продолжила выполняться, а не-отрисовывательная прекратила! Ведь в Draw можно вписать любой код, в том числе меняющий переменные обычно находящиеся в степе. Что тогда - искусственно запрещать писать в Draw всё кроме рисования, или фильтровать это при установке флага "фсемстаять"? Любой из вариантов уже совсем не так просто реализовывается, как тебе сейчас взять и сделать:
Об этом говорилось раз, два, и говорю третий:
http://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/maths/number%20functions/lengthdir_x.html
http://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/maths/number%20functions/lengthdir_y.html
Ну и обратно:
http://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/maths/vector%20functions/point_direction.html
http://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/maths/vector%20functions/point_distance.html
Спасибо! Я хотел погуглить, что за lengthdir такой,. Да забыл)
Я не понимаю твоей агрессии по данному вопросу. Будешь так орать - отправишься в мой личный игнор.
Как ты привык сделать нельзя. Но это не значит что "через жопу".
Через жопу - это когда нет никаких мануалов и практик и ты сам сидишь и выдумываешь решение проблемы. Или когда тебе говорят что вообще нельзя сделать так как ты привык. В данном случае можно и не так сложно как кажется. Просто этого никто не делает потому что есть возможность снять скриншот и поставить его фоном. В юнити и лёве можно так сделать одной строчкой кода? КЭП подсказывет, что нельзя. Потому что юнити вообще не умеет с полпинка текстуры на лету генерировать, например. Через жопу сделано?
Так-то можно до чего угодно доебаться.
или
Гамак любят не за супер-универсальный функционал, а за удобство разработки. Заложенного функционала хватает для разработки 2Д игр за глаза.
Но ведь ты ввёл в игру новую переменную. А Алекс уже три дня назад писал что он с этой целью (как твой is_pause) использует
if (global.Menu != noone). Кто тебе сказал что это "элементарно" в реальном полновесном проекте? У тебя просто код из двух с половиной спичек, естественно его легко поддерживать - это не игра, в нём ничего нет. Да это даже не ООП, это процедурное программирование где ты предполагаешь отрисовывать всю игру из контекста рендера, а не предоставлять каждому объекту свой Draw Event. Это разве удобно?За последние дни перечислено 4 (ЧЕТЫРЕ) способа это сделать, ты читал хоть на что отвечаешь?
Короче, я так понял что есть 2 варианта сделать паузу:
1) Заводить глобальную переменную и во всех событиях объектов делать exit если эта переменная равна 0.
Во-первых, мне влом перебирать все события у всех объектов и вставлять туда одинаковую строчку. А во-вторых, даже после этого один объект, который движется по path все равно продолжает двигаться.
Получается что такой вариант работает только если все перемещения объектов управляются из скриптов.
2) Отключать/включать все объекты при нажатии кнопки.
Но, блядь, они перестают рисоваться! Почему нельзя просто отключить обновление всех объектов?
Поэтому, видимо, и надо делать скриншот.
Еще есть room_speed, управляющий скоростью обновления комнаты, как раз то что надо, но движок выдает ошибку когда присваиваешь ей 0.
Да уж, в гамакере не смогли реализовать нормальную паузу, оба варианты работают через жопу.
А дело-то, всего-лишь перестать обновлять все объекты.
На дворе 2020 год, почему до сих пор нет нормального 2D-движка, а есть только конструктор с кучей ограничений и фреймворки, где надо все делать руками?
тот же вопрос, я думал это легко реализовать
Я примерно так паузу делаю:
Почти то же самое но без перехода в другую комнату можно сделать по официальному гайду:
https://www.yoyogames.com/blog/551/coffee-break-tutorials-pausing-your-game-gml
И я не пойму, чем этот способ плох и чем он не подходит? Он не отражает запаузенность или что?
Если прям очень нужно чтобы спрайты были анимироваными, то с некоторыми оговорками можно попробовать что-то такое:
Оговорки из серии "простое рисование", "без постобработок","не использовать image_index для условий" (иначе взрывы будут плохо отрабатывать).
Phaser, Flixel - вот тебе фреймворки, там где ты можешь всё что хочешь сделать. Только ручками допиши =)
Про ограничения я не очень понял. В гамаке можно сделать так же как в unity, но вручную, обсчитывая для всех объектов свои переменные и заведя свои скрипты для их обсчёта. Делается довольно просто через объект-прототип, в который закладывается вся эта функциональность.
Я про движки. Есть конструкторы (ограничения), есть фреймворки (все ручками пиши), а нормального движка для 2d - нет.
Переход в пустую комнату - тот же костыль что с отключением всех объектов.
Мне надо чтобы игра просто останавливалась и все объекты переставали двигаться и обновляться пока игра на паузе. У вас для этого скриншот надо делать, потому что остановить вызов step отдельно от draw - нельзя.
Начинаю знакомиться с гамаком и уже натыкаюсь на ограничения.
Не поверишь! Я работаю с Unity и уже натыкаюсь на ограничения! Работаю с JS и уже натыкаюсь на ограничения!
Не "у нас", а в движке. Это единственная задача, для которой тебе нужен этот функционал?
Нормальный движок для 2D это Гамак. Анимированная пауза это блажь, а обычная там легко делается.
Даже анимированная там легко делается. Но анимированная пауза - это непоянто что с точки зрения UX и геймдизайна. Непонятно зачем, и есть непонятные штуки такие как анимированные взрывы, частицы и прочее - что с ними делать во время анимированной паузы - ХЗ.
Анимированные взрывы, выходит, надо останавливать. Делить объекты по отдельному списку взрыв-невзрыв, частицам давать отдельные команды, путям ставить скорость 0. Интересно, в Юнити все партиклы тоже подвержены таймскейлу из коробки? А в Лаве? Если нет, то даже хвалёный "простой" таймскейл - это неполная пауза.
Частицы в юнити аффектятся TimeSacel-ом насколько я помню. Я не уверен насчёт setTimeOut только. По крайней мере в JS таймеры делались так. А сейчас походу единственный способ сделать таймер - это в Update вручную их считать. Заебись удобно! Зато паузу можно сделать через timeScale =)
В юнити всё норм с timeScale и частицами.
Есть.
ностальгия) давно юзал :3
В слово "нормальный", каждый вкладывает свой смысл. Для меня Godot Engine очень нормальный. Если бы это было иначе я бы пользовался чем то другим, например: phaser или pixi.js. GMS можно считать очень нормальным, ведь в одно время на нем было создано много игр, пока не появились всякие Юнити, Анрилы. Все еще зависит от уровня знакомства с документацией к конкретному движку.
Мне кажется пауза с переходом в другую комнату не очень, ибо где-то слышал на гамине, что есть какие-то проблемы с persitent, на всякий случай не буду рисковать, а остальные методы возьму на вооружение. Спасибо!
Да там есть небольшой лайфхак с persistent, но я всегда пользуюсь и всё в порядке. Никто не жаловался на проблемы с паузой.
Если верно помню, то если иметь персистент обж и персист комнату и пермещаться, то всякая дич произходит... Возможно дублирование обекта, возможно хуже, не помню точно.
Господа, к чему писать "не помню" и "где-то слышал"? Есть конкретная проблема - есть конкретное решение. Про персистентность я закодил Алексу исходник ещё 4 месяца назад для демонстрации как она должна работать. При этом персистентны и все комнаты, и объект игрока, но не объекты врагов, и никаких багов там нет.
Незнаю, у меня проблемы были... Возможно это с хтмл было связан. Чесно сейчас не скажу точно...
Дай исходник - я скажу, фигня вопрос.
1) Фиг его найдёш
2)(это уже критично) комп на котором он сломан-в процессе попытки починки...
Так что увы... Но щас уже с уверенстью вспомнил что это в хтмл было... (Так что 90% что не ошибаюсь Хд) хотя возможно в 1.49 это починили кстати, но фиг знает. Я с тех пор отказался от многокомнатности.
Не, ты всё равно скинь. И не придётся ни от чего отказываться, оно ж точно должно работать если правильно настроить.
С удовольствием, но у меня шнура для диска нет понимаешь...
Шнура??? А у тебя есть кеды или кроссовки?
Угу, чтоб этот диск как второй к материнке подключить...
Может шнурки подойдут?
Не, без кабеля не вариант...
Пора делать новый абстрактный объект o_pausable родителем и наследовать все объекты первой степени абстракции от него. Тогда не надо ничего копипастить. Чтобы не оверрайдить степ, поместить проверку флага в Begin Step ли End Step. Можно даже в какой-то из пицот видов ивента Draw.
Ну так надо же не только скорость остановить, но и скорость пути. Всё это пишется в o_pausable и наследуется автоматически.
Ты только забыл - нафига ТЕБЕ такой тип паузы? Алекс придумал что-то там себе что он хотел, у него это авторская идея. А у тебя это откуда взялось? Это что, единственный способ сделать паузу?
Напомню тебе третий вариант: это слить application_surface в скриншот и отображать его.
Ты Уася, в "гамакере" никогда не решали эту задачу, потому что она взята из воздуха и не приносит денег. Деньги приносят игры, а не паузы, и чтоб игровые движки существовали, машина должна крутиться, а разработчики кушать еду, одеваться и где-то жить. В Юнити пауза есть не потому что это важно, а потому что они могут себе это позволить "на сдачу" для неприоритетных фич - он финансируется вагонами денег (более миллиарда долларов, см. ссылку далее).
Всё что ты сейчас делаешь это критикуешь движок созданный 10-50 людьми (а в оригинале, до ГМ8, вообще одним профессором из Нидерландов) на какую-то неигровую тему, в сравнении с движком созданным 1000-5000 людьми. Потому что тебе что-то там кажется через жопу сделанным. Ну-ну.
Скорее всего там она есть как техническое средство, которое задумывалось для слоумоэффектов и отладки анимаций, но потом кто-то придумал делать так паузу.
ну так это проблема профессора, что он не может сделать нужный людям коммерчески успешный продукт и оттого не может включить даже простейший необходимый минимум.
пауза через скриншот это действительно через жопу
Объясни мне почему "через жопу"? Только тем что так делают в юнити и лёве?
"Через жопу" - это глобалы объявлять в объекте и иметь доступ к ним только через неймспейс.
"Через жопу" - это вызывать функцию сортировки отрисовки вместо раположения спрайтов на слоях
"Через жопу" - это слать сообщения, вызывая какие-то там события у объекта вместо того чтобы выполнить код напрямую в его контексте.
"Через жопу" - это иметь доступ к своим ассетам через параметры скрипта или грузить их с диска
"Через жопу" - это не иметь возможности отрисовать хпбар юнита в самом юните, а городить иерархию доп-объектов
А делать паузу при помощи скриншота - это не "через жопу", а один из способов делания паузы причём гарантированный. С учётом того, что сделать паузу через отключение события обновления в GMS тоже можно.
потому что концепт пауза абсолютно никак не связан с концептом скриншот. наличие множества других жоп в других продуктах, как и наличие удобных решений этой проблемы в других продуктах мало на это влияют
вызывать функцию сортировки отрисовки вместо расположения спрайтов на слоях - это похоже на какую-то сильно специфичное решение специфичной задачи. для чего это делать?
хпбар - приаттачил компонент на нужный объект и делай с ним что хошь, рули с любого скрипта
Пауза - это статичная картинка. Скриншот - тоже статичная картинка. По-моему это гораздо более связанные концепции чем "пауза - это когда игра рисуется но не обновляется".
Ну я понял, ты просто не можешь выйти за рамки контекста юнити, поэтому любой другой подход тебе сразу видится неправильным. Дальше не о чём с тобой разговаривать.
пауза - это статичное время
Ты не прав. Картинка может не меняться, а игра обновляется.
И картинка может меняться и быть анимированной, а игра при этом - не обновляется.
Ты просто к этому привык за все время работы в гамаком и любой другой подход тебе видится неправильным.
Если ты с кем-то не согласен, это не значит что ты прав.
Знаешь, вообще-то именно в этом месте люди правы. Мне самому не нравится делать паузу скриншотом, а на Иксбоксе другая система сёрфейсов и так это решение не работает - ну так и лолшто, я убрал фон на паузе ВООБЩЕ и заработал те же самые денежные знаки, даже больше чем в Стиме где этот фон на паузе есть.
Неправы люди в другом - они думают что раз где-то паузу сделать легко, то там и остальную игру сделать легко, ведь пауза это просто, значит дальше в ГМе будет вообще ужас. А всё с точностью до наоборот.
Тут я не согласен. Паузу в GM сделать легко. По крайней мере легче чем потом ебаться с тем чтобы выделять объекты которые будут останавливаться и те которые не будут. И всё это менеджить. Если бы в у меня была возможность в лёв или юнити делать паузу через скриншот - я бы так и делал. А то потом окажется что какие-то объекты (от самописных классов, например) не учитывают TimeScale. Ищи ошибку три тыщи лет.
Я не знаю как у тебя, но у меня на иксбоксе точно такая же система сёрфейсов как и на ПК.
Ну значит это у Дурбека такой код просто был, что переставал работать. Тут главное другое, я его вырезал - игру на забросали помидорами за это. Всем* плевать что отображается у игры на паузе, пауза сделана чтоб пойти попить чай.
* кроме единиц эстетов, не влияющих на платёжеспособное большинство
Это как?
Может, application_surface_enable(false), но я пока не совсем вижу как это тут применимо.
Как-как, жопой об косяк.
Ну окей, нечерезжопный ты наш.
Я хочу сделать паузу, но так чтобы у меня игра чуток размывалась. Можно это быстро сделать в юнити или лёве?
чтобы у тебя игра чуток размывалась добавь эффект чуток размывания на камеру. чо как дитя
тока опять же. даже если бы это было невозможно сделать, это никак не отменяло бы черезжопности необходимости задействовать скриншот при паузе.
Я ждал подобного ответа =)
Потому что в этом случае твоя камера будет размывать каждый чёртов фрейм игры сжирая производительность просто так.
А я просто сделаю размытие своего скриншота один раз при создании и всё.
разумеется, ибо он как раз логичен. и размытие я могу использовать и контролировать везде где захочу, в паузе, инвентаре, попадании, опьянении, анимации смерти, переходах, диалогах. Причем свободно регулировать ее на разных леерах и по глубине
но какое отношение имеет ничтожная по эффективности оптимизация к паузе? Если твоя задача пауза + дополнительная экономия ресурсов, то тогда такое решение удобное и подходящее и плохо то что некоторые движки не имеют возможности в одну строку делать скриншот в текстуру
В лёве можно, если ты всё написал нормально
Вот примерно так же можно сказать и про паузу в гамаке через timeScale
Ну и как это сделать?
Ага, ага. Безусловно, программа на которой уже 20 лет делаются игры с десятками тысяч отзывов, коммерчески безуспешна и нуждается в подобных советах. Минутка ликбеза:
https://store.steampowered.com/app/391540/Undertale
https://store.steampowered.com/app/460950/Katana_ZERO/
https://store.steampowered.com/app/274170/Hotline_Miami_2_Wrong_Number/
https://store.steampowered.com/app/248820/Risk_of_Rain/
https://store.steampowered.com/app/242680/Nuclear_Throne/
https://store.steampowered.com/app/447530/VA11_HallA_Cyberpunk_Bartender_Action/
https://store.steampowered.com/app/751780/Forager/
https://store.steampowered.com/app/356670/Spookys_Jump_Scare_Mansion/
И что, хоть в одной из этих игр есть "простейший необходимый минимум" - анимированная пауза? А там где есть пауза через скриншот, это кому-то испортило настроение, здоровье и карьеру? Нет же, люди просто сделали то что надо сделать, а не судачили по три часа как старые бабки - это костыль, это некостыль, а вот по такой траектории алгоритмов мы уже приближаемся к черезжопному критерию костыльности.
разумеется это была ирония после твоих слов, что у юньки есть ресурсы на такое, а у гамакера нет.
следующая ирония, на которую не стоит реагировать без юмора это сравнение картинки Risk of Rain и Risk of Rain 2.
Картинка, хаха. Да не было бы никакого Risk of Rain 2, если бы не Гамак, на котором удобно спрототипировали модель геймплея и сделали полновесную первую двухмерную часть. Тем же самым обязана серия Enter/Exit The Gungeon, игре Nuclear Throne. Равно как и, например, Spelunky, которого я не привёл потому что его 8-битная версия в Стиме не размещается.
Exit The Gungeon!!! уиии
какого wtf ваще? 2d(unity лол) платформер на мобилки? в это можно играть? :(
так это же прекрасно. тут никто не спорил с потенциальным утверждением, что выпусти разрабы ганжн и рейн2 на гамаке они были бы в сто раз лучше.
Risk of Rain 2 сделан на юнити потому что он 3Д и это вполне логично, т.к. в гамаке делать 3Д игру - всё равно что на юнити делать 2Д.
В последнее время я всё склоняюсь к утверждению, что и в Гамаке делать 3D игру проще, чем на Юнити 2D-игру. В Гамаке 3D есть ещё с середины 2000-х годов, там дальше только стоит уже вопрос "красивое 3D" или "некрасивое". Ну и отсутствие редактора трёхмерных уровней встроенного, увы. Однако, проскакивающая сейчас мода на лоу-поли и "полигоны как на PlayStation 1-2" может дать интересную нишу для "нетрёхмерного" Гамака. Я как раз собираюсь сделать проект чтобы проверить эти возможности.
лол, ну в целом я ещё не отказался от идеи скриншота и отключить инстансы, но ещё и не пытался реализовывать, просто в других движках я не делал скриншоты ради паузы, и поэтому не привычно
и кажется будто что-то не то делаю...
ещё не знаю, будет ли скриншот работать с моим сурфейсом, который находится в PostDraw главного скрипта
отрисовки всей игры, это я сделал для того чтобы был автозум окна и pixelperfect, надеюсь эти эффекты не будут конфликтовать
А как эта строчка влияет на автозум и pixel-perfect?
Вообще это рулится размерами view и его порта.
У меня кнопка Resize у окна разблокирована и можно окно как угодно менять, в этом объекте есть также:
а в скрипте scrResize
и потом в конце отрисовывается скорректированный surface
то есть я проверяю разницу между размером окна и старыми данными,
и обновляю размер surface умножая на ровное значение x1 x2 x3 x4 и т.д.,
мне главное чтобы скриншот паузы с моим surface не конфликтовал)
но в целом я пока ещё не пытался реализовать паузу на скриншоте, может там вообще нет проблем
Только непонятно зачем его рисовать, если application_surface сам автоматом рисуется (если только ты принудительно не выключил отрисовку). В остальном всё правильно выглядит.
Ты не пробовал убрать это событие Post Draw? Результат меняется?
Я ещё это добавил на старте:
application_surface_draw_enable(false);пустой экран будет
В целом, получается как на моих любимых эмуляторах)
ну вот если эту строчку убрать и Post Dra убрать? Что-то поменяется?
автоматически будет на весь экран увеличиваться отрисовка, меньше пустого места будет, но не pixelperfect (пиксели разных размеров, например на цифре "82")
а в моём случае, если места на экране меньше, чем можно увеличить на round значение,
то экран не увеличивается, зато соблюдается pixelperfect, я такое кажется в Tic-80 и Pico-8 ещё видел,
в данном случае размер окна чуть не дотягивает, чтобы экран мог увеличиться ровно в x2 раза,
(это конечно минус, что так много пустого места, зато пиксели ровные, лол)
Всё, я догнал. Ты в комнате бордеры делаешь чёрные если окно больше игры.
Ага, просто я часто видел игры на GameMaker где в опциях есть кнопки Zoom x2 Zoom x3 Zoom x4 на ПК, подумал что пусть лучше игра автоматически этот размер ставит, хоть до Zoom x100, если разрешение монитора позволит.
Я тоже делал пару раз zoom X, но я именно окно под игру подгонял без чёрных рамок, и делал проверку на размер экрана, чтобы окно не становилось больше него.
Это как вариант. Я не говорю что твой вариант не верный. Можно и так и так.
Я в своей игре в опциях даю выбрать скейл только если игра в окне, а если фуллскрин то она тоже скалируется, но автоматически, по максимуму. Разрешение 640х352, получается 640*2 = 1280, 640*3 = 1920, в принципе в большинство мониторов попадет, мне кажется.
Как вариант, только не знаю как ставить размер автоматически по максимуму в окне,
или находил, но забыл, надо погуглить, а то у меня окошко вначале очень маленькое.
Кстати, про FullScreen пока ещё не знаю, как там делать, но вроде игра при нажатии alt+Enter нормально отображается и без дополнительных строк кода, или хз.
В гм просто делается - window_set_fullscreen(true или false). А если set заменить на get то можно наоборот проверять в фуллскрине игра или нет.
Вот исходник сделал в gmz формате, потестировать или покритиковать:
https://drive.google.com/file/d/1RO5PJ7qBAr_6COkrJT2om0_lJUK9nWUF/view?usp=sharing
Так, я посмотрел.
MAIN -> Create:
А для чего нам глобально эти три переменные, если у нас уже есть YesObject, в котором их можно хранить? У тебя тут место для потенциальной несостыковки скриптов в будущем - может выйти так что global.YesObject уже noone, но global.YesAct всё ещё хранит значение от предыдущего, и запаришься искать ошибки.
Не-не, ни в коем случае не i=1, должно быть i=room_first, ну а если кроме первой (видимо ты полагал что нумерация начинается с нуля, и тогда 1 это вторая комната), то делай i=room_next(room_first).
if (room_next(room) != -1)Только room_exists(room_next(room)), все эти цифры типа i=1 для комнат и -1 вместо индексов ресурсов - зло.
MAIN -> Step:
Ты передаёшь тут название объекта, но:
1) Делаешь это строкой - тебе нужен asset_get_index("o_menu_pause") чтобы получить индекс объекта из строки;
2) На самом деле тебе достаточно просто писать не в кавычках, и тогда asset_get_index() уже не нужен;
3) Скрипт menus ничего потом не делает с этим аргументом кроме сравнения с пустой строкой, ты вроде как сделал пустые слоты для чего-то в будущем, но непонятно для чего.
То же самое на строке 15 в скрипте Talk. Идём далее:
Монструозный скрипт, думаю ты запарился его выверять пока написал. С другой стороны, ты выставил ориджин спрайта в центр и прописал поворот через градусы, так что тут даже не к чему придраться. Молодец!
o_FoeCore -> o_HeroGirl Collision
Собственно, это и есть lengthdir (вот это подстава, правда?):
Правильно организовал наследование o_coll, тут тоже молодец.
Скрипту drawGirl() не нужен аргумент - ты вызываешь его только из её объекта, да и само название говорит о том что он уместен только там. Если убрать из скобок self, а из тела скрипта var _self = argument0; и все "_self.", то работать код будет точно так же само.
Для того чтобы обращаться к переменным вызвавшего объекта, не обязательно писать ни self.dir, ни id.dir, ни пропускать это через скрипт и делать _self.dir, хотя все эти три способа тоже будут работать. Просто пишешь dir и скрипт, обладая контекстом вызова, сам достаёт эту переменную из вызвавшего инстанса.
o_BoxCore -> Create
Это ты делаешь два флага для того чтоб на второе использование давать другой результат? Не очень понятно для чего это предназначено.
Фигово я переменные называю, ибо начал забывать что это значить) в общем это объект чтобы туда переслать сигнал "Use" при диалоге, но не меню, я немного тут сам себя запутал потому-что вначале планировал сделать только Yes/No проверку для меню, а теперь добавил и в диалог.
YesObject, чтобы туда (это может быть как дверь, так и персонаж, так и другой объект) отправить сигнал согласия, и там бы уже какие-то переменные обработались, если нажать выбор "Yes"
Может стоит ещё раз эту часть кода переписать, более понятно, или хз
Да, у тебя исходник выглядит так, будто ты тестируешь много всего параллельно. Но если ты уже потерял понимание, что именно тестовое, а что нет, то начни с удаления того что явно не нужно. Бэкап сначала стоит сделать конечно.
вначале я сделал просто без кавычек, но в некоторых случаях у меня там была ошибка, забыл какая, а с кавычками ошибка ушла, ну я так и оставил)
Видимо ты сравнивал с "", вот оно и ругалось на попытку сравнить o_menu_pause со строкой, а o_menu_pause без кавычек это число, присваиваемое Гамаком автоматически, разрабу его знать ни к чему, это типа как указатель на ячейку памяти - кто там знает что в нём? Потому и обращаются по переменной, а ты вводишь в код какую-то новую, неизвестную движку строку, которая совпадает с названием объекта, но он-то об этом не знает. Пиши без кавычек и убери сравнение с "", сравнивай с noone. Хотя... по ходу ты поэтому и писал его, чтоб "" было быстрее набирать чем noone?
Можно сделать другой скрипт, в котором этот аргумент вообще не нужен, вместо чтоб обрабатывать полный скрипт где куча аргументов пустая или ни о чём. Таким образом можно более частным скриптом уточнять более общий. Но пока что неясно как ты построил архитектуру вызовов, нарисуешь схему может?
лол, да, noone раздражает каждый раз писать) в null и то меньше символов)
Это название временное, я забыл, что правильное название у этого эффекта 9-slice)
но почему-то в голове всплыло это странно название "9x9", лол xD
правильнее было бы что-то типа "Draw9Slice"
Слушай, а я и не знал. Теперь знаю, круто!
Спасибо за аналогичный пример моему коду) буду знать как это работает, а то я думал вначале что за lengthdir такой)
первое использование это я нажимаю кнопку А на объекте
второе использование после нажатия Yes (на "вопрос")
таких использований может быть и больше, в зависимости от целей
Тогда понятно. Стоит обозвать переменные более конкретно, типа isUse и isUseConfirming или isUseSure.
Слушай, я лоханулся тут. Всё он там делает, вот же:
А для того чтобы не писать впустую ни noone, ни "", сделай скрипт menus0 с таким кодом:
И вызывай просто
menus0("close"),menus0("end")и так далее.первый раз вижу такой функционал, не совсем понял как это работает, хз, попробую потестить
Ну это я от себя там ноль дописал, ты можешь вообще назвать скрипт m(), но не стоит. Это просто другой скрипт который вызывает твой первый главный скрипт меню, просто не требует второго аргумента для вызова и вместо него всегда пробрасывает "" в menus.
Я, например в гамаке не ебался с камерами так как я это делал в Phaser или той же юнити.
Точно так же как я в гамаке не ебался с отрисовкой GUI так как я это делал в юнити через передачу хуелиона аргументов в ебучий скрипт, в котором ещё нужно было поизвращаться с отрисовкой этого дела.
Вот так я рисовал UI бомбарды на юнити. Массивы текстур, иначе никак, ведь имена ассетов нельзя в скриптах использовать.
Вот результат
В половине движков у спрайтов origin не поддерживается и тебе нужно руками это учитывать.
Все движки разные в реализации каких-то фич.
Шикарно выглядит!
И да в юнити куча своих проблем)
PS если не ошибаюсь вроде как можно имена ассетов в скриптах использовать, если ресурсы закинуть в папку "resources", или я не понял про что идёт речь
Ну вот и начинается. В то время как я в гамаке пишу просто
sprite_index= spr_glass
Причём там можно менеджить группы текстур сразу, выгружая и загружая в память по необходимости.
Мне это понравилось в гамаке) я вообще люблю просто писать обычный текст (String) в коде,
чтобы указывать на переменные или объекты. Если постараться, то можно сделать в юнити упаковщик всех переменных и объектов/ассетов в словарь (Dictionary) и вызывать по именам, я как раз над этим работаю в юнити сейчас.
Ну вот да. О том и речь, что в любом движке ты будешь допиливать функциональность под себя если ты видел для себя решение более удобное. Меня на самом деле в юнити и таймеры вырубают. По крайней мере в js нужно было писать setTimeout, и я вообще не уверен, что timeScale будет её аффектить.
Задать таймер через alarm[0]=40 куда проще ИМХО. Но и минус есть. Там можно было анонимную функцию отписать, а в GMS нужно в событии прописывать.
а я таймеры в GMS и Unity пишу вручную, переменными D:
потому-что в юнити не люблю и плохо понимаю корутины, а в GMS пока даже не пробовал изучать alarm
Вот тебе мини-лекция по alarm
В коде пишешь: alarm[0]=30 что значит что он каждый степ/фрейм будет отниматься на 1 и сработает через 30 таких фреймов.
А сработает - значит выполнится событие alarm0 для объекта. После этого переменная alarm[0] станет равной -1, что значит что таймер не запущен. Тоже можно проверять.
Массив alarm[0] для каждого объекта свой и их можно создать до 12 штук на объект. Удобство ещё и в том что его можно использовать как счётчик - а это довольно много доп возможностей. Будешь заходить на мои стримы - узнаешь каких именно =)
Спасибо! Я тут как раз счётчик вручную сделал, может перенесу в alarm)
Он не совсем точный, потому-что нужно отнимать каждый кадр не -0.0166, а где-то -0.0166666666666667 и хз можно ли ставить после запятой столько значений, но хотя может это мелочь и даже за 100 часов эта разница будет незначительная, но наверное проще это в таймер alarm закинуть
Довольно оригинальное решение, без подкола сейчас. Не думал о таком.
Начиная с ГМС2.3, есть in-line функции.
Я вот по основной работе сейчас занимаюсь HTML/CSS
И относительно недавно открыл для себя PUG и SASS - то где не нужно ставить точки с запятыми и уёбищные скобки, где теги можно объявлять без <>. В общем каеф. Код читается в разы лучше и выглядит приятнее.
О, это то за что я полюбил GameMaker 6.0 в 2006 году! (в том числе)
Честно говоря это не особо в чём-либо убеждает, т. к. стены текста могут быть нужны просто потому что они одинаково в этом месте нужны и в ГМе, и в Юнити, и в других движках. Тут бы пояснить что именно ужасного в том коде, я вот не догнал.
Начать можно с этой дичи:
Я должен передавать в скрипт название шрифта и массивы текстур, потому что иначе ресурсы в Unity задействовать в коде нельзя...
Далее:
Кто-то мне сегодня утром кукарекал что в гамаке ВЫНУЖДЕН создавать объекты на любой чих =)
А тут смотри чё происходит - я создаю объект Color, чтобы потом его передать в качестве поля в объект GUIStyle чтобы потом его передать в функцию рисования. Куда уж коду на гамаке сравниться:
Итого три строки кода вместо семи, т.е. более чем в два раза меньше.
Конечно, в стилях что-то такое есть и даже может показаться что это удобно. Может быть если бы это была вёрстка сайта, то да. Но это игра, разовое место во всей игре для отрисовки UI...
Двигаемся дальше:
Мне нужно всегда обозначить прямоугольник. Я не могу нарисовать текст свободно в любой точке.
ScaleMode принимает три значения со смыслом "вписать", "растянуть" и "обрезать". Т.е. функции зеркального рисования тут нет, поэтому мне пришлось создавать зеркальные ассеты. Тогда я начал понимать, почему игры на юнити так много весят. Про оптимизацию не слышали.
А из-за этих постоянных вложенностей, создания объекта и передачи его куда-то там код раздувается и выглядит некрасиво. Ну вот что это за пиздец то?
Time.deltaTime или transform.position.z или rigibody.velocity - это же обосраться просто!
И это в JS только! В шарпах тебя вообще заставят все неймспейсы писать и там просто лютый ад.
Вот ещё пара примеров:
Да в рот ебал я такое писать. Какое-то высранное недоразумение программировать на ООП в стиле функциональщины. Точнее так - я понимаю что ООП - это подразделение всего на объекты. Но цвет - это просто перебор. Скоро для каждого байта информации начнут объекты создавать. Ну а чё, оперативка то резиновая! Нужно - растянется =)
Мне вот очень импонирует модель названий констант в GMS.
fa_left, vk_right, c_red и т.д.
И ёбанаврот! Можно писать без этих дебильных префиксов, потому что все и так всё знают, а не тащат это из синтаксиса C# только для того чтобы можно было делать игры на языке, который заточен под ентерпрайз аппликухи. Конечно же блядь программисту не понятно что FloorToInt - математическая функция, как Cos, Sin, Abs, Sqrt и нужно явно указать, а то вдруг ты у себя в объекте реализовал свой метод Cos, который считает его по отличной от общепринятой формуле. Или функция FllorToInt внезапно превращает пол в уровне в международный.
А потом всякие типа трупрограммисты будут рассказывать мне что это единственно правильный способ, что ВСЕ ТАК ДЕЛАЮТ, а остальное не православно. Да ОК, нет проблем. Только я на своём коммерчески неуспешном гамаке в котором всё делается через жопу буду писать для 2Д игр кода в три раза меньше и в три раза быстрее чем на юнити. Ну а вы пишите эти непонятные конструкции, тратье часы на чтение кода и создавайте лишнией ассеты, передавая их в параметричсекие массивы, зато всё ПРАВИЛЬНО сделаете, не через жопу, молодцы!
Вот теперь понятно.
Только теперь вот это не понял, какое зеркальное рисование?
Когда ты можешь текстуру отзеркалить. В гамаке это делается занчением -1 в параметре xscale функции draw_sprite_ext
у текстуры вроде есть свойство offset = -1; или с подобным названием, но я чаще переворачиваю объект по scale к которому эта текстура прикручена) хотя если это с GUI, то я хз как там работать, у меня весь GUI обычные объекты префабы никак не связанные с UI юнити, ни со старой, ни с новой системой
Возможно, есть способ отразить текстуру в моём коде, при помощи шейдеров, например. Но я его не нашёл.
Рисовать UI при помощи префабов? Т.е. плейнов с текстурами?... absolutely not kostyl solution XD
Глянул тутор по GUI через объект canvas. Да, стало гораздо лучше, чем было =)
Я может тоже когда-нибудь доберусь до туторов по GUI. Хотя пока мне привычнее юзать обычные объекты и вторую камеру.
Но всё равно по мне очень много телодвижений нужно сделать. В гамаке я просто нарисовал всё в нужных частях экрана в одном событии. А с новой системой GUI мне всё равно нужно накидать в этот канвас объектов, каждый отдельно настроить, в каждый добавить текстуру (правда здесь уже есть зеркалирование), а если там есть какая-то логика отображения или использование переменной - для каждого такого объекта ещё и отдельно в скрипте прописать это.
В целом, такой подход свои функции "отображения UI" выполняет. Так что я не буду говорить что это какие-то костыли или черезжопное решение. Можно и так. Костыли или через жопу - это если бы у меня был единственный способ сделать GUI - скачать и установить third-party библиотеку из другого движка, в которой этот функционал есть.
Это я о разнице между "другой подход"(есть официальные гайды по тому как это делается) и "через жопу"( когда инструмент не предусматривает механизмов решения твоей задачи).
можно кстати цвет инициализовать один раз в глобальном скрипте и юзать постоянно во всех скриптах, если он часто нужен, и в гамаке мне всё равно не нравятся заранее прописанные цвета, и приходится свои создавать, я уже привык создавать цвет с нуля, в гамаке столько же кода надо писать на цвет)
Не столько, в Юнити нужно ставить точки, а в ГМе не нужно! :yak:
JS Unity
var color : Color = Color(.5,.5,0,1);C# Unity
Color color = new Color(.5f,.5f,0,1);Game Maker
var color = make_colour_rgb(127,127,0);да в целом строки кода почти одинаковы)
Про точки я шутил, но вот теперь минутка занудства от старого фанатика Гамака:
И вуаля, теперь вместо:
ты можешь во всём проекте писать просто
Что, можно так в Юнити? Не-а, нельзя.
Если принципиально нужно задавать цвет от 0.0 до 1.0 вместо от 0 до 255, то тогда скрипт rgb:
и код будет:
Итого тут один раз написано слово color, без скрипта rgb - два, но в Юнити - три! Чего ради?
В юнити создаёшь скрипт Game, с функцией:
потом в другом скрипте, вроде должно сработать, но не тестил:
либо я не понял про что идёт речь, но если про то что диапазон цвета 0-255, то мне без разницы,
мне нравятся оба диапазона цвета, что 0.0f-1.0f что 0-255, и это в функции юнити тоже можно сделать
Не должно, у тебя RGB принимает Vector3, поэтому и вызывать надо:
На самом деле надо прописать:
Тогда будет как ты хочешь. Но всё равно надо color писать два раза, а в ГМе один. Да ещё вдруг какой-то Game появился. Такие дела,
color = rgb(127,127,0)по-любому удобнее.лол, да, ошибся)
Ты можешь макрос добавить на свой цвет и использовать как константу.
В gms2 есть директива
А в gms1 в специальном интерфейсе всё то же самое делается.
Это может быть не всегда удобно, так как поди разбери какие константы в каком объекте используются сходу. Для такого нужно их называть начиная с подходящего слова. Но так тоже можно, да.
Макросы же к объектам не привязаны. У контроллера просто создаёшь их сколько нужно. ФИшка в том что ты задаёшь цвет точно так же как заданы встроенные цвета, по-моему, вплоть до цветового отображения в коде.
Ну это верно.
но вообще да, в юнити много где приходится писать длинные строки кода, хотя там много визуальных инструментов для создания контента, того же UI
В юнити много крутых инструментов, которые я бы хотел видеть в гамаке.
То что я написал о недостатках выставляет меня в глазах читателей хейтером юнити. Я написал только про код и язык, который мне не кажется удобным. То что игра запускается и отлаживается прямо в редакторе сцены - это очень круто. В гамаке можно только анимации объектов посмотреть, ну в 2.3 ещё твины.
Система компонент сама по себе довольно крутая.
Возможность драг-н-дропа ресурсов в поля визуального редактора. в GMS2 это частично можно делать и есть альтернатива делать это кодом, а в Юнити это практически единственный способ использовать названия ресурсов в коде.
Работа с частицами супер-круто сделана.
Есть много крутых фич. Но весь функционал заточен на 3Д игры. Это самая главная причина по которым я использую гамак, а не юнити.
Хаха. Вот щас чисто обидно было, без всякой иронии. В 2013 году я написал GMXD - "игровой встраиваемый дебаггер", который позволяет добавлять ивенты в объекты на лету. Я там даже автоподсказки делал для того чтоб функции автоматически подставлялись. Кто-то стал его юзать? Нет конечно, потому что гыыыыыы уэээээ ГОМЕ МОКЕР СТУДИА, а там больше нету execute_string(), на который опирается 99,9% функционала проги, т. к. это динамическое выполнение кода.
В ГМе все эти долбаные годы, начиная с того как execute_string появился, и до Студии 1 (около 10 лет!) была возможность разрабатывать игру прямо во время её работы. И теперь в 2020 Хейзер, сидя в Студии 2, мне заявляет что это есть в Юнити и это очень хорошо. Ну ахереть просто.
https://yellowafterlife.itch.io/gamemaker-live - при том что есть ещё и такое.
а, так такой жуткой хераборы c onGUI и заданием в нем всех параметров нет давно в юньке. на все есть готовые компоненты, с кучей опций и настроек. В общем случае ты создаешь объект нужного типа, слайдер или баттон или текст, ручками прямо на сцене раздвигаешь его, задаешь цвета вешаешь спрайты, анимации, и потом через скрипт крутишь только те параметры, которые тебе нужны. Заодно сетки для упорядочивания, помещение объекта на камеру или в пространстве игры все доступно без кодинга.
Была жопа, но сейчас такой UI запилить это самый бегиннер уровень
Да? Тогда что не так с этой неделю назад представленной игрой в плане интерфейса, сделанной на свежей версии Юнити?
Там автор в комментарии пришёл, и говорит что задолбался там всё править.
понятия не имею что там, это надо у дева спрашивать. может быть и дев, но это не точно. К тому же он пишет про баги (которых как ты, сам понимаешь в продукте за миллиард немного) и input - проблем с XInput я не встречал, но я и не ковырял сильно
Ну, выглядит неплохо.
Это точно. А ещё чем больше денег вложено, тем обратная совместимость лучше. (нет)
Если честно я запутался, self или id?! Или без разницы?!)
Да, и мне объясните. В 8.1 я пользуюсь self и все работает.
Я написал про id в контексте того, что self не работало у Алекса, но сам код не проверял. Как проверил Rs, данный код с self работает, просто Алекс, судя по всему, где-то в другом месте ошибся. Вообще я использую self, когда объект вызывает сам себя для определённого действия как аргумент для скрипта. Ну и по идее id более универсальная переменная.
Я там просто просто опечатался)
self работает быстрее. Вообще не очень понимаю зачем её использовать, разве что как в примере, если ты переменные именуешь как дегенерат, мешая всё подряд. Если взять за правило глобалы именовать капсом, локальные строчными, а все переменые, объявленные через var начинать с почерка то и проблем нету. Можно какие-то другие правила выработать.
Я не использую self и не использую id для обращения к переменным объекта, так что мне кажется это вообще избыточный функционал.
Тот же пример но без self
Тут прикол в том, что всё что объявлено через var в таких конструкциях доступно не зависимо от скоупа и имеет более высокий приоритет. Именуйте переменные правильно и не ебеись с self.
Интересный пример с with! Надо запомнить.
Я часто self использую чтобы отправить все переменные разом из объекта например в скрипт.
DamageObject(self,5);
А зачем?
Скрипт DamageObject выполняется в том же контексте и подхватывает все переменные объекта.
Если тебе нужно вызвать его в контексте другого объекта то делаешь просто
with (objId) DamageObject(5)
А как внутри скрипта работать c этим?
То есть у меня в функции/скрипте "DamageObject" нужно проверить сколько Defense и HP у объекта.
что-то типа:
Работать так как если бы ты этот код написал внутри объекта:
Гамак - это по большей части не про лишнюю писанину. Считай что скрипт - это просто параметризированный макрос =)
Рекомендую использовать argument именно как массив. Это даст возможность сделать скрипты с плавающим количеством аргументов. В GMS2.3 это скорее всего поменяется.
Пока таких прогнозов нет, старые скрипты работают так же как новые, только оборачиваются в функции.
Есть одно исключение - в коде коллизии если ты пишешь:
то это более однозначно чем
Просто по самой логике чтения текста (без проверки есть там где-то наверху по тексту или стеку вызовов var dmg или нету). На движок это конечно никак не влияет.
Я так не пишу. Мне достаточно написать other чтобы понять что это переменная из другого контекста, а все остальные из теукщего. Но если без привычки, может ты и прав.