Godot 3.1 вышел. Говорят, там куча наворотов новых, думаю это ещё один хороший повод начать уже нормально изучать этот движок. В некоторых местах он лучше юнити, скрипт моментально компилируется и он динамический, как Lua, в отличии от долгого ожидания в юнити. Но есть и минусы в отличии от юньки, но мне годот интересен тем, что в нём удобнее делать пиксельную игру, чем в Unity.
- 13 марта 2019, 23:48
- 07
И вот ещё в нагрузку
блин теперь это уже выглядит конкурентно гамаку...
Ой да ну. Пока нужно писать портянки с обработчиками событий - никакой конкуренции. Вот будет классификация по событиям + добавление своих собственных. Вот тогда может быть. С ресурасми как я понял здесь тоже не очень пока работать.
Однако, скелетная анимация выглядит достойно.
Говорят, что, если бы Хейзер устроился в Yoyogames евангелистом, то смог бы уже прикупить виллу в Майями!
Да это смешно выглядит когда в видосе типа "У нас крутой дружелюбный UI теперь" и сразу же показывают эту охеренную портянку с обработчиками событий. Дело чисто в удобстве. Чтоб найти нужный блок в портянке - часто нужно сильно погружаться во всю портянку и бегать поиском. Это меня угнетает во всех движках где я это видел, в т.ч. и в Юнити, хотя там можно несколько разных скриптов навешивать, не раздувая внутренний код. В общем хуёвое индексирование в таком подходе.
Альтернативный подход я только в гамаке видел. Когда у объекта вместо портянки мааааааленькое окошко со списком событий, которые этот объект использует. Но каждое событие раскрывается на портянку. В GMS1 было нелохо сделано что на одно событие можно было назначит два куска кода, да ещё и поименовать их как угодно особым типом комментария. Правда используется редко, так что во второй студии такого уже нет.
Это странно, что в Юнити такого нет.
Это с тамошней скриптово-компонентной системой не очень согласуется. Например, есть коллайдер, и есть два скрипта, которые должны обрабатывать столкновение с разным эффектов (например, один рассчитывает физическое влияние, второй - получаемый урон). Куда тогда эти слоты сунуть? В каждый скрипт? Ну так ивентов по умолчанию в монобехе десятки. А если влепить их чисто на коллайдер (было бы логично), то тут отпадает возможность назначать туда два обработчика с разных скриптов.
А что мешает просто дать возможность "соединить" слот в коде с какой-то финтифлюшкой в GUI Юнити? По типу IBAction в XCode.
Не понятно, ставишь сигнал на коллайдер, потом пользователь пишет сколько угодно где угодно слотов и привязывает их к сигналу. В каком месте не согласуется?
Вроде не похоже на портянку ¯\_(ツ)_/¯
Какие портянки? Тут сигналы-слоты, как в Qt.
Никак не заходит что-то... Раза 3 пробовал...
Но он хорош, да.
Сайт не работает?
а если прога, то может проблема с OpenGL
Не заходит использование Годо.
Вроде начинаешь все нравится, а потом какие-то шероховатости, то тут то там, и желание копаться в нем пропадает.
Раньше скрипт в Юнити тоже моментально компилировался.
К сожалению я такие времена не застал. Все мои 200 скриптов компилятся в моём проекте за 30 секунд, это настолько долго для стиля программирования, как у меня, я программирую методом тыка, и после каждого тыка проверяю нормально ли написал код.
Вроде как они пытаются встраивать систему с пакетной раздельной компиляцией скриптов, хотя это конечно не сравнится с горячей перезагрузкой того же Годота.
А я сижу на старой версии 2018.2, из-за того что юнити отказалась от Java Script в 2018.3 версии.
Как только перепишу свои 150-200 скриптов на C#, возможно смогу потестить новые фичи юнити)
ну буду постепенно переписывать, может быть даже найду решение, как сократить их количество)
Вот тут что-то даже вроде живое. Не пробовал?
Проблема в том, что Array нету в C# в отличии от UnityScript, я даже не представляю, сможет ли он автоматически перевести это.
Спасибо, попробую потестить, ради интереса! Но скорее всего код придётся вручную переписывать)
Ближайшая альтернатива - это
List<T>
А почему не T[] ?
Я на этом основывался, когда советовал. Как я понимаю Find / Sort и т. п. надо статически из Array вызывать? В List<T> они как методы. Но если всё это можно провернуть с T[] в юнити, то можно и его использовать. Я не углублялся в эту тему, unityscript не использовал.
Я скудно знаком с C#, поэтому и спрашиваю. Сейчас посмотрел, вроде бы List - это не linked list, а простой массив, так что, наверное, сгодится.
Я тоже. Давно не писал, так как после знакомства с Clojure я за динамические языки, в особенности для разработки игр. Поэтому по вопросу array vs list лучше stackoverflow скажет.
Что имеется в виду под динамическими языками? Языки с динамической типизацией?
Ага. JS, Lua, языки в game maker и Godot и т. д.
Интересно, изменишь ли ты своё мнение года через два-три.
Интересно, вспомнишь ли ты об этом года через два-три.
Не уверен, но в общем мне действительно интересно. В первую очередь, интересно сравнить со своим опытом, а именно любви к скриптовым языкам типа питона, которая тем больше угасала, чем больше я на таких языках писал.
Такой ответ информативнее! На более широких масштабах выигрыш от статической типизации, я думаю, будет. На уровне прототипов / простых игр - это оверхед.
Ну в общем-то Алекс выше пишет, что у него 150-200 своих скриптов. Я не знаю, достаточно ли это широкие масштабы, но дебажить все эти макароны в рантайме на предмет того, что Object blabla doesn't have method Foobar(), на мой взгляд, не очень приятно.
В этом случае и правда полезна Strict опция в языках. Чтобы опечатка не заставляла искать сутками проблему, я так в Lua случайно опечатался и дебаггер даже не указал, то что такой переменной у меня нету вообще.
Смотря, какой язык. Haxe вполне элегантен, чтобы быть статическим, но не сильно при этом раздражать.
Не показывайте это Алексу, а то он будет четыре движка одновременно ковырять :D
Там пока нестабильно и не готово, чисто модельки свои погонять внутри окна Блендера (это чисто моя глазомерная оценка, но длительные проекты с этим затевать пока не стоит).
Интересно, чем это лучше голого Блендера? Там же тоже вроде можно игры делать прямо внутри
Насколько я понял, BGE выпилен из 2.8 совсем, но добавлен Eevee, который хоть и реалтайм, но без гарантированного количества кадров в секунду...
Ух ты, что-то новенькое))
изучив Lua и почитав справку к Godot, мне тоже очень понравились динамические языки
Свой язык в годоте ещё хорош тем, что там есть сахар для функциональности самого движка. Например, $ вместо get_node().
Конечно, это палка о двух концах, но удобно.
А в Годот можно сокращать операторы, как в Lua?
например так, я очень люблю сокращать длинные названия и операторы,
для меня чтение кода в разы увеличивается, когда всё очень коротко написано,
да и писать легче, такой код
Нет. Функции там не первого класса объекты, к сожалению. Это неприятный минус.
https://docs.godotengine.org/en/3.1/getting_started/scripting/gdscript/gdscript_basics.html#referencing-functions
Конечно, не то же самое, но для приведённого примера сработает (во второй строке Гамин съел обязательный отступ пробелами слева)
P.S. что-то код странно на Гамине подсвечивается, разломало на 2 строки и съело отступ у 2й строки
Если код из нескольких строк, то надо сначала нажать на кнопку, а потом вставить его в появившиеся окошко.
О как, спасибо, теперь для полного счастья не хватает только GDScript подсветки xD
Кстати, ещё есть кнопка для кода в Формат->Строчные, и она таких окон не выдаёт...
Добавил GDScript и убрал Формат->Строчные. Наверное, вообще "Формат" из комментариев стоит убрать, может выравнивание из него только оставить.
Еееееее
Но иногда применение get_node более чем оправдано. К примеру, в случаях, когда сцена присоединяется динамически.
Да, конечно. Как доступ через точку или []
или такие плюшки:
Это прикольная вещь!
Это уже вариации на тему printf. Функциональность движка тут ни при чём.
Ты чертовски прав, но практически никто форматированием не пользуется, а между прочим это полезная возможность.
Большинство подобного функционала доступно через Linq для любого IEnumerable типа. Правда, не знаю насчет производительности.
Так в шарпах есть с десяток разных типов коллекций на разные вкусы, плюс Linq. Думаю, можно подобрать вменяемую альтернативу.
Не знал, что там их много вариантов. И это все динамические массивы?
Ну я уже выбрал List (я думал что это единственный вариант), я просто к тому, что у меня много Array в коде,
и придётся очень долго переписывать это всё. Я очень люблю динамические массивы использовать)
PS Этим мне Lua порадовал (недавно освоил), что там очень легко оформлять динамические таблицы.
Да весь net framework к твоим услугам
Ну, там скорее непосредственно структура коллекций различается. Некоторые коллекции могут представлять собой обычный динамический массив, но будут иметь разные методы доступа к данным (например, если нужна индексация, то тут List или стандартный массив, но если, например, коллекция будет использоваться для очереди, то тут больше подойдет Queue, и т.д.).
ЧТОООООО?
Серьёзно? То есть теперь на юнити только на говняном C# писать эти неебические тавтологии?
Ну нахуй такое дерьмо. Умерла Юнити. Жаль.
хотел бы я ошибаться, но в справке юнити теперь только примеры C# :(
ЗЫ главное чтобы Godot не пошла по тому же курсу, я не хочу потом через несколько лет узнать, что я зря время потратил на этот язык. Например на GDScript
Кстати, ещё вариант установить Lua поверх C#: https://assetstore.unity.com/packages/tools/moonsharp-33776
Но я не пробовал, возможно, понадобятся обвязки какие-то...
Зачем переписывать? Тебе нужны эти 2.5 фичи? Без них никак не обойтись?
И проверь - может они просто отключили возможность создавать JS-файлы из редактора, но не использовать их, как было с Boo. Попробуй вручную в проводнике создать js-файл.
это как раз в 2018.2 версии (которой пользуюсь) , нельзя создать ЯваСкрипт, но можно юзать,
а в 2018.3 убрали Ява Скрипт совсем
Если скрипты содержат описание объектов (например, один класс в коде для одного персонажа в игре), то возможно, что стоит перенести это по максимуму в Json (то есть просто в текстовые файлы, которые парсятся при загрузке соответствующих персонажей, а не при компиляции), чтобы не напрягать компилятор (не зависимо от языка). У меня на работе такая фигня на Haxe, но поздно менять уже...
Уникальные скрипты у меня написаны на отдельном языке (сделал себе мини скриптер, типа Lua, только слабее и для себя) Там просто такие скрипты как:
1) скрипты работы ачивок, перков
2) таблицы данных для текста, для одежды, для вещей и цены,
3) различные скрипты меню, кнопки, эффекты, информация в тексте, инвентарь и работа с ним
4) кастомизация, покупка кастомизации, выбор кастомизации в меню
5) качание от ветра, кручение, движение, автодвижение текстуры
6) смена времени суток, смена погоды,
7) выходы с уровня, и места куда выход ведёт, сейв поинты
8) ядро всей программы, ядро уровня, управление камерой и границы уровня
9) управление персонажами, управление врагами,
10) контроль урона оружия
11) генерация на карте событий и врагов
12) транспорт и управление им
ну это так на вскидку, что вспомнилось с ходу
Не очень понял, если основной код на каком-то не-JavaScript языке, то что тогда в тех 150-200 скриптах?
может я тоже тебя не так понял, думал ты говоришь об уникальных скриптах, которые используются только один раз для уровня или одного события за всю игру, то для них я сделал самодельный скрипт, который не компилируется, а остальное никак не вынести в такие самопальные мини скрипты
Хмм... хотя впрочем, JavaScript тоже не компилируется по идее :D
Я имел в виду вынести всякие таблицы с циферками и строками из общего кода, но, видимо, это уже и так сделано?
ага, таблицы я вывел) насоздавал разных массивов, и они используются в качестве данных висящих на префабах
Сейчас Годот хорош для 2D, особенно мне понравились Node Graph - для создания диалогов прекрасный инструмент. Хорошая работа с json, что говорит об легкой интеграции например с itch.io или gamejolt. Визуальный редактор шейдеров, лично для меня это не очень, но народ прется от этого. Акцент на автотайлы, и обновленный инструмент работы с ними - загрузил картинку и просто разметил нужные тайлы слоями: навигатион, коллизион, оклюжен и т.д. Хорошо поработали с сетью, добавив сокеты. Дерево анимаций теперь работает как конечные автоматы и модульное исполнение. По синтаксису полно плюшек: необязательная типизация функций и переменных, пользовательские классы, setget.
Вот мой поверхностный субъективный взгляд такой: я пробовал проходить несколько туториалов сейчас и во времена второй версии. Сейчас получилось всё гораздо быстрее, удобнее и понятнее. И в целом впечатления намного более позитивные.
мне пока там не нравится, что атласы или группы текстур автоматически не собираются (или как в юнити с пару кликов) чтобы использовать на полную катушку Animated Sprite, я боюсь использовать его, допустим у меня будет 100 персонажей по 100 кадров на каждого, и для Animated Sprite нужно резать это всё на отдельные картинки.
А как сильно будут нагружать 10000 отдельных картинок на процесс игры??
Зачем тебе Animation Sprite? Animation Player, очень полезная штука., а вообще у Спрайта есть параметр атласа: загружаешь картинку, устанавливаешь количество строк и столбцов и выставляешь текущий фрейм, а потом при помощи кода или тогоже player меняешь кадры.
И для него вкусные пиксельные шрифты нашел: тыц
о, надо затестить, Спасибо) Я всё ещё откладываю изучение годота (GDScript) вначале учил Tic80 (Lua), а теперь тут Битси конкурс) думаю, надо уже и годот опробовать.
Я предлагаю на следующем конкурсе: код или гаминатор, коллаборацию замутить, если конечно получится... а так шрифты крутые:
Хуёвые пиксели...
блин точно( не Pixel Perfect
Да тут и толщина рамки слева и справа разная. Но к шрифту же это не имеет отношения
Да, шрифт неплох. Хот вот эта единичка странновато выглядит.
Мне непонятно, зачем пиксельный шрифт в непиксельной игре. Ошибка интерполяции хайреза/вектора на скейле или дробных значениях? Или просто годот так работает с пиксельартом, выводя всё на плейны?
Ты про что сейчас? Я думал, это antonka нафотошопил по-быстрому
нет, не фотошоп.
Картинка показана не в один один как она есть, а растянута согласно ширине экрана в полный размер, т.е. пропорции не соблюдены, отсюда такая трансформация.
Использую Scale для текстуры - 2.6, отсюда и траблы, т.к. значение не кратно целому числу. А так да, глаз у тебя меткий.
Есть ещё такой трюк (коммент, не пост) для масштабирования, не пробовал, но может, поможет.
Такое часто на шрифтах вижу когда пытаешься в пиксельарте юзать готовые.
Но у тебя со шрифтами вроде хорошо всё, значит только текстура скейлится крива - нужно в пропорциональном скейле значит отрисовать.
8 лет пиксельарта + доёбистая натура XD
Коллаборацию можно, могу пиксели рисовать)
программист из меня не самый лучший, тем более на Годот, я только начинаю с ним знакомиться :D
только я в интернете редко бываю, могу заходить и скидывать материал , а потом пропадать) я нормально работаю только оффлайн) в онлайне меня часто тянет на ютюб за летсплеями или мангу почитать XD
А что значит "пиксельные шрифты для него"? Подойдёт же любой TTF, состоящий из квадратиков, типа Press Start 2P, и ещё есть редакторы шрифтов, например, FontStruct.
Я не правильно выразился, но думаю тут особой ошибки в выражении нет, пиксельный шрифт - шрифт имеющий ярко выраженные острые грани, без сглаживания углов.
А, понял! Я думал, речь идёт про нахождение bitmap-шрифтов такого формата, который поддерживает Godot, когда можно было взять TTF.
Но если кто-то делал пиксельную игру не на Godot, то он уже нашёл какие-то шрифты, и они точно так же заработают в Godot. Вот и не понятно, при чём здесь вообще Godot. :D
нет, у Годо со шрифтами не все хорошо. Слишком маленькие шрифты (шрифт 8х5 на itch.io) нельзя сильно увеличить без искажения, а если использовать еще Camera2D то проблемы только увеличатся. Как вариант, под конкретную игру создавать свой шрифт, либо иметь набор из нескольких, как 04х20, 04х25, 04х30 (ссылку давал вышел). Хотя, я допускаю, что что-то упустил при работе со шрифтами в Годо и из-за этого получаю некоторый гемор.
Хм... А вот это ты сделал?
Знать бы где эта галочка...
Нашел, она по умолчанию включена. Есть нюанс. Допустим имеем шрифт, в одном случае, чтобы получить красивый пропорционально ровный "рисунок" нужно использовать значения кратные 8 (8, 16, 32 и т.д.) при выборе размера шрифта, в другом случае шрифт - 12, 24, 48. А по сути у создаваемых шрифтом одинаковая разметка кегля. А как это все получается, что по разному работает в программе не понятно... Нужно изучать короче.
А можешь загрузить мини-проект, где что-то искажено в шрифте из-за увеличения? (а то, может, у меня тоже что-нибудь искажается, а я и не знаю, хоть я и не делаю пиксельную игру, но всё же)
Силами комьюнити появилась свежая документация для скачивания, как прямо по заказу alexsilent:
https://archive.hugo.pro/builds/godot/docs/godot-docs-html-nightly.zip
Непонятно, чем встроенная не устраивает:
Встроенная - это только API. Ну и меня она не устраивает, что в ней были пробелы, когда последний раз смотрел :D
примеров мало) но так она тоже неплохая вроде, чем больше примеров, тем лучше и легче понять материал для меня
Ееее! Спасибо :3 Надеюсь там есть новенькие примеры кода)
Единственное, что меня напрягает, так это то, что из сцены НЕ находящийся в ДЕРЕВЕ сцен, нельзя получить доступ к другой сцене и нужно прибегать к обмену данными через setget или автозагрузку. Особенно сложно, когда объекты создаются динамически.