Всё ещё учусь работать в Game Maker (GMS 1.4.9), параллельно участвуя в конкурсе на GCup.
1)Немного неприятно, то что разрешение экрана и FPS нужно менять в каждом уровне отдельно,
по логике это должно выноситься в опции и быть общим для всех уровней.
2)Также немного прокачал рисование персонажа для кастомизации, хотя возможно это всё будет лагать при 60 FPS на слабом ПК, я не уверен:
- 18 июня 2020, 17:21
- 04
Блин, неужели еще кто-то получает удовольствие от драу_что-то_там(x+vh+50, y+vh+50, w+vh*2+40, h+vh*4+60). Ну это же пиздец, братцы...
Альтернатива?
Я не знаю как там в GMS, что сделано, но обычно спрайты просто расставляются в тех местах где они должны быть, как например в Godot. В gms разве нельзя "руками" делать сложную структуру? Ragdolls не реализован?
В той версии что юзаю я GMS 1.4.9 с этим сложно, проще ввести кодом, но я люблю такие функции, и хотел бы в юнити. Например если я хочу показать какую-то надпись или спрайт в GMS, то просто беру и показываю,
а в юнити пришлось бы создавать отдельный объект и не забыть его удалить потом.
С чем сложно-то? Вы тут щас странные оба - один спрашивает сам не знает что, а другой отвечает за движок который ещё не изучил, причём отвечает непонятно на что.
По пунктам объясняю:
Там можно скомпоновать составной объект из частей вообще без всяких вызовов функций и ручного выставления оффсетов.
Ну и это одна маленькая задача в рамках огромного проекта.
Ксит, я имел ввиду про визуальное создание иерархии спрайтов/объектов, как в юнити или годот,
хотя возможно я просто не нашёл этот функционал, я хз:
Минуточку. Это если нужно в другой комнате такой же герой с такой же иерархией, то придётся копипастить. Разве не префабами это надо делать?
Префабов в ГМ нет, это правда. С другой стороны, в GMS2.3 уже есть не только они, но и возможность составлять из них анимации, см. таймкод и снизу слева трек-панель - поверх чувака поставлены отдельно в иерархию меч и щит. Так что тебе это недоступно только потому что ты учишься на старой версии, на которой из-за этого менее удобно, а значит менее приятно учиться.
штош
ага, префабами)
Ну так вот префабы в ГМС2.3+ теперь есть.
Ну ладно) я буду покупать только тогда, когда научусь и определюсь с GMS, буду ли в будущем на нём работать и понравится ли мне (и сейчас с финансами не очень), пока только учусь сделаю одну-две игры и посмотрим. И хз можно ли там делать мобильные и ПК игры, не докупая каждый год снова лицензию, просто я не уверен насчёт мобилки, а вроде как на ПК постоянная лицензия.
Подписка у Гамака только на самое дорогое - консольные экспортеры по $800 в год, причём без региональных цен как у всего остального в Стиме у них.
Стимовские региональные цены в РФ - ОЧЕНЬ щадящие:
https://steamdb.info/app/585410/
https://steamdb.info/app/585620/
А потом на них ещё и скидка падает.
Вообще можно импортировать костные анимации вроде.
По удобству когда как. Иногда удобно как ты говоришь, а иногда удобно рисовать всё в одном объекте.
Не "вроде", а импортировать векторные анимации можно из Spine, и из совместимых с ним прог, например DragonBones.
Пример: https://twitter.com/kittariagame/status/1270455841712246785
В смысле, удовольствие? Где это ты в ГЕЙМДЕВЕ видел удовольствие, "братец"? XDDDDDDDDDD
В игры хорошо только играть. Делать их - боль и проклятье, особенно двухмерные на трёхмерных движках.
всё же мне кажется 3х мерные, на 2х мерных сложнее)
Ирония доходит до того, что скоро в ГМС2 будет проще делать трёхмерные, чем в Юнити двухмерные.
это скоро ещё должно вырасти до сейчас.
Ну хз, иногда лучше работать с готовым объектом, но иногда лучше рисовать через draw, смотря какое действие, я бы очень хотел такие функции в юнити, а в годот они вроде есть, встречал в документации.
В юнити придётся свои костыли делать.
Если в юнити я захочу сделать тоже самое, то мне нужно:
1) на уровне создать 8 спрайтов и сделать их родителя (в принципе пока просто),
не забыть все спрайты размещать на некотором расстоянии друг от друга по оси Z, чтобы они
не отрисовывались раньше других, а sprite order не трогаем, ибо он нам понадобится для других целей,
чтобы весь объект выглядел целостным и части его спрайтов не пересекались с другими частями других объектов (смотреть, в пункте 4);
2) при смене направления персонажа можно было бы только родителя по scale переворачивать, но нужна
дополнительная проверка, чтобы второй раз подряд не менять направление, что-то типа:
3) анимацию можно сделать в аниматоре в юнити, с одной стороны проще, с другой стороны для небольших пиксельных объектов обращаться к таком сложному функционалу не очень хорошо. Или если я захочу настроить слои, то есть например, чтобы руки анимировались отдельно, лицо отдельно, то для таких пару пикселей настраивать аниматор со слоями не самое лучшее дело. Если я захочу чтобы появлялся какой-то объект в анимации, какого тут нет, то мне придётся создать этот дополнительный объект заранее и скрыть его,
возможно даже придётся много сразу объектов создать и скрывать их, чтобы в определённый момент анимации их показывать, либо придумать в скриптах создание и удаление объектов, но также через аниматор надо настроить костыли поведения и прописать функции.
А тем временем с draw, можно рисовать только когда работает триггер, всего 1 строка кода:
(хотя придётся повозиться с настраиванием правильной позиции, везде свои плюсы и минусы)
4) Чтобы спрайты этого объекта не пересекались со спрайтами например врага, то нужно каждому новому врагу, через скрипт всем спрайтам врага сделать другой Order, что-то типа:
А тем временем с рисованием draw таких проблем вообще нет, и не нужно создавать костыль порядка отрисовки для этого, спрайты разных объектов никогда не будут пересекаться при draw методе.
PS так что есть везде свои плюсы и минусы, что-то легче делать визуально, а что-то лучше делать кодом.
Что значит спрайты разных объектов никогда не будут пересекаться? У каждого спрайта уже есть некая область коллизии?
1) А что если коллизия в виде триггера, допустим все враги опасны, но я могу сквозь их пролетать?!
Или сквозь героя пролетают пули.
2) Если я прохожу мимо NPC, с которыми не сталкиваюсь, то будут видны все пересечения спрайтов.
В моей игре на юнити например куча NPC, которые ходят по городу и можно легко переходить сквозь них,
и неписи сами друг через друга иногда проходят, и видны косяки с пересечением спрайтов между ними,
чтобы это убрать мне приходится ещё помимо Sprite Order также случайно менять позицию Z, чтобы было меньше пересечений, но иногда у при пересечении пару неписей и почти одинаковой Z позиции этот косяк снова всплывает(( а с отрисовкой draw такой проблемы никогда не будет.
3) Если в игре есть Y/Z Order, (то есть чем ниже объект, тем у объекта больше Z Order, например для изометрических RPG), в таком случае, если мы приблизимся к другому объекту, у которого не будет коллизии, то спрайты там все друг с другом пересекуться.
Что-то сложна.... Какие-то заморочки, что даже в это вникать не хочется. Ты меняешь Z чтобы что-то там исправить, триггеры коллизий, коллизии триггеров, триггерные триггеры коллищий... 🙄🤯🤕
Что касается Годот. Есть физические объекты: кинематик, статик и ригид. Хочешь сталкиваешься, хочешь нет - реализуется через слои. Есть. Area2d которую проходишь, но она регистрирует столкновение и выход из объекта. Все. Просто и дешево.
Дело не в коллизии, а то что её может не быть, и тогда персонажи могут находиться на одинаковой координате и их спрайты могут друг в друга влезать. С годотом я тоже пока не разобрался, потом буду думать, но там есть много интересных моментов, которые мне понравились.
Чтобы они друг в друга не влезали создаются разные сущности: player, npc1, enemy. Они никак не будут влезать друг в друга. У гмс я не знаю, в годот точно такого нет.
Спеэффект взрыва ДОЛЖЕН влезать поверх спрайта персонажа, если этот персонаж сейчас получил ракетой в лоб. Зачем тебе делать взрыв который автоматически выталкивается из своего текущего положения, если он как раз должен пересекаться с тем что повреждает?
Я как раз в GMS сейчас гуглю, как сделать так чтобы вновь созданный объект был выше по приоритету отрисовки остальных, а то у меня пуля где-то за всеми объектами отрисовывается,а нужно чтобы она была выше даже, чем главный герой. По умолчанию я думал так, если создаёшь новый объект то он сразу рисуется поверх всех объектов, но видимо тут другая система, либо я не так что-то сделал.
Он рисуется поверх всех ранее созданных объектов, существующих на той же глубине (depth). Пример типичного распределения:
Враг ниже всего, игрок выше, пули игрока ещё выше. Наследуется всеми конкретными врагами и пулями от абстрактного врага и пули соответственно.
Спасибо) а я думал там надо скриптом делать
Вот допустим классический пример из моей игры, когда координаты по Z оси случайно оказались одинаковыми
у двух неписей и они стоят рядом:
Возможно тут можно придумать какую-то проверку при пересечении неписей, чтобы позиция по оси Z, никогда у них не была одинаковой, если они пересекаются (потому-что разбрасывать случайно по позиции Z не всегда помогает). Так что никуда не деться от этих костылей)
И да, у них нет коллизии, ибо они как персонажи игры River City Ransom, то есть идут слева направо или наоборот справа налево без проверки столкновения для симуляции толпы.
Проверку пересечения? Неужели ты не представляешь масштабы происходяшего - сколько писанины тебе предстоит... По моему не в том направлении двигаетесь, товарищ...
По-моему ты забыл что он говорит про Юнити, а не про ГМС. И в пользу последнего, а не первого.
Странно видеть такое в 2020 году, но у тебя движок гмс старый, так что вполне возможно. Срочно переходи на студию - игры нужно делать, а ты ерундой занимаешься🤣
этож вроде как скрин из юнити...
Это да, Юнити)
а сунуть каждому коллайдер и пускай стукаются, не?
да, но вопрос вроде как про то как сделать это без подобного....
Перемудрил ты с порядком отрисовки, используй SortingGroup. Да и с направлением движения переусложняешь, пожалуй.
А как с направлением движения работать?
то есть если вот так оставить, то не будет лишней траты ресурсов?
Пример на UnityScript (JS был в Unity до 2018.2 версии):
Пример на C# (ибо C# не может работать с одной осью):
Мне кажется не оптимально так каждый кадр для каждого персонажа прокручивать, или же есть другой вариант?
То есть, SortingGroup поможет вообще убрать эти пересечения спрайтов, даже если группы находятся на одной Y координате? Если так то круто, не знал, хотя не уверен есть ли такая опция в 2018.2 версии юнити, ибо я пользуюсь той версией из-за того что она последняя понимает JS, а мой долгострой написан на UnityScript((
Но в новой игре, на новой версии юнити возможно даже будет полезно, Спасибо!)
Да, SortingGroup используется чтобы спрайты разных объектов не перемешивались при отрисовке. Просто на родителя надо повесить компонент. Судя по документации в 2018.2 SortingGroup есть.
У тебя же там по сути написано
if (transform.localScale.x != direction) { transform.localScale.x = direction; }от oldDirection можно избавиться. У объектов без коллайдеров и прочей физики можно и каждый кадр размер менять, с физикой вроде бы как не стоит.Мне просто нужна переменная direction чистая, то есть там должно быть либо 1 либо -1, без плавающих чисел.
А, ты там потом ещё scale домножаешь на что-то. Ну тогда
if (Mathf.Sign(transform.localScale.x) != direction).В принципе, как вариант)
хотя от таких проверок в юнити всё равно сложно избавиться, например, если надо проверять отключить объект или нет, допустим это лампочка, можно ли спамить без проверки вот такую функцию каждый кадр,
если таких лампочек ещё и много?
lamp.SetActive(LampOnTrigger);или лучше мой способ с:
хотя возможно тут по аналогии тоже что-то можно придумать с методом GetActive, хотя хз
может опция называется enabled? типа
В принципе если это работает то прикольно, Спасибо за совет) а то я реально постоянно накидываю проверки типа "old...MyVariable"
В данном случае свою переменную заводить не надо. У гейм обжекта есть поля activeInHierarchy и activeSelf, можно проверять одно из них, то, которое подойдёт в конкретной ситуации. Если на десятке-другом простых объектов будешь просто SetActive без проверок дёргать, то ничего страшного не случится. Если у тебя буллет хел с тысячами патронов, то там будет куча мест где и чего оптимизировать, и об активности объекта ты будешь знать и без проверок.
Мне кажется, ты пытаешься оптимизировать не там, где будет тормозить. И, возможно, раньше времени.
Первый и четвертый пункты чет перемудрены. Кроме sorting order, есть еще sorting layer, и вот layer глобально используется для того, чтобы разделять объекты на группы по приоритету отрисовки. То есть, можно вынести layer для персонажа и layer для противников, и если layer противников будет ниже layer персонажа, противники уже никогда не будут рисоваться поверх персонажа. А order используется уже внутри самого layer, например, чтобы задать порядок отрисовки отдельных элементов.
Я кстати заметил, что у меня нет отдельного слоя для врагов (а надо бы), я просто дал персонажу ордер 10 или типа того, и это кстати тоже вполне сработало бы (просто начинаешь с большого значения для персонажа), но со слоями это куда проще.
Я думал SortingLayer это тоже самое что и SortingOrder, только как константы потому и никогда не пользовался,
но всё же, а что если мне надо каждого непися фильтровать друг от друга, чтобы они не пересекались между собой, на каждого непися отдельный SortingLayer делать?
Посмотрел, похоже решение с Sorting Group выше должно работать нормально.
В настройках можно сделать сортировку по Y. + на персонажа вешать сортинг груп. И у спрайтов не забудь выставить ориджн поинт а не центр. Этого всего достаточно чтоб никто ни с кем не конфликтовал.
Возможно я мазохист :D , но мне почему-то больше нравится отрисовывать через draw, хотя конечно не нравится вручную настраивать координаты, можно было бы так чтобы размещать по координатам было бы как в юнити (визуально в редакторе размещать), а управлять отрисовкой спрайтов как в GameMaker, то было бы супер.
Да, это принципиальная разница в подходах - {создавать и удалять объекты для любого элемента картинки} против {прописывать что рисовать каждый кадр в коде}.
У обоих вариантов свои плюсы и минусы (и свои поклонники и противники), лично мне больше нравится второе, а в идеале видимо должна быть возможность легко делать и так и так. Впрочем, в юнити вполне можно один раз запилить велосипед который будет вызываться как draw_sprite_ext() каждый кадр, а внутри сравнивать новые вызовы со списком вызовов из прошлого кадра и создавать\удалять требуемые объекты. И да, тормозить не будет.
У гмс и юнити такой возможности нет?
Насчет ГМС я без понятия, в юнити (как и любой среде с первым подходом, я для SFML такое сделал) можно сделать свой велосипед для immediate режима, хотя он, возможно, будет менее удобен чем родные методы.
В юнити всё окей с созданием объектов, но нет отрисовки draw.
Но в GMS я хз, кажется нету создании визуальной иерархии объектов в редакторе,
но лично мне нравится метод draw, хотя я хочу чтобы работали сразу 2 метода,
когда я не хочу париться с созданием ста мелочей, то просто пропишу в коде отрисовку без создания и удаления этих мелочей, этих ста объектов просто физически не будет существовать.
И кажется именно в годоте есть оба метода, и отрисовка и создание объектов, поэтому меня годот тоже очень заинтересовал)
Нет уж... Давай осваивай гмс, раз начал, а то так и не напишешь никогда игру своей мечты.
вроде в гмс2 что-то такое в вели недавно, но я не совсем уверен насколько это то, так как сам не пробовал...
Нету там такого. Но руками несложно допиливается, если нужно.
в 2.3 но оно вроде ещё в бете или типо того... некий animation curve но опять же возможно вы правы)
В новой бете вводят.
В GMS объекты по-другому устроены в отличие от юнити.
В юнити ты можешь сделать пустой объект и навешивать на него компоненты. В GMS объект сразу идёт со всей своей обвязкой. Поэтому городить в GMS иерархию дорого по производительности.
Лично мне не нравится иерархия в юнити. Точнее так. Я понимаю для чего она нужна и для 3Д игр она необходима. Но 2Д игры на юнити всегда были злом. И там можно запросто обойтись без иерархий.
К тому же, в GMS её можно сделать вручную по мере надобности. А в юнити рисовать как GMS не получится =)
Мне иерархия в юнити на 2д нужна для кастомизации и ленивой анимации, чтобы одна анимация работала для 100-200 разных персонажей в игре, конечно это зло, я понимаю, но кастомизация это моя слабость, в юнити я не знаю как иначе сделать без иерархии) А в GMS норм без иерархии благодаря отрисовке на лету)
Это о ГМС до 2.3, теперь это устарело и структуры данных существуют отдельно от объектов, производительность страдать не будет. Я так понимаю, пост мой ты про 2.3 не читал, или не вник в его суть, а стоило бы.
Золотые слова.
У этих структур данных нет ни полиморфных методов, ни наследования, поэтому иерархию на них не забабахаешь.
Хейзер под иерархией имел в виду не наследование, а композицию. Так что забабахаешь.
да на юни и 3д не всегда гуд =) (хотя возможно это разрабы перемудряют, но всё-же...)
Какая визуальная иерархия? Вроде бы речь идёт о слоях - они есть. Насколько я понял, SortingOrder из Юнити это переменная depth в объектах ГМа, а SortingLayer это слои инстансов в ГМе.
В твоём конкретном случае достаточно написать просто:
И всё, у тебя порядок отрисовки меняется в зависимости от Y-координаты.
А по поводу того что можно сделать игру не используя draw_sprite ни разу - разумеется можно. Я так первые свои игр 5 сделал.
Спасибо! Как раз с отрисовкой пули и взрыва надо было решить вопрос)
было бы прикольно такое замутить, но я придумал только сложный метод, который будет нагружать проц)
ну он будет на сколько-то нагружать, но тысячу раз за кадр сделать "if" - это вообще ни о чем. Сделать dictionary в котором ключом будет спрайт и координаты, при вызове draw_sprite_ext искать в нем текущий вызов, если не найден - добавлять новый объект. А в конце обработки кадра удалять объекты которыеза этот кадр не вызвали. Точнее не удалять а прятать, чтобы потом переиспользовать когда понадобиться добавить новый объект.
Чтобы прятать нужно ещё какой-то список спрятанных объектов сделать, в целом возможно этот вариант не так плох, хотя по ощущениям кажется что много ресурсов это всё будет кушать)
Режим с созданием объектов в любой случае более оптимален чем непосредственный - меньше данных пересылается на видеокарту. В одном случае пересылаем когда что-то добавилось\удалилось, в другом - каждый кадр пересылаем всё (если конечно в draw_sprite_ext под капотом нет аналогичного механизма).
Но если объектов порядка тысячи, шустрый скриптовой язык и сделать без явных косяков, то тормозить особо нечему.