С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то начат перевод официальной документации: https://docs.godotengine.org/ru/latest/
Но вообще, будь мужиком и изучи английский: https://godot.readthedocs.io/en/stable/
Вместе с движком обязательно смотри примеры, там есть всё - от платформера до чата. Примеры качаются прямо в движке через свой магазин.
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Игры, созданные глобальными кириллами: https://godotengine.org/showcase или https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Годнота от анона:
Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
Все языки в одном месте: https://vk.com/topic-70467171_35982467
Предыдущий тонет там: >>583342 (OP)
Архивы:
1 https://arhivach.ng/thread/207802/
2 https://arhivach.ng/thread/388500/
3 https://arhivach.ng/thread/388501/
4 https://arhivach.ng/thread/388502/
5 https://arhivach.ng/thread/388503/
6 https://arhivach.ng/thread/432708/
7 https://arhivach.ng/thread/433902/
8 https://arhivach.ng/thread/436355/
9 https://arhivach.ng/thread/455461/
Бля ты даун что ли, я тебе говорю бери юнити, пожалеешь сука, короч тебя предупреждали, прибежишь с обосранными портками плакаться, жалеть не будем.
Написано более 10000 постов однотипного говносрача. Поздравляю.
>А ты пытаешься траллировать гондотеров в перерывах между прогулками и еблей тяночек? Я правильно понимаю?
>Почему годот такой бездушный?
>Это ты просто безрукий.
>Ну конечно, ЕСТЕСТВЕННО! Сижу на яхте, троллю гондотирав.
>Хотел тебя обоссать, а потом подумал что ты прав, ведь это Хуан называет все нестандартными названиями.
>Хочу вкатится, но мне интересно, а какие вообще игры были созданы на Годоте?
>Смотри в шапке треда.
>В основном уёбищные однотипные пиксельные платформеры.
Тем временем, в ньюфаго треде с обосранными портками бегают только юнитидауны, пока годаны спокойно пилят игры.
Какое отношение анимешные картинки имеют к гондОте? Вы там от совсем безыгорности обезумели?
> почему в ОП-постах игрового движка в гд аниме-картинки
Потому что я могу.
А, так ты просто завидуешь, что у твоего движка нет маскота.
Давайте подумаем, возможно ли, чтобы студия хотя бы АА-класса выбрала годот в качестве движка для своей игры?
Тут в прошлых тредах проскакивали ссылки на чела, который брался пилить форк годота, ибо Хуан сделал какие-то там списки через кучу, а не массивы через стек, или что-то такое. Уточните, кто знает?
То есть, если профи залезет в сорцы годота с аудитом, то он предположительно охуеет и пошлёт нахуй?
Студия АА-класса будет писать свой велосипед.
https://www.executionunit.com/blog/2017/07/14/in-defence-of-writing-your-own-engine/
>Вот есть у меня две ноды с нулями в одной глобальной точке. Нода А вращается произвольно, а нода Б фиксирована. В ноде Б есть произвольный вектор В. Мне надо, чтобы этот вектор после задания дополнительно поворачивался на поворот ноды А.
Смотри какую штуку я нашел.
https://docs.godotengine.org/en/3.1/classes/class_remotetransform.html#class-remotetransform
То есть можно сделать так: у тебя есть нода А и нода Б, которые вращаются произвольно. Но в ноде Б ты заводишь промежуточную ноду Б' и переносишь туда ее остальной контент.
Потом добавляешь в ноду A RemoteTransform, в свойствах задаешь путь к ноде Б', и ставишь галочками переносить только повороты.
Сам не пробовал, отпишись если поможет.
Да, за будущее годота можно быть спокойным - игр как не было, так и не будет, баги не поправят, зато каждый релиз будут новые модные фичи, как у юпити. Потому что багфикс потом сложно продавать. Ты же не выкатишь релиз, в котором список изменений будет состоять из "пофикшены глитчи физики, пофикшен редактор анимаций, который рандомно не сохранял изменения на выходе, пофикшены микрофризы и статтеринг". Тогда донатеры задумаются, "а что, годот был забагованным говном?" Они просто не в курсе, они ведь игры не делают на годоте.
А вот какой-нибудь НОВЫЙ МЕГА РЕНДЕР НА ПУКАНЕ хорошо продается.
Глядишь, скоро AR/VR подвезут, ECS и прочую модную шелуху.
> Глядишь, скоро AR/VR подвезут, ECS и прочую модную шелуху.
АР/ВР уже есть ващета. А ЕЦС уже вышел из моды.
Хороший вопрос, хотя юньку ты зря упомянул. Там 3д хоть и лучше текущего годотовского, но тоже хуевое. Анрил же может не всегда иметь такую мягкую ценовую политику, как сейчас. Да и про сторонников опенсорса забывать не стоит. Опенсорсых движков с приличным 3д нет (ну или почти нет). Хуже от того, что годот попробует занять эту нишу, никому не будет.
Да пусть занимает, я к тому, что Хуан выбрал неправильный вектор. Надо вместо рендера на пукане было запилить нормальный рендер под десктоп на opengl 3.3, чтобы оно работало и на встроенных видюхах, и на десятилетних. Потому что если 3д и будут пилить на годоте, скорее всего это будет лоу поли индюшатина, и странно, что у таких игр будут системные требования уровня последних AAA игр.
>Надо вместо рендера на пукане было запилить нормальный рендер под десктоп на opengl 3.3, чтобы оно работало и на встроенных видюхах, и на десятилетних.
Возможно. Но что-то мне подсказывает, что на вулкане шансов запилить хороший рендер больше. А для 2д, лоу-поли и древних девайсов останется OpenGL ES 2.0 (по словам анона).
Вы заебали форсить этот опен сорс. Все равно Хуан не принимает пулл реквесты на изменение движка. Все равно и его шестерки пилят его, никого не подпуская, чтобы собирать донаты. Толку от этого опен сурса.
Карго культисты ебаные, для вас терми "опен сурс" обладает каким-то непонятным, магическим смыслом.
>Надо вместо рендера на пукане было запилить нормальный рендер
Надо было рендер вынести в абстракцию и подключать любые рендеры как модули. Хуйлан такое не умеет к сожалению. У него все захардкожено с зависимостями по всему движку. Почему ты думаешь он переписывает с gl es 2 на 3, потом опять на 2, потом на vulkan уже 4 года? Он ебанутый анскилльный велосипедист.
А нормальный разработчик бы просто взял bgfx.
>нет необходимости платить
Я и так не плачу за юнити
Нет, смысл опен сурс в распределении работы. Вместо того, что каждая контора самостоятельно пишет весь свой код, код делается общественным. Теперь вместо дублирования одного и того-же кода, все конторы пилят и улучшают один общий проект. Эффективность налицо. Они все равно делают это из экономических соображений. Большинство коммитов во все опен сурс проекты всегда делается профессиональными программистами из больших корпораций. Просто совместная разработка для корпораций дешевле и эффективнее.
Никогда обычные пользователи не полезут в код опен сурса и не станут его переписывать. Это миф.
А от того что Хуан выложил исходники на гитхаб, не делает годот опен сурс проектом. Потому что он разрабатывается по классическому проприетарному принципу, где авторы пилят все сами.
То есть годот ничего не берет от опен сурса (не использует существующие опен сурс проекты) и ничего не дает опен сурсу (не коммитит в опен сурс проекты, не позволяет использовать части движка для каких-то других проектов, потому что движок - монолит).
Годот для мира опен сурс разработки как бы не существует.
>Нет, смысл опен сурс в распределении работы.
Ну это для тебя. Для меня - это как раз возможность легально не платить и менять под себя.
>А от того что Хуан выложил исходники на гитхаб, не делает годот опен сурс проектом.
Ладно, допустим, ты меня убедил. У хуана неправильно идет разработка и вообще его опенсорс не опенсорс. Но меня, опять же, как пользователя, волнует конечный результат. Назови мне движков с правильным опенсорсом, которые превосходят годот по возможностям. Я присмотрюсь.
>А нормальный разработчик бы просто взял bgfx.
Услышал модно слово и повторяет как попугай. Ты его попробуй собрать для начала, это такое же васянское говно. Сначала тебе надо скачать васянскую билдсистему. Потом васянские зависимости. Потом васянские классы имиджей. Потом писать все на васянском языке шейдеров, которые шаг влево шаг вправо крешатся на реальных видюхах.
>Все равно Хуан не принимает пулл реквесты на изменение движка.
Че еще спизданешь? Тебе хоть доплачивают за пеар юньки?
>а про игры на них. И игры на юнити прекрасно работают на некрожелезе
И я про игры. У меня на 10-летнем некрожелезе или греют видяху до 100 градусов (то есть неюзабельны), грузят уровни по 10 минут (на ssd), а игры примерно после 2017 года просто не работают (рисуют черный экран с глитчами). Так что идешь нахуй со своим пиздежом про швитой унете.
А еще он использует опен сурс компилятор, чтобы билдить годот!
Я что писал, что в годоте нет ни одной опенсурс библиотеки? Сам что-то придумал, сам опроверг.
Хуан не использует опен сурс там, где его нужно было бы использовать.
Ты правда не понимаешь недостаток Хуановского подхода к разработке движка? Не понимаешь, какие преимущества опенсурс дает?
Ну подумай, что Хуан мог бы сделать за эти 4 года полезного для движка, если бы интегрировал bgfx, вместо своего ебанутого велосипедства с рендером.
>Хуан не использует опен сурс там, где его нужно было бы использовать.
А определяешь где нужно у нас лично ты? Ты просто хейтер, если бы он делал bgfx ты бы говорил почему он не взял хуйнянейм вместо этого.
>если бы интегрировал bgfx
Да ты заебал уже с этим куском кала, я тебе все про него расписал
>Ты его попробуй собрать для начала, это такое же васянское говно. Сначала тебе надо скачать васянскую билдсистему. Потом васянские зависимости. Потом васянские классы имиджей. Потом писать все на васянском языке шейдеров, которые шаг влево шаг вправо крешатся на реальных видюхах.
И эти 4 года вместо доработки движка всем бы пришлось копаться в багах bgfx. А при каждом обновлении bgfx опять бы все ломалось.
>Да ты заебал уже с этим куском кала
Это самая популярная библиотека кроссплатформерного рендеринга.
Баги там ты сам выдумал? Ну давай сравним количество issues на гитхабе
>bgfx
>Issues 226
>godot
>Issues 5,000+
Конечно, это баги в bgfx мешают его использовать, ага.
>И эти 4 года вместо доработки движка всем бы пришлось копаться в багах bgfx
К твоему сведению, опенсурс разработка это не только пассивное использование кода, но и процесс общего вклада в разработку. Хуан мог бы исправить баги bgfx, и не только улучшить годот, но и помочь коммюнити bgfx!
Но у Хуана слишком больше ЧСВ, чтобы писать код чужому проекту. Зачем? Лучше свой велосипед писать 4 года. Свое говно, как говорится, не пахнет.
>Это самая популярная библиотека кроссплатформерного рендеринга.
Популярная среди твоих одноклассниках? Она нигде в серьезных продуктах не используется, это вещь в себе.
>Баги там ты сам выдумал?
Это отзывы тех кто ей пользовался.
>Хуан мог бы исправить баги bgfx
О том и речь. Вместо написания движка все бы сидели и занимались фиксами чужого говнокода.
Юнити с 2017.3 версии отменили поддержку железа десятилетней давности, отбросили DX9. На некропеках теперь только чёрный экран и звук, лол. Хотя DX9 это уже не "10 лет назад", а все 20, 10 лет это уже DX10 минимум.
Помню, было у меня такое на ноуте c корой дуба, горел тогда с чёрных экранов. Игры покупал, но те, которые не шли, откладывал на потом. Ясное дело, что я не был идейным нищебродом, просто ноутбук накладывает серьёзные ограничения на возможность апргрейда.
Еще возможно у тебя термопаста под крышкой чипа высохла. Сними крышку чипа и (только очень аккуратно) привинти радиатор напрямую к чипу. Я так делал на 560 гефосе. После этой процедуры на 20-30 градусов меньше греться стала.
>Причем тут это?
При том, что у тебя волосатый бублик не должен греть видеокарту до таких температур, если все в порядке с охлаждением. Что уж там про игрушки говорить.
Что-то я не туда воюю. Как бы за юнитидауна не приняли.
>Вместо написания движка все бы сидели и занимались фиксами чужого говнокода
А сейчас вместо написания движка все сидят и занимаются фиксами своего говнокода.
Или ты думаешь в Хуановском рендере не будет багов? Ты уже забыл любимую отмазку Хуана про баги в драйверах видеокарты?
>Она нигде в серьезных продуктах не используется
Лол. На этой этой библиотеки разработано игр больше чем на гондОти.
Ты бы хоть в описание заглянул https://github.com/bkaradzic/bgfx
Проблема не в багах хуановского рендера, а в том что по производительности этой хуйней невозможно пользоваться и сам по себе рендер дерьмовый, гипробы каловые. Это его потолок, он уже плакался, что никто не хочет рендер пилить и делиться знаниями, все грозится блог вести по разработке рендера, типо те кто сейчас хуйню допиливают проникнутся и станут рендер улучшать
Даже есть один коммерчески-успешный 2д рогалик https://store.steampowered.com/app/677120/Heroes_of_Hammerwatch/
Зачем нужен годот?
Хочу понять что делать в скриптах дальше для дополнительных механик.
Например:
по нажатию кнопки взрывать первый выпущенный снаряд или вообще все снаряды,
по нажатию кнопки снаряды копируют направление взгляда и летят туда.
Как положено по документации у меня 3 скрипта:
скрипт игрока со всеми инпутами и движением, прицеплен на капсулу,
скрипт пушки в котором функции стрельбы и смены, прицеплен на ребенка камеры,
скрипт снаряда который двигает его вперед и удаляет.
Где именно прописывать поведение, скрипте оружия или снарядов? Если я хочу выборочно редактировать параметры снарядов то мне придется хранить их списке? Еще надо сделать кулдаун на выстрел, как проверить что прошла 1 секунда?
> по нажатию кнопки взрывать первый выпущенный снаряд или вообще все снаряды,
В скрипте пушки создаётся снаряд в какую-либо переменную, например, var snariad = snariads.instance()
Далее, он отправляется игроку: player.add_snariad(snariad)
В скрипте игрока снаряды хранятся списком: var snariads = [] нулевое значение соответствует первому выпущенному снаряду, крайнее значение (snariads.count - 1) - соответствует последнему. В _процессе скрипт игрока чекает этот лист от последнего к первому (это важно!) и удаляет из списка те снаряды, которые уже не существуют.
Теперь, когда всё готово, мы делаем одну простую вещь: по нажатию кнопки, посылаем команду snariads[0].set_boom_bada_boom() либо for snariad in snariads: snariad.set_boom_bada_boom()
> по нажатию кнопки снаряды копируют направление взгляда и летят туда
Аналогично. Список снарядов уже есть у игрока в скрипте. По нажатию кнопки посылаем снарядам: for snariad in snariads: snariad.look_at(my_gase)
https://docs.godotengine.org/en/3.0/classes/class_spatial.html?highlight=look_at#member-function-description
> как проверить что прошла 1 секунда?
func some_function():
print("start")
yield(get_tree().create_timer(1.0), "timeout")
print("PROSHLA ODNA SECUNDA")
https://docs.godotengine.org/en/3.1/classes/class_scenetreetimer.html
Анон. Есть два выпуклых CollisionPolygon2D которые пересекаются.
Как мне получить полигон их пересечения?
То что ему нужно, никто, кроме него не определит.
Ну через группы тоже можно, хотя ящитаю, это (сорри за каламбур) как стрелять из пушки по воробьям. Группы нужны, когда есть множество разнотипных сущностей, которые самостоятельно создаются и уничтожаются разными источниками и логика определенной сущности не может их всех просчитать. Тогда проще завести группы и обращаться к группам. А тут твой потомок спавнит сущности одного вида, которые самостоятельно уничтожаются. Ты имеешь доступ к потомку, потомок имеет доступ к тебе. Проще и быстрее обмениваться ссылками на инстансы, чем ебаться с группами.
Привет, Анон.
Есть PoolVector2Array с набором векторов. Нужно каждый его элемент скалярно умножить на один и тот же Vector2.
Это можно как-то одной командой сделать?
Или только пилить цикл, по всем элементам массива?
Я просто не понимаю нахуя юзать годот? Ну говорили же запилите какую-нибудь фичу которой нигде нет, про те же события констрактовские, нет они подпрягли еще какого-то индуса ноды полировать. Их никто не юзает, потому что это тот же гдскрипт только неудобный. Или если в события не можете сделали бы шаблоны, но чтобы реально годные, фпс, рпг, чтобы хоть кто-нибудь реально сказал - вот это говно облегчило мне жизнь. Дрочатся как ебанутые, одно и тоже переписывают. Зайдешь на гитхаб там коммиты сыпятся, движуха какая-то, и так годами, а не происходит нихуя, в каждой области сраная недоделка, говнокопия юнити.
https://github.com/godotengine/godot/issues/30915
Как же ты жалок, наивный гондотя.
Использую Годо уже больше трёх лет, есть парочка законченных небольших игр, есть много мелких недоработок от джемов, и ещё пишу(писал) на нём большую полноценную игру(больше половины контента уже реализовано). И вроде бы всё хорошо и замечательно было, пока дело касалось только прототипов или совсем мелких проектов. Вот в чём с Годо никто не сможет потягаться - это со скоростью разработки. Тут вообще конкурентов нет, даже близко никто не валялся. Архитектура движка гениальна в своей простоте, позволяет за считанные минуты набросать костяк проекта любой сложности. Почему я никогда не прекращу пользоваться Годо окончательно, так как хотя бы даже для того же прототипирования равных ему нет.
Но как только ты выбираешься за пределы прототипов и игр больше чем из трёх сцен, начинаются проблемы. И проблемы серьёзные, особенно когда задумаешься о будущем.
1. Ориентация на мобилки. Как следствие - полное отсутствие рендеров для полноценных платформ. Даже банального OpenGL нет, это же охуеть вообще! Не ждите, что ваша игра запустится на старом железе, даже если у вас там пара содомирующих кубов в коробке и больше ничего.
2. Проблемы с производительностью, отчасти и-за первого пункта, подозреваю. Пока ты делаешь прототипы и маленькие игры для себя на своей йоба-тачке, которая покрывает всё это стократным запасом скорости, этого не замечаешь. Но как только начинаешь тестировать коммерческий проект на слабом железе(которого предположительно у 70-80% пользователей) - внезапно охуеваешь от 15фпс на сцене из двух спрайтов на фоне параллакса.
3. Опенсорс. От которого происходит целый ворох проблем, от мала до велика.
Первая - забудьте о простом релизе на консолях. Для этого нужно или самому движок переписывать, или нанимать стороннюю фирму.
Вторая - баги, баги, баги, которые никто не чинит, потому что все заняты добавлением новых ненужных фич, которые в свою очередь добавляют баги, баги, баги. И ладно бы мелкие, так ведь большие серьёзные баги никто не чинит. Я больше года назад завёл тикет на баг редактора, с которым столкнётся каждый, кто вздумает запилить более-менее серьёзный проект. Тикет приняли, разобрали, нашли причину, и... ничего не сделали до сих пор. А баг некисло так портит жизнь разработчику. Но, похоже, я единственный, кто собирался писать на Годо большой проект.
И с одной стороны - "почини сам, это же опенсорс". Но с другой стороны, а зачем мне тогда движок использовать вообще, простите? Мне проще самому писать на своём движке.
Вывод только один - при всех плюса Годо, что называется "not production ready". То есть на нём банально невозможно выпустить большой полноценный проект.
Итого - я переписываю свои мелкие проекты на юнити, а большую игру перевожу на самописный движок на SDL2.
И это очень обидно, потому что мне реально нравится использовать Годо.
>Небольшой крик души
>Использую Годо уже больше трёх лет
>Я больше года назад завёл тикет на баг редактора, с которым столкнётся каждый, кто вздумает запилить более-менее серьёзный проект. Тикет приняли, разобрали, нашли причину, и... ничего не сделали до сих пор.
А рассказать, что за баг или ссылку на тикет кинуть - западло?
Это какая-то паста?
>полное отсутствие рендеров для полноценных платформ
Вут? Почему у меня на железе 10-летней давности работает GLES2? Кстати, имей в виду что игры на юнити 2017+ года на старом железе не запускаются.
>забудьте о простом релизе на консолях.
Вут? Берешь и релизишь, просто сдк в комплекте никогда не выложат.
GLES2 - не полноценный рендерер. На встройках с ним проблемы, он банально не работает на половине, даже новых.
>Берешь и релизишь, просто сдк в комплекте никогда не выложат.
Ну-ка зарелизься-ка на свитч с пруфами. (у меня девкит свитча есть если что)
>>603835
Выбираю оба. Я это и имел в виду - когда игра технически закончена, всё дописано - и архитектура, и все модули, и интерфейс, и метагейм и т.д. Осталось только наполнение контентом - рисовать графику, строить уровни, скриптить врагов, режиссировать катсцены.
>На встройках с ним проблемы, он банально не работает на половине, даже новых.
Так на новых есть GLES3, и будет Вулкан. Чо ты тут клоунаду устраиваешь, лол?
> Я это и имел в виду - когда игра технически закончена, всё дописано - и архитектура, и все модули, и интерфейс, и метагейм и т.д. Осталось только наполнение контентом - рисовать графику, строить уровни, скриптить врагов, режиссировать катсцены.
Так не бывает в принципе в этой жизни. Любая разработка именно "большой" игры выглядит так - геймдизайнер придумывает фичу, левелдизайнеры добавляют ее на уровень, и идут к программистам, потому что средствами игры ее добавить невозможно или возможно только через костыли. И программисты меняют движок. То что ты описал - это фантастика, ну или очень-очень поздняя стадия поддержки ммо, когда ее уже 3 раза перепродали и разработчиков нет вообще, есть только пара срипткидди в поддержке.
В документации годота прямым текстом написано, к кому обратиться чтобы получить порт на свищ. https://godotengine.org/qa/30450/proposal-for-nintendo-switch-support-for-godot
> 1. Ориентация на мобилки. Как следствие - полное отсутствие рендеров для полноценных платформ. Даже банального OpenGL нет, это же охуеть вообще! Не ждите, что ваша игра запустится на старом железе, даже если у вас там пара содомирующих кубов в коробке и больше ничего.
Почему компы слабее мобилок?
> 2. Проблемы с производительностью, отчасти и-за первого пункта, подозреваю. Пока ты делаешь прототипы и маленькие игры для себя на своей йоба-тачке, которая покрывает всё это стократным запасом скорости, этого не замечаешь. Но как только начинаешь
В большинстве игор есть меню настроек графики, где можно подобрать себе параметры по своему железу. Почему ты так не делаешь?
> 3. Опенсорс. От которого происходит целый ворох проблем, от мала до велика.
> Первая - забудьте о простом релизе на консолях.
Чтобы релизиться на консолях, нужно заплатить деньги за СДК. Затем свою игру надо адаптировать к СДК. В прошлых тредах была инфа, что есть фирма, которая всё это сделала и продаёт уже готовые шаблоны экспорта, по цене: стоимость СДК + маржа за свою работу.
> Вторая - баги, баги, баги
> "почини сам, это же опенсорс". Но с другой стороны, а зачем мне тогда движок использовать вообще, простите?
Потому что починить это бысрее, чем пилить свой велосипед. Впрочем
> самописный движок на SDL2
Раз у тебя уже есть свой велосипед, тебе проще, конечно.
В итоге, что я могу сказать. Разработай себе универсальный подход, при котором ты клепаешь быстрый прототип на годоте, получаешь краудфандинг, а затем резко перебрасываешь весь контент в аналогичный проект на юнити и заканчиваешь игру на нём.
Впрочем, если изучил шарп, и минимально ознакомился с юнити, то кроме неотключаемого сплеша, у него минусов нет. Я недавно озвучивал свои мысли вслух в юнититреде по данному вопросу. Он делает годот по всем пунктам. Скорость разработки - это твой личный импринтинг. Набросать сцену с ебущимися кубами в юнити ничуть не дольше,чем в годоте. При этом, каждый куб может на себе носить несколько скриптов. И вообще, принцип списка компонентов уделывает принцип дерева: пока годот в дереве рекурсивно ветви обходит, юнити уже быстро пролетел по одноранговому списку компонентов и выдал результат.
Увы и ах. Самые удобные человеку вещи оказываются самыми неудобными машине. Это удобно, когда ты бросил риджидбади, ему в потомки бросил спрайт и коллижншейп, но не менее удобно, когда ты бросил геймобджект, ему в компоненты бросил риджидбади, коллайдер и спрайтрендерер. Разница минимальна, а выигрыш в скорости заставляет задуматься.
В годоте ты вынужден следить, чтобы не подвигать мышкой ноду коллизии относительно родительской ноды тела, в юнити этой проблемы нет. Компонент коллизии просто не имеет координат, они ему не нужны, он не существует в памяти как полноценный геймобъект (у которого одного как раз координаты есть), он только задаёт форму коллизии своему хост-объекту. То же самое и о спрайте.
Нодеву-то виднее, конечно.
А вообще мне похуй. Я табличку возле разложенных граблей вывесил - и умываю руки. А наступать ли на них - ваше дело. Мне лично шишки набивать надоело.
Да вам и беспокоиться не о чём, впрочем, всё равно тут никто никогда до этих граблей не доберется.
>В большинстве игор есть меню настроек графики, где можно подобрать себе параметры по своему железу. Почему ты так не делаешь?
Объясни, как сделать это на Годоте. Алсо объясни, как исправить настройками графики низкую производительность скриптов и пайплана рендерера?
> как сделать это на Годоте
Делаешь новую сцену с корнем Control и делаешь меню. Значения берёшь из ProjectSettings, всякие там антиалиасы и прочее. Сюда же помещаешь настройки ЛОД, размеров текстур и т.п. Это очень большая работа, но если мы говорим о большом ерьёзном проекте, эту работу делать надо.
> как исправить настройками графики низкую производительность скриптов
Шарпом, крестами.
> и пайплана рендерера
Переходом на юнити, в котом вулкан есть уже сегодня и ждать не надо.
Да просто мне реально обидно, потому что во всём остальном-то движок действительно хороший, и мне вообще очень нравится.
Но блджад, вот пилил я на нём два года игру мечты, и, когда впереди забрезжил свет окончания работ, начал потихоньку готовиться к релизу, собрал демку, пошёл тестировать на парке машин, и внезапно понял, что релизить-то не получится. И это пиздец.
>Я это и имел в виду - когда игра технически закончена, всё дописано - и архитектура, и все модули, и интерфейс, и метагейм и т.д. Осталось только наполнение контентом - рисовать графику, строить уровни, скриптить врагов, режиссировать катсцены.
То есть в годоте муторно добавлять горы контента?
>Покажи
гифрелейтед
>>603877
>я покажу
показывай
Вообще-то я подразумевал код показать. То, что на гифке я бы делал через one way collision
https://godot.readthedocs.io/en/latest/classes/class_collisionshape2d.html?highlight=collisionshape2d#member-variables
А какое отношение имеет Dwarf Fortress к твоему проекту? Да и говорить про DF смешно, во-первых его давно обогнали всякие успешные rimworldы, во-вторых с точки зрения gamedev это полная противоположенность того что ты описал, в DF вообще считай нет графики уровней и моделек, а именно код там постоянно пишется.
>во-первых его давно обогнали всякие успешные rimworldы
Римворлд - бездушный выблев на юнити, в котором нет и 5% от фич и интерактивностей из dwarf fortress.
"Обогнать" df этот кал может только в фантазиях пикрилейтеда, видимо ты на него чем-то похож.
Графон уровня римворлд это скорее минус чем плюс, вырвиглазное ноу-скилл говно без анимаций. Уж лучше ascii арт, чем такой кал.
>А РимВорлд на юнити просто взяли и запилили, да еще и с графоном сразу, и давно продают за $35 баксов.
Просто взяли и запилили унылое говно, в попытках срубить бабла на фанах df, и это говно даже близко не стоит с оригиналом. То, что продают - молодцы, но это не делает игру лучше и глубже, чем df.
А если для тебя финансовый успех - единственный критерий для оценки игры, то можешь не переживать за df, их авторы вполне себе безбедно живут на донаты от фанов уже не первое десятилетие.
Могу накидать только некачественного, как делать нельзя.
Ну да, каша ещё та, но у df-щиков cвоя атмосфера, зря ты к нему доебался. О вкусах не спорят.
>>603979
Это читал?
https://docs.godotengine.org/ru/latest/tutorials/networking/high_level_multiplayer.html
Ты совершенно прав, мой юный друг.
Финансы - совершенно не единственный критерий успеха. На мой взгляд, главный критерий - сколько игроков играет.
Ну, прямых цифр нам никто конечно не выдаст. Но мы можем косвенно оценить по движухе вокруг.
Тем на реддите с нового года о RW - 24,156, df - 4,221 (в 5 раз меньше)
Постов о RW - 326,654, df - 68,857
Каналов на твитче о df - 3 штуки с 30 просмотрами, RW - 8 c 340 просмотрами, и так далее. Можно долго продолжать, но картина ясна.
И главное, мне все еще непонятно, зачем было приводить df как пример "игрового проекта".
>Godot
Пиздот, этих чмошников еще с борды не попёрли? Какого хуя, админы, куда вы смотрите? Ебать
Короче, разобрался. Спасибо огромное >>603986 что сказал, в какую сторону гуглить. Короче, вот:
Хост:
Хост в ready делает массив IP-адресов для трансляции:
for address in IP.get_local_addresses():
var parts = address.split('.')
if (parts.size()==4):
parts[3]='255'
var tempIP=parts.join('.')
if tempIP!="127.0.0.255":
IPs.push_back(tempIP)
Тут я исключил 127.0.0.1(255) потому что он вызывал какие-то проблемы (уже не помню какие)
Далее в process() хост создаёт PacketPeerUDP и отправляет пустой PoolByteArray - "data" поочерёдно на все свои IP-адреса, которые подготовил ранее. 4242 в данном случае - порт, но он может быть любым:
var udp= PacketPeerUDP.new()
for IP_ad in IPs:
udp.set_dest_address(IP_ad, 4242)
udp.put_packet(data)
Клиент:
Клиент ТОЧНО ТАК ЖЕ собирает массив всех своих IP адресов (на мобилках он обычно всего один, помимо 127.0.0.1) с 255 на конце в ready(). Тупо используйте тот же код.
И в process() клиент тоже создаёт себя как PacketPeerUDP и слушает по всем своим IP из массива отосланный пакет, при получении которого записывает IP хоста в переменную. 4242 - опять порт, может быть любым. 65536 - дефолтное значение размера буфера.
var client = PacketPeerUDP.new()
for IP_ad in IPs:
client.listen(4242,IP_ad,65536)
client.get_packet()
HostIP=client.get_packet_ip()
Ещё раз большое спасибо >>603986 за наводку.
> я исключил 127.0.0.1(255) потому что он вызывал какие-то проблемы (уже не помню какие)
Это же loopback интерфейс, который если попытаться перевести "петлевзадый". Он настолько локальный, что не выходит за границы компа (устройства). Следовательно, сети на нём быть не может. Кроме такого варианта, когда на 127.0.0.1 сидит программный прокси-сервер (антивирус обычно), который подглядывает в пакеты и затем их перенаправляет в нормальную сеть 192.168.255.255 или 10.255.255.255
А это во что можно превратить?
http://docs.godotengine.org/en/3.0/tutorials/3d/fps_tutorial/part_two.html скрипт animation player'а
func animation_ended(anim_name):
# UNARMED transitions
if current_state == "Idle_unarmed":
pass
# KNIFE transitions
elif current_state == "Knife_equip":
set_animation("Knife_idle")
elif current_state == "Knife_idle":
pass
elif current_state == "Knife_fire":
set_animation("Knife_idle")
elif current_state == "Knife_unequip":
set_animation("Idle_unarmed")
# PISTOL transitions
elif current_state == "Pistol_equip":
set_animation("Pistol_idle")
elif current_state == "Pistol_idle":
pass
elif current_state == "Pistol_fire":
set_animation("Pistol_idle")
elif current_state == "Pistol_unequip":
set_animation("Idle_unarmed")
elif current_state == "Pistol_reload":
set_animation("Pistol_idle")
# RIFLE transitions
elif current_state == "Rifle_equip":
set_animation("Rifle_idle")
elif current_state == "Rifle_idle":
pass;
elif current_state == "Rifle_fire":
set_animation("Rifle_idle")
elif current_state == "Rifle_unequip":
set_animation("Idle_unarmed")
elif current_state == "Rifle_reload":
set_animation("Rifle_idle")
Тут только меняются названия пушки, действия одинаковы euqip, unequip, idle, fire, reload везде.
3 оружия с пятком анимации еще можно так расписать, но с каждым новым добавлением код будет расти в геометрической прогрессии. А после добавления кучи пушек поменять какую то фигню будет муторно. И я хочу в своей игре кучу пушек и больше анимаций для них.
Впрочем, дам подсказку. В дополнение к коду этой функции (anim_transition) я бы создал файл json, в котором описал бы правила работы конченого аппарата конечного автомата переключения анимаций. Например:
[
{"anim_from" : "pistol_equip", "anim_to" : "pistol_idle"}
]
В дальнейшем я бы не трогая код, редактировал файл правил.
Заменил кашу с тутора на это.
var cur_s = current_state.split("_",false, 1)
if current_state == "Idle_unarmed":
pass
elif current_state == cur_s[0] + "_equip":
set_animation(cur_s[0] + "_idle")
elif current_state == cur_s[0] + "_idle":
pass
elif current_state == cur_s[0] + "_fire":
set_animation(cur_s[0] + "_idle")
elif current_state == cur_s[0] + "_alt_fire":
set_animation(cur_s[0] + "_idle")
elif current_state == cur_s[0] +"_unequip":
set_animation("Idle_unarmed")
По идее должно работать, но проверить смогу когда все доделаю.
var cur_s = current_state.split("_",false, 1)
if current_state == "Idle_unarmed":
pass
elif current_state == cur_s[0] + "_equip":
set_animation(cur_s[0] + "_idle")
elif current_state == cur_s[0] + "_idle":
pass
elif current_state == cur_s[0] + "_fire":
set_animation(cur_s[0] + "_idle")
elif current_state == cur_s[0] + "_alt_fire":
set_animation(cur_s[0] + "_idle")
elif current_state == cur_s[0] +"_unequip":
set_animation("Idle_unarmed")
Это я понял, но по какой-то причине, если в массиве вообще есть такой адрес - всё ломается к хуям и for-цикл тупо виснет на нём, не слушая ничего по другим, правильным адресам.
А может, это моя локальная проблема и её надо как-то иначе решить, но мне проще одну строчку для проверки добавить
Обновись до 3.1 и используй AnimationTree, Люк.
https://docs.godotengine.org/en/3.1/tutorials/animation/animation_tree.html
With AnimationPlayer, Godot has one of the most flexible animation systems that you can find in any game engine. The ability to animate pretty much any property in any node or resource, as well as having dedicated transform, bezier, function calling, audio and sub-animation tracks, is pretty much unique.
Найс самоотсос Хуана. Спиздили все из юнити.
Открываешь https://docs.unity3d.com/Manual/animeditor-AnimatingAGameObject.html
@
Ищешь по странице - "You can animate any property"
@
Сасаешь потный хуец Хуана
Тащемта, Хуан много чего пиздит из взрослых движков, новый animation tree почти один в один из анрила спизжен, только более кривой, глючный и с уёбищным интерфейсом, в отличие от анриловского.
> спизжен, только более кривой, глючный и с уёбищным интерфейсом
это обо всём хуановском можно сказать.
редактор материалов? васянка под юич.
анимируй свойства? васянка под юнети.
анимейшн три, ну ты уже сказал тут всё.
что там ещё, а, да, ECS который на самом деле не ECS, тоже с юнети спизжен, и конечно же криво, не даст вешать свои скрипты куда угодно, и вообще НИТО.
https://www.youtube.com/watch?v=Q41FQT6_LxQ
> реально на Годо создать нечто похожее на вот эту игрульку.
В теории - да. Но никто пока не смог этого сделать.
А учитывая
>опыта в разработке не имею
Скорее всего, ты не сможешь сделать даже один домик из этой игры в блендере, что уж говорить целиком об игре.
> Суб 04:52:07
Я в такое время сплю.
>>604378
Вполне реально.
Если ты новичок, начни с видосов Сканера
https://www.youtube.com/watch?v=1igO4n4vWoI&list=PLf0k8CBUad-uBels10n74EIGQ45natifs
>нет ни одной 3д игры?
>нет опенворлда
Там бесконечный рандомный мир. Чекни демку
>Хуан не простил годотерам их своеволия. Сурово наказал он их. Беспрерывно делают годотеры игры. Напрягая все силы, разрабатывают они их и, кажется, вот-вот уже сделают игру, но каждый раз годот обновляется и ломается проект. И опять приходится годотерам начинать все сначала. Люди узнали об этом, и с тех пор любую бессмысленную и бесконечную работу называют «годотов труд».
Что это за аутизм? Ты понимаешь, что ты поехавший? Нахуя ты это делаешь?
Какие-то игры для тех, кто тебя обоссывает, какие-то игры для борды из 15 человек. Ты совсем ебанутый? Выйди на улицу, друзей найди и для них хотя бы делай, раз ты такой аутист.
Спасибо за два подписчика дарагие фанаты
> а можно в годоте пиксельные коллизии замутить по битовым маскам?
https://www.youtube.com/watch?v=UZu8NwlkXcU
https://www.youtube.com/watch?v=FEiNBVVCq_A
Уже 100 раз обсосано, окклюжн куллинг в 2к19 никто не использует, потому что он не работает в современных условиях, он работал только в 2000-х в коридорных шутанах, где еще делали S-образные стыки между уровнями чтобы не видно было следующий кусок карты. В годоте будет репроекция глубины, которая на основе предыдущего кадра и сдвига камеры определяет по маске что осталось скрытым и не надо рисовать, это топовая технология для опенворлда и прочего.
Скажешь мне тоже самое на демодне(от слова день а не дно)
https://youtu.be/VsORkaq9MRo
>>603162
Сделал через группы, потому что хз как чистить списки.
Какие в группах есть способы выбора конкретного элемента?
>>603084
Сделал кулдаун через таймер, потому что стрельба в скрипте пушки одноразовая и этот илд исчезает, а помещать его в общий скрипт не хочу, вдруг весь инпут встанет.
Что не так с поворотом у камеры? Чтоб снаряды поворачивались по взгляду пришлось добавить
camera_rot.x *=-1
camera_rot.y += deg2rad(180)
Без этого поворот был в обратную сторону.
Я менял в инспекторе поворот, эффекта ноль. Камера смотрит по оси z, снаряд тоже.
> хз как чистить списки
>>603083
> В _процессе скрипт игрока чекает этот лист от последнего к первому (это важно!) и удаляет из списка те снаряды, которые уже не существуют.
for index in range(list.size()-1, 0): if !list[index]: list.remove(index)
>Вообще-то я подразумевал код показать.
Забей. Смысл был в том, что есть ли в годоте _встроенные_ средства для построения побитовых масок из спрайтов-объектов и возможность работы с ними. Если их нет, то написать на шарпе или плюсах я подобие своего движка я и сам смогу.
>>603908
>То, что на гифке я бы делал через one way collision
Это только частный случай. Там дофига других необходимых вещей есть, которые через полигоны жопошно определять. Ну и плюс это работать должно в разы быстрее чем через полигоны.
------
Но я собственно уже сделал пока свой костыль через Physics2DDirectSpaceState и массив лучей. Потом что-нибудь получше придумаю.
------
>Где об этом почитать? Я конкретно не понимаю, о чем ты.
Говорю же забей. Если не знаешь, что это, то оно тебе и не нужно.
Я честно говоря даже не знаю где-бы это нормально описывалось, так чтобы понятно было.
Если вкратце. То берешь спрайты из которых у тебя тайлмап строится и делаешь с них черно белую маску, обычно через альфу, но есть и другие способы. Со спрайта игрока так же делаешь такую-же маску, либо в большинстве случаев лепишь простой AABB и коллизии проверяются побитовым сравнением этих двух изображений или прямоугольника с маской. Если часть маски попадает в прямоугольник вот это и есть твоя коллизия.
Если реализовать механизм правильно, на низком уровне, то работать будет быстрее чем, через полигоны. Ну и всякие плюшки, вроде тотальной разрушаемости ландшафта (типа как в игре Worms), проще работа с кривыми поверхностями (конкретно кривыми), проще рабоать если нужно, чтобы игрок проходил внутрь поверхностей и т.д.
---------
>>604941
>Он хочет pixel perfect collisions, но ведь сейчас не 1980
К сожалению да.
>>604941
>это создаст игроку больше неудобств чем улучшений.
Игроку вообще похуй будет, он даже знать не будет, что и как у меня там реализовано будет.
Это не проблема механизма коллизий, это уже вопрос гейм- и левелдизайна. Можно и в полигонах нахреначить такого, что игрок охуеет.
Надо просто маску коллизий создавать не фактически со спрайтов, а как дублирующую подложку где заложены нужные для коллизий формы с обрезанной шелухой.
>Разрушаемость?
Была идея, но я уже забил.
>>605089
>Если у тебя обычный платформер то ты разницы с квадратными коллизиями не заметишь
Заметил. То что раньше делалось простой проверкой на глубину проникновения или расстояния до поверхности, приходится делать через жопный костыль с массивом рейкастов. Но это похоже косяк годота, т.к. в нем метод intersect shape в direct_space_state похоже вообще не рабоатает. По крайней мере мне не удалось его заставить, вообще хоть что-нибудь выдать.
> дешевле вычислений с плавающей точкой
Я вас умоляю, коллега. В век 8-ядерных штеудов заниматься байтоёбством? Ради чего? Ради кого? Ваш личный загон - уважаю, ничего не имею против. Битовые операции вложены в гдскрипт, дерзайте, велосипедьте. Но не советую требовать подобный функционал искаропки.
Не, ну так то он может и прав быть. Для того чтобы проверить AABB там вначале отработает несколько if-ов в ООП, чтобы узнать что у нас именно AABB а не произвольный многоугольник под произвольным углом, и математика действительно будет во флоатах, а не интах. А для пикселей не нужно перебирать все, можно сравнивать например целые байты, а то и слова, по and. А может и в опенгл есть какая-то функция, узнать о наложении уже постфактум после рисования? Правда, это может создать неудобства в логике (надо будет откатывать обратно если с чем то столкнулся)
Нет, для пиксельных коллизий тебе придется перебирать все не пустые пиксели по площади спрайта, получать мировые координаты этого пикселя, выбирать значения из массива-маски по этим координатам и сравнивать. Чем больше площадь спрайта, тем тормознее будут твои коллизии.
Для AABB тебе всегда нужно просто сравнить несколько чисел. float, byte, не имеет значения. Ты думаешь что современные долго считают флоаты? Для современных процессоров боттленеком является невозможность распаралеллить инструкции для пайплайна, и миссы кеша.
>для пиксельных коллизий тебе придется перебирать все не пустые пиксели по площади спрайта, получать мировые координаты этого пикселя, выбирать значения из массива-маски по этим координатам и сравнивать.
Нет, не придется, кто тебе внушил такую чушь? Работает это, например, так. У спрайта делается битовая маска, 00111100 и так далее. В 32битной архитектуре, соответственно, в регистре у нас сразу горизонтальный скан целого 32-пиксельного спрайта. Битовая карта мира, естественно, храниться в массиве, и координаты определяются один раз, а не на каждый пиксель - у тебя это аналог вычислений внутри цикла, которые надо делать один раз до цикла, а потом просто инкрементить на шаг. Так что, если говорить совсем упрощенно, то мы накладываем маску спрайта 01100... на уровень 1111000... и если and дает ненулевой результат, то есть пересечение. В реальности там чуть сложнее, потому что надо делать не одно сравнение, а два - учитывая сдвиг не кратный 32 битам, то есть примерно так
(spr << xShift) & levelMask[i-1]
(spr > (32-xShift)) & levelMask
Плюс там еще надо немного математики над , но тут мне вообще лень думать. Но я сразу сказал что я вообще против этого подхода.
Там была речь о том, что это быстрее обычной AABB проверки что-то уровня пикрелейтед.
>Нет. Но по логике даже пачка битовых AND будет дешевле вычислений с плавающей точкой.
>гондотитя
Какая разница, если ты разрабатываешь на движке, который находится на дне выгребной ямы по перформансу?
Ты хоть усрись, но все равно не получится сделать так, чтобы не тормозило, число draw call'ов будет расти пропорционально кол-ву спрайтов на экране и твой 2д платформер уровня марио будет грузить процессор и видеокарту как крузис.
>музыка
Добавь видосики через видеоплеер.
Делаешь его невидимым и с него читаешь текстуру одной строчкой и вешаешь видео на спрайты или 3д модели.
> число draw call'ов будет расти пропорционально кол-ву спрайтов на экране
Это только в том случае, если каждый спрайт будет создавать себе инстанс текстуры (что в редакторе годота делается по умолчанию). Мы это ещё в прошлом треде разобрали. Просто берёшь и вешаешь на одинаковые спрайты ссылку на один инстанс текстуры. Затем берёшь и слепляешь все текстуры в одну текстуру-атлас, загружаешь один её инстанс, затем спрайтам назначаешь его и указываешь координаты кусочка текстуры, который нужен. Это дольше, запарнее, но будет тебе перфоманц.
У меня для всех пушек будет схема переключения анимаций как на пике. Эту схему можно будет сделать универсальной как тут >>604225 ?
> Добавь видосики через видеоплеер.
Как-то так?
>если ты разрабатываешь на движке, который
>число draw call'ов будет расти пропорционально кол-ву спрайтов на экране и твой 2д платформер уровня марио будет грузить процессор и видеокарту как крузис
Кстати, поправьте если не прав, но по-моему единственный способ сделать чтобы число draw call'ов не зависело от кол-ва спрайтов это использовать буфер-текстуры (ARB_texture_buffer_object, это минимум OpenGL 3.1) вместо полновесных обычных, что для 2D в принципе может прокатывать ибо там без мипмаппинга и фильтрации можно обойтись в отличии от перспективного 3D. Интересно, какие-нибудь из популярных 2D движков их юзают?
А при простом спрайт-батчинге-то draw call'ы тоже растут пропорционально, просто с меньшим коэффициентом.
>А при простом спрайт-батчинге-то draw call'ы тоже растут пропорционально
Нет. При спрайт батчинге у тебя будет один меш, в котором все координаты спрайтов. И один дров колл. А на видяхе уже на ее 1000+ ядрах все квады нарисуются параллельно.
Погоди, разве я тебе уже не рассказывал все это в прошлом треде?
Анон, а ты уже задонатил, чтобы еще одному Хуановскому дармоеду не нужно было работать?
https://twitter.com/godotengine/status/1165949802175225860
Пускай Субботу Звонких Голосов в шоукейс добавят а там и посмотрим...
Раньше я немного работал в гамаке, там тоже скрипт - гмл. Прокатило
Суть токова: в годоте компонент emission не излучает свет. Сэд бат тру. Пришлось велосипедить. Позади квада с эмиссией установлен SpotLight, в _process я хочу вычислить средний цвет текстуры и сделать его цветом светильника. Как я только не делал, вот пикрелейтед вариант кода, а видеорилейтед вариант хуиты, которая получается. Слишком дёрганный свет получается, как будто свеча горит на ветру.
сначала я брал матрицу източек текстуры с шагом 10 пикселей, потом я стал брать из центра. Добавлял десатурацию. Пробовал задавать разные шаги интерполяции в зависимости от яркости. Ни-ху-я.
Вообще, можете на пальцах объяснить, что у меня не так?
>но можно сходу пример 3д игры на этом движке, выпущенной
продаваемой пока нет, но есть про твою мамку
https://www.youtube.com/watch?v=pXctms1b82g
Берешь N пикселей с картинки (твоя сетка подойдёт)
суммируешь R G B каждого из них
Потом делишь на N (количество пикселей) вот тебе и типа примерно средний цвет
Чтобы резко не моргал только его и интерполируешь с прошлым значением.
Один draw call - это один вызов функции отрисовки, glDrawArrays или её производных.
Чтобы был один дравколл для спрайт батча - нужно ручками собрать вертексы всех рисуемых спрайтов в один vbo и отрисовать их за один вызов функции отрисовки.
Для текстур при этом есть несколько вариантов. Можно собирать все спрайты в одну мега-текстуру, и конвертировать локальные текстурные координаты в глобальные. Можно создать массив текстур, GL_TEXTURE_2D_ARRAY, это что-то типа стопки отдельных текстур, наложенных друг на друга, таким образом можно передать в шейдер хоть сто текстур и использовать их в рамках одного драв колла, выбирать нужную в шейдере. Есть еще 3д текстуры, можно так же билдить текстурный куб из спрайтов и использовать в качестве текстурных координат не 2д вектор, а 3д.
>Интересно, какие-нибудь из популярных 2D движков их юзают?
Спрайт батчи есть почти в любом движке, на котором делают коммерческие 2д игры. XNA/monogame, libgdx, cocos, юпити.
Кроме гондотитя, естественно, Хуан не понимает, зачем это нужно, он загружает один спрайт на сцену и у него всё летает, значит и так сойдет.
Если интересны детали реализации - посмотри исходники monogame какого-нибудь, там опенсорс.
>>605695
Попробовал ещё раз. Получается так же, по моему даже сильнее моргать начало.
>Можно собирать все спрайты в одну мега-текстуру
Но у обычной 2D текстуры сильные ограничения на размер. Поэтому я и заговорил о texture_buffer_object, который ограничен по сути только памятью видюхи.
>Можно создать массив текстур, GL_TEXTURE_2D_ARRAY, это что-то типа стопки отдельных текстур, наложенных друг на друга, таким образом можно передать в шейдер хоть сто текстур и использовать их в рамках одного драв колла, выбирать нужную в шейдере.
>>по-моему единственный способ сделать чтобы число draw call'ов не зависело...
А, значит я был неправ, он не единственный. Спасибо за инфу, про такой вариант буду тоже знать.
>>Интересно, какие-нибудь из популярных 2D движков их юзают?
>Спрайт батчи есть почти в любом движке
Я не в общем про спрайт батчи спрашивал, а про мега текстуру реализуемую в виде texture_buffer_object. В tbo просто нету мипмапов и фильтрации. Хотя если цель -- тупо блитить из текстуры на экран, то они и не нужны.
Донаты с патреона. Сейчас хотят нанять еще одного программиста, надо еще тысячу в месяц дотянуть.
https://www.reddit.com/r/gamedev/comments/cvsq6a/godot_is_within_1000_on_patreon_of_being_able_to/
Анон, у меня встал вопрос.
Есть сцена, на ней есть Label в котором bitmap font'ом пишется какой-нибудь текст.
Можно ли сделать так, чтобы на эту Label не влиял размер окна и текст в ней всегда был в масштабе 1:1 ? Т.е. к примеру, если у меня базовое разрешение игры 320х240, а игра запускается в окне x4 (1280x960), то чтобы текст в этом Label рендерился, без учета масштаба
Вобщем вот так сделал, результат меня устраивает.
>>605762
Сначала: var arr : PoolColorArray
Потом: for x in range(0, pict.w, 10): for y in range(0, pict.h, 10): arr.append(get_pixel(x,y))
Затем: for pix in arr:
- sum_red += pix.r
- sum_gre += pix.g
- sum_blu += pix.b
И в конце:
final_color = Color(sum_red / arr.size(), sum_gre / arr.size(), sum_blu / arr.size())
Получается чорный
>>605707
Нахуя вы там пиксели руками суммируете в гондотитя-скрипте, вы ебнулись? Да еще и каждый фрейм, как я понял.
Просто делай ресайз твоей пикчи с билинейной фильтрацией в размер 1x1, он автоматом даст тебе среднее значение. И работать будет побыстрее, потому что в реализации ресайза перебор пикселей будет на плюсах реализован, а не тормозном гондотитя-скрипте.
http://docs.godotengine.org/en/3.0/classes/class_image.html#class-image-resize
Самое быстрое будет, скорее всего, влезть в исходники кодека и там найти какое-то значение по блоку еще до того, как его распаковали, ведь суммируя пиксели ты по сути выполняешь двойную работу.
Цвет отресайзенной пикчи явно не соответствует. И продолжает бешенно мерцать, как на видосах выше.
Чтобы не мерцало, меняй цвет не каждый фрейм, а раз в 0.2 секунды задавай desiredColor, цвет, к которому стремится текущий, а actualColor (который назначается источнику света) высчитывай через линейную интерполяцию - actualColor = lerp(actualColor, desiredColor, deltaTime).
Тогда меняться будет плавно.
А насчет цвета, хз что еще посоветовать, по идее можно определять доминантный цвет через алгоритм типа такого - https://github.com/BlueCocoa/mashiro, но это придется спускаться на уровень плюсов, на гондотитяскрипте попиксельные вычисления не лучшая идея. Хотя, если делать их не каждый фрейм, в раз в 0.2 секунды или даже секунду - то в принципе можно попробовать.
Когда в годоте будет нормальный импорт мешей? Импортирую .obj - материалов нет, импортирую .dae - материалы есть, но сам меш виден как сцена. Можно ли как-то обойтись без этого пердоллинга?
Пытаюсь сделать шейдер, задаю команду:
vec4 color = textureLod(SCREEN_TEXTURE, SCREEN_UV);
получаю в ответ:
Unknown identifier in expression: SCREEN_TEXTURE
-------
Что не так, это ж вроде встроенная текстура, не? Может там где галку какую чекнуть надо в настройках?
> Видео-то хоть с ютубчика стримишь, или
А что, надо было с ютубчика стримить???
Швабодный вижок понимает только швабодный формат. Сконвертил в вебм, но там чот видеопоток не выводится. ХЗ, ЧЯДНТ.
В той же теме где ты видел есть ссылка на https://github.com/Superwaitsum/GDSercomm
Удачной компеляции конечно.
Капец чел спасибо, чёб я без тебя делал. Документацию писал пидор, хрен найдешь этот метод не зная конкретного названия.
> Как мне привязать его закрытие к кнопке?
Есть ли какие-нибудь гайды по особенностям разработки в GODOT (и не только) под андроид и под веб? Какие отличия от разработки под win? Что можно и что нельзя делать? Какие разрешения и аспекты исползовать?
------
А то вот сделал я допустим прототип. Под виндой запускаю все нормально играет. Экспортирую в html вроде бы играет, но на половине браузеров шейдерную воду не показывает. Экспортирую в андроид, играет, но наэкранное управление начинает туда сюда скакать (хотя в веб версии на том же андроидном браузере рабоатет нормально).
Не могу тебе помочь, т.к. я пилю игоры только под пека. В качестве поддержки вот тебе няша.
Я, короче, решил окончательно, что буду пилить свой Ундертейл с блекджеком и шлюхами в Годоте, а не GMSе. Воть.
Да не, игра никоим образом не будет связана с Подхвостом (возможно, позаимствую кривожопый стиль рисовки и расположение юнитов на поле боя, как в Дельтаруне), просто именно она вдохновила меня на то, что в одно жало можно сбацать что-то охуенно цепляющее (хотя я и до нее переиграл в десятки индюшни, смастеряченных в одиночку) на готовом двигле.
> сбацать что-то охуенно цепляющее
Сможешь прямо сейчас выдумать короткую, но цепляющую историю? Что-то вроде "каждую ночь мне снится тяночка моей мечты, она милая и приятная. Мы занимаемся вместе кучей интересных вещей (и сексом тоже, разумеется). Мы ходим в походы. Вместе делаем игоры. Катаемся на байке. Иногда занимаемся простыми домашними делами, уборкой или стиркой. но всегда это все весело, хорошо и с любовью.
А потом я просыпаюсь одинокий и больной лысый карлан, и кашляю в своей засаленной постели.
..., и приступил к своему привычному утреннему ритуалу. Как всегда я первым делом вытащил из потайного кармана в рукаве своей мантии позолоченную подзорную трубу, некогда украденную у своего наставника. Старый хрыч поначалу справедливо подозревал меня в воровстве, но так и не смог доказать моей вины, поскольку эта тончайшей работы вещица словно влитая поместилась в моей прямой кишке, куда я ее спрятал на время повального обыска моей скромной обители. Сейчас же это искусное творение гномьих рук наведено линзой на окно четвертого этажа Солнечной Башни, где с минуты на минуты должен появиться объект моей неуемной похоти. Правая рука привычно потянулась к промежности, потирая вовсю набухающий бугорок...
Итак, тест.
Дано, типичное для мариво-игр:
-Сколлящийся задник
-Пара надписей
-Спрайты, летающих по синусоидам
-Анимация по 4 кадра
Конфиг: некропека 2007 года (e8500, 4GB, gtx260 <1GB)
Пик1: gd script, 850 спрайтов@60fps
Пик2: gd script, 1900 спрайтов@30fps
Сказки про перегрев идут нафиг. В годоте 53°C, в простое у меня обычно 51°C.
Это не 95°C, как в некоторых карточных играх на юнити
Пик3: cpp, 1900 спрайтов@30fps
BREAKING NEWS: на моем компе в данном тесте С++ НЕ ДАЛ УСКОРЕНИЯ.
Неожиданный эффект: Хром, запущеный в фоне, -5 FPS.
Пик4: веб версия. 700 спрайтов@30fps
в вебе переключение gdscript/cpp неактуально, поскольку все равно все транспилировано в js.
Веб версия - https://govdot.herokuapp.com
Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
На каждый сцену со скриптом.
То есть вообще ноль оптимизации, железо 10-летней давности, 2000 спрайтов на комфортном fps, этого за глаза для типичных инди-игр.
А если это все еще оптимизировать, то и уровень факторио наверняка достижим.
Да, так можно задушить процентов 15.
>BREAKING NEWS: на моем компе в данном тесте С++ НЕ ДАЛ УСКОРЕНИЯ.
Почему breaking? Вроде любому очевидно, что если спавнить ноды из с++, то на графический пайплайн это не повлияет и отрисовка будет по прежнему работать по-Хуановски.
>Пик2: gd script, 1900 спрайтов@30fps
Такое себе, ты доказал, что на гондоте невозможно сделать игру уровня террарии, в ней на full hd экране будет одних тайлов около 8к, не учитывая персонажей и окружение.
> Почему breaking?
Потому что каждая нода выполняет свои рассчеты даижения по синусоиде
> Такое себе, ты доказал, что на гондоте невозможно сделать игру
А вот и ничего подобного, я показал что на железе 10-летней давности, замечательно все работает вообще без всяких оптимизаций.
Террария это другой жанр, в ней никто не будет делать каждый тайл независимо анимируемым спрайтом в своей фазе и частоте, там будет тайлмап, у которого анимируется текстура целиком, то есть все тайлы огня меняются синхронно. Может быть вообще кастомный шейдер. Я привел только отправную точку, откуда можно ускорять минимум в 5 раз.
Разбиваться-то они может и разбиваются, но отрисовываются они через спрайт батчинг, одним draw call'ом.
Эта фича есть и в xna, на котором изначально пилили террарию, и в юнити. А в годоте нет, тут хоть разбивай, хоть не разбивай, каждый тайл будет отдельно рисоваться. Ты ничего не наоптимизируешь в итоге, упрешься в рендер.
>>606919
Это еще медленнее будет, тут уже отрисовка упрется в процессор, получится 2д рендер без аппаратного ускорения.
>>606918
>откуда можно ускорять минимум в 5 раз.
А что не в 10?
>Может быть вообще кастомный шейдер
Хуйня без задач в плане оптимизации, если нет возможности задать свой формат пикселей и описать свой пайплайн.
>там будет тайлмап
Насколько помню, тайлмапы в гондоти только статические и не подходят под разрушаемый мир, поправь меня если неправ.
Ну все, тебя уже понесло, конечно любая ячейка тайла редактируется, и непонятно с чего ты решил что тайлмапу нужен спрайтбатчинг, спрайт батчинг это объединение независимых отдельных спрайтов в дроуколл, кто тебе сказал что цельный тайлмап не идет одним дроуколлом сразу? Короче выдумал новой хуйни, ну ничего и на нее тест напишем.
> ну ничего и на нее тест напишем
Этого он и добивается уже второй тред подряд, чтобы аноны доказывали ему, что они не верблюды, писали тесты с бенчмарками, вместо того чтобы делать игры. В итоге на юнити куча игор от анонов, а на годоте куча тестов и срачей.
Неужели так сложно игнорировать и репортить срущего юнитуха?
Так тестики и не для него, а для анонов, которые не делают игры на годоте, потому что наслушались всякого вранья, будто годот не подходит для 2д, или не подходит для некропека, или греет видяху. А тут бац - и ссылочка на тестик, второй раз его делать не нужно.
>В шапке будет ссылка со словом govdot
Моя работа здесь завершена.
... входит в тред бариста!
Тогда тебе помогут сигналы с биндингами.
Хуан сделал гениальную вещь: к любому сигналу можно дополнительно прикрутить любое количество переменных. Например, есть сигнал hide, мы его коннектим так connect("hide", self, "on_hide"). Сам сигнал объявлен без аргументов, поэтому функция on_hide должна быть также без аргументов. И тут появляются биндинги! Пишешь: button.connect("pressed", self, "on_pressed", [menu_frame]) где меню_фрейм это и есть то окно, которое ты планируешь закрывать. Далее, описываешь функцию-обработчик уже с параметром: func on_pressed(frame): frame.queue_free()
Таким нехитрым образом ты можешь на одну кнопку повесить универсальный обработчик, обрабатывающий разные объекты. В момент излучения сигнала в обработчик передаётся разный бинд.
Если у нас сигнал с параметром, то биндинги добавляются в конец:
connect("signal_with_param", self, "on_swp", [bind1, bind2])
func on_swp(param, bind1, bind2)
У меня случилось это https://github.com/godotengine/godot/issues/13163
Причём, по ссылке ЭТО случается в открытом проекте, при совершении некоторых действий. У меня же ЭТО происходит сразу при запуске.
Я уже неделю гуглю, и ничего.
Некоторое время меня спасала моно-версия, я там редактировал свой проект не пользуясь шарпом. Но для моно нет шаблона экспорта в хтмл5, если я правильно понял.
В общем, жизнь боль, чот приуныл, посаны.
Не унывай, анон! Решим твою проблему. Но не сразу.
>floor_normal is the up direction, used to determine what is a wall and what is a floor or a ceiling. If set to the default value of Vector2(0, 0), everything is considered a wall. This is useful for topdown games.
>на туториал-видосе чувак ставит floor_normal=Vector2(0, -1), чтобы фигурка прыгала, отрываясь от палки под собой
Я тупой и нихуя не понял. В интернете текстового пояснения не увидел. Как это работает, памахите?
Немного годноты про сигналы. В этом выпуске: Синглтон для сигналов. Сигналы с биндингами.
https://www.youtube.com/watch?v=S6PbC4Vqim4
Тебя же предупреждали, что годот написан дилетантами и состоит из багов чуть более, чем полностью. Нахуй ты в него полез?
Более того, от этой хуйни не застрахован и билд твоей игры, потому что билд игры и редактор это в целом одинаковые приложения на рантайме годота. Так что если каким-то чудом ты релизнешься со своей гондотной игрой в стим, вполне можешь увидеть в отзывах, что у 50% игроков она просто рандомно крашится при запуске или в процессе игры, и ты ничего не сможешь с этим поделать. Даунята с двача посоветуют тебе пересобрать движок из исходников, веря, что это магическим образом устранит баги из кода, а Хуан ехидно улыбнется, снимет с карточки очередные 12к долларов донатов и поедет отдыхать на море.
>>607675
Ну да, с 2017 не пофиксили, но скоро всё будет, не сомневайся.
Боюсь, что года до 2030 Хуан будет переписывать по кругу рендеры, скоро вот допилит вулкан, поймет, что написал хуйню, а донаты нужны, вспомнит про bgfx, еще пару лет будет на него переписывать. А потом опять на opengl, потому что bgfx хуйня. А там глядишь и новое графическое апи выпустят.
Вот интересно, ты все так кукарекаешь с дивана о том, что ни разу в своей жизни не пробовал сделать? Или только когда речь касается сборки годота с .net?
Потому что если бы ты попробовал написать хоть один скрипт на C# без sdk, ты бы увидел, что билд просто крашится. А в комплекте с годотом идет только рантайм, сдк надо ставить самому.
>Даунята с двача посоветуют тебе пересобрать движок из исходников, веря, что это магическим образом устранит баги из кода
Анон, тут нет никакой магии. Просто у него линукс, а это такой зоопарк, что проще собрать самому и узнать чего не хватает, чем выяснять что там у него отличается.
Как пересборка из исходников поможет тебе выяснить чего не хватает и что отличается?
Ну пересобрал ты, ту же версию, запустил, там точно тот же краш. Потому что ты собрал точно тот же код с теми же багами. Ничего не изменилось. Пересборка внезапно не выведет тебе окошко с сообщением "ебать, да у тебя тут Х не хватает в системе". Она не поправит баг в коде. Будет точно тот же краш с тем же сообщением об ошибке.
Сейчас бы собирать мастер для работы над игрой. Он же нестабильный, там еще больше крашей и косяков. Туда сливают пулл-реквесты Васянов и потом разгребают баги.
>>607981
Это так не работает, из-за косяков с линковкой программа бы в принципе не запустилась. Если она запускается и крашится уже в рантайме, это баг рантайма, кода самого движка.
>Он же нестабильный, там еще больше крашей и косяков.
Постоянно собираю, никаких крешей и косяков, наоборот одни фиксы.
Понимаешь, мы же не знаем вообще откуда тот линуксоид скачал годот - из стима ли, с сайта ли, из какого нибудь репозитория пакетменеджером, какая там версия, какие зависимости.
> там написано kernel sigreturn, это ошибка ядра линукса
Во, шарящий чувак! Погоди, постой!
Короче, у меня дебиан, недавно обновился на 10й, когда 9й из стейбла в олдстейбл перешёл.
Годот скачан с официального сайта.
Архитектура 32х разрядная.
Далее вот какая хуйня произошла: у меня все бинарники годота лежат на сетевом диске, подключаемом (монтируемом) вручную через самбу. Я ж говорю, колясочник я. Через фстаб не удалось настроить монтирование. Каждый раз ручками ввожу пароль от сетевых дисков.
И в тот раз я по запарке забыл подключить диски и запустил ярлык. Ничего не произошло. На экране. Но внутри дебиана, я полагаю хрустнуло колесо моей инвалидной коляски. Ну я запустил скрипт, ввёл пароль, диски подключились. Но годот запускаться перестал. Выдаёт пикрелейтед. Первой мыслью было перенести бинарник годота в \home и запустить оттуда. Но нихуя. Инвалидная коляска уже сломалась.
Щас у меня есть мысль, что надо какой-нибудь кэш где-нибудь почистить. Но ничего подобного не гуглится.
> никаких крешей и косяков, наоборот одни фиксы
Сможешь навскидку сказать, что пофикшено, по сравнению с 3.1.1?
И ещё, ответь плиз, собирал ли ты кастомные шаблоны экспорта с вырезанными неиспользуемыми модулями? Я, например, хочу собрать кастомный шаблон экспорта, в котором вырезана вся физика, всё тридэ, вырезано двадэ от Node2D оставлено только то, которое от Control, на котором, собственно и сделан весь проект.
Хотя я почитал https://github.com/godotengine/godot/issues/27094
И вот что я скажу, лучше изобрести свой велосипед. ТОчнее взять готовый сделанный правильно, а не через остаток от инта.
>Потому что если бы ты попробовал написать хоть один скрипт на C# без sdk, ты бы увидел, что билд просто крашится. А в комплекте с годотом идет только рантайм, сдк надо ставить самому.
Написал несколько тысяч строчек кода. Ничего не крашится. Сдк не стоит, стоит только MsBuild. Где твой бог теперь?
>>607932
Признаю, не учел линуксоводов с маководами. Им и правда скорее всего нужен MonoSDK. Пользователи же самой популярной ОС просто ставят MsBuild, а не засирают свой пк кучей ненужной хуйни ради утилиты, которая идет в комплекте.
А сам велосипед чё не заскринил?
Пришлось нагуглить и перевести из шарпа с джавой:
https://gamedev.stackexchange.com/questions/162976/how-do-i-create-a-weighted-collection-and-then-pick-a-random-element-from-it
А теперь то же самое для питонщика с утиной функцией:
Блять, быстрофикс, пока никто не видит!
А хули там показывать, велосипед как велосипед
В целом, норм, хотя я для понятности кода, делал бы через словарь ключ-значение:
var common_chest = { items = ["хуй", "пизда", "джигурда"], chances = [3, 3, 4] }
и далее
choice = Choices.choices(common_chest.items, common_chest.chances)
Но это если бы я был питонщиком с синдромом блаба. Так-то вижу, что данная функция неудобна. Лучше сразу передавать в "мешок" подготовленный словарь с элементами ключ-значение. Потому что эти элементы не я ручками буду подавать, а сама игра будет формировать элементы. Причем не сразу, а в зависимости от состояния игры списки лута будут дополняться или урезаться игровой логикой. Хранить ключи отдельно от элементов в двух разных массивах это - НУ ТАКОЕ.
Поэтому мой велосипед работал бы либо как там >>608348 либо как-то так:
var common_chest = [ {item = "хуй", chance = 3}, {item = "пизда", chance = 3}, {item = "джигурда", chance = 4} ]
и далее
choice = MyRandomSubclass.get_item_from(common_chest)
При этом в реальной игре common_chest получал бы актуальный список элементов у синглтона игровой логики приблизительно так: var common_chest = Game.get_actual_items_list_for(CHESTS_COMMON)
Создавать рандомгенератор как объект (RandomNumberGenerator.new()). И у него будет метод randfn()
https://docs.godotengine.org/en/3.1/classes/class_randomnumbergenerator.html#class-randomnumbergenerator-method-randfn
Почему копрокуб не двигается при нажатии на кнопку? Вроде всё правильно сделал
Ну так ты в переменную при нажатии выставляешь "ускорение", на которое потом сдвигаешь. А при отпускании ты его не обнуляешь. Переменная глобальная же (в рамках файла). Может тебе ее в функцию перенести?
И вообще, пройди туториал или почитай в прошлом-позапрошлом треде, как делать управление.
Не получится.
В юнити можно к одному объекту прикрепить несколько скриптов. Кроме того, игровой объект содержит в себе только трансформ и ещё парочку базовых предметных вещей. Весь остальной функционал вешается на один игровой объект компонентами, скрипты тоже вешаются, как компоненты.
В годоте же есть куча разнородных потомков общего объекта с намертво прибитым функционалом. И к каждому такому можно привесить только один скрипт, прибитый гвоздем к типу ноды (я имею введу директиву extends).
В юнити доступ к функционалу через бинарный поиск шаблона<компонента>.
В годоте доступ к функционалу через "строковые/мать/его/пути".
При всём уважении к гению и отваге Хуана. Он создал мертворожденное тормозное говно, которое by design не сможет быть оптимизированно и догнать по скорости хотя бы жидовский юнити, не говоря уже о таких мастодонтах, как УЕЧ или плачдвижок.
Sad but true. Deal with it.
var sprite = Sprite.new()
var texture = StreamTexture.new()
texture.load_path = "path/to/stex/file" # вот тут тормознёт опять
sprite.texture = texture
self.add_child(sprite)
Тебя никто не заставляет обращаться в годоте по строке, делай getNode() кешируй результат в переменной и все.
>>608902
Хз причем тут дженерикс, это просто синтаксический сахар, если у тебя мешок компонент типа TA, TA, TB, TA, TC, TB, TA, TA, вызов getcomponent<TA> никак тебе волшебным образом поиск не ускорит.
Петя Сканер добрался до Марио
https://www.youtube.com/watch?v=H2a4lgV7CuY
> Вот все летает на старом компе
На моём амуде фх-4200 тормозит. Там, где у тебя 30, у меня 15 ФПС.
Спасибо, забрал на будущее.
Я сам пока вот этого товарища смотрю, пока понятно объясняет:
https://www.youtube.com/watch?v=wETY5_9kFtA
https://www.youtube.com/watch?v=rFAyFeqYPFM
Сделай отдельно какую-нибудь "точку взгляда" перед мордой игрока и по движению мыши поворачивай ее, а не камеру. А камерой просто догоняй эту точку с ускорением/замедлением (в зависимости от расстояния между "точкой взгляда" и "точкой камеры")
(то что в кавычках примерные названия, я х.з. как это правильно по научному называется)
Я не сторонник mouse filtering'a в FPS. Он больше подходит неспешному кинцу для плоек. Но оно существует:
https://hardforum.com/threads/what-exactly-does-mouse-filter-do.1387030/
А вот и нет, в других играх всё нормально (даже проверил на двух мышках).
На том видео плохо видно, но дело в том, что по оси "x" в центре поворот происходит медленее, чем ближе к -90 и 90 градусам, там поворот идёт быстрее. Это как камеру в редакторе в локальном пространстве по "x" поворачивать, такой же эффект происходит. Не знаю как такой эффект объяснить, может я наркоман уже.
https://pastebin.com/0KFHw6yn
код с годот доков, только кнопки и clamp камеры под проект изменил. Моя реализация fps управления была похожей, но там нечего смотреть, такая-же проблема была. Вот и думаю, может в самом проекте что-то.
Не использовать move_and_slide, а делать что то свое? Такое возможно?
На видео код с примера FPS, который в доках.
Алсо, прыжок во время вот этой вибрации не работает... Очень неприятный на управление персонаж получается ;-;
Колижены на Source мои любимые...
>У одного тебя, бедненький, не работает. Ну так возвращайся на свой сорс, хули ты в треде срёшь, мразина?
Что я сру, мразина? Я просто задал вопрос, почему у меня поворот камеры кривой, скинул код и сидел думал. Я решил этот вопрос, меш игрока кривой оказался.
И зачем ты смешал меня с двумя анонами, я вообще тот анон (>>609210), который примеры моей (а не движка) проблемы с годота скинул, сравнив с тем, как это должно быть (на сурс вообще похуй, самая левая игра, которая скачана была).
Пиздец, короче, ёбаный.
> Качай с opengameart
Там ничего стоящего нет, одни заманухи от платных артистов.
> делай 3д лоуполи
Вот это поддерживаю.
>>609868
Анон, лепи игоры из кубов! Представь себе: говорящие кубы!
Сделойте мне игру, экшон-эрпогэ, суть токова: Можно играть кубами, а можно играть шарами. И если играешь кубом, то грани параллельные, кругом плоскости и ты олзаешь по ним. А если играешь шаром, то можно кататься туда-сюда. Диалоги со скиллчеками - конусам в диалогах доступно угрожать другим фигурам, что посадят на остриё. Прокачка. Можно родиться кубом и постепенно прокачаться до цилиндра или до тора. И если поверхность повредят, то катаешься вприпрыжку. Визуально в игре три зоны: плоскость с простыми фигурами. Рубленная поверхность для округлых, там в центре есть старый чертёж, в котором сидит злой додекаэдр. И графон такой, чтобы фигуры вдалеке двадэ, а когда приближаешься в тридэ.
Можно грабить матеманы.
Ньюфаг Вкатился в годот из кастрата. Сейчас постигаю туториалы по простейшим играм и ГДС. Объясните пожалуйста, грубо говоря, вот допустим различные ноды выражают моего гг - его куклу и анимации, его коллизии, его платформерный объект который движется - так вот, всякие моменты вроде запрета контроля если мы получаем урон, через переменные - пишутся в одном скрипте? То есть - управление анимации, управление инпутом, и т.д. или все группируется и выглядит как несколько нодов?
А мужики то и не знали, знай себе делают приложения для навигации да калькуляторы.
> Привет, подстилки)
Здравствуйте, Господин!
> всякие моменты вроде запрета контроля если мы получаем урон, через переменные - пишутся в одном скрипте? То есть - управление анимации, управление инпутом, и т.д. или все группируется и выглядит как несколько нодов?
Есть несколько способов, каждый из которых является применимым/допустимым. Выбирай в зависимости от твоего стиля кодинга и личного удобства для себя.
>>609909
> инклюд нод используют для того чтобы объединить 2 скрипта и они оба выполнялись для объекта?
Не только. Не совсем. Ноды вкладывают в ноды для достижения комбинированного эффекта (например, нода коллизии должна быть вложена в ноду физического тела, чтобы задать ему форму).
Объединять скрипты можно несколькими способами. Самый привычный это var script = load("/path/to/script.gd").new() но опять же есть еще пара способов, в зависимости от твоих предпочтений.
> Какой аналог в годоте условия every x seconds?
Есть несколько способов... Эммм... ну ты понел. Есть ноды-таймеры, которую ты можешь добавить в свой объект-сцену и сделать, чтобы он срабатывал эвери Х секундс. Есть корутины, есть сцентритаймер, работающий на корутинах. Можешь создать кастомный счётчик в коллбэке главного цикла (_process()), можешь создавать таймер кодом, чтобы не ебаться с нодами (в рантайме всё равно он будет как нода в дереве, но то уже мелочи).
>>609914
> Примеры приложух?
Один из годотеров пилит приложуху "конструктор диалогов" и иногда постит скрины. Можешь поискать в тредах. Сейчас что-то он затих. Наверное ниасилил.
>>609929
Талант это 5% предрасположенности и 95% титанического труда (с)
>>609984
О да, ИТТ тоже калькулятор постили.
> Один из годотеров пилит приложуху "конструктор диалогов"
тоже какое-то время назад запилил чисто для себя подобное, вот только из-за того что подобного говна много, но все они работают через хуй пойми что и имеют слабую документацию
скажите, что сделал очередной велосипед, но я на нем хотя бы катаюсь теперь
Держу в курсе - проапгрейдил видяху на 750ti (б/у с али, как известно топ за свои деньги, минимальная видюха для современных игр).
Итого результаты для конфига (e8500, 4GB, 750ti 2GB)
gd script, 985 спрайтов@60fps
gd script, 1980 спрайтов@30fps
cpp, 1000 спрайтов@60fps
cpp, 2075 спрайтов@30fps
Заметил странную штуку, иногда при добавлении пачки в 500 спрайтов fps просаживается и не восстанавливается, а если добавлять по 5 штук, то может тянуть и большее количество без просадок.
>>610321
Коллеги, напоминаю, что это пример умышленно неоптимизированного кода, который просто накидали и работает. Причем он работает в окне (не фулскрин), с аэро прозрачностью, каждый спрайт тут это сцена. И если под террарию в любом случае придется писать свой движок или оптимизировать готовый, то для нормальных инди игр типа Hollow Knight или Braid этого движка хватит за глаза. Будем честны с собой, террарию вы никогда не сделаете. А найти пример игры, которую нельзя сделать, можно для любого движка, это не так сложно, лол.
>Hollow Knight
Тут соглашусь, он технологически примитивный, даже опенворлд не запилили, как в salt and sanctuary.
>Braid
А вот это вряд ли, насчет перемотки времени уровня брейда на гондотитяскрипте есть большие сомнения.
>>610354
>ряя, ваши спрайты не спрайты
Ваше мнение очень важно для нас, оставайтесь на линии.
В террарии блоки - это динамические элементы, для них прописана логика, у них есть атрибуты, такие как здоровье, помимо просто положения в тайлмапе.
А рисуются они XNA-шным спрайт батчем, такой рендеринг невозможно реализовать на годоте, не перепиливая куски движка на уровне плюсов.
Я спорить не буду, потому что во первых не интересуюсь террарией, а во вторых мне похуй.
Но очевидно что это все делается тайлмапом, в котором сами тайлы анимируются, то что у них логика и здоровье это дело десятое, это может быть операция над массивом чисел. А уже отдельные эффекты какие-то могут спавниться спрайтами, и тут уж запаса в 1000 хватит за глаза.
> это все делается тайлмапом, в котором сами тайлы анимируются
Ты представляешь, какой будет гемор - анимировать годошный тайлмап? Тебе придётся заготовить тайлы-фреймы для анимации и менять их в каждой ячейке тайлмапа, где у тебя планируется анимация. Либо заготовить атлас-текстуру и анимировать выбранный регион для тайла.
В любом случае будет заёбисто.
https://godotengine.org/qa/11223/is-it-possible-to-change-animate-tilemap-cells
Проще собрать уровень на объектах. В том числе, используя тайлмап как матрицу для расстановки объектов: в дизайн-тайме ты расписываешь тайлмап. В рантайме у тебя функция _ready расставляет объекты по уровню, используя map_to_world затем выгружает тайлмапу.
> как только у тебя будет больше чем 30 на 30 тайлов
А я им вручную текстуры из одного атласа раздам и увеличу фпс. Главное не делать это преждевременно. Преждевременная оптимизация - антипаттерн. Сначала игру сделай, а потом задумывайся, как батчить спрайты.
>а потом задумывайся, как батчить спрайты.
Смысл думать о том, что в принципе невозможно делать в гондотите?
>А я им вручную текстуры из одного атласа раздам
Так вся фишка в том, что рендер Хуана все равно будет рисовать по одному кваду за draw call, в этом и заключается отсутствие спрайт батчинга, от которого у всех встают волосы дыбом.
Так ли много игр ты видел, где 1000 одинаковых спрайтов на экране? Это бесполезный бенчмарк. Возьми хотя бы десяточек спрайтов, и назначь их рандомным образом, посмотрим что будет.
Переключение текстур дорогая операция в opengl, если Хуан не догадался в рендере сделать сортировку спрайтов по текстуре, то будет еще бОльшая просадка, т.к. на каждый draw call будет переключение текстуры.
>одинаковых спрайтов
Очередное НЕ ТАК, ясно.
Годаны, помогите плиз красивую гранату сделать. Настроек частиц подкиньте. У меня какое-то говно получается.
ДЛЯ ЖЕЛАЮЩИХ ОБОССАТЬ ГОДОТ
Тест под юнити с двумя сценами, "оптимизированной" и "неоптимизированной". Можете наглядно сравнить производительности этих движков.
Скачать тут https://www114.zippyshare.com/v/xyvZnE26/file.html
Я так понимаю, там билды под шин? Пользователи божественной ОСи все равно не смогут запустить.
Надо сделать так - запустить на твоём компе бенч годота, заскринить результат, сколько спрайтов, сколько фпс. Потом юнити и тоже заскринить. Чтобы была видна разница на одинаковом железе. Сделай плиз, если нетрудно.
Следующий популярный миф - мол, ладно, а вот Терраррию не сделать, якобы неправильно работает тайлмап, через спрайты.
Проверяем. Не знаю что там в Террарии, в моем тесте сейчас так:
120х68 карта, 256 разных тайлов 16х16 пикселей.
На самом деле два слоя тайлмапов, просто чтобы смотрелось лучше. Обсчитывается только один.
Плюс статический задник-картинка
Два вида анимаций тайлов
Первый - циклическая смена текстур через AnimatedTexture. Так делается огонь, вода и т.д.
Второй - собственно изменение конкретных клеток. В качестве теста написал коротенькую реализацию игры Жизнь Конвея.
Плюс накидал спавн спрайтов, в определенных условиях. В террарии ведь должны быть еще герои и спецэффекты.
Результат - 60 fps на 750 ti, коллеги. Кстати я разобрался как на ней записывать видосики. Проект будет лежать там же, на govdot. Указал лицензию - CC0 public domain, и код и картинки.
Зачем нужен годот, если есть юнити?
>не запустится вообще или будет рисовать кашу из за изменений в шейдерах с 2017 года
Шиз, плес, юнити компилит 500 конфигураций каждого шейдера при билде для охвата всех видюх. Чухану конечно это неизвестно так как он юнити близко не видел, зато он имеет уверенность рассуждать что там где не запустится и сколько градусов будет у видяхи. Типичный годото чуханоид.
У меня с железом какая-то хуйня. Или шындовс засран. Но ФПС падает до 20 уже на 1500 спрайтах.
>Всяко лучше ползающего червя-юнити
Что ты несешь, шизик? Уже обоссывали сто раз, что годот юнити никогда не догонит из-за спрайт батчинга.
https://github.com/godotengine/godot/issues/1527
>https://github.com/godotengine/
>issues 5000+
Нет чтоб фпс 5000+ было, лол.
Мдауш. Досадно.
Сначала запустил 10к спрайтов и там и там, классический стресс-тест для 2д рендера. Юнити выдает стабильные 60 фпс, годот всего 10.
Потом замерил на 2к спрайтах, т.к. у годоти к этому моменту фпс падает до 50. У юнити на 2к - 400.
И это на железе, на котором все игры последних лет работают на ультра настройках без просадок.
Причем, у юнити (видимо из-за спрайт батчинга) фпс падает не линейно, а все медленнее и медленнее, чем больше спрайтов на экране. У годота падает линейно, каждое добавление 500 спрайтов роняет фпс на одинаковое значение.
Так что делаем выводы, посоны.
>Ну скажите им, что много спрайтов НИНУЖНО, ну скажите, что 20 фпс это более, чем достаточно для современных игор! Годотя литает, я скозал! Литает!!!11
Тут проблема не столько в конкретных 2к спрайтах на конкретном железе, а именно в линейной зависимости фпс от кол-ва спрайтов.
Для моего не самого слабого железа 2к это предел. Для чьей-то некропеки это может быть уже 1к, 500 или даже еще меньше.
В юнити фпс падает так - добавил x спрайтов, фпс упал на y. Добавил еще x спрайтов, фпс упал на y/2. Добавил еще x, упал на y/4, добавил еще - упал совсем на чуть-чуть. Эта нелинейность достигается как раз за счет батчинга и прочих оптимизаций, сортировки по текстурам/шейдерам, чтобы уменшить переключение контекстов, и т.д.
В годоте на каждые x спрайтов всегда падает на y, и это станет проблемой для некоторых жанров игр, типа той же террарии, факторио, римворлд и т.д, где спрайтов на экране побольше, чем в клоне супер марио.
>Сам только что придумал?
Нет, еще издревле 2д рендеры так бенчмаркали, если смог преодолеть 10к спрайтов и удержать стабильные 60 фпс - значит, сделал годный рендер.
Ради интереса загуглил - в Touhou кап в ... 2000 спрайтов.
При этом они не независимые, как в бенчмарке, а двигаются по связанным траекториям, а значит очень легко оптимизируются инкрементом в цикле.
А вот Казаков с его 64000 юнитами просто так не сделать, да. Но такое где угодно оптимизировать
>типа той же террарии, факторио, римворлд
Ты опять начинаешь, жиробасина?
В этих играх не будут использоваться спрайты для всего. А будет использоваться ТайлМап, для которого написан второй бенчмарк, и там тоже нормально все будет.
Хочу ардуинку/аврку подцепить.
Usb на ардуиньке работает как последовательной порт. Зря я его com портом обозвал, но суть та же, т.к usb порт на ардуиньке это не полноценный usb, взаимодействие идёт через Serial.
Копипаста: Все платы Arduino имеют, по крайней мере, один последовательный порт (также известный как UART или USART): Serial. Он связан с цифровыми выводами 0 (RX) и 1 (TX), а также используется для связи с компьютером через USB.
Комп:
проц: i7-4790
видео:NVIDIA Quadro K620
разрешение: 2 монитора по 1920х1080 (рабочий стол расширен на 2 монитора)
Win7x64
---------------
Проект: любой 2Д платформер со скроллингом.
Когда включены оба монитора, то происходит такая штука:
К примеру если разрешение проекта 384х216 и я его запускаю в окне любого размера вплоть до максимального (1920х1080), то все двигается и скроллируется максимально плавно, без задержек и рывков.
Если же я включаю режим Fullscreen или делаю borderless окно 1920х1080 (что по сути тот же фуллскрин) начинаются рывки при скроллинге и перемещении)
Если же отключить один из мониторов, либо сделать дублирование рабочего стола на оба монитора, то рывки и прочая хрень пропадает и все опять становиться плавно.
Есть идеи как это можно пофиксить?
Ну или хотя бы можно ли из кода узнать, сколько у юзера мониторов, чтобы предупредить его про возможность таких косяков в случае если их больше одного?
Открой на втором мониторе диспетчер задач на вкладке с мониторингом ресурсов (ой, у тебя некросемёрка, тогда на вкладке с процессами отсортируй по ЦоПе) и смотри, кто нагружает систему: только годот, годот и ещё кто-то, кто-то другой. О результатах отпишись.
У меня для тебя две новости, плохая и плохая.
>Fullscreen
>делаю borderless окно
В годоте нет нативного фуллскрина, то что ты называешь fullscreen и есть бордерлесс окно. Потому, что он Хуан решил, что это тупо - делать полноценный фуллскрин в 2к19.
https://github.com/godotengine/godot/issues/14542
>Godot does not understand fullscreen video modes. It is kind of silly to support that nowadays, given that monitors all have fixed pixel densities.
>начинаются рывки при скроллинге и перемещении)
СТАТТЕРИНГ
СТАТТЕРИНГ
СТАТТЕРИНГ
СТАТТЕРИНГ
>Если их в один 3840х1080 объеденить через настройки нвидии (если конечно у тебя такая опция есть) твоя проблема остаётся?
Они у меня в один общий рабочий стол объединены. Т.е. можно перетаскивать окна туда сюда, но при включенном фуллскрине, окно растягивается только на один монитор.
Попробовал задать в проекте разрешение 3840х1080 и borderless, так чтобы растянулось на два монитора. Дерганья остались хотя и чуть меньше чем просто в фулскрине.
Причем самое забавное, что даже когда игра дергается, FPS показывается стабильные 60.
Если один монитор отключить или сделать его обычным дублем первого то проблем вообще нет, в любых режимах игра идет плавно.
> Вроде бы пришли к выводу всем тредом, что 20 фпс более чем достаточно для любой современной игры.
Тролли и демагоги могли к чему угодно прийти. Ты либо один из них, либо вообще не можешь в сарказм, с которым они "пришли к выводу".
Либо у тебя сарказм и я в него не смог только что, кек.
Да тут не в cpu дело, очевидно же, что не хватает пропускного канала видюхи.
Попробуй другие игры погонять, если там тоже статтеринг - значит в целом видюха не тянет такое разрешение и не успевает обновить кадр. Если только в гондотите - то можно только посочувствовать, опять Хуанорендер свинью подложил, неэффективно использует пропускной канал, что неудивительно, учитывая как он рендерит 2д (draw call на каждый спрайт).
Перфоманс, полноценный фуллскрин позволяет работать процессу напрямую с видюхой в нативном режиме, и выжимать из неё больше. Грубо говоря, в нативном фуллскрине вывод видюхи маппится напрямую на монитор, при бордерлессе - на окошко операционной системы. Поэтому нативный фуллскрин до сих пор остался во всех основных движках типа юнити, анрила, и юзается в большинстве игр, особенно с крутыми графоном, типа ведьмака какого-нибудь.
Но Хуан посчитал что это глупо, видимо по той же логике, по которой 20 фпс хватит всем.
> (draw call на каждый спрайт)
Пруфца бы. А то по дукументации опенгл - дравкал выдаётся на инстанс текстуры, а не на программную абстракцию "спрайт".
Таким образом, если запихнуть все текстуры в один атлас, мы ручками сделаем тот же самый батчинг, который делает этот надоедливый платный движок с неотключаемым сплешскрином.
Блядь, вы необучаемые что ли? Уже обоссали и разжевали сто раз, что годот рендерит каждый спрайт отдельным драв коллом независимо от текстуры, даже если ты сто раз рисуешь один и тот же спрайт, будет сто драв коллов.
https://github.com/godotengine/godot/issues/1527
Нет, они до сих пор продолжают маня-фантазировать про атласы какие-то, что там само всё объединится и отпимизируется по велению левой пятки Хуана.
> мы ручками сделаем тот же самый батчинг,
Угу, совсем тот же самый, настолько тот же самый, что у годота 10 фпс там, где у юнити 60.
>>610719
> годот рендерит каждый спрайт отдельным драв коллом независимо от текстуры, даже если ты сто раз рисуешь один и тот же спрайт, будет сто драв коллов
Не пизди. По твоей ссылке бенч без атласа. И загляни в код, там как-то вообще тупо идёт присвоение в цикле вижуалсерверу нового инстанса текстуры. Ясен хуй там будет 100500 дрочкалов.
>Да тут не в cpu дело, очевидно же, что не хватает пропускного канала видюхи.
Похоже, что нет. Сейчас перекинул один моник на встроенную видяху, точно такая же фигня. С одним монитором (любым) все гладко, с двумя - дерганья. Загрузка ЦП всегда одинаковая.
>Попробуй другие игры погонять, если там тоже статтеринг - значит в целом видюха не тянет такое разрешение и не успевает обновить кадр. Если только в гондотите - то можно только посочувствовать, опять Хуанорендер свинью подложил, неэффективно использует пропускной канал, что неудивительно, учитывая как он рендерит 2д (draw call на каждый спрайт).
Попробовал несколько разных игр, результат 50 на 50. В некоторых такой проблемы нет и все гладко, в других дерганья при двух мониторах и гладко при одном. Причем движки у всех разные.
Т.е. дело тут не в количестве дроу колов, а в чем-то другом, либо в винде, либо в опенгле.
Попробую поэкспериментировать на других компах и системах.
Хуан как всегда будет переписывать уже существующее
https://marketplace.visualstudio.com/items?itemName=geequlim.godot-tools
>В годоте нет нативного фуллскрина, есть бордерлесс окно
И слава богу. Сейчас 2к19, уменьшение фпс практически незаметное (доли процента), зато alt-tab будет мгновенным без секундного мигания, и будет превью окна на таскбаре.
>типа ведьмака какого-нибудь
Тут 50/50, у половины народа борделесс окно лучше работает.
https://steamcommunity.com/app/292030/discussions/0/613958868351211325/
@
ПОСТИШЬ ШАРИК НА ФОНЕ ФОТОГРАФИИ
@
ХОМЯКИ В ВОСТОРГЕ ВИЗЖАТ ОТ НОВОГО ФОТОРЕАЛИСТИЧНОГО РЕНДЕРА
Проиграл что-то.
https://github.com/godotengine/godot/issues/21244
Покажи другой свободный опен сорс с таким же покрытием платформ, работающий из коробки. cocos2d-x - нет 3д редактора. ogre3d - такая же сегментация на 1 и 2 версии, как у Хуана с gles2. urho3d - говно мамонта, выглядещее как 90-е. Год назад я тоже проигрывал - чего это на Godot все так наяривают, почему он в топе гитхаба по звездам. А потому что так и есть по факту Хуан свое дело знает, тише едешь дальше будешь. Вот сейчас перепишут на Вулкан и производительность вырастет, что тогда придется выдумывать хейтерам?
>Вот сейчас перепишут на Вулкан и производительность вырастет, что тогда придется выдумывать хейтерам?
К тому моменту, как зарелизят 4.0, выйдет графическое апи нового поколения, условно назовём его Хуйкан.
После выпуска 4.0 все охуеют от количества багов, от того, что у части пользователей всё будет глитчить и статтерить, у другой части будет просто черный экран вместо рендера, у немногих счастливчиков всё будет кое-как работать. Поддерживаться, разумеется, будут только топовые видеокарты последних лет, т.к. на старые видюхи вулкан не завезли. Т.е. о поддержке некропекарен и старых ОС, чему сейчас радуются пользователи гондоти, можно будет забыть.
Хуан выступит с заявлением, что разработчики драйверов под вулкан некомпетентны, нахуячили баги в драйвера, всё сломали, поэтому гондотя и не работает, и что проблемы с рендером можно решить только переписав его полностью на Хуйкан. Будет запущен новый этап сбора донатов на новый рендер на Хуйкане, после сбора денег Хуан снова пропадет на пару-тройку лет. Когда проест все донаты, выкатит еще один кривой полурабочий рендер, без спрайт батчинга для 2д и без окклюжен куллинга для 3д, и скажет, что у графического апи Хуйкан слишком много внутренних проблем, разработчики выкатывают забагованные драйвера, да и поддержка оставляет желать лучшего. Поэтому, единственный способ исправить все недостатки рендера на Хуйкане - переписать всё на принципиально новое графическое апи под названием Защекан, выход которого анонсирован в 2035 году. Разумеется, для решения столь амбициозной задачи необходимо будет запустить новый этап сбора донатов на реализацию рендера на графическом апи Защекан.
Я это к чему всё. Отсутствие вулкана не помешало разработчикам запилить кучу годных игр за последние 20 лет, и в 2д, и в 3д. Сейчас бы думать, что вулкан решит все проблемы годота, в том числе самую главную - научит Хуана программировать и решать проблемы.
>К тому моменту, как зарелизят 4.0, выйдет графическое апи нового поколения, условно назовём его Хуйкан.
Зачем нужны эти фантазии? Закон Мура давно остановился, ничего особо нового в ближайшую пару лет не будет. Иначе все бы уже об этом трубили во всю.
>у части пользователей всё будет глитчить и статтерить, у другой части будет просто черный экран вместо рендера
Прям мой опыт с юнити описал.
>Т.е. о поддержке некропекарен и старых ОС, чему сейчас радуются пользователи гондоти, можно будет забыть.
Даже если это случится, ничего не мешает продолжать использовать Godot 3 для такого.
>Отсутствие вулкана не помешало разработчикам запилить кучу годных игр за последние 20 лет, и в 2д, и в 3д.
Естественно, многие написали in-house движки для этого.
Мне надо поставить 0.075сек. А редактор позволяет выставить только 0.07 или 0.08
Не-а. Там действительно есть проблема когда к AnimationTree цепляешь AnimationPlayer, чтобы гонять его через стейт машину. Там не идут сигналы и свойства не поменять из кода:
Вот например.
>AnimationPlayer signals are not emitting when animations played from AnimationTree
https://github.com/godotengine/godot/pull/30390
Такое ощущение, что AnimationTree создает где-то свой экземпляр плеера и его гоняет, а тот который в дереве сцены висит мертвым грузом.
Сорян не та ссылка (но она тоже имеет отношение).
Вот которую я сначала хотел написать:
https://github.com/godotengine/godot/issues/28311
Не завезли, и не завезут. Позиция Хуана такая - пока терпите, ждите версию 4, рендер на пукане.
Но и там спрайт батчинга не будет, просто пукан пошустрее чем opengl, да и работает только на топовых видеокартах последних лет, поэтому тормозов там никто не заметит, можно будет и дальше спокойно проедать донаты и не запиливать оптимизации в рендер.
> Только там где он делает стейт машину именно для анимации, а не для перемещения игрока.
Он делал комбинированную. Переключение состояния "ходьба" означает одновременное включение анимации "ходьба" и перемещения модельки.
Неужели ты из примера не можешь вычленить нужное тебе?
> не запиливать оптимизации в рендер
Сами запилите. Форкните. Опенсорц же. Чё, слабо?
>Сами запилите. Форкните. Опенсорц же. Чё, слабо?
>Он делал комбинированную. Переключение состояния "ходьба" означает одновременное включение анимации "ходьба" и перемещения модельки.
Не, не пойдет. У меня две отдельные стейт машины, одна для игрока, вторая для его анимации. Мне так удобнее.
>Неужели ты из примера не можешь вычленить нужное тебе?
Не люблю видеотуториалы смотреть. Слишком большая потеря времени пересматривать все и искать где и что там кто делает.
Зачем мне форкать гондот, чтобы что-то там запиливать? Хуан все равно не принимает пулл реквесты, затрагивающие его кормушку (рендерер, который он переписывает несколько лет подряд на донаты, относится к их числу).
А так я уже давно пилю свой собственный двиг со своим рендером на opengl.
>Хуан все равно не принимает пулл реквесты
Пачаны, подскажите. Сижу на Конструкт2 и не делаю игры уже несколько лет. Есть ли смысл перейти на Годот и не делать игры на нём? Там и 3Д есть.
Вообще хотелось бы на Юнити ничего не делать, но Годот меньше объёмом и говорят простой, удобный, саврименный не хуже Юнити...
> закон Мура касается ПРОЦЕССОРОВ и он работает
Закон Мура НЕ работает. Отсутствие явления (работа закона мура, существование боженьки, сотоны и ангелов с бесами) - в доказательстве НЕ нуждается. В доказательстве нуждается именно наличие явления.
Ты посмел кукарекнуть, что закон Мура всё ещё работает (несмотря на то, что имитацию его работы делают за счёт наращивания ядер (де факто количества процессоров). Так что будь любезен доставить пруфы твоего вскукарека, иначе твоё очко переходит в зрительный зал.
Так, спокойно! Ты как и положено местным аутистам понял все буквально. Когда говорят о законе Мура, не имеют в виду тупо уменьшение транзисторов в 2 раза (впрочем и тут скоро упрутся в физику), а еще и сопутствующее уменьшение тепловыделения и рост производительности. Есть правда еще многоядерность, но она упирается в то, что мало какие алгоритмы можно легко параллелить.
Поэтому и ответ на твой вопрос - причем тут годот - если бы ты читал внимательней был бы тебе ясен - я отвечал на предположение что прям вот сейчас появится новый прорывный api. Предпосылок к его появлению нет, вулкан был просто эволюцией того, что вместо фиксированных шейдеров можно писать код, который на том же железе позволит считать только то что хочет программист, а не только то, что заложил инженер в видяху. Вот и вся магия роста перформанса.
Хотел согласиться но погуглив выяснилось что он все же работает. Просто, как пишут, не в intel процах общего назначения, а у тайванцев. https://medium.com/predict/moores-law-is-alive-and-well-adc010ea7a63
Ну смотри, по сравнению с констрактом, годот предоставит тебе более низкий уровень программирования игор. То, что в констракте (конструкторе игор) делал одним кликом, как само собой разумеющееся, в движке (годот, юнити, уеч) потребует от тебя либо написание определенной логики, либо скачивание уже написанных кем-то ассетов.
Например, в констракте ты просто, без задней мысли кидаешь на сцену спрайт, говоришь констракту - это топдаун персонаж игрока. Констракт говорит - окей - и всё, ты уже можешь ходить персонажем. В движках тебе придется описать ручками логику передвижения. Скомпоновать с физикой. Ну, либо скачать кем-то написанное.
И так во всём. В конструкторах тебе даётся готовая логика уровней. Ты можешь наполнять уровни контентом, настраивать переходы между ними. В движках будь любезен сначала сам организовать логическую структуру уровней, спроектировать каким образом уровни будут наполняться контентом, как будут осуществляться переходы, а уж потом наполняй контентом.
Есть сцена с тайлмапом, несколькими нодами-спрайтами и нодой-игроком. У игрока в скрипте создается дефолтная Camera2D, без smoothing. Во время движения по сцене ноды-спрайты начинают дрожжать (тот самый jitter?), а между тайлами тайлмапа иногда проскакивают вертикальные полосы.
Не знаю что там с драйверами Nvidia, про которые тут что-то писали, но от видеокарты это вроде не зависит т.к. проверял и на Nvidia и на Intel встройке, то же самое все.
Что это может быть, и как фиксить? Может ли это быть связано с CanvasLayer (у инстанснутых нод-спрайтов добавил у каждой, чтобы выводить попапы, которые они могут выводить, по центру экрана, а не относительно начальных координат камеры или чего-то там)?
>интроспекция
А тебе уже не терпится переделывать поломанные обновой проекты?
(два дня переделывал сломавшиеся двадэ частицы и это нихуя не смешно, в документации не обновили, как теперь делать анимацию фреймов частиц, кое как методом тыка нашёл, что надо особую текстуру добавлять в ресурс и настраивать там)
https://github.com/godotengine/godot/issues/29576
>It's the damn kernel! For some reason, kernel 4.19. is causing processes to stall while running. I just got things working on a 4.9. kernel. facepalm
Ну Хуан не виноуат, что дрочер использует древнее ядро. Или погодь. У него на 4.19 не взлетело, а на 4.9 зороботало? Я нипонел.
З.Ы. Ванильная Бобрунту 18.04.3 с ядром 5.0, только что включил стимгодоту 3.1.1, все робит. Давно пора привыкнуть, что дистры это ебаные суповые наборы, где-то что-то есть, где-то чего-то нет и распространять вместе со всем, что надо - через ебаные снапы.
Я серьезно интересуюсь. Т.е. в чем твой профит, если какая-то часть людей бросит годот и пересядет на юнити?
https://github.com/kyzfrintin/Godot-Mixing-Desk
Ты слепой? Я же уже прикреплял картинку
>>611664
Нет 2-кратного роста перформанса ни на синглкоре, ни на мультикоре
Да ты совсем дурак? Закон Мура работает! Просто сейчас технологии достигли предела возможностей физически.
Уже в 2007 году сам Мур заявил, что действие этого закона больше невозможно из-за фундаментальных причин — атомарной природы вещества и ограничения скорости света, которое не позволяет процессорам работать еще быстрее.
Понял? Но это не значит, что мощности компьютеров перестали и перестанут расти. Они продолжают расти и будут расти, только другими путями.
Да не работает он. Кстати вспомнил еще причину, почему он фуфло - нанометры то сейчас не настоящие, а маркетинговые! Транзисторы по сути не уменьшаются уже почти, а только дорожки проводящие между ними. https://habr.com/ru/post/423575/
Не вижу ничего плохого в обсуждении недостатков нашего любимого движка. У нас же нет цели обелять его ура-шапкозакидательством. Он медленне юпити? Допустим, хотя тормознутость юпити известная проблема, к любой игре отзывы на стиме почитать. Его производительности достаточно для большинства игр? Да, это наглядно показали бенчмарки. Ускорится ли он? Да, работы уже ведутся, надо просто подождать.
Конечно.
1. Тыкаешь редактировать тайлсет
2. Плюсиками добавляешь сколько надо текстур
3. Кликаешь с какой текстуры хочешь тайл
4. Тыкаешь добавить одиночный тайл
5. Помечаешь тайл на текстуре
6. Вы великолепны.
Нужно кликом мышки указывать точку на карте. Карта двигается камерой за игроком. Всё в двадэ.
Я получаю event.position - он мне рисует координаты в окне, где я мышкой ткнул.
Гугел подсказывает, что надо event.position - position, делаю так, но координаты всё время разные для одной точки на карте, в зависимости от положения камеры.
Подскажите правильную формулу.
Я пошёл дальше гуглить, позже почитаю ответы.
ну то есть ты слит вместе со своим рузке языком, свинья лишнехромосомная. жаль вам обезьянам открыт доступ к достижениям. сидели бы вы как в Северной Корее на калькуляторах в чебурнете и там бы воняли. А то сидят лишнехромосомные с вражеских чипов не развивающихся во вражеском интернете и воняют что-то доказывают )))
То, то! Уже усё работает.
Как при использовании анимэйтед спрайт в коде выбирать нужную мне анимацию?
self прописанный в скипте сцены, которая была инстанцирована будет ссылаться на тот нод, к которому прикреплен скрипт?
> отдельная сцена = класс
Нет. Отдельная сцена - файловый ресурс, который подгружается в дерево сцен и по инструкциям этого ресурса в дереве сцен создаётся поддерево (ветвь).
На этом уровне классов нет, есть ноды, которые все - единый класс Node. А уж какой потомок класса Node, это задаётся либо ресурсом либо скриптом и влияет только на него самого и его ветвей в дереве.
Ещё раз, в дереве сцен нет ООП, нет наследования.
> Инстанцирование = создание объекта этого класса.
В ООП = да. На том уровне, на котором ты создаёшь инстанс из класса. На уровне дерева сцены есть только добавление ветвей: add_child() - что будет у тебя в скобках - зависит только от тебя.
> self прописанный в скипте сцены, которая была инстанцирована будет ссылаться на тот нод, к которому прикреплен скрипт?
И тут, не зная всего вышеописанного мной, ты скрестил ежа с ужом.
Скрипт сцены - это скрипт-расширение класса, указанного после директивы extends! Если в ресурсе TSCN указан тип (класс) Sprite и указан скрипт my_sprite.gd, то при создании инстанса из PackedScene будет создан класс-потомок Sprite c расширенным функционалом. Посмотри, как это выглядит в рантаймовом дереве (во время выполнения проекта нажать вкладку "удалённый" в панели с деревом сцены).
Поэтому, в выполняющемся проекте не будет никакого нода, на который должен ссылаться инстанс спрайта, все методы будут в нём, как рсширения, self, как и положено будет ссылаться на сам инстанс.
ИДИ НАХУЙ ТУПОЙ ДОЛБОЕБ
ТЕБЕ УЖЕ СТО РАЗ ПОЯСНЯЛИ
В РАМКАХ ПРОЕКТИРОВАНИЯ СЦЕНА = КЛАСС, ИНСТАНС = ОБЪЕКТ
ВОТ ОФИЦИАЛЬНАЯ ДОКУМЕНТАЦИЯ
https://docs.godotengine.org/en/3.1/getting_started/workflow/best_practices/what_are_godot_classes.html
Блять как же я с тебя сгорел.
ДЕРЕВО - ЭТО ПРОСТО ДЕТАЛИ РЕАЛИЗАЦИИ ВНУТРЕННОСТЕЙ ДВИЖКА!
С точки зрения ПОЛЬЗОВАТЕЛЯ движка (разработчика игры)
Сцена = класс
Инстанс = объект класса
Сигналы = методы
С тобой говорить просто невыносимо
Это примерно как если бы кто-то сказал:
Я хочу сделать в ООП-Хуитоне класс, который наследуется от другого класса
А ты бы начал доказывать:
Никакого ООП не существует!
Есть только запись в структуре HuitonObject! И там указатель на другой HuitonObject! А никакое это не наследование!
Да всем насрать как это технически сделано, блджад!
>User-created types are not technically classes
И че блять!
А еще там написано первой же строчкой
In Godot, scripts and scenes can both be the equivalent of classes in an Object-Oriented programming language.
As a result, many best practices in Godot boil down to applying Object-Oriented design principles to the scenes, nodes, or script that make up your game
Ты не проецируй, я себе скачал еще УЕ4- лучший из проприетарных движков. Так что я могу сравнивать с лучшим из опенсорс движков - Годотом. И что такое "выбрали не тот двиг"? Это не семья, движок всегда можно сменить. Для одних задач один, для других другой.
Правда юпити уже в пролете, это да.
Классный уход от темы, одобряем. Это как на личности переходить, но в среде анонов.
>>612135
>>612117
Ну вот смотри. Я создаю отдельной сценой нод. Назовем его UnityFag. Повесим на него скрипт. Запихнем несколько переменных Honor, Hp, и Agressiveness. Напишем пару функций отвечающийх за что-нибудь.
Это по-сути, готовый экземпляр, как я понимаю. Но мы его воспринимаем как класс, ибо далее:
_Динамически_ начинаем инстанцировать одного за другим UnityFag-ов в количесте N штук в нашу главную сцену, которую назовем, скажем GodotThread. Пусть методом add_child(). Но при инициализации вызываем условный сторонний метод, который начинает колдовать с характеристиками. Итого получаем кучу экземпляров условного класса.
Я думаю, методом костылей можно реализовать и инкапсуляцию, и полиморфизм, и наследование - если все это понадобится.
Да, я пользуюсь утиным методом определения сущностей. Если что-то хрюкает, имеет пятачок и сидит в луже, то это вполне возможно будет свинья, хоть под это определение подходит куча анонов, засирающих этот тред срачем.
Вот Lua блядь нихера не поддерживает из коробки ООП. Его там блядь нет. Но его можно сделать на Lua. И ни один хуй - ни разу ни под одной статьей на хабре из десятка посвященных реализации принципов ООП, не написал "это нихуя не ооп, потому что вы все хуи, а не разработчики."
Я так делал, но там в основном все демки с одной сценой в которую уже добавлены все элементы игры. Есть несколько где используется инстансинг, но меня больше интересует как правильно удалять объекты из сцены, то как я пробовал удалять они удаляются, но всё равно, как я понял, остаются в памяти.
Ну в таком смысле, да. Согласен.
Если хочешь, как в юнити, делай пикрелейтед. Но есть один нюанс. Два. Жёлтеньких треугольных нюанса. Поэтому, совсем как в юнити не получится. Пикрелейтед2.
Вдогонку вариант скрипта из пикч выше:
Вы можете коротко ясно сказать на чём проще сделать и быстрее игру 2д и 3д на Годноте или Юнити?
Переведено с английского языка.-Allegro - это польская платформа для онлайн-торговли. Управляется Allegro.pl Sp. Z O.O. которая была образована в 1999 году и впоследствии приобретена онлайн-аукционом QXL Ricardo plc в марте 2000 года. QXL Ricardo plc изменила свое название на Tradus plc в 2007 году и была приобретена Naspers в 2008 году. Википедия (Английский язык)
И вот наконец я самостоятельно нашёл решение (когда придумывал название методу-велосипеду, который теперь удалю):
snapped_vector = unsnapped_vector.normalized().snapped(Vector2.ONE)
Я везде ищу.
>>612342
Помоги ещё вот с чем. На радостях от обнаружения snapped() я кинулся ещё один свой велосипед переписывать и удивился тому, что мой велосипед работает так как мне надо, а метод выдаёт хуиту. Пикрелейтед закомментирована попытка перевести с велосипеда на метод.
Задача: Имеем виртуальную сетку с заданной величиной ячейки. Нужно вернуть вектор, описывающий центр ячейки, ближайшей к исходному вектору. Или, проще говоря, округлить входной вектор до размера ячейки.
Так ты и ни одной игры еще не сделал. Загрузить одну модельку на пустую сцену и получить 60 фпс - охуеть достижение.
Приходи как будет готовая игра.
Хотя кого я обманываю, мы оба понимаем, что этой игры не будет. Верить в возможность создания полноценной законченной игры на годоте - это как верить, что из жидкой дрисни можно построить небоскрёб
- есть (условно) тактическая стратегия
- она требует соответственно многооконность/многоэкранку. Ну то есть, не наличие нескольких мониторов, а возможность переключаться с одного на другой экраны. Например, 1) глобальный экран 2) графики 3) торговля 4) что-то еще.
- нужна именно многоэкранка, а не "всплывающие окна"
Я планирую реализовать это как инстансы отдельных сцен, корневыми узлами которых будет canvasчто-тотам. Все содержимое их будет обновляться при вызове конкретного окна, которое будет "выплывать" наверх.
Управлять всеми процессами будет отдельный нод engine так:
1) Game
2) UI, Engine
3a) UiTrade, UIGraph, UIGlobal, 3b) EnEconomics, ... etc.
Я правильно все делаю, или велосипед изобретаю?
Дополнительный вопрос:
коем хуем можно сделать пиксельно-точную высоту прыжка? Есть какая-нибудь формула уровня: Сила прыжка - (гравитация*дельта) чтобы посчитать насколько высоко эту силу нужно выставить. Ибо я заебался делать десятки тестов, чтобы тупо найти десятичное значение силы для прыжка.
PS: Всё время речь шла про KinematicBody2D
А как годот обрабатывает тайлмап'ы? Это я к моменту о оптимизации и производительности в 2Д
Допустим есть карта уровня для платформера. Пускай будет только графика, без коллизий.
Можно поступить двумя способами:
1) Создать карту как тайлмап, и закинуть его в сцену как "Tilemap"
2) Создать один большой png спрайт карты и закинуть его в сцену как "TextureRect" или "Sprite"
По затратности создания эти варианты приблизительно одинаковы, а вот какой будет лучше по производительности?
Правильно всё делаешь, только имя Engine уже занято.
А в целом годно. У меня так юзеринтерфейс построен: в корне его нода со скриптом, содержит метод ShowUI(PanelIndex) при вызове метода панель, которая указана, отображается, остальные скрываются. Ты ещё можешь дополнительно при скрытии делать им стоп-процесс.
> Есть какая-нибудь формула уровня: Сила прыжка - (гравитация*дельта) чтобы посчитать насколько высоко эту силу нужно выставить.
Боюсь, тут придётся открывать учебник по кинематике. Ну или статью в википедии. https://ru.wikipedia.org/wiki/Кинематика
>>612509
> какой будет лучше по производительности?
Тайлмап заявлен как более производительный. Только вот проблема в том, что на картах нвидия он моргает как сучка.
>Тайлмап заявлен как более производительный.
А можно подробности, где заявлено?
А то все что я нашел в мануале это: "they are optimized for drawing large numbers of tiles", а это вполне может быть "оптимизед" по сравнению с закидыванием кучи спрайтов на сцену, а не с рисованием одной большой текстуры цельным куском.
> Только вот проблема в том, что на картах нвидия он моргает как сучка.
У меня не моргает на нвидии. Кроме тех проблем с двумя мониторами и фуллскрином, что я выше по теме отписывал, проблем с отображением нет.
Неосилятор-ложкоблядь, зачем ты проецируешь свои юнитипроблемы на нас? У нас игры есть, тормозящие, моргающие, но есть. А у тебя нит игор, только коллекция ассетов. Вообще, чем больше юнитимрази срут ИТТ (пока годотогоспода игоры делают), тем больше я убеждаюсь в гениальности юнитеков: создали платформу, на которой можно делать ассеты и продавать их. И уже который год тянут бабло из школоты.
Классная игра! Спасибо, Абу!
Зачем тебе? Каких то питоновских либ в гдскрипте не хватает или че?
Я так понимаю что единственный способ добавить модуль - пересобрать сам годот. Ну соответственно надо установить питон 3.5, pip, scons, студия/mingw Не знаю какая у тебя ОС, я собираю батником на основе этих
https://gist.github.com/Calinou/6cd0c45f994b31f281eec66f0eeb401d
https://gist.github.com/Calinou/44edbd5d9c4a2ac0dbc8f165b8b7f0ce
https://gist.github.com/Calinou/4a5eded8c811193e4618ebe77f750b7f
Смысл думаю понятен
Подробные инструкции тут https://docs.godotengine.org/en/3.1/development/compiling/index.html
>>612393
По вашему всякие ГТА, майнкрафты - незаконечнные игры же выходит.
Там постоянно пилят новый контент, новые моды, новые механики.
Даже старые игры когда их еще записывали на болванки или картриджи, там были ревизии и патчи, а теперь их начали переиздавать тоже постоянно дорабатывая что-то.
Игры по типу Скайрима вообще выпускаются голыми недоделками, чтобы их сами пользователи доделывали.
В дрочильнях то же самое, новые уровни, новые персонажи, новые абилки. Даже если не упоминать сам контент (который, как утверждают на гд, важнее программирования), то абилки то требуют чтобы их накодили.
В общем, единственное что может остановить разработку - это когда директор проекта скажет все, мы его закрываем.
И то это не гарантирует, что люди не начнут сами дорабатывать модами, как к ToEE до сих пор Circle of Eight выходит, или например фанаты сейчас переписывают эмуль сервера давно закрытых City of Heroes и Dungeon Runners
>Там постоянно пилят новый контент
Покупай новое длц за 9.99$
>новые моды
Моды это личная инициатива рандомного челика
>а теперь их начали переиздавать тоже постоянно
Купи любимую игру еще раз за 49.99$
>В дрочильнях
А в не дрочильнях?
Тетрис это законченная игра или может надо модами ее допилить? Или марио? Нахуй проследуй короче, чухан безигорный.
В чем суть твоего возражения? Какая разница, доделывал игру рандомный челик, или оффициально? Было это длц платное или бесплатное? Если что-то доделали, то значит оно было незаконченным.
Тетрис постоянно доделывают, всякие новые механики, какой то режим где больше 4 линий можно удалить если накопить бонусы, мультиплеер, спамить противнику мусором и мешать.
В марио каждый день новые "невозможные" уровни добавляют.
Законченность игры определяет только менеджер, который говорит: релизим так как есть! Это все произвольое деление на тайтлы.
>Тетрис постоянно доделывают, всякие новые механики, какой то режим где больше 4 линий можно удалить если накопить бонусы, мультиплеер, спамить противнику мусором и мешать.
>В марио каждый день новые "невозможные" уровни добавляют.
Господи какой ты тупой. Опять приравнивает высеры васянов к "допиливанию" игры.
:3
Название сайта как бы указывает годотодетям на их место.
https://kidsthatcode.org/programs-sanbernardino-2/unity/
Согласен, юнитидитя)))
Пошли оправдания, ну да.
>название сайта
ебать аргумент. А знаешь, что в школе изучали двадцать лет назад? Плюсы. Давай, говори теперь, что на плюсах пишут только школьники, мистер-охуительная-логика
>что там с взрослыми играми на годоте?
Вот какая то на патреоне. Инб4 взрослая игра не взрослая.
Эти "манёвры" будут продолжаться пока на годоте не появится ХОТЯ БЫ ОДНА ИГРА.
Игра, это не поделка школьника на коленке, который запустил годот и по тутору сделал за неделю на коленке хуйню уровня какого-нибудь юнитековского асетфлипа, который делается за 3 минуты, а действительно продукт.
Что-то хотя бы уровня сабнавтики, холлоу найта, харстоуна, капхеда, да или хотя бы дарквуда, зе форест, римворлд, ну на крайняк файявоч или аутер ворлдс.
ХОТЬ
ОДНА
ИГРА
НА
ГОДОТЕ
> Что-то хотя бы уровня сабнавтики, холлоу найта, харстоуна, капхеда, да или хотя бы дарквуда, зе форест, римворлд, ну на крайняк файявоч или аутер ворлдс.
Я смотрю, на юнити у тебя каждая первая игра не браузерная параша типа БАТЛЫ.
Юнити - не движок, а конструктор, причём, строго определённого жанра игр - поиска записок в лесу со слендерманами и анубисами. На этой параше даже два дэ графика реализуется через жопу, а не как у всех.
> эти "маневры" будут продолжаться пока жив хоть один тугосеря, которому нечего делать, кроме как СРАТЬ В ЧУЖОМ ТРЕДЕ.
>Срать, это вам не мешки ворочать. Это надо найти время, место, придумать как и обо что триггернуть собеседника, это вам не пукнуть в лужу.
>Что-то уровня полыхания пуканов, взрыва пятой точки, дымления ануса.
>ИГОР
>ДЕЛАТЬ
>НЕКОГДА
>СРАТЬ
>В ЧУЖИХ
>ТРЕДАХ
>ВРЕМЯ
>ЕСТЬ
На годоте много игр, больше одной. Так что твое утверждение уже ложно.
>асетфлипа
Откуда на годоте ассеты? Вы ж говорили там самому все писать надо.
>Что-то хотя бы уровня
В чем определяется уровень? Формализуй. Иначе ты продолжишь маневрировать "это не игра Х, поэтому несчитово".
Как твоё ёрничество создало ХОТЬ ОДНУ ИГРУ НА ГОДОТЕ?
Никак.
>>612928
А ты можешь годот обсужать отдельно от юнити или годот не существует отдельно от юнити?
Ответить про годот на вопрос про годот хотя бы в теории возможно?
>>612929
А ты можешь годот обсужать отдельно от юнити или годот не существует отдельно от юнити?
Ответить про годот на вопрос про годот хотя бы в теории возможно?
>>612933
>На годоте много игр, больше одной.
Тогда наверное тебе не составить труда показать хотя бы одну настоящую игру на годоте. Чтобы это была действительно игра, законченынй коммерческий продукт, а не недельная поделка школьника по тутору, которые выставлен в потешном шоукейсе.
>Откуда на годоте ассеты?
Насколько часто тебя ебошили по голове, что ты прочитав это
>хуйню уровня какого-нибудь юнитековского асетфлипа, который делается за 3 минуты
задал самый уебанский вопрос в мире, которым можно было на это ответить?
Когда тебе клиент говорит "Бургер, одну картошку фри и колу" а будем честны, годотеру другой работы не найти, ты тоже начинаешь ёрничать вопя на весь макдак АТКУДА В КОЛЕ КАРТОШКА?
>В чем определяется уровень?
Я тебе привёл примеры игр. По ним ориентируйся. Я понимаю, чтоб для твоего уровня интеллекта это очень сложная задача, но ты всё же постарайся.
Ну конечно же есть, дурачок.
https://www.youtube.com/watch?v=tOCpIcSvODE
>хотя бы одну настоящую игру
Ваши игры не игры, ясно.
>законченынй коммерческий продукт
Мы уже разобрали несостоятельность законченности. Коммерческие продукты выставлены на итчио, стиме и т.д.
> недельная поделка школьника по тутору, которые выставлен в потешном
Это ты сейчас 99%юпити "проектов" описал.
>Я тебе привёл примеры игр. По ним ориентируйся.
Ты не сливайся, а формализируй критерии, там, в количестве объектов, текстур или геймплейных выборов, а то когда тебе приводят ты отвечаешь что ваши игры не игры. Зачем мне тратить на тебя время? Сначала ты потрать на формулирование своего тезиса, тогда будем с ним разбираться.