С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то есть варианты русскоязычного перевода части доков на ресурсе конкурирующей фирмы: http://c2community.ru/forum/viewforum.php?f=119
Ещё начат перевод официальной документации: 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
Предыдущий тонет там: >>565315 (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/
Кликнул по topmost спрайту.
Нет игор на годоти, НЕТУ, ЧТА ПОДИЛАТЬ.
Все, с завтрашнего дня делаю игру на годоте!
https://www.youtube.com/watch?v=ajk4RcR0R4g
Поработал тут над QWAS-управлением в изометрической демке, которая идёт с годотом вкаропке и готов выкатить вам свои результаты, которые на мой взгляд весьма неплохи. При одиночных нажатиях Q или W, A, S происходит движение по изометрическим осям. Если же надо двигаться по осям экрана, клавиши QWAS образуют квадрат, нажимая на грани которого, мы двигаемся по экранным осям: WS - вправо, QA - влево, QW - вверх, AS - вниз.
Модифицируйте проект "Isometric Game" показанным на скринах образом:
Суть происходящего в коде:
Мы формируем вектор инпута с клавиатуры по авторской формуле вектор2((право-лево), (низ-верх)), затем мы поворачиваем полученный вектор на 45 градусов влево (с минусом), координаты всё еще экранные. Поэтому мы умножаем полученный вектор на cell_size нашей тайлмапы.
В итоге получаем инпут повернутый и отмасштабированный изометрически.
Далее в процессе мы его нормализуем и умножаем на скорость с дельтой.
>>571456
Надо тесты делать. Но мне лень, тебе, полагаю тоже.
Чисто логически предполагаю, реакция человека работает гораздо медленнее, чем процессы компа, поэтому это не прецедент оптимизации. Даже если умножения работают очень медленно, инпутлаг будет на грани человеческого восприятия.
Частота вызова физик-процесса задаётся в настройках проекта. Пикрелейтед.
Коллбэк инпута вызывается только при физическом вводе, в нашем случае при нажатии клавиш.
Таким образом, с дефолтными 60 коллбэков физики в секунду, реакция на наш инпут будет быстрее нашего восприятия.
>и можно словить рассинхроны
Ага, типа, ставишь блок, а он не успевает поставиться и ты получаешь урон.
Только спать уже охота чота.
Похоже, челлендж провалится.
Ну и хуй с ним. А мне тем временем осталось сделать удаление линий и можно идти в стим!
Спасибо. До расповского тетриса мне ещё далеко!
Окей, но завтра. Основной тетрис готов. Линии урезаются. Челлендж ван-ивнин-тетрис выполнен!
https://www.youtube.com/watch?v=xygE_E8Hz6s
Продавать нельзя. Бесплатно выкладывать можно же.
Алсо, какой вариант блоков лучше?
>Сделай бомбочки как в тетрисе на тетрисе за 50 рублей
Напомните плиз, что за бомбочки? Это когда мигающий блок летит и проходит сквозь блоки?
Нее, в тридэ будет пикрелейтед. И его будет брать в руки тридэ-персонаж, чтоб поиграть.
Надеваешь очки виар, а там унутри столик с миньками вахи и аватары твоих кентов, которые зашли по сети.
Пффф
https://store.steampowered.com/app/518580/Accounting_Legacy/
Настолько противоречит, что на заставке движка реклама скамкоинов.
Никогда не верь рандомам ни в чем что касается юридических вопросов (даже мне), читай договоры сам, перепроверяй. Даже GPL позволяет вставлять рекламу, просто там это бессмысленно, любой васян будет пересобирать со своей рекламой или без рекламы, исходники то открыты.
Ни GPL, ни MIT не запрещают коммерцию. С GPL это бессмысленно по причине указанной выше. MIT менее опенсурсная лицензия поэтому она даже не обязывает раскрывать исходники.
Так же лицензия не распространяется на результаты работы, т.е. если GPL на сервере геренрит сайт/картинку/текст, то тут тоже не нужно отдавать исходники. Может показаться что к играм это не относится, но ведь скоро все серваки будут работать в гугл стадиуме, и игра не будет скачиваться, а только стримиться, поэтому можно будет хоть GPL игры делать.
>чтобы хотелось отблагодарить труд автора
Нихуя ты не понимаешь в коммерции. Позволь я тебе немношк объясню, как всё в реальном мире происходит.
В реальном мире бывают студии наподобие тройка-геймс, которые выпускают пару-тройку игор, которые затем чуть ли не культовыми считаются, но благодарные игроки почему-то скачивают их годноту на торрентах. А кушать-то хочется и студии типа тройка-геймс разваливаются.
Поэтому глупо уповать на то, что благодарные пользователи отблагодарят тебя донатами. Нужно любыми способами подталкивать их к платежам. В том числе оплата просмотром рекламы. Сэд бат тру.
>на чем-то более продвинутом
Пока ещё никто не смог повторить демки на годоте, которые мы с распидором выкладываем ИТТ. Следовательно продвинутее годота ничего нет.
Например, у юнити нет дерева сцен. Они прикрутили нестед префабы вроде, но по отзывам - это кривой велосипед.
У остальных движков даже этого нет.
УЕЧ принципиально не рассматриваю, потому что это продукт другой весовой категории, для игор ААА класса, запиливание на нём игр соло - это как стрелять из пушки по воробьям.
>Во время тройка-геймс никаких торрентов не было.
>Протокол был создан Брэмом Коэном, написавшим первый >torrent-клиент «BitTorrent» на языке Python, 4 апреля 2001 года. >Запуск первой версии состоялся 2 июля 2001 года.
>Vampire: The Masquerade[d]Дата выпуска Соединённые Штаты Америки 16 ноября 2004
> Arcanum: Of Steamworks and Magick Obscura Даты выпуска США 21 августа 2001
> 16 сентября 2003 The Temple of Elemental Evil
Алсо, помимо торрентов были всякие директ-коннект-клиенты, ослы-ишаки.
>И что? По твоему в год создания все такие вжух и
>>572163
>помимо торрентов были всякие директ-коннект-клиенты
>Я почему-то испытываю боль, когда ввод делают через вектор. Видимо, сказываются годы
Вон уже даже французы догадались делать ввод через вектор https://www.youtube.com/watch?v=YnvZNkQHcrI
Оказалось там целая функция для этого есть! Конвертировать bool в int оказывается нинужна было всё это время.
Отныне мы будем двигаться так! И только так!
>годот пока ещё не смог повторить ни одну игру
Вот это было обидно ща.
Да разве это игра? Вот, посмотри, как должен выглядеть настоящий тетрис, тетрис от юнитибогов.
https://www.youtube.com/watch?v=0nNp3nqtbWQ
Жалко только, что железа ps4 не хватает на настолько продвинутую и сложную игру и она постоянно тормозит. Все-таки за юнитикачество нужно платить.
Ыыы. Бомжи, ёптя, надо было прошку брать.
А если серьёзно, всем похуй, самый лучший тетрис на PS4 (возможно и вообще)
https://www.youtube.com/watch?v=PFVL6t8IHE8
Хотел пожаловаться, но выяснилось, что как обычно самдурак.
Создал словарь, присваивал его новым создаваемым объектам, забыв, что словарь передаётся по ссылке и охуел, что у всех объектов одинаковый словарь. Проблема решилась методом .duplicate() словаря.
В общем, как обычно, если в годоте ишьюс, проверь сначала себя и свой код.
Ну вообще сеттинг помойки - благодатное дело. Тут тебе и незаезженный (пока) сеттинг, и идейная состовляющая в виде "мусор поглащает планету, надо что-то делать". Можно ещё потом говорить, что делал игру, чтобы привлечь внимание проблеме (которая действительно существует).
И все равно ничего не изменится.
https://twitter.com/godotengine/status/1116328432877674496
Да какие пруфы, господи, развертку для ебаных волос делал, такой мутор я ебал. Так и не успел доделать. Еще анимацию бега прикручивал через юнитигуманойда, но она дерганная и нужно было в блендере править, подключать через гуманойда и чекать, лучше стало или нет, и так раз сто.
Держи в курсе.
>>572948
> рулет
Никак. Тебе в юнити тред.
Хуану виднее, а ты будешь подчиняться!
>>573070
>instance() делает копию объекта
Пиздуй троллить тупостью в другом месте.
>>573073
Инстансинг это батчинг геометрии на видяхе, чтобы на вывод одинаковых объектов не плодить оверхед. И только у одного Жуана instance() это new().
Нет, у меня на скрине не написано другое. Там именно один экземпляр в движке и несколько копий на экране. Возможно через батчинг, возможно через шейдер, неважно. В любом случае смысл инстансинга - уменьшить затрачиваемые ресурсы - полностью противоположенный тому, что в него вкладывает Жуан.
>Когда изучал программировании по геометрии
Но что самое печальное, что ты всерьёз думаешь, что тебя все троллят, а создатель движка дегенерат. При этом ты приходишь сюда и высираешься, что всё говно, но продолжаешь есть кактус, а не съебёшь нахуй туда, где всё называется как ты хочешь.
Илита /gd/ как она есть.
Я ничего не путаю. Скрин инстансинга с гугла выше.
>>573110
>ты всерьёз думаешь, что тебя все троллят
Поначалу, действительно, я думал что меня троллят
>посоны как в годоте называется инстансинг?
>ололо object.instance()
Но теперь я точно вижу, что тут одна илита которая не знает что такое инстансинг.
>создатель движка дегенерат
У создателей движка как раз инстансинг, инстансинга нет только у создателя годота.
http://www.undeaddev.com/lets-play-with-a-lot-of-meshes-part-1/
https://docs.unity3d.com/Manual/GPUInstancing.html
>не съебёшь нахуй туда
Потому что святой жуан сделал название противоречащее индустриальному стандарту, а критиковать его нельзя? Нет, пожалуй, останусь тут.
Вот специально залез в доки юнити глянуть, раз ты на него ссылаешься.
И там всё сходится с тем, что я знаю. Операция, в целом, дорогая. Пикрил. Тебе явно говорят. Копию объекта. Это ещё один объект. Это накладные расходы. А то, что ты хочешь - это переиспользование, пул.
Специально, для таких как ты, в один абзац написали.
https://unity3d.com/learn/tutorials/topics/scripting/object-pooling
Обосрался - обтекай. Ссылку я уже приводил выше. Инстансинг - дешевая операция, которая ускоряет рендер в несколько раз. Никаких копий не создается, рисуется тот же меш.
https://docs.unity3d.com/Manual/GPUInstancing.html
GPU instancing
Introduction
Use GPU Instancing to draw (or render) multiple copies of the same Mesh
at once, using a small number of draw calls. It is useful for drawing objects such as buildings, trees and grass, or other things that appear repeatedly in a Scene
.
GPU Instancing only renders identical Meshes with each draw call, but each instance can have different parameters (for example, color or scale) to add variation and reduce the appearance of repetition.
GPU Instancing can reduce the number of draw calls used per Scene. This significantly improves the rendering performance of your project.
>Мне похуй, что ты спрашивал.
Оно и видно, пиздишь мимо кассы о чем-то своем, увидел слово похожее и все перепутал.
>инстансинг создаёт копию объекта.
Инстансинг не создает никакую копию, а переиспользует уже загруженный меш. А твой instance() конечно создает копию объекта в памяти, и копирует весь меш. А, ясно, ты зачем-то копией называешь клонирование. Пиздец.
>>573145
В Жуане?
>А твой instance() конечно создает копию объекта в памяти
А "мой" instance() создаёт инстанс класса, уёбок ты упоротый. Непонятно какого хуя у тебя в башке щёлкнуло, что он создаёт копию(!) объекта(!!)
>GameObject
>GetComponent<Transform>().gameObject
Вы тредом ошиблись сер.
Испокон веков в программировании инстансингом называли создание объекта некоего класса. В геймдеве конечно есть еще одно значение, которое относится к графике, однако корень срача в данном треде в том, что некий господин проебал уточнить, что именно он имеет в виду и теперь мечущего кал по всему треду.
Все не в ногу, один Хуан в ногу
Это новый уровень аутизма, пиздеть про instancing, и приводить в пример скрин, где написано geometry instancing? Geometry instancing относится к геометрии, просто instancing имеет и другие значения, даже дауну это понятно. Но обосравшему пол-треда дегенерату похоже не очень понятно.
Тебе глазки жиром залило? Понимаю.
Это, блджад, выдача по запросу instancing. И все, сука, все говорят geometry instancing. И даже в вики речь идет о geometry instancing. И только в конце есть маленькая приписочка - см. также Instantiation. Ты реально не различаешь похожие слова, походу, бармалей.
>>573188
Ты долго будешь продолжать дристать себе на голову? Тебе ИТТ не поссал в рот только ленивый, может уже успокоишься и съебешь?
>смешно если прочитать самый последний абзац скрина, там где обучалка openGL
Ебать как смешно, ты наверное аж взвизгнул со смеху, хлюпая и захлебываясь соплями от осознания факта собственной правоты?
Даже дауну понятно, что в контексте opengl под instancing подразумевается именно геометрия, потому что отрисовка геометрии - это единственное предназначение opengl. Поэтому там нет нужды уточнять, какой именно instancing. Но только даун будет проецировать на все остальные контексты и визжать, что у этого слова может быть единственное значение в любой ситуации.
>Ебать как смешно, ты наверное аж взвизгнул со смеху, хлюпая и захлебываясь соплями от осознания факта собственной правоты?
Да съебись ты уже, не надоело позориться?
Я тебе не про instantinating, а про инстансинг сцен, если бы ты хоть немного вкурил годот, то знал бы, что у него есть такой термин. И означает это не копирование объекта, как ты, ебанашка, придумал, а создание экземпляра сцены из запакованного ресурса.
https://docs.godotengine.org/en/3.1/getting_started/step_by_step/instancing.html
Да ты же поехавший, нахуй! Инстансинг - это использование инстансов. Как и каких именно - уже от контекста завит. Ясное дело, большинство разработчиков в первую очередь подумают о ООП и инстансах классов. Рендеринг и геометрия только тебе особенному в голову приходят.
А учитывая, что сцены в годоте по сути выполняют роль классов - нет ничего удивительного, что люди подумали, что ты об их инстансинге спрашиваешь.
Да всем просто поебать, нормальные люди изучают инструмент, учатся создавать игры. Им без разницы, как там фичу назвали, инстансинг, хуинстансинг, главное что оно есть, задокументировано и работает - почитал доки, понял, что это и для чего нужно, спокойно применяешь.
Ты один тут на говно изошёлся, как будто Хуан тебя лично выебал в жопу и написал на ней фломастером instancing.
Вы, бля, совсем не учитесь.
>2i19
>считать мегабайты
сложна
И чтоб покачивался при ходьбе?
Просто скачай ассет
https://godotengine.org/asset-library/asset/127
>>573829
>>573855
ПРОБУЕШЬ ГОДОТ
@
СИСТЕМА ЗАРАЖАЕТСЯ ЕГО БАГАМИ
@
ЛОВИШЬ ПО ПЯТЬ СИНИХ ЭКРАНОВ В ЧАС
@
УЗНАЕШЬ ТЫСЯЧУ СПОСОБОВ ВЕЖЛИВО ПОСЛАТЬ ПОЛЬЗОВАТЕЛЯ НАХУЙ ОТ ИНДУСОВ В ТЕХПОДДЕРЖКЕ
ПРОБУЕШЬ УЕЧ
@
УЕЧ СЪЕДАЕТ СНАЧАЛА ВСЮ ВИДЕОПАМЯТЬ, ПОТОМ ОПЕРАТИВНУЮ, ПОТОМ МЕСТО НА ЖЕСТКОМ ДИСКЕ, А ПОТОМ И ТВОЮ ЛИЧНУЮ
@
ВСЕ РАВНО КРАШИТСЯ С ПОТЕРЕЙ ПРОГРЕССА
@
ЖИВЕШЬ ДО КОНЦА ЖИЗНИ С АМНЕЗИЕЙ, ИЗ ВОСПОМИНАНИЙ ТОЛЬКО 4К ТЕКСТУРЫ
ПРОБУЕШЬ ЮНИТИ
@
НИЧЕГО СПОСОБНОГО ТЕБЯ РАССТРОИТЬ НЕ ПРОИСХОДИТ
@
ВЕДЬ ВСЕ САМОЕ СТРАШНОЕ С ТОБОЙ УЖЕ СЛУЧИЛОСЬ, ЕСЛИ ДОКАТИЛСЯ ДО ЭТОГО ДВИЖКА
В Годоте С# не работает => движок сосет
На плюсах разрабатывали игры еще до твоего рождения, и скорее всего всё еще будут и после твоей смерти. Это не извращение, а стандарт индустрии со времен её зарождения.
А шишарп в индустрии относительно недавно, его стали применять, чтобы юнити-додикам жилось попроще, ибо ЦА юнити не может осилить полноценное программирование.
В чем ты усматриваешь извращение? Современный c++ это не c++ 99 года. Он позволяет писать почти так же легко как на новомодных языках (некоторые идиомы правда принципиально отличаются, поэтому проще писать в плюсовом стиле чем натягивать сову на глобус). Плюс у тебя вся мощь оптимизаций, производительности, доступных либ и при необходимости возможность писать хоть фарш на шаблонах.
На самом примитивном уровне кодинга c++, python/gdscript и какой-нибудь js вообще не различается - я постил в тред годотуториал переписанный в лоб на плюсах.
Часть игор сделана на юнити! Ну не может же быть, что все эти игоры на гондоте?
https://www.youtube.com/watch?v=NlKEO1N8wMM
И ещё выкатили
https://www.youtube.com/watch?v=ODn4oOqWGik
Ебать ты тугой, это последствия передозировки юнити в организме? Когда настолько привык перетаскивать ассеты из маркета по сценке, что когда видишь буковы в посте, уже не вдупляешь, что они означают.
Откуда ты высрал про то, что шишарп создали для юнити? Черным по белому написано, что конкретно в ИНДУСТРИИ ГЕЙМДЕВА он начал получать распространение именно с приходом юнити.
Появился джава, который набрал обороты и захватил рыночек. Мелкомягкие просекли фишки и захотели отхватить часть рыночка ынтерпрайзного и выкатили свой сисярп. Он был простой, что образовалось много кодомакак, которым надо было куда-то деваться. Одна компания подсуетилась и выпустила игровой движок, который сделала под сисярп, шобы в свою очередь срубить бабла на вкатывальщиках под девизом, что нашу хуйню освоит и школьник и уже завтра вы выпустите свой крузис. Туда же стали подтягиваться школьники, которые на тех же мантрах, шо сисярп - это легко и это айти, гы-гы, срублю бабла и 300к/с.
На этом разговоры про сисярпы/юнити прекращаем в треде, буду затирать и банить, заебали школьники. Валите в свой загон в соседнем треде.
(Автор этого поста был забанен. Помянем.)
https://docs.godotengine.org/ru/latest/getting_started/step_by_step/your_first_game.html
https://www.youtube.com/watch?v=C0szslgA8VY
Я спросил мне не ответили.
Вот вопрос >>574173 >>574178
Руководство https://docs.godotengine.org/ru/latest/getting_started/step_by_step/your_first_game.html
Время покормить деревотяночку говнокодом!
Вениамин ненастоящее имя
>>574595
>Я мимо.
А я?
Рассказываю. Я запилил самый простой в мире, но мощный конфигуратор приложух. Уже юзаю его в двух своих проектах.
https://www.youtube.com/watch?v=Yiew9ru-6a0
Вот вам универсальный гайд
1. Используете шарп вместо гдскрипт - производительность растет раз в 400.
2. Максимально сокращаете количество нод и вызовов к api годота. Особенно вызовов, которые перестраивают древо сцен. Производительность растет в дохуя раз в зависимости от количества сокращений. В моем случае прирост был даже больше чем от шарпа.
Дерева сцен нет, тот анончик обдолбался. Дерево нодов: все вызовы, которые будут создавать или удалять ноды в твоей сцене. Т.е. как бы логично, что если уменьшать количество объектов и количество логики в твоей игре, то она сможет быстрее работать. Короче он по всем пунктам написал какую-то хуйню.
>Древа сцен нет
https://docs.godotengine.org/en/3.1/getting_started/step_by_step/scene_tree.html
SceneTree - это у тебя древо нод, но обдолбался я. Хорошо.
>уменьшать количество объектов
Не просто объектов. У тебя могут быть, например, шарпо-объекты, которые не наследуются от нод и создаются при помощи new - они очень быстро работают. А есть тормозные ноды, у которых даже элементарный GetNode занимает дохера времени.
>>574686
Ну юзай кресты тогда, на них тоже игры можно делать. Для меня шарп куда более удобен.
>>574688
Например, AddChild, RemoveChild, MoveChild.
Игрушка - симулятор жителя города. Кроме игрока есть и другие жители, которые имеют те же возможности, просто ими управляет ИИ. Игра пошаговая 1 ход - 1 минута игрового времени. Если игрок, допустим, спит, то он пропускает 600 минут/ходов и игра должна просимулировать город на эти 600 ходов. Тут уже была заметна небольшая задержка между нажатием кнопки и выводом результата.
Перед тем, как запускать игрока в город - город симулируется 3-6 игровых месяцев для создания его истории и отношений между жителями. Вот тут гдскрипт, ноды и я вместе с ними соснули по полной.
Сейчас перенес проект на шарп, вот что получил: 120000 ходов гдскрипт-нодо версия считает 30+ минут (мне просто надоело ждать и я закрыл приложение, поэтому конкретного числа нет), шарповерсия считает 4 секунды. На случай, если вылезет умник и скажет, что гдскрипт-нодо версия попала в бесконечный луп - нет, нет попала. 12000 ходов она считала 6.5 минут, шарп их считал меньше секунды, а миллисекунды я не замерял.
И если вы думаете, что у меня там пиздец какая сложная симуляция, то вы ошибаетесь. Игра сейчас на стадии макета, в конечной версии расчетов раз 10-20 больше будет. И вот если увеличение шарповских 4х секунд в 10-20 раз пережить вполне можно, то годотовских 30+ минут нихуя нельзя.
Сейчас годот у меня по сути выступает фронтэндом для шарпа - рисует гуй, менеджит медиа ресурсы, рендерит. Игровая логика его считай не трогает, и все хорошо.
Короче, не повторяйте моих ошибок. Если у вас в игре есть даже намеки на сложные расчеты - сразу шлите нахуй гд скрипт и перекатывайтесть на решетки/кресты. Если планируете использовать много нод, то сначала сделайте себе бенчмарк и убедитесь, что производительность вас устраивает.
> Особенно вызовов, которые перестраивают древо сцен.
Прокомментируй плиз, насколько быстро будут работать объявления объектов на сцене в стиле дельфи?
Типа такого:
onready var Image1 = $Scene/Images/Image1 as Sprite
onready var Body1 = $Scene/Bodies/Body1 as KinematicBody
Затем в остальном скрипте обращаться только по этим именам.
>насколько быстро
Все познается в сравнении.
$ - это тот же get_node. Вызов к апи годота, что всегда не быстро. Однако, если одновременно много get_node не запускать или запускать их во время загрузок, то жить можно.
>Затем в остальном скрипте обращаться только по этим именам.
Это относительно быстро.
Вообще описанный тобой метод - самый логичный, если нужно использовать ноды. У меня так гуй работает.
Невероятное совпадение, но я тоже это использую для гуя. У меня включилась аналогия: гуй -> экранная форма -> delphi
По вопросу тормознутости гдскрипта - это никогда не было секретом. Гдскрипт тормозит и в высоконагруженных участках следует юзать шарп, плюсы или любой другой язык, на котором сможешь ре-имплементировать АПИ годота и сварганить либу для нативскрипта.
Да это сразу понятно было, что ноды на самом деле дорогие, но почему-то форсятся как то, что используется для каждого пука.
https://github.com/godotengine/godot/issues/23052
Но вообще логично - если сложные вычисления нужны - нахуй гдскрипт. На него ещё жаловались вот здесь:
https://www.reddit.com/r/godot/comments/47j49k/gdscript_is_very_slow/
И что-то мне кажется, что ситуация не сильно поменялась.
А вот интересно, стал ли гдскрипт быстрее после введения типизации в 3.1.? Кто-нибудь проводил тесты?
Ведь динамическая типизация Хуана означала повсеместное использование типа Variant, а это лютая хуета. Помню, от него еще на кодерских форумах в 2004 плевались.
Соответственно, в гдскрипте без типизации строка:
var a = 1
означает в гдскрипте с типизацией:
var a : Variant = Variant.int(1)
Вы могли подумать что это int, но хуй там плавал!
Фанбои то? Это самый рак любого коммьюнити обычно - челики, которые тупо минусуют и кукарекают. Там довольно правильные вопросы поднимаются. Например, то, что должно по идее быть отдельным объектом памяти навроде твина или логического хитбокса - в годоте будет отдельной сущностью, которая в дерево добавляется. Вот и думай, в итоге у тебя даже простая сущность с анимациями будет как минимум 5 нод в себе содержать.
А потом такие челики спрашивают про 50к объектов. Загрузка скриптов отдельно вообще недавно появилась, я вообще хуй знает как жили люди, для которых её не существовало. Какое-то разделение логики или нормальная архитектура сразу нахуй идёт с таким подходом.
И это почти что единственное нормальное обсуждение воркфлоу, которое я нашёл.
>отдельным объектом памяти
Эксперт подал голос.
>спрашивают про 50к объектов
Это ненормально много, там его правильно макнули, что для этого уже надо быть на другом уровне разработки. Инстансингом хотя бы научиться пользоваться.
>я вообще хуй знает как жили люди, для которых её не существовало.
Создавали синглтон, тащемта никакой проблемы рулить другими нодами из корневой нет.
>И это почти что единственное нормальное обсуждение воркфлоу, которое я нашёл.
Там больше похоже было на "никто не знает как пользоваться годотом!" - "чувак, просто прочитай туториал и доки" - "ой бляя я тупой, удолите топик"
>> Но вообще логично - если сложные вычисления нужны - нахуй гдскрипт. На него ещё жаловались вот здесь:
https://www.reddit.com/r/godot/comments/47j49k/gdscript_is_very_slow/
Поэтому недавно на конференции Хуан обрадовал тем, что будет официальный еще Haxe.
>Haxeр
Почитал. Годнота! Хуан, делай. Анон разрешает.
Так-то в этой годноте нет ничего нового или удивительного, в раст и хасскель такие типы завезли уже много лет назад.
Но по сравнению с убогим gdscriptом это конечно прорыв, я рад что Хуан одумался и понял, что пытаться реализовать свой язык с нуля, если ты не эксперт в этом - хуевая идея.
https://github.com/godotengine/godot/issues/6194
Вы типо так же делаете? Каждая такая хуйня это теперь должна быть Area2D с коллайдером?
Твоё понимание было ужасно. А виноват как всегда движок.
Вот тут почитай https://docs.godotengine.org/en/3.1/tutorials/inputs/inputevent.html
Если в двух словах - лови клики в unhandled_input, а не _input - тогда гуй будет перехватывать раньше.
И да, инпут в годоте это фарш, будь готов к тому, что клики на спрайтах могут обрабатываться не в том порядке, в каком они отрисовываются.
>Почему для тебя это забавно?
Потому что ты выдаёшь забавные проекции типа этой:
>Для тебя неприемлима сама мысль, что
Походу ты уже для себя определил, КТО я и ЧТО я. Посему не вижу смысла тебе что-то объяснять.
Для нормальных-адекватных же напишу, что в годоте ивенты вызываются в произвольном порядке, в зависимости от загруженности движка задачами, поэтому нельзя пизать перекрывающие друг-друга инпуты, которые будут обрабатываться в рандомном порядке. Если изволил вывести на экран модальную гуй-форму, то изволь позаботиться о блокировке инпута в игровой сцене.
https://github.com/RodZill4/godot-openstreetmap
https://www.youtube.com/watch?v=tOCpIcSvODE
Эх, надо плюсы учить, но мозги уже старые - не понимают.
Чтобы не быдлокодить, по современным плюсам много ресурсов. Ну например https://github.com/AnthonyCalandra/modern-cpp-features
Просто делать можно на каком-нибудь питоне. На шарпе уже периодически надо прерываться и в документацию посматривать. А на С++ - ад пиздец и израиль. Удовольствие может получать только мазохист, ну или перодлик, которому не код писать надо, а с библиотеками и настройкой ебаться.
Неужто гдскрипт НАСТОЛЬКО тормозов привносит?
Просто пытаюсь сейчас кое что запилить (в стиле "поймай много объектов"), вот пока только с математикой поведения объектов разобрался, доходит до пиления этого всего, и у меня возникает вопрос, а не усрётся ли гдскрипт от просчёта этого поведения на столько игровых объектов (например от 5 до 15 тысяч)?
С одной стороны, кресты мне импонируют, и я скорее их люболю. С другой стороны, монстрячиться с модулями и сопряжением срр с годотом не хочется, да и вполне логичным выглядит написать это всё средствами же ide. Но боюсь, что без плюсов оно реально может усраться (столько-то считать).
Не, нахуй-нахуй. Я с паскаля начинал своё знакомство с миром программирования, и я был несказанно рад, когда познакомился после паскаля с крестами. Даже vb98, да простят меня предки, мне показался более вменяемым, чем паскаль (если вообще можно так о vb98 говорить).
>>575557
Ну то есть оно у меня, вероятно, умрёт?
>Движки по сути предлагают инфраструктуру для простых игр, ну там 10-20 объектов, может быть 100 более простых.
Не знаешь, не пизди. У меня в уече остров есть, где одних только деревьев около 20к инстансов, а там еще трава, камни, ветки на земле, которых еще больше. Слава Foliage Tool с динамической генерацией растительности!. Все нормально работает в 30+ фпс, но у меня пека не очень и оптимизацией я еще занимаюсь.
Просто инструмент нужно правильно подбирать под задачу.
>>575560
Оно у тебя не умрет, но тормозить будет. Даже если напишешь идеальный С++ код, годотоноды все испоганят. Под еба-производительность бери какой-нибудь шустрый фреимворк и все нехватающее пиши сам или используй уеч.
Начальные элементы ну до 9 знаков после запятой присутствуют. Собственно, как я понимаю, мне надо сделать всё в модулях - формирование первичных значений с точностью в эти самые 7-9 знаков), передать значения в другие модуля/функции, где они будут использованы для обсчёта, а уже оттуда получать с точностью условные 5-6 знаков в сам годот для использования в построении сцены?
Может я упоролся, пытаясь чуть-чуть математики заюзать в проессе?
Сейчас бы спиздануть что-то про точность и не понимать, как работает плавающая точка на современных процессорах.
На, просвещайся, мыслитель.
https://habr.com/ru/post/305276/
Спойлер - плавающая точка и точность вообще не сочетаются, выбери что-то одно.
Всё, вопрос снимаю. При итерировании списка объектов получаются динамические объекты (или как там правильно) и это считается не типобезопасным.
При итерировании через инт всё зелёненькое.
Деда, ты б погуглил и не позорился:
https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/nullable-types/
Причем тут шарп и null вообще, наркоман?
Притом, что доки читать надо.
Гдскриптовский if рассматривает выражение при нём (повторяю при нёооом) как nullable type (которыми все гдскриптовские типы и являются у Хуана, в дотипизированном стандарте из 3.0. вообще был только один тип nullable variant).
И гдскриптовский if срабатывает когда выражение не:
1. 0
2. null
3. ""
4. Vector.ZERO
И т.д.
Когда пишешь код правильно, нужные фичи получаются сами собой.
Вот пишу вчера код, добавляющий экземпляры формочки с текстовыми полями в общий контейнер. Для М/Ж/БГ/ГК вариаций этих самых текстовых полей. И тут такое дело, при создании новой ветки дерева контейнер оказывается пустым. Я сначала бросился было дописывать костыль, чтобы при переходе в новую ветку автоматически вызывалось создание первой формочки, но внезапно понял, что мне именно пустая форма будет нужна, потому что при выводе в файл запроектированы записи без текста, но с параметрами.
Держу в курсе, кароч.
Переменная PlayTime была придумана чтобы дать LOOP анимации моргания поиграть какое-то (случайное) время, про is_playing я в курсе, и потом выключить. Но я еще не придумал, как это оптимально сделать...
>как это оптимально сделать
Равномерное горение лампы не является анимацией.
Анимацией является моргание.
Моргание это: однократно затемнить -> засветить
Таким образом ты пилишь только анимацию моргания.
Затем в коде объекта-лампы пишешь функцию, которая... Знаешь, я бы даже кинул в объект лампы таймер, у которого функция при таймауте рандомно меняла бы ему интервал и запускала анимацию моргания.
Только надо проверить, не вызывает ли таймер свой таймаут при изменении интервала?
Нужно было лучше подумать, перед выбором движка, тогда бы не грабанули.
https://www.youtube.com/watch?v=vmIuDNmC2Y4
Только я тебе ещё посоветую создавать таймер кодом. Тут выше дискасс был за медленность обработки нод по путям в сцене. Я этот дискасс полностью подтверждаю.
Создать ноду в коде ненамного сложнее, чем вызвать get_node(), зато ты сможешь создавать любое количество мелких объектов для различных утилитарных задач, не заморачиваясь их расстановкой по сцене.
Например, вот мой велосипед для быстрого вызова окошка-сообщения:
Ух, анончеги, чтобы получать значение нажатой кнопки удобным и привычным мне образом, мне пришлось нагородить велосипед с тремя квадратными колёсами!
Есть ли способы изящнее?
Вениамин ненастоящее имя
>Вениамин ненастоящее имя
Мечтаешь быть евреем?
>окно вылезает за пределами монитора
Интересный случай. У тебя несколько мониторов?
Проверял на пустом проекте, то же самое центрируется за пределами монитора, когда размеры игрового окна превышают расширение монитора.
УМВР
Обратись к Хуану за помощью.
Пиздос, в годот не завезут спрайт батчинг до версии 4.0, Хуану слишком сложна перепилить рендеринг по это.
Зато завезли такую мега-важную фичу, как возможность отключить часть функционала редактора, чтобы неосиляторы не пугались.
> в годот не завезут спрайт батчинг
Ты мне так и не ответил на вопрос. Вот допустим, отважные двачеры форкнули бы годот, завезли бы в него спрайт батчинг.
Ты на полном серьёзе считаешь, что после этого у тебя бы сразу появились игры?
Не льсти себе, ты просто оправдываешь свою прокрастинацию тем, что в %движокнейм% нет %фичанейм%, потому что разрабу якобы лень перепилить %модульнейм%.
Если бы ты реально хотел делать игры, ты бы перекатился на другой движок или фреймворк. но ты упорно продолжаешь срать в годотреде.
Репорт.
Ентот простолюдин прав, еще бывает такое усложнение (на уровне дауншифтинга), когда имея весь инструментарий "забаводел" усложняет сам себе работу, ограничивая себя разными надуманными часто условиями. Надо просто делать игру, здесь и сейчас, не больше не меньше И.Г.Р.У.
А чё, в годоте нет спрайтбатчинга? См. рис. 1.
Серьёзно, неявный спрайтбатчинг уже даже в SDL2 есть для большинства рендер-таргетов, не говоря уж о двиглах типа Love, которое на Lua в котором, я напомню, в стандартной библиотеке даже string.split нет
>Ты мне так и не ответил на вопрос.
А я с тобой в этом треде и не общался до этого.
>Если бы ты реально хотел делать игры, ты бы перекатился на другой движок или фреймворк.
Так и сделал, перекатился на аметист, пилю потихоньку свой рендерер с батчингом, который собирает все спрайтшиты в одну большую текстуру и рендерит весь мир за один draw call без переключений текстур/шейдеров, получается охуенно, рендерит несколько десятков тысяч тайлов без просадок фпс.
Но за годотом продолжаю следить и надеяться, что его доведут до ума со временем.
А у тебя много игр на годоте? Или ты просто так обвиняешь всех в безигорности, при этом ничего не сделав сам?
>>576805
Порталы видимо тоже в четверке придется ждать, 3.2 больше похож на какой-то минорный релиз, ни одной киллер-фичи.
>>576806
Ну если тебе норм, что у твоей 2д И.Г.Р.Ы. будут системные требования как у крузиса и просадки фпс на не самом топовом железе, то флаг тебе в руки. 50000 draw call'ов на 5000 спрайтов - это просто несерьезно для движка, который заявляет, что 2д это его сильная сторона. Даже в древней xna спрайт батчинг есть из коробки, что позволило запилить на ней ту же террарию, где на одном экране может рендериться по несколько тысяч динамических тайлов с освещением.
https://github.com/godotengine/godot/issues/1527
>аметист
Интересно насколько гибок там скриптинг. Если он на голом Расте без какого-либо подобия сборщика мусора поверх (как в UE4 поверх C++) или встраиваемого языка с оным, то скриптить, сдаётся мне, будет слишком зажато и неудобно. Но именно для рендерера этот динамизм не нужен, да.
Скриптинга из коробки пока нет, аметист вообще пока довольно сырой, версия 0.1 как-никак. Писать сейчас что-то на аметисте - равносильно тому, чтобы писать с нуля, ты от него получаешь только абстрации над ОС, неплохой менеджер ресурсов с возможностью допиливания кастомных форматов данных, стейт машину и ECS, и уже поверх этого накидываешь всё руками сам. Так что это скорее SDL на стероидах, чем какой-то полноценный движок.
Мейнтейнеры вроде хотели добавить какие-то скриптовые языки, но это еще нескоро случится.
Так что да, пока только хардкор, только голый раст.
Но там близкая к идеальной реализация ECS, так что можно попробовать накидать скриптинг самому, подключить враппер луа в виде отдельной системы, например.
Но мне до скриптинга еще много чего предстоит запилить, так что пока не думал об этом.
Для большинства людей делать игру на чем угодно, в том числе и годоте - 1000% гарантия никогда не доделать игру. Как думаешь, если взять для статистики тысячу человек, скачавших годот, сколько из них зашли дальше туториалов с офф. сайта, а сколько сделало что-то законченное?
Геймдев не только про программирование, движок и код это только малая часть того, что нужно для того, чтобы доделать игру.
>>576827
Так твой пост ни о чем.
Годот не обладает всем инструментарием для создания всех возможных игр. Мне, например, нужно построение навигационного графа по бесконечно растущему в 4-ех направлениях квадратичному дереву, в котором хранится игровой мир, чтобы персонажи могли сами добегать из точки А в точку Б, преодолевая любые расстояния. Наверное сам догадываешься, что будет если писать это на gdscript'e. Можно было бы вынести это в модуль на плюсах, но опять же, будет проблема с рендерингом, 120 на 80 тайлов на экране - звучит не так уж и много, но это уже почти 10к спрайтов, что равносильно смерти для рендера годота, учитывая что эти тайлы динамические и их нельзя запечь в статический тайлмап. Вот и думай сам, где тут надуманные условия для ограничения себя. Или ты опять скажешь, что это всё нинужно, просто нужно делать И.Г.Р.У.? Посоветуешь отказаться от бесконечно генерируемого мира и ограничиться уровнем 100 на 100 тайлов, чтобы годот не помирал от нагрузки?
И это только один конкретный пример, можно придумать еще целую кучу концепций, которые в принципе не представляются возможными на годоте в его текущей реализации.
Для ряда задач он хорош, конечно, если делать что-нибудь не особо сложное, какие-нибудь 3 в ряд, платформеры с небольшими уровнями, и т.д., годот справится с этим хорошо и по скорости разработки у него не будет равных. Но это небольшое подмножество несложных игр не равно всем возможным идеям на свете.
>Так твой пост ни о чем.
О намеренном нерацианальном торможении процесса создания игры, может тебя это не касается конечно.
>Годот не обладает всем инструментарием
Ну да, разве я писал обратное, вообще его не защищаю, может тебе Ю.Н.И.Т.И. подойдёт лол.
>Или ты опять скажешь, что это всё нинужно, просто нужно делать И.Г.Р.У.?
Именно, а если инструмент не справляется с твоими гениальными техническими задумками. возможно на этом построен уникальный геймплей, найди подходящий инструмент, или начинай делать игру с тем функционалом который есть.
>Посоветуешь отказаться от бесконечно генерируемого мира
Дело твоё, мне такие игры не нравятся. У меня была идея создать особую генерацию, понятно что секрет этой уникальной технологии я не могу разглашать, вокруг нас гениальные воры и бизнесмены, не хочу очередной раз прочитать, как кто-то реализовал мою идею и заработав миллиарды переехал в Кремниевую долину.
В этих всех конструкторах есть один серьезный минус, они все в результате несут в себе весь функционал и поэтому весят не адекватно проекту. 2019 год и до сих пор эти рукожопы не придумали способ хотя бы модульной "компиляции" на основе используемых возможностей в игре.
Вопрос: насколько похож? Прокачаю ли я свои навыки в python, если завершу проект на Godot с использованием GDScript понмаю, что многое зависит от сложности проекта, но все же.
Меня пугает то, что у Godot по сравнению с Unity очень маленькое сообщество. Хз даже есть ли на stackoverflow тег godot. Уверен, что на тостере точно нет.
Еще это вроде сырой движок. Насколько он багованый? Оптимизированный?
Как следствие небольшогопо сравнению с Unity - нулевого комъюнити - это минимум туториолов и готовых решений.
Кто-то сталкивался с адаптацией проекта под разные разрешения экранов на мобильные платформы или созданием мультиплеера? Насколько сложнее по сравнению с Unity, если там это делали?
Мне почему то кажется, что многие перекатились в godot с Unity или Unreal. Есть ли здесь такие? Какие плюсы и минусы можете отметить по сравнению с гигантами инди геймдева?
Пришло время покормить деревотяночку говнокодиком!
>Посоветуешь отказаться от бесконечно генерируемого мира и ограничиться уровнем 100 на 100 тайлов, чтобы годот не помирал от нагрузки?
Я бы посоветовал ленивую генерацию. В любом движке. И даже не чисто ленивую, а компромисс между ленивой и "трудолюбивой". Очевидно, что когда Довакин в Вайтране, нет смысла генерировать домики деревянные вокруг Рифтена, и нет смысла генерировать поведение нордов, курсирующих между теми домиками. Однако, есть смысл выводить на экран горы возле Рифтена, которые, допустим, видны из Вайтрана (которые не перекрыты Глоткой Мира). И есть смысл держать в памяти скрипт непися, который в Рифтене занят неким квестовым делом и должен отчитаться Довакину через N времени. Опять же, нет смысла загружать в память всего непися, вместе с его анимациями, репликами, маршрутами на навмешах и т.п., скрипты дел должны быть модульными и грузиться в память отдельно от, например, анимаций.
А то если ты попытаешься загрузить весь открытый мир, у тебя любой движок ляжет. Точнее ляжет не движок, а комп, обсчитывающий твой мирок поатомно. В онлайн-играх тоже отрисовка с обсчётом мира происходят в общем лениво, таким образом, что нагрузка на сервер прямо пропорциональна количеству игроков. Таким образом можно динамически, на лету, подключать к обработке мира новые серверы.
мимоархимаг
Я как-то делал генерацию карты "в лоб", при помощи простого рандомизатора, заряженного "случайным" сидом, и вывода в файл массив, висящий в памяти и выгружаемый в файл после выхода.
Логика токова: ЕСЛИ в файле нет инфы о участке карты, ТО сгенерировать новый и записать в файл, ИНАЧЕ загрузить из массива.
Получилось неоч, я не сообразил, как быстро доставать из массива нужный индекс, приходилось искать по массиву, что привело к тормозам.
Если бы я был у мамы умнее, я бы наверное умел использовать всякие дерева поиска, но увы.
Это самое, мне нужно было сделать свайп, чтобы на андроиде можно было между вкладками прыгать, очень долго трахался, в конце концов работает всё как задумывалось (на компе с мышкой, на андроиде ещё не знаю что ожидать). Можете оценить рукожопость? Мне кажется я всё сделал через задницу. Тут короче каждая вкладка это отдельный нод-спрайт, которые во вьюпорте наслаиваются один на другой, а переключение между ними происходит через изменение z-index. И ещё есть подозрение что я не понимаю что такое вообще функция, она же должна что-то всегда возвращать через return, не? Короче у меня вроде всё пашет как хотел на данном этапе но терзают смутные сомнения в правильности подхода.
Вениамин ненастоящее имя
В годоте есть встроенные табы. Я ими не пользовался, но на 99% уверен, что они лучше твоих велосипедов.
А вообще ты со своими велосипедами, незнанием что такое функция, монитором и Вениамином кажешься интересной личностью. Не прекращай отписываться в тред о своих успехах.
>В годоте есть встроенные табы.
И вот в этом >>576020 проекте они активно используются.
>>577543
Веня! Юзай табы годота. А оформление сделай через тему.
> есть подозрение что я не понимаю что такое вообще функция
В паскалеподобных языках есть разделение на функции и процедуры. Функции возвращают значение, процедуры - нет. В сиподобных языках (которым, несмотря на пайтон-табуляцию, является годоскрипт) понятие процедур заменено функциями, которые имеют тип void (пусто).
Годоскрипт ещё и динамически типизируемый, это значит, что ты можешь не возвращать значений, а потом хуяк - и возвратить.
Любое слово return в функции вернёт null (void), любой return с параметром, например, return null вернёт в общем случае тип Variant, содержащий в себе указанное значение, в моём примере, тот же null. Логически это похоже, но технически немного другое. С появлением типизации, если функция объявлена как, например, -> String: она сможет возвращать только строки, например return "venya", кроме того, компилятор годота будет требовать от тебя, чтобы все ветки кода внутри такой функции были явно завершены return'ом.
Пять секунд в редакторе тем:
Возможно лучше пикчей, ибо годотовые стайл-боксы выдают кривые скосы. Вот здесь ширина границы задана одинаковой, но на деле разная.
Бида. Вот так выглядит 9т.
>>577597
>Ну это жи опенсорс.
Конпелируй на здоровье.
Шейдеры - сила! Гдскрипт - могила!
Ага, спасибо! Прояснил моменты!
Короче табы встроенные нищебродские в плане дизайна как я понял, наверно оставлю свои + потом наверну еще на них эффектов в фотошопе чтоб получше смотрелись.
Делал сегодня конструктор планет, сначала смотрел видосы по процедурной генерации, но это слишком сложно для меня, поэтому решил слоями текстуры накладывать друг на друга.
Получилось вроде норм, мне пока такое подойдет, потом ещё улучшу/добавлю/заменю текстурки когда основную механику игрули сделаю.
Вениамин ненастоящее имя
Ну то что будут выглядеть как говно я не исключаю, не могу проверить на данный момент, при экспорте проекта на андроид вылетает ошибка с jarsigner (ну с этим я разберусь). Но вот то что при другом соотношении сторон табы разъебутся, ну хз, чем они отличаются от других спрайтов в игре, которые не разъёбываются? Они же вроде как должны подгоняться под экран в заданных пропорциях. Сами табы у меня 1900х1000, окно игры 1920х1080, если запускать с разрешением отличным от 16:9, полагаю там просто будут черные полосы, где размер короче.
Не пробовал сам со встроенными табами играться, почитал что вы написали, вроде сами не в восторге от них.
Кароч, ящитаю, каждую локацию следует делать отдельной ветвью в структуре данных, чтобы при загрузке сразу грузилась эта ветвь и не трогались остальные, из локаций, которые не загружены.
На пикчах я накидал пример использования.
Во, анончик, гляди, всё как и предполагал, черные полоски сверху и снизу, т.к. планшет не 16:9, не распидорасило зато. На табы нажимать неудобно, это да, но это касалось бы и встроенных тоже. И это планшет 9" на мобилках вообще хрен попадешь наверное. Буду думать.
Спасибо за фидбек.
Там ещё текстурный стайлбокс есть, я хотел тебе гайд накинуть, но там похоже, баг с выводом его в инспектор. Можно создавать его как отдельный ресурс, а потом грузить в тему сохранённый файл, но это такая еботня, так что делай как делается, у тебя неплохо выходит, в стиле дос-приложений, как я полагаю.
Словари в гдскрипте передаются по ссылке. Таким образом, можно делать процедуру (void функцию) у которой один из аргументов - словарь и процедура меняет в нём данные по ходу работы.
Вы спросите, нахуй это нужно, если можно просто возвращать значение функцией?
А я отвечу. Сигналы. Они же события. Всё это войды. И словари это уникальный хитровывернутый способ обмена данными через сигналы.
Пример:
В одной ноде объявлен сигнал get_data(data)
В другой ноде этот сигнал приконнекчен к процедуре on_get_data(data : Dictionary) -> void: data["result"] = "gotovo"
В третьей ноде мы делаем вот так:
var data : Dictionary = {}
node1.emit_signal("get_data", data)
После чего в переменной data будет содержаться { "result" : "gotovo" } это данные, которые пришли из второй ноды, о которой третья нода ничего не знает!
Ну не охуенно ли?
Подскажите, пожалуйста:
Вот например у нас поле с квадратами, какие лучше ноды использовать для них?
Сами квадраты выглядят убер просто, мне придется использовать для них спрайты, или есть вариант стилизации (задать цвет, границу, тень, как в CSS например)?
Спасибо за наводку.
Вообще оказалось сложнее чем я думал. Ну хоть немного с созданием интерфейса разобрался.
>Хватит проводить реанимацию годотреда, все, СДОХ! Перекатывайся из под шконки к нам уважаемым людям в юнититред.
Если кому-то вдруг захочется посмотреть на говнокод, то вот
https://github.com/AlexSanchez101/15-puzzle
Вот реально хотел бы выслушать плюсы и минусы, что выбрать вкатывающемуся в 2д-игростроение.
>реально хотел бы выслушать плюсы и минусы
Гамак - платный продукт с закрытыми исходниками. Это всё, что нужно знать об гамаке.
Это вендорлок, тебя привязывают к определенному продукту, чтобы ты не был способен перейти на другой без жертв.
С годо ты свободен в выборе дополнительного инструментария, ты так же свободен в перепиливании исходников движка под себя (хотя мало кто может в сегодняшнем дне, да).
Скорость исполнения скриптов меня не волнует. Когда я упираюсь в производительность гдскрипта, я перехожу на шарп. Когда Если упрусь в производительность шарпа - найму крестовика для оптимизации. А что может предложить гамак? Велосипедный GML без альтернатив? Ну хуй знает.
Мне вот дефолд очень нравится, своей возможностью кастомизации, нужно уместить игру в 200кб? пожалуйста Редактор есть, шейдеры поддерживает, 3д поддерживает, хотя и придется ручками дописывать некоторый функционал.
Но, я чертов сектант и получаю удовольствие только когда использую свободный софт. И под мои хотелки хватило бы дефолда за глаза, но т.к. я сектант для html использую phaser для остального godot.
>билд вместе с ресурсами игры < 10мб
Что за требование такое? 20 мб низзя, 10 можна!
У меня даже на играх которые по 8мб весят постоянные отзывы что игра долго грузится, спасите помогите. Вообще основная аудитория игроков это всякие въетнамы, Индонезии хз как так вышло но Европа+асашай очень мало играет в мои игры по этому важно, чтоб игра весила максимально мало
Кстати там мудрая вещь написана.
Настроить сервер, чтобы он отдавал файлы сжатые gzip'ом
Ничего не делая это дает сходу сжатие в 4 раза.
>Гамак - платный продукт с закрытыми исходниками. Это всё, что нужно знать об гамаке.
Исходники нинужны
>Это вендорлок, тебя привязывают к определенному продукту, чтобы ты не был способен перейти на другой без жертв.
>С годо ты свободен в выборе дополнительного инструментария, ты так же свободен в перепиливании исходников движка под себя (хотя мало кто может в сегодняшнем дне, да)
Почти ничего из этого сегодняшнему инди разрабу на геймаркеты и стимы нинужно. Это нужно только всяким заинтересованным сектантам, целью которой является даже не игру сделать, а какую-то демку лично для себя, чтобы через пару дней выложить её на гитхабе и забросить. Примеров обратного я практически не видел.
>выборе дополнительного инструментария
Только если в плане выбора языка на годоте от гдскрипта до сисярпа, это я согласен
Но GML это ебаная дрисня, я тоже согласен.
https://www.reddit.com/r/godot/comments/blp9kk/a_3d_space_shooter_that_i_made_in_a_48hour_game/
>И это планшет 9" на мобилках вообще хрен попадешь наверное. Буду думать.
Из интересного. Начинают процветать ебанутые соотношения сторон вида 18,5 на 9. Это если вдруг соотношения для тебя имеют какое-то значение.
А вот что касательно ситуации неудобных табов для нажатия пальцем. Из вариантов вижу запилить под мобилки несколько модифицированный интерфейс, где табы вызываются в виде отдельной подмениюхи при нажатии по квадратной кнопке, в которую попадать пальцем легко. ну и, соответственно, в выезжающем меню табы тоже заменены на квадратные кнопки для лёгкого попадания пальцами. Типа пикрилов.
>>576308
Добрался снова до своих ламп. Что-то медленно разработка идет, лол.
Похоже в доках не то что-то, там randi_range в апи референс описании, а на самом деле видимо rand_range. ??
Ну рассмотрю варианты, лол.
Кстати, так и не понял, в TileMap(TileSet) нельзя добавить AnimatedSprite в принципе? Как скажем воду сделать на карте анимированную...
>>579344
>Похоже в доках не то что-то, там randi_range в апи референс описании, а на самом деле видимо rand_range. ??
Походу понял, одни (ранди_ рандф_) будут если генератор создать, а второе типа глобальная функция. Тяжело быть очень хуевым программистом-любителем.
>так и не понял, в TileMap(TileSet) нельзя добавить AnimatedSprite в принципе?
Нет, но ты можешь сделать анимацию меняя индексы тайлов в заданной ячейке, а фреймы анимации добавить как тайлы. Но это выглядит костыльно. Может знающие кодеры толковее подскажут? Подождём.
>>579351
>дни (ранди_ рандф_) будут если генератор создать, а второе типа глобальная функция
рандф даёт дробное число, ранди даёт целое, ранд_рэйндж даёт дробное в заданном интервале.
Вот тебе мой вариант моргания, без корутин, простой как УАСЯ. Аниматед спрайт тут вообще не нужен.
И вот как он выглядит))
Итерировал бы этому массиву индексы джва часа!
>>579360
Ну это ж просто пример, анончик. Само собой, ты можешь сделать анимацию любой сложности, главное, чтобы она была короче, чем blink_min и чтобы она не была зацикленной (потому что таймер сам будет её запускать)
Алсо могу показать, как тоже самое сделать на корутине со scene_tree-таймером.
>Алсо могу показать, как тоже самое сделать на корутине со scene_tree-таймером.
Так даже короче выходит:
> разница в производительности, если писать на шарпе?
Смотря где. Если у тебя оператор for в колбэке _process(delta), который в своём теле опрашивает ноды по строковым путям, то в шарпе будет ЗВЕРСКИЙ ПРИРОСТ ПРОИЗВОДИТЕЛЬНОСТИ.
Но, скажем прямо, пихать в процесс for обрабатывающий строки - это долбоебизм и неправильная архитектура.
В большинстве игор у тебя микроскопические действия вызываются событиями вроде инпута или таймеров. Или при окончании анимации. Обрабатывать такое без разницы где. Различия в нанопикосекундах никто не заметит.
А выполнять какие-то сложные матан-расчеты можно отдельным модулем, годот позволяет подрубить либу, юзать шарп и даже модуль на сях прилинковать к исходникам годота и пересобрать.
Почему бы паришься про производительность, еще ничего не сделав? Просто бери движок, делай и не парься, с вероятностью 90% движок покроет твои скудные идеи и ты ни разу не вспомнишь про производительность.
Если ты делаешь что-то грандиозное и в один момент понимаешь, что все тормозит, то тогда уже можно задуматься, как оптимизировать, оптимизировать то, чего еще нет - бредовая идея.
А вообще, если тебя так парит перфоманс, то годот не для тебя, годот это скорее про удобство, а слабый перфоманс как плата за это удобство тебя ждет в любом случае, независимо от скриптового языка.
Если один аудиоплеер играет фоновую музыку, а второй плеер в объектах играет короткие звуки, то общий звук превращается в ПИЗДЕЦ!!!
ЧЯДНТ?
1) Как обстоят дела с ошибками кода движка? Движок часто вылетает или после компиляции происходит не то, что написано? Можете выразить это ввиде число_вылетов/день_разработки
2) Не смог найти релиз дату 3.2 версии, никто не знает когда выйдет?
3) Какие недостатки, отсутствующие возможности у движка, по вашему мнению?
Для 2д главный недостаток - нет спрайт батчинга, чем больше спрайтов на экране - тем больше начинает тормозить, каждый спрайт рисуется отдельным draw call'ом.
Еще глитчи и статтеринг, от которых никак не избавиться. Разработчики движка обвиняют nvidia в том, что они специально подкладывают им свинью в драйверах, чтобы только у годота были глитчи и статтеры, а в остальных движках все нормально.
Очень плохо, я так понимаю, это частая проблема? Если да, то такое недопустимо для коммерческого производства, просто потому, что эту ошибку я не смогу проконтроллировать и исправить.
Проблемы актуальны и на последнюю версию 3.1.1? Нету способов их разрешения?
И касательно обвинения нвидия, это действительно так?
По идее, то что проблема на стороне разработчиков драйверов, можно проверить путем проверки работы проекта на nouveau на линуксе.
Вот тут про nvidia. Хуан вместо того, чтобы пофиксить рендер в движке, строчит разрабам nvidia, чтобы фиксили драйвера.
https://github.com/godotengine/godot/issues/9913#issuecomment-451960340
Еще до кучи.
https://github.com/godotengine/godot/issues/19783
Проблемы актуальны для 3.1, фиксы скорее всего будут в 4.0 - когда рендер полностью перепишут с нуля на вулкан. То есть, в ближайшие пару лет это вряд ли случится.
>Для 2д главный недостаток - нет спрайт батчинга, чем больше спрайтов на экране - тем больше начинает тормозить, каждый спрайт рисуется отдельным draw call'ом.
Где об этом прочитать? Я сделал тестовую сцену, чтобы посчитать draw call'ы, а мне пишет, что их ноль. Я не думаю, что анон пиздит, скорее всего пиздит годот. Правда же? Анон же не может пиздеть?
Почитать можно тут.
https://github.com/godotengine/godot/issues/1527
>>579983
>>579982
Почитаю пока. А то что-то я заебался спрайты создавать, в ожидании, пока фпс просядет.
О, кстати, хорошо, что не закрыл:
>Here's what I found out from the 5000 sprites benchmark :
>Testing 5000 sprites on screen without dynamic batching:
>Unity 5: 50001 drawcalls, 173 fps
>Godot: 50001 drawcalls, 175 fps
Как правильно измерять фпс? Годот же пиздит, а вы не пиздите, братишки!
>>579996
Блеать, не работает эта хуйня. Нет ли софта попроще? Навроде GPU-Z?
Пришлось экспортнуть проект. В общем вот такие дела: Спрайтов много, больше на единицу экрана, чем в тех видосах по фактории, что я посмотрел на ютубе. Все спрайты анимированы. ФПС просел со 144 до 60. Без батчинга, на который тут все молятся.
Резюме: Я согласен с Хуаном (в его посте по ссылке), что батчинг - не главное. Большинство игор можно начинать делать уже сейчас, как раз к моменту релиза игры подъедет четвёрка с батчингом и вулканом.
>где вас учили так беспруфно кукарекать?
МГИМО финишд.
>Что за пиздос, почему они мерцают?
Чтобы стимулировать нагрузку на ГПУ.
>>580172
Ну, собственно говоря, при всей толстоте вынужден заметить, что если по карте разбросаны транспортёры, по которым ездят ресурсы, то вполне реально, что спрайтов будет больше, чем в моём варианте.
Как говорится всё круто, но переделывай.
>Чтобы стимулировать нагрузку на ГПУ.
Ты правда такой тупой, или толстишь? В шейдер передается цвет спрайта, в формате rgba, от того, что ты сменил один компонент цвета с 1 на 0, никакой дополнительной нагрузки на гпу не появилось. Объем передаваемых на gpu данных остался тем же, количество рисуемых спрайтов осталось тем же.
Единственное, что ты загрузил - это проц, который должен менять единичку на нолик и обратно.
Гододик - это не просто состояние души, а еще и диагноз, похоже.
>Для факторио тебе писать самописный движок энивей.
Ни анон ИТТ, ни десяток просмотренных видосов про факторио не убедили меня в том, что для неё нужен отдельный самописный движок.
Это же обычный тайкун, коих тысячи! Вот только не надо опять цитировать пиздобольство автора фактории про оптимизации, которым он высасывает донаты из фанатов.
Вот анону выше не хватает спрайт-батчинга, при этом, допустим у него есть три варианта:
1. Использовать любой движок со спрайтбатчингом.
2. Использовать опенсорсный движок и если в нём нет спрайт-батчинга, то запилить свой, если уж ему так нужно.
3. Написать свой движок с нуля, включая спрайт-батчинг, векторы, матрицы, операции над ними, физику, коллизии, патчфиндинг, талмапы, анимации, звук.
Очевидно, что при наличии п.2. п.3. превращается в изобретение сотни велосипедов ради одной опции. При наличии п.1. остальные пункты несущественны. Однако для сектантов опенсорца, даже если на юнити отменят неотключаемую заставку, годот не бросим! Далее за всех говорить не буду, но лично я не вижу смысла писать движок с нуля, когда есть уже готовый опенсорсный, в который можно дописать свой модуль.
Ну чувак, ты бы хоть почитал как пайплайн гпу работает, почему тебе нужно объяснять элементарные вещи? Можно же быть ГОДОДИКОМ и при этом хотя бы немного интересоваться, как работает код под коробкой.
Каждый спрайт рисуется двумя треугольниками и описывается 4 вершинами и 6 индексами, каждый кадр при отрисовке спрайтов заполняются 2 буфера - с вершинами и индексами, в конце кадра они пачкой уходят на видюху с помощью draw call'a. Это в нормальном движке, в годоте нет батчинга и поэтому буферы отправляются отдельно для каждого спрайта, т.е. вместо того, чтобы отправить over 9000 тысяч вершин, что для современных видеокарт пустяк, в реализации Хуана буферы посылаются over 9000 тысяч раз по 4 вершины и 6 индексов за кадр. При этом, происходит насилие над пропускным каналом видюхи, потому что каждая отправка данных на гпу это дорогая операция, кол-во которых необходимо минимизировать. Это так, тебе для общего развития, чтобы ты понимал, зачем нужен батчинг.
Теперь про формат вершин. В вершинном шейдере описываются атрибуты вершин, которые принимаются на вход шейдера. Для 2д движка это могут быть, например, координаты по x и y, uv-координаты (положение спрайта в спрайтшите), цвет вершины (в rgba формате). Т.е. в сумме = 42 + 44 + 4*4 = 40 байт. Это на одну вершину. Для одного спрайта - 4 вершины, 160 байт. Десять спрайтов = 1600 байт. Когда ты сделал альфу 0 для половины из этих спрайтов, как думаешь, сколько байтов уйдет на гпу? Правильно, 1600 байт, потому что это будет тот же набор вершин с теми же атрибутами, только у части спрайтов вместо 1.0 в компоненте альфы будет стоять 0. Но этот 0 занимает все те же 4 байта (т.к. это 32 битный float).
От того, что ты занулил альфа-компонент, никакой симуляции нагрузки не возникает, каждый кадр рисуется абсолютно идентично тому, как если бы рисовался со всеми непрозрачными спрайтами. Отрабатывает ровно столько же draw-call'ов, на gpu отправляется ровно столько же байт информации.
Ты зеленый, или правда живешь в таком сказочном маня-мире?
Каждый кадр рисует сцену с чистого листа. Нет никаких отличающихся данных. В конце кадра стоит flush, экран очищается. и с новым кадром отрисовка начинается заново - для каждого спрайта заново собираются вершины и индексы, буферы отправляются на gpu.
Поэтому когда на экране одинаковое кол-во спрайтов, нагрузка стабильная, ты можешь перемещать их как хочешь, менять цвет, альфа-канал, даже менять положение в спрайтшите и таким образом анимировать - на gpu будет передано одинаковое кол-во байт за каждый кадр.
Видюха не знает, какие данные были переданы в прошлый раз, ей вообще поебать, она не хранит никакое состояние. Прислали массив данных, отрисовала, очистила, рисует следующий кадр.
>Пруфы чего?
Этого >>580242
>Каждый спрайт рисуется двумя треугольниками и описывается 4 вершинами и 6 индексами, каждый кадр при отрисовке спрайтов заполняются 2 буфера - с вершинами и индексами, в конце кадра они пачкой уходят на видюху с помощью draw call'a. Это в нормальном движке, в годоте нет батчинга и поэтому буферы отправляются отдельно для каждого спрайта, т.е. вместо того, чтобы отправить over 9000 тысяч вершин, что для современных видеокарт пустяк, в реализации Хуана буферы посылаются over 9000 тысяч раз по 4 вершины и 6 индексов за кадр.
Потому что у меня другая инфа: Класс CanvasItem объединяет всю графику своих потомков в один спрайт перед отрисовкой кадра и посылает на ГПУ один спрайт. Поэтому, кстати, в шейдерный язык годота был введен тип шейдера canvas.
Толсто. Утечка памяти наоборот, когда указатели на данные остаются висеть в системе, указывая, что память занята, хотя приложение уже забыло об этих данных и доступа к ним уже не имеет. Вот что такое утечка памяти псина тупая. Подонок. Мразь. Я не для того плачу за интернеты, чтобы меня тут троллили такой толстотой!
>Компания NVIDIA выступила с предупреждением о том, что её предыдущие драйверы имеют серьёзные проблемы в безопасности. Ошибки, найденные в программном обеспечении, позволяют проводить атаки класса «отказ в обслуживании», что позволяет злоумышленникам получать администраторские привилегии, ставя под угрозу безопасность всей системы. Проблемы касаются графических карт GeForce GTX, GeForce RTX, а также профессиональных карт серий Quadro и Tesla. Необходимые заплатки уже выпущены почти для всех вариантов оборудования, однако те пользователи, которые не полагаются на автоматическое обновление драйверов через GeForce Experience, должны установить исправленные версии самостоятельно.
>Согласно бюллетеню безопасности, выпущенному NVIDIA в течение прошедших праздников, проблема касается одного из базовых компонентов ядра драйвера (nvlddmkm.sys). Допущенные в нём программные ошибки с синхронизацией разделяемых между драйвером и системными процессами данных открывают возможность для разнообразных вредоносных атак. Опасные баги давно просочились в код NVIDIA и присутствуют в версиях драйверов для видеокарт GeForce с номером 430, а также в драйверах для профессиональных карт Quadro и Tesla с номерами 390, 400, 418 и 430.
>Кроме того, ещё одна критическая ошибка была обнаружена и в инсталляторе драйвера. Как сообщается в бюллетене, программа некорректно загружает системные библиотеки Windows, не проверяя ни их местоположение, ни сигнатуру. Это открывает злоумышленникам возможность подменять загружаемые с высоким уровнем приоритета DLL-файлы.
>Данные уязвимости весьма серьёзны, поэтому всем пользователям графических карт NVIDIA настоятельно рекомендуется обновить установленные в системе драйверы на исправленные версии. Если говорить о картах семейств GeForce GTX и GeForce RTX, то для них безопасная версия драйвера имеет номер 430.64 (или более поздний). Для карт семейства Quadro исправленные версии имеют номера 430.64 и 425.51, а для продуктов семейства Tesla — номер 425.25. Для старых профессиональных графических карт, которые не могут быть обновлены до указанных версий, исправления должны последовать в течение ближайших двух недель.
https://3dnews.ru/987335
А какие проблемы с https://github.com/ShadowApex/godot-go биндингами?
Сделал примитивный осмотрщик предметов. RayCast'ом проверяю когда игрок смотрит на интерактивный предмет. При нажатии на кнопку с объекта получаю информацию (например имя), дублирую модель объекта в место перед второй камерой, и передаю через сигнал на главную сцену, что игрок осматривает объект и информацию. Там уже манипулирую со всем этим.
Если кому понадобится, проект тут https://github.com/AlexSanchez101/Interactive-inspectable-items
Может и сами, что подскажите.
Как я понял, у годота не очень хорошо с созданием своих классов
>Как я понял, у годота не очень хорошо с созданием своих классов
Что ты подразумеваешь под "не очень хорошо"?
Класс создать можно? Да.
Сконструировать экземпляр можно? Да.
В 3.1. так же добавили клуч class_name которым ты можешь объявит скрипт как класс и конструировать его из других скриптов так же, как встроенные классы (без обращения к путям файлов).
>Класс создать можно? Да.
>Сконструировать экземпляр можно? Да.
>class_name
Да, ты прав.
Сейчас глянул. Меня смущало, что при добавлении на сцену нода со своим классом через менеджер годот автоматически привязывает к нему файл со скриптом. И я не стал проверять - писать extends CustomClassName
И вот кстати, не могу найти инфу как сделать наследование от двух классов. Возможно и не понадобится, но пока я не обнаружил, что RayCast может проверять Area, то я не был уверен, как одинаковую функцию и на StaticBody и на RigidBody
Спасибо
>Но при этом он всё равно популярен у геймдевов
И где он используется? В сталкере со старбаундом? Популярность уровня гд. Кстати, старбануд, тормозящий даже на еба-процессорах, хорошо показал, почему не стоит использовать луа. В геймдеве популярны кресты и шарп ну пусть еще питон будет, если вы визуальные новеллы за игры считаете. Остальными только неосиляторы или хипстеры пользуются.
Я СКОЗАЛ!
https://en.wikipedia.org/wiki/Category:Lua-scripted_video_games
Луа в геймдеве юзался еще задолго до того, как ты был в яйцах своего бати, задолго до того, как юнити появился, в те времена шарп юзали только в кровавом анальном энтерпрайзе.
Близзарды, запилившие world of warcraft со скриптами на луа тоже хипстеры и неосиляторы? Может им расскажешь, что там у них тормозит? У них популярность уровня /gd?
Что за хуйню ты несешь, зумерок? Проследуй на парашу.
>как сделать наследование от двух классов
Множественное наследование вызывает проблемы и было признано вредным: (Класс А наследуется от Б и Ц, класс Д наследуется от Б и Е, класс Ф наследуется от А и Д. Если не проследить за уникальностью методов в классах Б, Ц, Е, при компиляции получишь непредсказуемое поведение: сначала всё вроде работает, потом внезапно хуяк - выход за границы индекса или несоответствие типов. Юзеры ругаются. Работа стоит. Ты не понимаешь, что не так?)
Поэтому любой уважающий себя современный язык не поддерживает множественное наследование, предлагая вместо него одиночное наследование плюс наследование интерфейсов, например (шарпо-псевдокод):
class MyBeautifulNode : ParentNodeClass, ICanvas, IPhysics, Ipersistent { }
Наследование интерфейсов предполагает что ты гарантированно реализуешь в классе функционал уникальными, не вызывающими коллизий при поиске методами.
Но ещё лучше, делать, как предлагает анон, композицией, в том числе, организуя себя через интерфейсы:
class MyBeautifulNode : IParentBehaviour, ICanvas, IPhysics, Ipersistent { }
В годоскрипте интерфейсов нет, он для простых задач, например, расширения функционала существующих классов.
Если у тебя сложная игровая логика - юзай шарп, чтобы получить всю мощь ООП в своём проекте. Либо организуй себя диздоками, а не кодом.
>Луа в геймдеве юзался еще задолго до того, как ты был в яйцах своего бати
Нет, луа мой ровесник. Но суть даже не в этом. Индустрия не стоит на месте, она постоянно развивается. И то что в прошлом было меинстримом (хотя луа им и в прошлом не был), сейчас используется только хипстерами. Неужели ты таких очевидных вещей не понимаешь?
Кстати, охуенный список. Такая то куча игр, что даже на каком-нибудь 3м уече их было больше. Что уж там говорить про целые языки программирования. Еще заметь - множество игр из твоего списка имеют продолжения и уже в продолжениях луа не используется. Отгадаешь, почему? Правильно: если в прошлом луа и имел какой-то сомнительный смысл, то сейчас - это удел хипстеров и неосиляторов.
>world of warcraft
Ммм, какая актуальная и новая игра.
>Близзарды тоже хипстеры и неосиляторы?
Нет конечно. Они же луа со времен вова и не используют.
>Такая то куча игр, что даже на каком-нибудь 3м уече их было больше. Что уж там говорить про целые языки программирования.
А третий анрил это нецелый язык программирования? Ты сам-то понимаешь, что несешь, или просто хуячишь рандомный набор слов?
И да, уеч = ue 4, он не может быть третьим.
>Отгадаешь, почему?
Потому, что многим студиям эти продолжения стало выгоднее делать на готовых движках типа unyti и уе, в которых нет поддержки lua. Студии, которые продолжают работать со своими движками, продолжают работать и с lua, тот же croteam с их talos principle.
>Ммм, какая актуальная и новая игра.
Это логично, что там много старых игр, если напрячь мозг и подумать, то можно прийти к выводу, что чисто статистически за прошедшие 10-15 лет игр вышло больше, чем за последние пару лет.
Elder scrolls online для тебя не новая и не актуальная? La Noire какой-нибудь тоже?
В общем, весь твой пост хуйня, что-то ты совсем обпукался в штанишки.
>>581235
> На чотких-резких шарпе/крестах пишем движок
Шарп резкий только если как понос, на нем движки не пишут, из-за сборки мусора в том числе. Большинство движков, юзающих шарп для скриптов - на плюсах.
В годоте нет ни строчки на шарпе (если не считать саму интеграцию шарпа как скриптового языка). Пиздеть хуйню с уверенным видом, ничего не понимая в вопросе, о котором пиздишь, это так в духе гододиков.
>В годоте нет ни строчки на шарпе (если не считать саму интеграцию шарпа как скриптового языка). Пиздеть хуйню с уверенным видом, ничего не понимая в вопросе, о котором пиздишь, это так в духе гододиков.
Так и знал, что доебутся. Эх, надо было пофиксить сразу, но теперь уж поздно.
>А третий анрил это нецелый язык программирования?
Анрил3 - это не язык программирования (боже, с кем я тут сижу, что мне такое объяснять приходится), это движок. Один из многих движков, которые используют кресты. И только лишь на нем игр вышло больше, чем игр, использующих луа за всю историю.
>И да, уеч = ue 4, он не может быть третьим.
Вот это манямирок. А виндоус, например, - это тоже только Win10? Windows 7 быть не может? Иди в /s - расскажи поцанам, что они на несуществующих системах сидят.
>Потому, что многим студиям эти продолжения стало выгоднее делать на готовых движках типа unyti и уе, в которых нет поддержки lua.
Если бы поддержка луа была нужна хоть кому-нибудь - ее бы уже давно запилили.
Ты сам вов притащил. На что получил логичный ответ, что индустрия во времена выхода вова несколько отличалась от современной. Ну и на что ты эту хуйню написал?
>Это логично, что там много старых игр
Я слова не говорил о том, что в списке много старых игр.
И если уж ты об этом заговорил. Не важно, сколько в списке старых игр - бесполезность и непопулярность луа показывает практически полное отсутствие там новых. Сколько там игр использовало луа за последние 5 лет - 5? 10? 20?. А теперь сравни, сколько использовало кресты или шарп или, прости господи, питон - а потом говори, что твое говно популярно в геимдеве.
А, вот к чему ты доебался. Ну ок, you got me. Но ты вроде понял, что я анрил 3 в виду имел.
>>581266
Я изначально писал >пусть еще питон будет, если вы визуальные новеллы за игры считаете.
А визуальных новелл на питоне дохуя (больше чем игр с lua). Если речь про AAA - то нет, питон там конечно непопулярен.
Вот эти галки поласкай ладошкой. В настройках экспорта. Вдруг компрессия польётся?
Для начала, не паниковать.
Ты говоришь о размере распакованного файла.
Проведи простой тест:
1. распакуй apk в какую-то папку
2. замени в папке stex на webp
3. запакую эту папку в новый архив (apk это zip по сути)
4. сравни получившийся размер.
Разница наверняка будет меньше чем ты ожидаешь.
>>581359
>>581356
Уменьшил, причем сильно. Раньше было 47мб, сейчас 17мб.
Рассказываю как, вдруг кому-то нужно будет.
Выбираем любое изображение, переходим на вкладку Импорта (она на пике), ставим в разделе Сжатия режим Lossy.
Потом указываем эту настройку импорта по умолчанию.
Закрываем редактор
Удаляем папку .import и все файлы вида png/jpg/webp.import
Запускаем редактор и экспортируем игру
>Если у тебя сложная игровая логика - юзай шарп
А как связать движок игры со сторонним языком? Ну, типа, я понимаю, если py-скрипт запускает в терминале батник и наоборот, но в данном контексте я не представляю, как заставить взаимодействовать встроенный движок годота и наружный компилируемый язык.
> как связать движок игры со сторонним языком?
Это называется binding. По сути, скриптом генерятся все названия функций во всех классах со всеми параметрами.
https://github.com/GodotNativeTools/godot_headers/blob/fb3010491be433f4e44119c743f682bb4710ec72/gdnative_api.json
Может быть еще пишутся классы-обертки.
В результате ты получаешь библиотеку, которую можешь подключить и использовать из своего любимого языка, вызывая любую функцию которая есть в движке.
Хули толку, если ничего не работает.
Скачал билд с моно, добавил пустой дефолтный скрипт на шишарпе, сборка падает с ошибкой Failed to build solution, заебись вышел релиз. Прямо сразу захотелось попердолиться вместо создания игр , подебажить, что же там падает.
>>581859
Вот что нашел на гитхабе.
Huh, I see that Godot is actually appending a hard coded path to the installation dir for MSBuild, which is not great.
Если не дай бог у тебя стоит версия студии не та, которая стояла у Хуана на момент разработки фичи, либо ты поставил на другой диск/по другому пути, то всё, работать ничего не будет.
Самдурак, что поделать.
>Если не дай бог у тебя стоит версия студии не та
Пожалуйста, хватит срать себе в штаны и начни наконец читать инструкции. Тебе вообще не нужна студия, любой версии. Тебе нужен MSBuild из Visual Studio Build Tools, которые ставятся отдельно от студии. Если их установка для тебя слишком сложна - ставь MonoSDK и переключайся на него в настройках годота.
> I see that Godot is actually appending a hard coded path to the installation dir for MSBuild
Образец кода годота в студию. Ну или ссылку на гитхаб, где приволокли кусок кода, где Хуаном захардкожено.
Потому что человек, пишущий движки, 99% знает, как опросить целевую систему на наличие в базе данных установщика (или в пакетного менеджера) требуемого пререквизитного софта и получить пути к исполняемым файлам.
Пока не пруфнешь этот свой вскукарек, считаем тебя троллём.
>начни наконец читать инструкции
Где инструкции? Я скачал билд с моно, там нет даже файлика readme, только бинарник и какие-то либы моно.
На странице с загрузкой тоже ничего не упоминается, никаких гайдов, ссылок на доки, предупреждений, что перед тем, как скачать и запустить сначала нужно попердолиться и что-то донастроить.
Visual studio на компе уже стоит, естественно, с ним и msbuild и прочее.
>>581919
Мне делать что ли нехуй, копаться в коде годота, чтобы какой-то додик с двача поверил, что у меня что-то не работает?
Мне достаточно issue на гитхабе, в котором это обсуждается.
https://github.com/godotengine/godot/issues/27269
Пишут, что уже пофиксили в 3.1.1, но что-то все равно нихуя не работает, буду дальше ковырять.
>>581929
Годот 3.1.1, студия 2019 community.
Ладно, моя последняя попытка тебе помочь.
>Где инструкции?
На странице загрузки:
For the Mono version: MSBuild
(from Visual Studio Build Tools or the Mono SDK)
>Visual studio на компе уже стоит, естественно, с ним и msbuild
Видишь слово from выше? Знаешь, что оно означает? Ему нахуй не нужен/не подходит msbuild в твоем Visual studio. Ему нужен отдельный msbuild из Visual Studio Build Tools. Так что переходишь сюда https://visualstudio.microsoft.com/downloads/?q=build+tools, качаешь Tools for Visual Studio 2019 и ставишь там MSBuild (ставишь все в стандартную папку, на случай, если тот иссю с гитхаба не пиздежь, MSBuild все рано почти ничего не весит). Потом убеждаешься, что в настройках годота у тебя тоже стоит MSBuild - и вуаля, все работает.
>моя последняя попытка тебе помочь
Спасибо анон, что пытаешься помогать ИТТ даже троллям. Твои посты ценны для истории.
>Почему нет версии годота сразу с предустановленным расширением для шарпа?
Но ведь есть же.
Ну а хера тогда этот
>>581843
>Хули толку, если ничего не работает.
>Скачал билд с моно, добавил пустой дефолтный скрипт на >шишарпе, сборка падает с ошибкой Failed to build solution, заебись >вышел релиз. Прямо сразу захотелось попердолиться вместо >создания игр , подебажить, что же там падает.
Жопу рвёт? Скачай и долбись со студией.
Да я уже все починил, решилось минорным апдейтом 2019 студии. Видимо там поменялся какой-то путь, и годот смог подхватить его, может у разработчика стояла как раз эта версия студии и поэтому на ней все работает.
Поражает токсичность коммьюнити годота, пока у тебя все работает - все отлично, ты свой, тебе все рады. Как только у тебя что-то отвалилось, перестало работать - все, ты сразу превращаешься в тролля и пидораса, который рушит ламповый маня-мирок, в котором у всех все идеально работает, люди, которые вчера тебе респектовали и помогали, сегодя будут хуесосить тебя и слать нахуй только потому, что ты посмел поставить под сомнение парадигму "Хуан - бог, а баги в годоте в принципе отсутствуют".
>>582139
Вот как надо. Как прикрутить плавность разберёшься?
Ну там куча вчего осталось, все 2д встроенные ноды-классы рассмотреть, контейнеры например мне щас не помешало бы понять. Потом садишься такой за годот и не знаешь как что-то сделать и даже не знаешь с какой стороны подступить, потому что тупо не знаю гдскрипта. Можно запилить туториал типа самые часто используемые приемы в годоте, и рассмотреть там инстансинг сцен/объектов с примерами, использование таймеров, сигналов, инпутов итд итп. Ну такое без чего ни один проект не обходится. Тупо почитываю доки на официальном сайте, но слишком много инфы и сразу из головы вылетает, да и нужно закреплять материал на примерах. GDQuest отличный канал, но сложновато порой.
Ну вот чет хз про height. Попробовал и 0.3 и 0.1 ставить, но "приседает" недостаточно низко (почти не приседает, я бы даже сказал).
А для плавности, как я понял, нужна анимация. Только что буквально увидел как двери крутить. Думаю принцип такой же.
>>582146
Я слишком не шарю, чтобы об этом беспокоиться.
Вот зачем ты глупости пишешь. А как он будет в щели залазить?
... Если ещё более по уму, то там надо проверять что шейп вернулся, что шейп это капсула. А если совсем по уму, то шейп надо создавать ручками.
>>582225
>лучше сделать коллайдер из 2 форм, и верхнюю просто отключать во время приседания
ИМХО, костыль. Движок прекрасно обработает модификацию параметров для шейпа (физического коллайдера).
Бампаю вопрос. Вопрос открыт. Немного погуглил, посмотрел туториалы. Нихуя непонятно. Разнёс эффекты по басам (bus) и наложил огромную вонючую кучу постпроцессингов (limiter), от которых стало ещё громче щёлкать.
Памахити настроить звук, ну будьте же вы людьми!
>урокцифры.рф
Что это за пиздец?
>>582459
Поменяли уже урок оказывается. Хуй его найдешь теперь. Ну там короче графон как на пикрилейтед, без интерфейса. Геймплей - просто ходишь ищешь сломанные станки. По щелчку мыши они чинятся. Возможно такое на вашем годоте, при условии что я конченный дебил?
Нашел в официальной документации
https://godot.readthedocs.io/en/stable/tutorials/2d/2d_movement.html
Click and Move
Все запускается, но значок не двигается :)
Хер знает, я воспроизвел обучалку и у меня все нормально работает.
Коллижн шейп сделал через меню на 1м пике.
Клик мышки добавил в инпут мап на 2м.
Буквы с разной скоростью - анимировать свойство Visible Characters или Percent Characters
https://vimeo.com/163355997
По прозрачности, видимо, тут
https://docs.godotengine.org/en/3.1/tutorials/gui/gui_skinning.html
Вот сейчас сделал так.
1. Выбрал Label, свойство Theme -> New Theme, там же Edit Theme
2. Внизу открывается тема, там в углу есть кнопка Edit Theme
3. В вылезшем меню Add class items, выбрать Label (если у тебя в нем текст)
4. Теперь справа появляются свойства для Label
5. Выбрал там Styles -> Add StyleBoxFlat, потом на него Edit
6. Выставил Bg Color на нужный цвет, поставил альфу меньше 50%
Там всё сложно. В какой-то момент движок сбрасывает масштабирование коллайдер-шейпов. В какой именно - не помню. В документации пишут не делать так. В смысле не устанавливать размеры коллайдеров через scale.
>Be careful to never scale your collision shapes in the editor. The “Scale” property in the Inspector should remain (1, 1). When changing sizing the collision shape, you should always use the size handles, not the Node2D scale handles. Scaling a shape can result in unexpected collision behavior.
Мне этого достаточно.
8. Добавил в тему кастом-фонт с поддержкой русских буков.
9. Все объекты от класса контрол (зелёненькие) располагать в одной ветви дерева, где корень control (зелёненький) и тему задавать именно ему. У остальных элементов тема подхватывается автоматически.
Читать документацию:
>void move_child( Node child_node, int to_position )
>Moves a child node to a different position (order) amongst the other children. Since calls, signals, etc are performed by tree order, changing the order of children nodes may be useful.
Написано же: будет неожиданное поведение. В общем случае будет работать как ты предполагаешь, но в любой момент может получиться так, что скейл коллайдера сбросится, а сама машинка останется отскейленой. Там же в чём суть: физический движок сторонний (буллет), годот посылает ему сообщения о коллайдерах, буллет возвращает сообщения о коллизиях (это если грубо, на пальцах) и о векторах скоростей, согласно физической симуляции. Поэтому такая странная работа с ними из кода, вместо логичного Объект.Коллайдер.Свойство = чонибудь, мы вынуждены писать Объект.Коллайдер.set("Свойство", "чонибудь") потому что обёртка. Мы не имеем доступа к интерфейсам буллета, а обёртка предоставляет метод set, через который мы задаём свойства.
Можно было бы доебаться к Хуану, что он неосилятор, но видимо Хуану просто нравится такое, потому что есть же директфизикстейт с прямым доступом к физону. Можно было бы доебаться (и доёбывались в прошлых тредах) что якобы буллет прикручен и Хуан реализовал АПИ, совместимый со своим велосипедным физическим поддвижком? Так нет же, зачем ему такую обёртку было делать даже для своего поддвижка? Тут именно стратегия. Хуан стратегически выбрал этот универсальный способ обмена сообщениями между компонентами без доступа к их интерфейсам.
Метод set есть и у нод для типобезопасной установки свойств, есть метод call (и cfll_deferred) для типобезопасного вызова методов.
Это дизайн. Это стиль. Если кто-то не согласен - пусть требует вернуть деньги, ах да, это же бесплатный опенсорц.
>>582671
Всё верно, только self_modulate же.
Это из-за target = position. Хотя мне казалось что я проверял, двигается ли персонаж, когда написал эту строчку. А написал я ее из-за того что мой персонаж при запуске приложения двигается к координате 0, 0
А еще не меняется спрайт при движении вверх. Я бы хотел чтобы он менялся в секторах пикрилейтед. Это наверное нужно учить всякие параболы из школы?
>>582729
Анончик. Даже когда у тебя это всё заработает, твой персонаж будет двигаться по прямой к точке клика мышкой. Он конечно будет скользить по коллизирующим поверхностям, но рано или поздно он упрется где-нибудь во внутренний угол.
ПОЭТОМУ рекомендую тебе прямо сейчас начать делать всё правильно с заделом на будущую расстановку препятствий по карте. А именно - организовать движение по навигационному полигону. Я делал по этому уроку:
https://www.youtube.com/watch?v=KU1PslMiZ98
Тут расписана хитрая техника построения навиг.полигона через тайлмап, но ничего не мешает тебе строить его динамически. Идея в том, чтобы покрыть навигационными полигонами все места для движения и исключить места с препятствиями. Дальнейший поиск пути годот сделает автоматически.
вот ещё более наглядный пример
https://www.youtube.com/watch?v=Ad6Us73smNs
Спасибо конечно за ответ :) Но сейчас мне нужно чтобы спрайт менял свое состояние в зависимости от того в какой сектор (пикрилейтед) я кликну мышкой.
https://docs.godotengine.org/en/stable/tutorials/math/vector_math.html?highlight=math
Нашел здесь углы, но как их задавать и с чем сравнивать (position, target, velocity >>582718 ) не знаю.
В ютубе нашел только поле обзора у объектов основанное на этих углах
https://youtu.be/dC4-TSFv32Y
>>582761
>>582761
>>582775
Эх, зарекался не давать голодающим рыбу, но давать удочку.
>Я конечно не особо понимаю как работает Vector2 и почему его называют velocity
Советую разобраться сразу, потому что просто копипастить куски кода - это путь в никуда.
https://habr.com/ru/post/131931/
>подробно напишу что мне надо
Может быть, вот такое было надо?
Доброе утро! И бамп! Проснулись потянулись, роботушечки мои! Светодиодиками заморгали, маслицем закапали и за работу. Игоры делать. Годотом игры делай, вот так: func vzhukh_vzhukh():
Короче, все что мне надо я сделал (пикрил). Пока в коде не разбиралсяно вчера читал про vector math в godot доках, хотелось быстрее посмотреть что получится.
Правый сектор почему-то менял свое значение с отрицательного на положительный и наборот, поэтому спрайт не менялся. Пришлось написать как обведено прямоугольником.
Пока что все работает плавно, но когда-нибудь это все полетит к чертям собачьим
ИМХО, анимация здесь не очень подходит.
Анимация тебе устанавливает начальное значение и плавно вращает в конечное значение. У меня же просто идёт приращение на единицу к новому положению на круге, без анимаций, в _процессе. Не понимаю, как у тебя на анимациях это всё работает плавно? Покажи скрин настроек анимации. Как я понимаю, у тебя всё должно скакать при переключении анимаций.
Хотя вот можешь посмотреть проект у себя
https://yadi.sk/d/ozf1_Vm1A0pRCA
ОБС же https://obsproject.com/ru
>>582836
Ща глянем.
А хотя вот совет: у тебя screen_size объявляется в _ready и там же остаётся локальная.
Можно делать, как ты сделал с target, но гораздо лучше, как было показано выше, объявлять через onready var в области объявлений. onready var для того и предназначено, чтобы разгрузить функцию _ready от громоздкого бойлерплейта присваиваний.
Беру тогда какой-нибудь видос связанный с тем, что поможет мне достичь своей цели, например, https://www.youtube.com/watch?v=RZyiy9bbeNE Делаю все как в видео, и у меня нихуя не работает, не хватает каких то функций
У меня не работает:
screensize = get_viewport().get_rect().size
есть
screensize = get_viewport().get_visible_rect().size
но скорее всего из-за него у меня не работает
flower.set_pos(Vector2(rand_range(40, screensize.width-40), (40, screensize.heigth-40)))
.set_pos тоже нихуя не работает
Что делать то?
Проблема в том, что в 2017 году он почему-то пилил для старой версии годота.
Вот же под твоим видео ссылка
http://kidscancode.org/blog/2017/02/godot_101_06/
Там в первом комменте исправления для годот 3
for Godot3 some important changes
screensize.get_viewport().get_rect().size
USE
screensize = get_viewport().get_visible_rect().size
g.set_pos(Vector2(rand_range(40, screensize.width-40),
rand_range(40, screensize.height-40)))
USE
g.set_position(Vector2(rand_range(40, screensize.x-40),
rand_range(40, screensize.y-40)))
>не попрошайничая на дваче
Попрошайничай, анон. Для этого мы здесь собрались.
Поключил к flower сигнал пикрил 2
К BodyTrigger пикрил 3
Теперь мне нужно объединить оба сигнала в условие и при его выполнении организовать queue_free(). Пытался сделать это прямо в flower, но они требуют от меня какие-то аргументы
>на нём такие проекты как node.js
Пиздец ты дебил, у тебя правда в голове такой маня-мир, что ты в это веришь? Нода - это рантайм на С++, js для него играет роль гдскрипта для годота, просто скриптовый язык, чтобы запрограммировать вызовы методов, реализованных на плюсах.
Это как заявлять на полном серьёзе, что годот написан на гдскрипте.
Ща погодь, открою исходники тваггера, у меня там всё это реализовано было ещё зимой. Но я не помню как.
>>583060
Всё, открыл, посмотрел. В общем, у меня всё по другому там сделано:
1. Всё сделано через группы. Допустим, есть на карте ЦВЕТОК, в нем нет никакого кода вообще, у него есть Area и ему назначены группы, например: "растение, подбираемое".
2. Вся логика взаимодействия со сценой навешана на персонажа. У него при детекте чьей-то Area внутрь прописывается action_target = area
3. При нажатии на действие "экшон" (у тебя мышка, ЛКМ) он чекает не нуль ли action_target? И если не нуль, то к какой группе он относится. Если к группе "подбираемые", то послать ему кью_фри(), если разговариваемые, то достать из него ресурс диалога и так далее.
У такого подхода есть свои минусы и я в целом не рекомендую слепо воспроизводить его. Во первых, это клепалось для ТВГ без оглядки на расширяемость и вариативность. Во вторых, данные следует убирать из логики, а у меня там получалось, что интерактивные объекты носят в себе данные, а не указатели на данные в файловой системе.
Если тебе нужны примеры проектов, то рассмотри те, которые идут искаропки. Каропка пикрелейтед.
>>583070
И в любом случае без образного мышления в связке с общими навыками кодинга никуда. Я так подозреваю по твоим постам ИТТ, что у тебя нет за плечами пары десятков лет кодинга в ентерпрайзе.
Если так, то делать игоры будет сложно. Делание игор подразумевает, что ты уже делал программы, а теперь поднял планку до делания игор.
Потому что язык динамический и он ничего не знает о том, что ты навешал на body.
>>583075
>У меня за плечами паскаль в школе и хтмл в шараге.
Этого мало, чтобы на лету понимать разницу в объявленных переменных.
В версии 3.1. добавили такую возможность, как объявление типа.
В одном скрипте напиши
class_name MyClass
Затем в другом скрипте напиши
var my_body : MyClass = body_in_area as MyClass
Вот тогда на my_body появится интерфейс во всплывающих подсказках.
Впрочем, ты всегда можешь писать наощупь и если не ошибёшься, годот динамически считает твою переменную
>>583087
>Ну и почему не работает?
Потому что у ClickTarget НЕТ ТАКОГО ПОТОМКА, они друг другу братья, а не родитель-потомок. Следовательно ты должен обратиться к родителю, а только затем к потомку родителя. К сыну своей матери, так сказать.
get_node("../BodyTrigger")
И опять же Это не то знание, которое ты должен получать в геймдевелопинге, с этим знанием ты уже должен был прийти в геймдевелопинг.
Поэтому я сразу сказал, что тебе будет оооочень сложно.
Я решил проблему тем, что сначала объявил переменную, а потом в func _ready() написал что она равна get_node(BodyTrigger).body_in_area
Но у меня чето все поломалось, даже в print ничего не выводило. И персонаж не двигался.
Скачал бэкап, который я случайно себе завел. Сейчас все буду делать заново я ничего и не сделал толком
>>583083
Если ты знаком с паскалем, то предлагаю тебе дельфи-стайл для работы с элементами сцены. Выше я уже давал скриншоты с его реализацией. Здесь >>582795 например.
Как мы помним из нулевых, в дельфи есть форма и когда ты кидаешь на форму мышкой контролы, то ИДЕ автоматически закидывает в связанный модуль необходимые определения:
type TForm1 = class(TForm)
Button1 : TButton;
Button2 : TButton;
Label1 : TLabel;
end;
В годоте я сам делаю по смыслу такое же и всем рекомендую. Ибо поиск по дереву сцены (медленный) происходит только один раз при загрузке скрипта и в дальнейшем мы имеем в скрипте определённые переменные для всех нод, которые нам понадобятся.
Делается это так:
onready var button1 : Button = get_node("Button1")
onready var button2 : Button = get_node("BottomPanel/CloseButton1")
onready var label1 : Label = get_node("MainPanel/Labels/Hitpoints")
Сделал, проверяй https://yadi.sk/d/VWBylsfr1oNc3Q
Нет, со справочником я бы это дело бросил быстро. Я им пользоваться вообще не умею
Вот так делаю игры я:
И вот ещё вдогонку. Домашнее задание, так сказать.
Аналогично, коллега. Когда я понял, что могу писать игры, я внезапно понял, что не умею рисовать. Пришлось пилить утиный тетрис из 90х.
>Сносное двадэ реально пилить в одиночку
Ага, традиционное никому ненужное говно из пикселей. Лучше уж майнкрафт или чибиков каких.
https://sketchfab.com/3d-models/p-chan-8faf9a43fc04424988f9cc213fa8c16d
Заметь, о пикселях как раз я ни слова не сказал. Тащемта, мода на пиксели прошла и по маркетинговому правилу S-образных кривых, сейчас нужно вкладывать очень много сил в пиксельарт, чтобы получить отдачу. Мне оно не нужно.
Поэтому да, следует рисовать высокоразрешенческий арт.
https://www.youtube.com/watch?v=Peje2YEWXFw
Почему на туториалы для годота надонатили больше, чем на сам годот?
Это страх. Люди боятся реального дела. Придётся взять на себя ответственность по доведению проекта до релиза. А люди боятся ответственности. Не все конечно, большинство.
Есть очень тонкая грань в просмотре туториалов, когда они из обучения превращаются в развлечение.
Сидит такой упырь-аутист за пекой и смотрит туториалы. Месяцами. Годами. Нихуя не делает, только срёт в комментах. Но если залетит мамка в комнату "Ты почему уроки не сделал? Почему в гостиной не пропылесосил?" - "МАМ НО Я ЖЕ ОБУЧАЮЩИЕ МАТЕРИАЛЫ СМОТРЮ!"
"Ах, умничка, учись корзиночка!"
>Но правильный путь - взять юнити
Если бы все были такими категоричными долбоёбами как ты, мир бы сейчас не знал о существовании таких игр как dwarf fortress, cave story, iconoclasts, stardew valley, kenshi, terraria и сотен других.
Так что перестань нести хуйню и проследуй в юнити тред, не надо учить людей что и как делать, без тебя разберутся.
https://www.youtube.com/watch?v=craTObqV184
Как минимум одна уже есть.
Так что обоссан, съеби из треда.
>Как минимум одна уже есть.
>запостил протоговно
Лил.
>съеби из треда.
Нет. Выбор годота вместо юнити это страх. Ты специально выбираешь плохой инструмент, чтобы твоя игра никогда не дошла до релиза. Чтобы можно было бесконечно затягивать разработку. Чтобы если залетит мамка в комнату - "Ты же начал делать игру пять лет назад, когда уже доделаешь?" - можно было ответить - "МАМ НО Я ЖЕ ГОДОТИР!" - И она печально опустив голову покинет комнату, в очередной раз убедившись, что сын до сих пор долбоебина.
Срачи в годот-тредах вместо разработки на юнити это страх. Ты специально выбираешь любой способ не заниматься разработкой, чтобы твоя игра никогда не дошла до релиза. Чтобы можно было бесконечно затягивать разработку. Чтобы если залетит мамка в комнату - "Ты же начал делать игру пять лет назад, когда уже доделаешь?" - можно было ответить - "МАМ НО Я ЖЕ УНИЖАЮ ГОДОТИРОВ!" - И она печально опустив голову покинет комнату, в очередной раз убедившись, что сын до сих пор долбоебина.
>Только среди инди-петушни.
Кукарекнула инди-петушня. Годотодаун продолжает переводить стрелки на анриал, про годот нечего сказать, все что я сказал правда. Для инди юнити побеждает анриал, для неинди анриал побеждает, а вот почему человек, который реально хочет сделать игру, должен взять вечнонедоделанный нищенский кастратогодот вместо огромного ахуенного богатого движка юнити непонятно.
>Я знаю, зачем ты здесь. И я прослежу за каждым из 28 постов.
Что? Годаун ебанулся.
Просто пойми, что ты шизик. Никто не спорит что у юнити ассетов больше чем у годота - он позже начал. Никто не спорит с тем, что в годоте еще не все сделано - но то, что сделано, с головой хватает для создания игр. Но когда ты говоришь, что юнити стоит наравне с анрилом - всем понятно, что ты поехавший, и ты у себя в уме просто игнорируешь реальность.
Я давно уже в движкосрачи не вступал, но иногда нужно, новые посетители должны знать подноготную движков.
>Никто не спорит с тем, что в годоте еще не все сделано - но то, что сделано, с головой хватает для создания игр
Так вопрос не в этом, а в том, почему человек, который реально хочет сделать игру должен взять вечнонедоделанный нищенский кастратогодот вместо огромного ахуенного богатого движка юнити? Ну замени юнити на анриал, может я на него вскоре пересяду, но у него есть недостаток в роялти, но вопрос про годот.
>у юнити также недостаток в роялти.
Купить лицензию за 1.5к баксов, если заработал больше 100к несущественно
>>583316
>Потому что это самый полноценный и поддерживаемый опенсорс движок
Будто это какая-то ценность сама по себе. Вот вам делать нехуй, годотеры, сидите на огрызке и еще новичков неокрепших завлекаете в свое болото, травмируете навсегда.
>Купить лицензию за 1.5к баксов, если заработал больше 100к несущественно
Пиздец, это животное даже не открывало страницу покупки юнити, а топит за него. Уже давно там модель пожизненной подписки, а не разовая выплата. Сделал игру - всю жизнь платишь с её продаж ежемесячно.
За уеч нужно отдавать 5%, это больше, чем 1.5к в год за юньку. И это не единственная причина.
>>583323
>И plus, и pro распространяются по подписке, там не разовая выплата, а бесконечные ежемесячные платежи.
125 долларов в месяц, ослина годауновская, заработал больше 100к за последний год, изволь заплатить1.5к, про какую пожизненую подписку ты пизданул?
>>583325
>сплешскрин "маде ин юпити"
Про сплешскрин говнота никто и не узнает никогда.
В чем ложь-то? В персональной версии юнити нельзя убрать сплешскрин, его можно убрать только когда начнешь платить ежемесячную мзду.
>И сплешскрин тут не при чём, можешь его и в прошке не отключать.
Речь о том, чтобы наоборот его отключить, нахуй это надо, так позориться.
ПЕРЕКАТ >>583342 (OP)
ПЕРЕКАТ >>583342 (OP)
ПЕРЕКАТ!!!
>>583342 (OP)