Это копия, сохраненная 18 ноября 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1) Простота.
2) Кроссплатформенность.
3) Бесплатность.
4) 2D.
5) 3D.
А так-же куча различных фишек вроде разветвленной анимации, охуеннейшего дебаггера с графиками и статистикой, подсветка синтаксиса прямо в редакторе с автодополнением, поддержки интернет протоколов и многое другое, о чем ещё не знал ОП первого треда.
С чего начать?
С изучения документации. Если не можешь в инглиш, и даже в гугл-переводчик, то есть варианты русскоязычного перевода части доков на ресурсе конкурирующей фирмы: http://c2community.ru/forum/viewforum.php?f=119
Но вообще, будь мужиком и изучи английский: https://godot.readthedocs.io/en/stable/index.html
Вместе с движком обязательно смотри примеры, там есть все - от платформера до чата. Примеры качаются прямо в движке через свой магазин.
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
FAQ: https://godot.readthedocs.io/en/stable/about/faq.html
Игры, созданные глобальными кириллами: https://godotengine.org/showcase или https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
>3D
Предостерегаю вкатывальщиков - физика не работает, половина андроидов и встроенных видях не работают.
Киллер тайтлы за день не делаются. И за неделю не делаются. И за месяц. И даже за год.
Я вот свой пилю уже больше года, и пока готово от силы 20% игры. Хотя я почти закончил вылизывать все базовые механики, так что дальше быстрее пойдёт, но всё равно прогнозирую ещё года два до завершения.
Так что, учитывая, что юзабельная версия 2.1 вышла только два года назад, киллер-тайтлы на Годо ещё год как минимум не появятся.
>разветвленной анимации
Кстати, вот, где это и как делается? Кто-нибудь пользовался? А то я пока все ветвления анимации делаю через вызовы функций, но может есть проще путь?
>Ты просто об свой костыль спотыкнулся.
Хуан споткнулся об свой костыль, все верно. Видео его.
Есть такая нода, но учить её не начинай, Хуан её задепрекатил и пилит новую:
https://godotengine.org/article/godot-gets-new-animation-tree-state-machine
Она в 2.1.х ветке тоже будет? 3.х меня не интересует, так как всё равно пользоваться им смысла нет, сырой ещё. А пока его допилят, я свой проект на 2.1.х закончить успею.
Эээ... ты потерял меня. Какие системы анимаций, ты о чём вообще сейчас? Причём тут базовые ноды? Причём тут визуальные костыли?
Заебись системка. А на шарпе они продают модули для интеграции в свою игору? А натренировать нейроночку они за сколько возьмутся? А то у меня днищепека.
гм, ну я вообще про 2Д говорил, для начала. А потом я не очень понимаю какая связь всё же.
Я имел в виду, как управлять анимацией из другой анимации, такого вида ветвления. Например, у меня есть анимация приседания и вставания персонажа. И нужно, чтобы по окончанию анимации вставания запускалась idle анимация. Пока я это делаю вызовом функции из анимации(там треки функций есть). Вопрос, собственно, был - можно ли как-то по-другому это делать, проще?
Как 3д моделирование связано с тем, что коллайдер проваливается под землю?
+ модели делал не он, ему делали на заказ
>Как 3д моделирование связано с тем, что коллайдер проваливается под землю?
Напрямую, блядь. ведь коллайдер это геометрическое тело, просто невидимое. строится либо полигонами, либо параметрически. имеет свои координаты, располагается на сцене именно моделером, и если между коллайдерами образовалась дырка - это косяк именно моделера уровней.
Мне гораздо интереснее посмотреть на код и на дерево из той вебэмки, где белые меши трясутся. Там видимо хитрый хейтер годота ебанул ригидбоди в том месте, где обычно на всех движках юзают статики и визжит "смотрите, как в говнодоте физика трисётси!"
>Мне гораздо интереснее посмотреть на код и на дерево из той вебэмки, где белые меши трясутся.
Смотри, это же опен сорс, баг публичный, с проектами-пруфами.
>Actually this is an even better example, just a cube:
https://github.com/godotengine/godot/issues/21409
>akien-mga commented 36 minutes ago
Important announcement for all Godot contributors: As of 79c6a83, the master branch is now in alpha stage
Пойду качать/пересобирать.
>нихуя не понятно, что это такое и как им пользоваться
Какой ты непонятливый. Добавляеш анимации в список и переключаеш и теребиш.
Причем тут это вообще? Даже если бы такое было в годоте, никто тут бы не стал бы тратить часы своих криптоферм на то, чтобы ноги и руки персонажа махались независимо.
Через моно. Я лично проверял, поднимал монодевелоп на штабильном дебиане и усё работает, собирается. Правда тормозит даже на официальных дровах (ой, то есть на модулях ядра конешно же, штоты-штоты линекс) нвидия.
Получается тру кроссплатформенное приложение.
Потому что, если пытаться использовать формы, начинаются огромные подводные камни в виде принципиально неработающих в линуксе формах винды и работающих с кучей оговорок формах гтк в винде. Ну это чисто поверхностный взгляд, я уверен, что на этот пост рано или поздно выскочит анон у которого всё работает, достаётся за полсекунды, без задней мысли.
В голос
Что не так? В нем хотя бы регистрироваться не надо. Мог бы быть какой нибудь телеграм где без мобилы не зарегистрируешься.
классика годототреда
Что в них хорошего, если физика так и глитчит? Это ведь означает, что скорее всего issue перекочуют в следующую версию и теперь придется ждать как минимум 3.2 и надеяться, что хотя бы в ней поправят.
Ну ничего, ждали три года и еще подождем, главное ПОТЕРПЕТЬ.
>хитрый хейтер годота ебанул ригидбоди в том месте, где обычно на всех движках юзают статики и визжит "смотрите, как в говнодоте физика трисётси!"
Что-то не помню, чтобы хотя бы в одном движке ригид боди в форме прямоугольника трясся на ровной поверхности, даже когда лет 10 назад программировал на допотопном блитз бейсике, там и то не было такого.
Но манька ИТТ превзмогает, скоро и ригидные тела окажутся не нужны, будем сделаем всё через статик боди, зато ничего и трястись не будет.
Все же есть надежда, что баги все-таки записаны на 3.1, а поскольку она альфа, то до релиза хоть что-то поправят.
> видеодрайвер перестал отвечать и был восстановлен
Эээ, как бы тебе помягче сказать-то? В общем, твоей видюхе - пизда.
Что-то там формата __%%__
Впервые об таком слышу. Объясни поподробнее, что это и для чего? Попробую помочь тебе с кодом.
http://www.gamefromscratch.com/post/2015/09/25/Godot-Engine-Tutorial-Part-15-Static-and-Programmatic-3D-Meshes.aspx
Я об этом. Вот только речь о гексе, разделенном на множество треугольников. Премного буду благодарен, если помимо вертексов поможешь и с uv.Также прилагаю картинку для наглядности
В релизе. Ну можно и сейчас но с багами.
Да.
Что ты несешь? За 10 лет ни одна игра, ни один эмулятор не вылетает, годот на глес3 не вылетает. Только с глес2 проблема. Где-то там бесконечный цикл, видимо не проверяется какое-то условие.
Еще один годотовец порвался.
Вопрос открыт
А кроме дурацких игр в которые играть не возможно, годот на что-то способен, или сам факт что там, что-то запустилось и двигается уже прогресс?
Видимо годот из тех программок, которые нужно самому пересобирать, что бы хоть что-то заработало. Думаю если выйдет реально стабильный и удобный релиз, то он тут же перестанет быть бесплатным.
>Вопрос открыт
Это даунский вопрос, полно годных игр вообще можно на коленке написать, а тут движок целый.
Этим деревянным, прибитым гвоздями интерфейсом совершенно невозможно пользоваться после удобств юнити.
Почему опенсурс-оборванцы не понимают, что юзабилити > все остальное.
Движку можно простить многое, в том числе плохую графику (потому что 99% кириллов все равно это не нужно), но не плохой интерфейс.
Но ведь юнька в следующей версии копирует интерфейс с годота.
>А кроме дурацких игр в которые играть не возможно, годот на что-то способен, или сам факт что там, что-то запустилось и двигается уже прогресс?
Если кто-то и сделает хорошую игру, то рассказывать всем, что он тратил время работая на годоте, будет полнейшей глупость. Это как признаться, что выкопал яму вилами или граблями, или построил дом из говна.
Мы сделаем новый UI редактора, потому что нынешним невозможно пользоваться
Надо что-нибудь модное, чтобы по одному только название захотелось задонатить.
Проще делать говно-уроки про то, как двигать спрайт с клавиатуры, и собирать донатов больше, чем Хуан.
>Проще делать говно-уроки
Это если ты внешностью и харизмой удался.
Нам сычам остается только сумрачно писать код.
Если устанавливать годот из Стима, то скачается всё необходимое. И шаблоны экспорта, и примеры игр.
DEGROD Engine
А если серьезно, то по аналогии с другим известным форком: GameCyclone. Вот будет отсылочка так отсылочка!
Погоди, я только с работы пришел. Весь день ебался с райзеном, в попытке установить на него спермёрку. Такой неожиданностью для меня стало, что она туда не ставится. Какие то сумрачные утилиты от гигабайта качал, патчил ими установочный образ. Нихуя не помогло. Пришлось поставить линукс. Завтра буду изучать вопрос, какую Виртуалку поставить для корпоративного софта.
Сейчас лежу не могу встать комп домашний включить.
Ты расскажи хоть, что сам пробовал, и что не получилось?
Окей, я просмотрел ссылку. Там генерируют меш. На первый взгляд ничего сложного. Какие у тебя проблемы возникли с этим?
В том, что я не хочу писать индусский код для каждого треугольника, а хочу их генерировать через хитрый алгоритм. Собственно, спрашиваю, есть ли такой где-нибудь, дабы не писать самостоятельно.
Помочь и гуглить-за-тебя это разные вещи.
Тогда поторопись, а то Хуан запилит раньше тебя.
Короче сам нашёл, нужно файлик с именем _sc_ кинуть в папку с исполняемым.
Gamut
Подчеркивает игровую направленость. Есть преемственность названия с годотом (общее окончание). Круто звучит. Есть готовое лого.
Уже предвкушанию как Хуан будет биться в истерике
стакаху крепкого кофе за тебя
Гениально
Раньше для этого нужно было скачивать еще что-то. Да и вообще много придется докачивать, почему нельзя сделать всё в одном архиве.
Неполноценный продукт, урезанная версия.
Ну так почему нельзя было сделать полную версию программы, всё нужное в одном архиве?
Ну не знаю, вы же юнитипидары все равно постоянно ассеты какие то качаете.
>полную версию программы
я наоборот щитаю что говнот недостаточно модульный. какой-то блоб данных, вместо движка.
очередное доказательство никчемности хуана как программиста.
Так это движок, а не фреймворк или либа. Вообще если сам компилируешь кое что можно дефайнами отключить.
Ну и что? Не следует unix философии Хуан.
В идеале движок должен из себя представлять модульные, подключаемые библиотеки, плееры для разных платформ использующие эти библиотеки и фронтенд (редактор). Все.
Плеер бы запускался например так: godot.exe game.zip, просто загружая игру из архива
Интересно, если всё возможное в годоте скачать, сколько будет весить и можно ли сделать рабочую сборку из этого.
Так и сделаем в нашем форке Gemor'е.
У многих движков и конструкторов отдельно поставляются export templates, хули доебались.
Не всем нужен экспорт. Допустим, у тебя команда (хаха, ну прикол, у тебя, команда), один уровни строит, второй персонажей анимирует, а собираешь всё вместе ты. Им экспорт не нужен. Они тебе просто ресурсы в систему управления версиями грузят.
Ну нифига себе, на годот работают целые команды и даже уровни строить пытаются. У них даже есть выбор использовать экспорт или нет, до чего технологии дошли, безумие.
Главное, чтобы спрайтов в следе было не более 50ти на фрейм, а не то фпс просядет.
Прав был анон в прошлом треде. Надо сразу кресты учить.
Но ведь это годот спиздил интерфейс юнити
Единственное сходство, это кнопки под панелью. Такие кнопки существовали задолго до Хуана
В говне(доте) даже табов нет. Окстись, маня.
>2D в годоте с гдскриптом нормальное?
Как для двадэ так блотанутое чет, для пеки норм, для позапрошлогодних нефлагман мобилок - не оч.
Ну я слышал, что у вас там впринципе какие-то процессоры мобильные не работают, так что изначально не собирался под них делать.
Бенчмаркни, бенчмаркни. Вон в бомбермем-треде анон делал:
f = preload(fire.tscn)
...
p = f.instance()
Где fire.tscn - это простенькая нода со спрайтом, разбитым на 50 фреймов и аниматором, который проигрывает эти фреймы один раз, после чего нода самоуничтожается. И вот 50 таких инстансов наглухо сажали у него GTX1060.
Дерзай, может ты оптимальнее бенчмаркнешь.
Подъебка засчитана. Но разгадка в том, что глитчи физики во всех этих уважаемых коммерческих движках, что указаны в видосе, происходят от того, что симуляция физики на данном этапе развития техники ещё очень далека от реализма. Реально симулировать физику могли бы воксельные алгоритмы, но пока что домашние пека не потянут воксельные миры с такими мелкими вокселями, которые были бы не видны глазу.
Очень обидно. Остаётся только терпеть и ждать.
Они платные. А юнити даже не опенсорс. А уеча не свободный. Это движки для рабов.
Я пилю потихоньку, но смысла торопиться нет. Сейчас только перешел на 3.1 альфу, потом переделывать когда релизнется, потом буду ждать 3.2.
А потом 3.3 и вот ты уже состарился, а игру так и не сделал.
Распидорашка не палится, но запах кала не скроешь.
Не качайте посоны, у меня так брат умер.
А вот этот пост, случаем, не является обсуждением модерации?
Дичайше проигрываю с самосборщиков, которые на серьёзных щщах пилят ААА проект по самосбору, а в это время один хитрый распидор буквально выбивает у них табуретку из под ног, запилив уже три тайтола по вселенной. Они такие выпускают релиз в стиме, а им - нна в ебало судебный иск на стопицот мильонов за нарушение авторских прав. Угораю! Жги дальше, расп!
Это ловушка, не ведись на это.
Пара шизофреничных миниигр, названные самосбором из-за того, что распидору не хватает внимания.
Пара шизофреничных миниигр достаточна, чтобы заняться патентным сквоттерингом.
Станет ли Годот настолько же популярным как Юнете? Ну типо я сейчас вкачусь, стану годот жуниором и потом смогу на хедхантере найти работу в офисе?
Значит учи.
https://www.youtube.com/watch?v=UTAeDoRIHaA
В основном конечно всякая 2D параша но есть и пара графонистых игор
Что тебе мешает выучить годот И юнити? Там учить-то особо нечего. Оба движка могут работать на шарпе. Как минимум шарп учи обязательно, если метишь в офисе работать. А зная шарп, тебе будет похуй, как писать игру:
class Player : MonoBehaviour {}
или
class Player : Node {}
В любом случае учи современный айтишный подход к симуляции физики, он в целом схож во всех физических движках: есть три вида тел: статические, динамические упрощённые и динамические усложнённые. Вся симуляция физики рассчитана на то, чтобы сделать игру (или в общем виртуальную сцену) как можно быстрее, ибо на данном этапе развития техники, компы не тянут полноценную симуляцию физики.
Всё остальное во всех движках различается в сущих мелочах. Такие же плееры звуков, такие же средства сериализации, такие же средства работы с сетью. Различия только в названиях классов/методов. ну и в скоростях конечно. Кто-то сделал быстрее, вовремя понял, что другие так не смогут, закрыл код и требует роялти. А кто-то сделал не так быстро и понимает, что денег за это не дадут, потому открыл код под опенсорц-лицензией.
Что тебе мешает учить годот И юнити? там учить-то особо и нечего. В одном движке компоненты называются нодами, в другом движке ноды называются компонентами.
Оба движка могут в шарп.
Вот шарп учи обязательно, раз метишь в офисе работать.
А с шарпом тебе будет похуй, как писать код игор:
class Player : MonoBehaviour {}
или
class Player : Node {}
Выкидываешь из питона импорты, работаешь только с одним импортом, который неявно устанавливается для любого скрипта - import Godot
В остальном различия минимальны, если чего-то не хватает из модулей питона - ищи аналоги в АПИ годота, если не найдёшь - пиздец, приехали.
Ну и оператор match ещё, кажется это личное изобретение команды Хуана.
Годотовских игр в 10-ки раз больше. Просто МИТ лицензия этот проклятье. Ведь никто не обязан сообщать, что он сделал на этом движке. Вот если GPL или EULA проприетарная была, все бы уже знали про игры на годоте.
>Станет ли Годот настолько же популярным как Юнете?
Говно навсегда останется говном.
Когда идиотам надоест ЖДАТЬ, и без того никакая популярность говна исчезен окончательно, вместе с 10к Хуана.
>Годотовских игр в 10-ки раз больше.
Их можно детектить по гигантскому бинарнику и ресурсам, запакованным в один файл.
Добро пожаловать в семью си-подобных языков.
Есть ли нода, которая умеет отключать собственный скрипт?
Вкратце — она мне понадобилась для маркера АОЕ-скилла. Я прикинул, что если он будет появляться по команде из HUDа, бегать за мышью, а потом передавать свою позицию дальше и отключаться, это сэкономит мне до чёрта разных _process с проверками никому не нужных флагов и срежет треть существующих сейчас костылей.
Вариант скрипта с проверкой кучи флагов — не вариант, лишний _process, который 90% времени проверяет, что всё вокруг false — это боль. Вариант спавна этой ноды в виде инстанса и удоления по завершению её работы тоже не очень удобен, а вот именно такая нода, которая есть у кучи других объектов и отличается, по сути, только спрайтом, а большую часть времени не отсвечивает, была бы очень к месту.
У ноды есть свойство "скрипт", теоретически ты можешь обнулять это свой... блять стоп! Тебе поможет функция set_process() - она тупо отключает обработку скриптов в ноде из которой вызвана.
Вот я мудак безмозглый. Спасибо, моя жизнь больше никогда не будет прежней.
На самом деле мне очень стыдно, что я не просмотрел ещё миллион роликов, где всё это разжевано для существ с интеллектом улитки, но если я не буду тут задавать тупых вопросов, кроме срача ничего и не останется.
Не извиняйся, в кои-то веки у нас тут спокойный дискасс с обменом опытом, а не срач.
>ДА ЗА КАКИМ ЖЕ ХУЕМ Я 10 ЛЕТ УЧИЛ ЁБАНЫЙ ПАСКАЛЬ!?
Действительно. Я думал, про него еще в 90е забыли.
Детишек всё еще учат. Есть Lazarus, на котором очень легко и быстро набрасывать гуёвые софтины. Я на нём до сих пор всякую мелочевку пишу вроде индикатора даблклика.
Паскаль - хороший язык для обучения информатике, потому что там тебе нужно все объявлять. Безтиповые питоны и сиподобные языки с кучей неопределенного поведения хуже для понимания, что происходит внутри.
И о чем это говорит? Ты бы хоть книжку какую по питону прочитал.
Называется динамическая типизация.
В каждый момент времени result ссылается на конкретный тип данных.
Не безтиповый.
Если бы он был безтиповый то сработал бы такой код
a=5
b="hello"
a + b
А это вызовет исключение. Необходимо сделать приведение типов str(a) + b
Придуриваешься здесь только ты, уважаемый специалист.
Хотя конечно даже если бы это работало он бы все равно не был безтиповым. От тебя глупостью заразился. Ведь бывает автоматическое приведение типов, в данном случае его просто нет.
Ты отлично понял, что имелось в виду.
Да, формально только какие то абстрактные языки для матеши являются безтиповыми.
Но, блджад, в повседневной жизни проще сказать "безтиповый", чем "языки с динамической или утиной типизацией, с вариантными типами и прочей парашей, которые не требуют объявления типа переменной в до использования, и позволяют переменной сменять тип в процессе"
Снобы типа тебя НЕ нормальные люди.
Нормальные люди замечательно поймут, что имелась в виду.
А ты просто выебнулся свежими знаниями первокура, не более.
Так он не один даун здесь. Вы все что ли такие? Спасибо буду знать что годо для даунов.
Двое.
https://www.youtube.com/watch?v=AzWUxPelH94
https://godot.readthedocs.io/ru/latest/getting_started/step_by_step/index.html
Пожелаем же долгих лет и безболезненной смерти этому святому человеку!
Жаль тебя разочаровывать, но этот автоперевод там уже с пол года и чаще мешает при поиске инфы.
> повседневной жизни проще сказать "безтиповый"
Нет, не легче, это полный пиздец называть штуки тем чем они не являются
А может это нейроночка спиздила с сайта?
public class Enemy : StaticBody2D, IEnemies, IMovable, IPersistent, IHaven, IAllaH
Нет? То-то же! Юзайте сишарп!
> А может этот ваш гдскрипт делать так:
> ООПараша
Как там в 2007? Седар милл ждалкера потянет?
Схуя это интерфейсы ООП? Учи матчасть, даун.
Неосилятор ООП порвался
Это как называется, когда минорные версии ломают проект?
>godot will self-destruct
Надо было чтобы он ещё компьютер с такой видеокартой дестрактил, вот ето был бы вин.
Когда мы напишем наш форк годота, он так и будет делать.
Ну мы ж не американцы, чтобы послушно бэкапить гигабайты ассетов ради сохранения килобайтного текстовика.
Почему в годоте по умолчанию не поддерживается написание на кириллице? Говно блядь
Русофобы.
У Хуана что-то совсем плохо с управлением.
Уже "героев" набирает, которые ему баги поправят.
Пример бага, который некому починить уже 2 года
https://github.com/godotengine/godot/issues/6485
Пусть просто не жмет эту кнопку. Хули какой тупой, обязательно надо нажать и поломать.
Так вот почему у тебя игор нет! Оказывается запятую ошибочно назвали двоеточием и это мешает тебе сделать хоть одну игру! А я-то наивный, думал, у тебя нет игор, потому что ты хуило бездарное.
Сейчас он напишет, что у него куча игор на других неговнодвижках, но он нам их не покажет, потому что у нас пачпорта нет.
Ты мне лучше объясни, почему Хуан вместо того чтобы исправить, пишет в топике ссылку на названия кнопок в шиндоус, и призывает Героя? Хуан не Герой?
Причем тут Хуан? Мы же выше выяснили, что ты хуило бездарное, сидишь в треде, мониторишь незакрытые ишью на гитхабе. Изо всех сил пытаешься доказать кому-то в интернетах, как в интернетах кто-то неправ, что пишет игоры на говнодоте.
>Причем тут Хуан?
При том, что он отписался в топике, вместо того чтобы исправить и закрыть баг.
>мониторишь незакрытые ишью на гитхабе
Я их не мониторю, а попал туда из новости на главной движка.
>Движок дырявый как жопа ОПа-годототредов
>Самое время переписать с нуля анимации. Анимации сами себя не перепишут.
>вместо того чтобы исправить и закрыть баг
Не барское это дело, баги исправлять. У Хуана есть ВИДЕНИЕ проекта и ежемесячные 10к$ донатов
>Как это дерьмо форкать, легче заново написать.
Дай угадаю, не осилить в 2к18 питон для сборки?
Хуаньчик, родной, он такой же как и я. Рос в весёлых 90х, игор не было, не родись я мальчиком, мне бы вообще не с чем было играть.
Годрот, zx pektrum был и денди, ну и бк-10 в 90х
Нет, я же не гей-пидар-юнитипидар.
Это кто вообще, мужики или бабы?
Поздравляю с открытием. Оказывается, пидоры уже третий тред подряд срут в годотреде. Может теперь-то наконец вы начнете их игнорировать, годаны?
ну, типа, зашквар с пидорами беседовать и всё такое.
Погоди, но ведь это ты все время делаешь массаж яичек родному Хуану. Значит, ты и есть главный пидор треда.
Тебе нечего стесняться, любить Хуана - это норма.
Питноподобный гдскрипт, сишарп, визуальный скрипт (пикча выше) и скрипт из внешней либы, т.н. нативскрипт.
>скрипт из внешней либы, т.н. нативскрипт.
Готовая обвязка есть для C, C++, D, Nim, Haskell, Rust, Go.
Языки по списку от более поддерживаемыми к менее поддерживаемым, т.е. Rust полгода назад обновлялся и скорее всего не заработает.
Т.е. можно взять С/С++ и писать на нем, но низкоуровнего, просто обращаясь к хедерам движка, но всякое Godot IDE и игровые скрипты - это уже не для тебя и уже на нем не напишешь?
Если брать кресты, то намного выгоднее взять исходник движка и приписывать к нему свои ноды, со своим функционалом. Потом компилируешь движок и в редакторе просто, без задней мысли кидаешь на сцену свои ноды.
Это будет производительнее, чем нативскрипт, но велика вероятность запутаться в дебрях Хуанового говнокода.
Ну это фреймворк все же, а не движок. А из них с чем работал больше пришелся SDL2 по душе, т.к. разрабатывается давно, запускается хоть на утюге, низкоуровневый при необходимости, да даже valve его под свое крыло взяла и спонсирует разработчиков.
Все будет работать и в редакторе, потому что редактор просто рисует ноды.
>Готовая обвязка есть для C, C++, D, Nim, Haskell, Rust, Go.
Хочу обвязку для FPC. Хуан, сделай!
>делает не Хуан
А что, Хуан что-то вообще делает?
Последнее что он сделал, это gles 3, который откатывают теперь обратно лел. Велосипедщик ебаный.
Учи мемы, чтобы не быть баттхертом.
Я пытался перевести хедеры, но мне не хватило знаний. Да и усидчивости тоже. Там охуеть сколько кода нахуярено.
>Там охуеть сколько кода нахуярено.
Так он вроде автоматически генерится скриптом по списку функций из json файла.
Ты же не руками писать собрался?
>Учи мемы
Да уж, Pascal в 2к19 это тот еще мем.
Автоматическая генерация выдает какой-то нерабочий код. Возможно я не старался, конечно.
А, разобрался о чем ты. Это функция scons, которая генерирует код для джавы и си.
Я пробовал конвертор сишных заголовков фрипаскаля и он мне какую-то хуйню выдавал.
Оставлю это здесь, чтобы было:
https://godotengine.org/qa/10650/best-way-to-create-events-between-two-nodes
https://www.youtube.com/watch?v=F6VerW98gEc
>Using Godot as my engine was a two edged sword, it allowed me to make use of really useful features for free (Tilemaps, post processing, portability, ease of exporting) but had me exploring the realms of limited documentation and forum browsing on the daily, trying to understand why X crash was happening or why Y feature was not working. Most times, the solution to any seemingly 'engine' related problem had to be solved and debugged by me - sometimes taking multiple days.
Наткнулся на реддите, вот вам реалии разработки на годоте. Забагованное сырое говно
Ишьюс это не баги. Там большая часть фича-реквесты "а хорошо бы, чтобы вы добавили свистоперделку".
Хуан уже озаботился этим и большую часть выкинет перенесет в отдельную репу.
Кириллица - не забота движка. Чтобы в твоей игре была кириллица, скачай и установи в проект кириллический шрифт.
Это принципиальный момент, который не изменится. Можете скринить.
>оптимизация - не забота движка. Надо самим попердолиться, чтобы была оптимизация, из-коробки этого не будет. Можете скринить
>удобство - не забота движка. Надо самим попердолиться, чтобы было удобно, из-коробки этого не будет. Можете скринить
>графон - не забота движка. Надо самим попердолиться, чтобы был графон, из-коробки этого не будет. Можете скринить.
>работоспособность - не забота движка. Надо самим попердолиться, чтобы работало, из-коробки этого не будет. Можете скринить.
Долго ж я ждал, пока ты передёрнешь. Кушай, мой зелёненький. Годот может выводить любые национальные символы. Однако о наличии шрифта с твоими национальными символами позаботься сам.
Хуан решил использовать юникод, а не изобретать свой велосипед? Что-то новенькое
А хули Хуан не добавил тогда такой шрифт? Другие же опенсурс проекты добавляют такое и не ноют, нет Хуану нужно быть особенным и выделиться долбаебом
или какой нибудь другой годный не для полных нубов в программировании?
>>27025
https://mega.nz/#F!hrQTlCpY!0xh2OfnusheK0s86LFZ1bA
Держи, няша. В том виде, в котором оно сейчас на гамроаде лежит. Там, как минимум, он ещё одну главу не доделал.
Без обид, но юнитибояре на своем движке уже покоряют космос игростроя, а годот это такая вырезанная из пластиковой бутылке лопаточка, чтобы играть в песочнице.
Ben Tristem обещал, но пока они в https://www.udemy.com/godot/ дойдут от хелоуворлдов и примитивных дваде-платформеров до хоть чего то - хуй знает сколько ещё времени пройдёт.
Был ещё один курс на юдеми ( вот уж где "качество", лол) вроде как с тридями, но не смотрел.
Ещё один - это https://www.udemy.com/godotcourse/, но там хрен знает насчёт научат ли хоть чему
Украсть можно даже на сижипирсе: https://www.cgpeers.com/torrents.php?id=57597&torrentid=57537
Благодарствую
Но ведь это правда. Ты действительно говна поел. Да, все вокруг "бабахнули", но это того стоило. Я могу "бабахать" и "подгорать" хоть весь день если ты для этого будешь говно кушать, договорились?
Нашел на Реддите игру, которая сделана в Pygame (не маркетолог):
https://store.steampowered.com/app/442210/Switchcars/
Выглядит более-менее (с точки зрения геймплейных фич, а не графона, конечно).
Имеет смысл сразу начать учить Годот или все-таки попробовать сделать какой-то проект в Пайгейме для начала? Спрашиваю опытных людей просто ради того, чтобы не терять время зря на, возможно, хуевый фрейморк Питона.
Плановый проект: 2д игра.
Примерно одного поля ягоды. Что Pygame что godot. Тут исключительно дело вкуса, разве что godot в итоге выдаст тебе проект чуть пошутрее
Не проецируй, бабахнувший говноед. На говне итт зациклен только ты.
При одинаковой кривости рук и умении пользоваться и тем и тем инструментом - да, godot незначительно, но шустрее, но на это можно не обращать внимание при выборе.
распидор чмо
Та про можно или нельзя на гитхаб пэйджес хотя бы захостить?
Ну, короче, 2Д-экшон суть такова...
Пользователь может играть лесными эльфами, охраной дворца и злодеем. И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы...
Это похоже на тред поддержки гитхаба или конгрегейта? Откуда тут знают, что там можно хостить, а что нет?
Это тред движка и, очевидно, тут могут знать можно ли хостить игру на этих сайтах. Уже думаю попробовать фазер.
Есть разные типы людей, некоторые если начнут писать тз, то у них все на бумажках и останется, а когда ты запускаешь редактор годота, все сразу расцветает, ты сразу начинаешь творить, экспереминтировать.
Да вообще поебать хоть говна попробуй.
Двачую!
Потому, что нет альтернатив. UE крутой, но слишком тяжеловесный для инди-разработки, unyti настолько кривое говно, что уже стало синонимом говноигр на пизженных ассетах, что еще остается? Только верить в годот.
Смотря что требуется и для каких задач. Где-то и UE хорош, где-то love - приходилось писать на разных движках и это зависит от проекта больше.
А у таких людей все останавливается на однотипных прыгающих квадратиках по платформам
О, идея!
У меня еще советское, не переживай.
Свинья, то что ты доверху засрал гд не делает его "твоим".
мимо
Тут даже непонятно, кто кого зашкварил - gd godot или наоборот...
Вот только слева чувак хотя-бы работает, а не понтуется как позёр справа аки казах своей неприменимой красотой.
Обидненько, но правде в лицо надо смотреть. Даже в инсталлере вижуал студии сишарп и бейсик идут одним пунктом. Что намекает на то, в каком углу зашкерен сишарп и с кем.
Потому-что бэйсик.net это полностью тот же Сисярп, только с другим синтаксисом, ебанько.
Мелкософт просто захотел срубить бабла на старых дедах пердунах, которым синтаксис васика привычнее, вот и всё.
Ты копротивляешься безнадёжно, мой милый шарпоед. Ибо с бейсиком мс дружит давно и плотно, еще в мохнатых 70х, молодой гейц нагревал на даллары крупные фирмы, продавая им ворованный айбиэмовский бейсик. потом появился борланд и начал банчить трубо-посралем. И тогда мс в лице гейца и борманы поделили сферы влияния и договорились, что мс никогда не лезет в пасраль, а борман никогда не лезет в бейсик.
Но си/сиплюсы не в счёт. Это полноценный язык и никто от него не отказывался.
Так что твой шарп в одном петушином углу с языками для недопрограммистов.
>считать, что VB.NET это тоже самое, что Visual Basic 90-х, что тоже самое что BASIC 70-х
Ох вау.
Ох хуяу, долбоеб. От того что в барсик напихали дотнетного ооп, он дворнягой быть не перестал.
И что ты хотел сказать этой простыней текста? Я блядь просто говорю, что Сисярп и васик.net это одного поля ягоды, где разное, это только синтаксис. А ты тут начал неведомую хуйню писать.
Мне сука абсолютно посрать/нассать/поебать что на c#, что на vb.net
На всем дваче, спасибо абу.
Сделать на движке окно конфигуратора, запускаемое перед основной игрой. В конфигураторе будет выбираться разрешение экрана, оконность режима, настройки графики, ну и что там обычно делается в конфигураторах.
Набросал небольшой набросок, там всё просто: Главная сцена - сплэш-скрин. Он читает настройки из инифайла и если там параметр "уже настроено" существует и равен тру, то сплешскрин прелоадит и инстансит сцену главного меню, сцена главного меню читает остальные настройки из инифайла. if not "уже настроено": то сплешскрин прелоадит и инстансит сцену "конфигуратор", которая вся построена на контрол-нодах, которая ресайзит окно под себя, у меня 800х600, и выглядит как типичный диалог с кнопками внизу: "отменить (выйти)", "сохранить", "играть!".
Всё правильно делаю? Какие есть замечания к идее?
Какой-какой? Модный, идущий в ногу с трендами.
Напишите ему пусть server ещё заменит на respectiveworker, а то еще посыпятся иски от обиженных представителей сферы обслуживания.
Пиздец, а Хуан у нас куколд бесхребетный оказывается..
Пусть он константы запретит, ибо вдруг переменная идентифицирует себя не как сексисткое число 45, а как булево выражение false..
Уже запретил. Гдскриптовые константы, по некоторым данным - это ссылки на переменные. Проверять это я конечно же не буду.
И до годота докатилось. По всему гитхабу сейчас такое восстание рабов.
>В конфигураторе будет выбираться разрешение экрана, оконность режима, настройки графики, ну и что там обычно делается в конфигураторах.
Ты юнитипидор что ли? Это все должно быть в настройках в самой игре.
Я хочу показать юнитизависимым, которые еще не стали пидорами, что такое же окно конфигурации можно запилить и в годоте.
И вообще, множество игр использует отдельный конфигуратор/лаунчер. Почему бы не сделать такой же ассет-кирпич для годота?
>И вообще, множество игр использует отдельный конфигуратор/лаунчер
Это ненужный костыль, добавленный потому, что юнитипидары очень легко могут накосячить, и записать такие настройки, при которых игра ничего не рисует. Вот поэтому им и сделали это инвалидное окно, чтобы пользователь мог починить. В нормальных играх настройки внутри игры, а при запуске рисуются красивые логотипы движков и спонсоров. А если что-то сломалось, можно зайти в папку документов и поправить настройку в человекочитаемом текстовом файле. Не надо копировать неудачные решения, только потому что они в куче говноподелий на юнити.
>Master/Puppet
Потом какой-нить альтрайт в футболке пикрелейтед завалит 50 нигеров и эти термины запретят
Да лаунчеров вообще-то полно в куче игор на других движках.
Это же удобно, когда игру можно настроить перед игрой. Банально субтитры включить, чтобы они отобразились в начальной демке.
И ЧСХ, если разрабы не делают такого конфигуратора - его делают сами игроки. Для тонкой настройки.
Может поэтому и не стоит такой встраивать в игру, ибо игрокам все равно не понравится и они сделают "только лучше"?
Не твои, вот ты и бесишься. Ты не сделаешь даже 10% интересной игры от любого из этих тайтлов.
Ты обдвачевался. По твоему интересны игры, в которые никто не играет?
А вот собственно и реализация (хуяк-хуяк и в продакшон):
Проорал с этого парня. Окно конфигуратора в Юнити это признак разработчика-школяра, который не смог его отключить чтоб запускалась нормально как и все игры сразу. В общем зашквар.
А ты хочешь эту хрень повторить еще в годоте, ахаха)) Вот что значит перенимание "лучших практик игростроя" xD
Ну так нам же и надо согнать школоту в годот, чтобы нарастить популярность. Ничего ты не понимаешь в пиаре.
> перемещать кубы
Тащемта это предел этого движка. Не, ну а что ты хотел от опенсорса, если запустилось и то хорошо.
Пиздец, кубы перемещать, как сложно. И это называется уроком.
Слева обычный казуал, а справа ебанат-бездельник в цветастых лохмотьях.
Годотодрочеры самокритичны.
Что правда то правда.
Годот в полной мере реализует только одну парадигму: GVNKD
В годоте нет и не будет ECS на уровне движка, Хуан сказал использовать иерархию сцен вместо этого.
Покажи, как ты понимаешь ECS и я покажу тебе, как это реализуется на годоте.
Надо просто настроить ширину Таба поменьше, но мне лень и похуй. Я ж на игру буду смотреть, а не на код.
Распидор может и чмо, но он знатный тролль, раз ты бомбишь от него уже несколько лет, еблан. Респект распидору!
Сам в ахуе. Но справедливости ради замечу, что для таких результатов я пердолил консольку несколько лет.
Лучше расскажи, как ты сделал фоновую загрузку с рабочей анимацией. Все мои попытки пока что упирались в то, что движок намертво останавливает любую обработку активного окна, когда происходит загрузка сцены, даже если она в параллельном потоке идёт.
Я просто не сохраняю слишком много объектов в одной сцене. Добивайся того, чтобы каждая загружаемая сцена была максимально лёгкой. Затем игровая логика конструирует конечную сцену из десятка маленьких сцен, подгружаемых по отдельности. Таким образом, загрузка любой сцены-компонента хоть и блокирует процесс, но на микросекунды. И ты сможешь обработать анимацию.
Само понятие "сцен" в годоте слегка сбивает с толку, ненавязчиво предлагая сделать в редакторе один тяжёлый объект и грузить его часами. Но это неправильно и годотовые "сцены" в твоей игровой логике должны быть мелкими, легковесными "компонентами" одной большой "сущности" в которую ты должен заложить "систему" для подгрузки и выгрузки компонентов на лету.
Это убивает весь смысл сцен. У меня вот есть сцена уровня с объектами. Так мне теперь вместо объектов ставить пустые ноды и писать подгрузчик для уровня? Ну и нахуя тогда вообще редактор нужен, да и вообще Годот? Мне тогда проще будет свой движок накатать, где фоновая подгрузка не будет блокировать основной процесс.
Ну вот чо ты истеришь? Ничего там не убивается. Сцены не пустые, просто легковесные, соблюдают принцип KISS.
Маленькую игру можно сделать одной большой сценой, загружаемой за раз. Но в крупных проектах хоть какой движок возьми, хоть свой сделай - будешь грузить ресурсы самописным менеджером ресурсов, оптимизированным под эту конкретную игру. В тех же юнити тредах, например, постоянно проскакивают кулстори про то, как команды разработчиков, плюясь и матерясь, выкидывают нахуй искаропочные решения юнитеков и пишут с нуля свои решения загрузки ресурсов.
Я говорю о ресурсах сейчас, хотя тормозить при загрузке могут и скрипты с какой-нибудь чудовищной процедурной генерацией всего подряд. А виноват у косолапого дауна конечно движок.
В общем, вместо одной большой сцены с миллионом объектов надо грузить пустую сцену с миллионом сцен в ней?
Именно так. Причем, по мере продвижения игрока по сцене, удаляющиеся объекты должны выгружаться, а приближающиеся - загружаться. Ты впервые слышишь об этом?
> Ты впервые слышишь об этом?
В контектсе Годота - да. Но тут же все самому делать надо, так что неудивительно.
единственное что нужно делать в котексте годота - это удалить его и установить юнити
> тут же все самому делать надо, так что неудивительно.
Уже не всё. Уже в ассетлибе есть и террейны и конечные аппараты (finite state machine), и много ещё всего. И ещё больше будет. Комьюнити растёт!
Flappy Bird за полгода? Ну такое...
В треде писали что минимальные. Я ни то ни другое не знаю, впрочем.
Можешь сам доки посмотреть - http://docs.godotengine.org/en/3.0/getting_started/scripting/gdscript/gdscript_basics.html#introduction
>Ну и оператор match ещё, кажется это личное изобретение команды Хуана.
>Change "switch default" to a _
Ну что ты. Это спизжено из функциональных языков.
let x =
match 1 with
| 1 -> "a"
| 2 -> "b"
| _ -> "z"
Ой, спасибо, буду знать.
Уже нашел решение. Можно сделать ноду Position2D и на ней в процессе ставить гообальную ротацию
>как ты сделал фоновую загрузку с рабочей анимацией
https://godot.readthedocs.io/en/latest/tutorials/io/background_loading.html
Да тут сидит один аутист, который не понимает из контекста очевидные вещи, типа безтиповые (динамические) языки.
А, так это он! Я догадывался.
А я уже два года как сменил дефолтное именование рабочих потоков с "worker" на "nigger". У меня даже продакшн логи нашего серверного приложения ниггерами наполнены, оказывается(а я уже и забыл об этом, лол).
Это охуенно.
Это показывает уровень твоего любительского профессионализма, поэтому настоящие профессионалы не будут воспринимать твои высеры всерьез.
Настоящие профессионалы (я, например) отлично понял, что он сказал, а вот ты обосрался, как всегда.
Я тоже понял, но если бы там дальше проследовала какая то претензия на оригинальную мысль, то я бы просто перестал читать, т.к. он уже показал что не в состоянии справится даже с базовыми терминами.
Пойми, я хочу чтобы диалог был построен на доверии, но доверие не может строиться на такой некомпетентности. Потому в следующий раз внимательно подумай прежде чем что-то писать.
Пошел нахуй.
Все работают над игрой мечты!
А ты не общайся, ты помогай нубам стать профи.
Не представляю, зачем это нужно? Просто из академического интереса штоле?
Ну я надеялся, что может кто и из местных пробовал)
А расскажи с каким оверхедом уже столкнулся, ну там кроме постоянного отключения невидимых объектов, раздутых сетевых пакетов и.. Есть конечно еще много вкусовщины, которую я бы сделал иначе, но тут уже только вкусы мои)
>Посоны, фризим ветку альфы, никаких новых фич, только фикс багов
>Новости: добавили в движок новую хуйню.
Шаг вперед два шага назад.
Невидимость - это вот ты ставишь что-нибудь эффект там света или спрайт и временами отключаешь ему прозрачность, например, линейно, до нуля. Ну и потом большинство просто так и оставляют, а для производительности надо еще сам объект в сцене делать невидимым, чтобы рендеринг его каждый раз не дергал на отрисовку.
Сеть - там много мусора передается, поэтому если пишешь высоконагруженную сетевую, но не получается их парадигма "из коробки есть все, что нужно" и берешь другую либу или пишешь свою. У них там eNet вроде используется видоизмененный.
Понятно, ну про прозрачность вроде все геймдевы должны знать, что прозрачность это пздц пздц дорого.
А про сеть можно подробнее, что именно за мусор там?
>Before anything else, we would like to thank our long-time sponsor Gamblify
>Gamblify
Донаты крутятся, лавеха мутится
Жуан, залониньтесь.
В чем дно? Тыскозал, что нельзя принимать спонсорскую помощь от лохотронщиков?
Я сильно слоупок?
Вскрыта фобия Хуана!
>нельзя принимать спонсорскую помощь от лохотронщиков?
>нельзя принимать спонсорскую помощь от террористов?
>нельзя принимать спонсорскую помощь от торговцев наркотиками?
>нельзя принимать спонсорскую помощь от продавцов органов?
Так и представил себе - ты оказываешься с Тимом Куком в лифте, и у тебя 10 секунд на питч, чтобы убедить его вложиться в твою игру. Ты запускаешь демку, а там реклама казино, в лифте открываются двери, играют фанфары, вбегают горячие карнавальщицы, бьют в тамтамы. Все, время вышло.
А, а, а! Началась игра!
Но такие ситуации допускаются и прекрасно работают, вне зависимости от "яскозал"какого-то омежки с двачей.
ЯДИБИЛ. Засунул код, опрашивающий дерево, в функцию _exit_tree(), когда ноды из него уже выгрузились.
А виноват, конечно же, движок...
Чот пиздеж чую я. Особенно просмотрев кучу туториалов по триде в годоте.
Придираться нужно не к отсутствию туториалов, а к дичайшим тормозам, лагам, глитчам в тридэ физике.
По факту годот сегодня - это двадэ движок. За триде возвращайся в юнити. Это я тебе как ОП треда говорю. Вечером подпишусь, если не веришь.
Ну правильно, ты ничего не мог найти, потому что твой вопрос некорректный. Что еще за "предметы" которые ты двигать собрался? Там есть RigidBody и KinematicBody с разным поведением. А если это базовый Spatial то его не "двигают" а используют translate как и положено в 3d.
Смотри, быть может я слепой, и проходил мимо святого, а может я просто привык к избытку документации юнити, но я бы не отрицал тот факт что помощи для 3д почти нету, особенно по сравнению с 2д. Кстати вангую ты тоже двадешник. На счёт пройзводительности тоже читал, и пока не понаехали фанатики с криками "самое сложное делай в нативе или сишарпе" или "исправят", скажу что учить ещё один синтакс и делать так никто не будет, тк слижком пердоливо, а исправить не исправят, тк это из за гдскрипта который на основе питона сделан, тут уже можешь не мечтать о межпланетных сражениях. Это наверное действительно главная проблема годота, опять же ести 3д, тк 2д есть 2д, тут сила не нужна.
>>28697
Вопрос у меня был такой : есть два стула я хотел создать мяч который бы спавнился в определённом месте, и сразу улетал в нужное направление, а position3d оказался спасиалом, и плюс к этому я не знал что есть глобальные координаты и локальные, и собственно транслейт тоже фигово у меня работал, мне в редите посоветовали пользоватся трансформом. В любом случае я посмотрел что такой хуеты в 2д нету и люди не парятся, и тк на форумах годота все двадешники то мне постоянно советовали 2дшные функции аля get_position() когда даже слово position не существует в 3д, не то что функции. Вообщем ад
> Спавнился мяч и улетал в нужном направлении.
Делаешь отдельную сцену "мяч". В корне сцены kinematicbody, в потомках - collisionshape и meshinstance c одинаковым шаром в параметрах.
Далее, в основной сцене делаешь load или preload. Устанавливаешь трансляцию координат. После этого добавляешь к сцене. И сразу после добавления вызываешь moveandslide с нужным ускорением в виде вектора-3, который задаёт и направление тоже.
Соглашусь, что выбор скриптового языка был у них очень неудачен, к тому же еще и переделанный до своего. Наверное даже AngelScript подошел бы больше под задачу.
Важный фикс:
1. Делаешь мяч - rigidbody.
2. Никаких move, просто при спавне мяча задаёшь два вектора: translation и linear_velocity.
3. It's just works!
Прилагаемые скриншоты послужат тебе туториалом. Я сделал простенькую сцену ballspawner с камерой и таймером. По таймеру происходит код на скрине 3.
В движке на производительность влияет архитектура, управление конвеером видяхи, а никак не то, на каком языке скрипты пишутся. Ну и да, делай в нативе.
>AngelScript
Интересно, пишут что он работает вместе с C++, значит его можно прямо к нативу прикрутить.
Как бы я так и сделал, но тк смотрел тутор на 2д то была засада с позишоном, который здесь транслейт, кстати я до сих пор не понял разницу между трансформом и транслейтом кроме того что трансформ зачем-то массив массивов координат. Боже, в юнити это настолько легче делается, я не понимаю зачем столько сложностей, в юнити блин это всё делается двумя кликами и тремя буквами....
> а никак не то, на каком языке скрипты пишутся.
>делай в нативе.
Хммммммм, расскажу тайну, натив тоже язык скриптования
Ну и результат, увы без видео, но мячи реально скачут в разные стороны.
Необходимо код со скринов выше модифицировать как на втором скрине в этом посте, а у таймера отключить one_shot.
В качестве домашнего задания, сделай translation так же рандомным.
> кстати я до сих пор не понял разницу между трансформом и транслейтом кроме того что трансформ зачем-то массив массивов координат
Трансформ - world matrix, транслейт - изменить координаты..
Линеар велосити вроде задаёт прямую траекторию, а мне надо чтобы он падал, но всё равно спасибо. Правда пожар мой это особо не потушило, так что я пожалуй всё равно вернусь к просьтенькому юнити который всё таки более заточен под 3д. но скрины сохранил
>Линеар велосити вроде задаёт прямую траекторию, а мне надо чтобы он падал
Неверно. Он задаёт ускорение в данный момент. После этого, в течение каждого кадра движка ригидбоди будет падать. Если оно в режиме ригид - оно падает автоматически. Благодаря этому автоматически получаются баллистические траектории полёта.
Functionality != пройзводительность
Там не слово про скорость, а тем временем когда я наспавнил мячей 40 у меня уже было 5 фпс
>когда я наспавнил мячей 40
А теперь наспавни их через сишарп и сравни производительность. Без этого твои возгласы - пустой кукарек.
И нет, за тебя это делать никто не будет.
Я пока не могу проверить так что утверждать действительно перестану хотя ты тоже доказать не можешь ололо, хотя в форчане и редите это обсуждалось, попытаюсь найти снова треды
Если рассмотреть код на скринах выше, то там язык вообще на выполнение сцены не влияет. Мячи спавнятся по таймеру. Двигаются физическим движком.
От того, что таймер станет на шарпе - ничего не изменится. Изменилось бы если бы сотни мячей спавнились циклом в одном кадре. Вот тогда бы гдскрипт соснул. Об этом на реддите и пишут. Я читал.
>натив тоже язык скриптования
Что еще за язык такой? C++ знаю, C знаю, натив не слышал.
А вообще я к тому, что большинство операций выполняется очень редко (клик мышкой например) и на это вообще оверхед языка не влияет. Если у тебя армии в сотни юнитов, то обсчет их логики на cpu, наверное, будет разниться между нативом и питоном. Но скорее все упрется в архитектуру рендера, а там надо смотреть, что и как, вроде бы батчи должны помочь.
Я имел в виду, почти бесплатно. Плюсы же есть, а писать на подмножестве плюсов нетрудно.
Да, у него биндинги к апи движка будет полегче прикрутить.
Я согласен что если починить архитектуру то будет намного лучше, но если починить интерпретер то будет ещё лучше, тк если сделать хорошую архитектуру но не оптимизировать интерпретер, это во первых извращенство, а во вторых интерпретер будет ботлнекать и всё равно будет лагать
На всех конференциях учат что надо профайлить перформанс вначале, потому что не угадаешь что современный компайлер сделает, а прематурная оптимизация зло как и отсутствие.
Похоже, Хуан не был на этих конференциях.
А то пока эти видеоняни до сути дела дойдут, я, блджад, рисовать научусь.
На шарпопараше тоже можно
Больше Годетки в тред!!
После чего:
extends Resourse
func _init():
И вперёд!
Вы понимаете, что это значит? Это же управляемые ресурсы! Этому квадрат, тому круг, остальным картинку с дулей. Этому таймс, тому курьер нью, остальным - комик. Этому техно, тому митол, остальным нудятину распидора))
А мог бы игры делать.
>Но без пердолинга - только во внешнем редакторе.
А чо там, как подключить и прочее? Студия стоит, я на шарпе пишу по работе.
>как подключить и прочее?
1. Скачиваешь годот-шарп с официального сайта.
2. Скачиваешь и устанавливаешь монофреймворк не ниже версии, указанной при скачивании годота (они пишут, что и не выше, но у меня нынешний стейбл монофреймворка вполне работает с годотом, а он выше что ли на две ревизии).
3. При создании первого скрипта на шарпе в любом открытом проекте, годот-шарп автоматически генерирует солюшон в папке проекта. В принципе, если ты хорошо знаешь шарп и тебе не требуется интеллисенс в работе, ты сможешь кодить прямо там, но мне удобнее выбирать дальнейший код из подсказок интеллисенса. Поэтому:
4. В студии открываешь солюшен из папки, где годот его сгенерировал и вуаля - вся мощь майкрософта помогает тебе писать код >>29156
Вот такой моно должен быть установлен:
Ой иди нахуй, блядь.
На карте стоит позишонтриде и перемещается по ВАСД, в потомках этого позишона находятся камера и риджидбоди, камера двигается жёстко, а риджидбоди двигается функцией аплифорс с анимацией ходьбы/бега. Направление вперёд-назад берется из вектора, который проведен из точки под камерой до точки позишона.
Начну реализовывать прямо щас. Если что толковое получится, покажу позже.
> Godot
@
> Планирую реализовать контроллер
@
> Как задать ёбаный трансформ ёбаной камеры, чтобы ёбаный горизонт не заваливался?
А ты почитай что там с Java произошло. Oracle выкатил новую версию с новым соглашением, и те, кто не используют OpenJDK, стали получать от них письма счастья, что вообще то вы нам денег должны.
Нихуя не понимаю, у меня джава что-то пишет по английски постоянно. У меня на работе циска админится джавой 6-ой версии. Мне надо что-то покупать?
Слона купи.
1) как посчитать расстояние между персонажами?
2) как организовать подбор предметов и инвентарь?
>как организовать подбор предметов и инвентарь?
Скачать с ассетлиба демку подбора предметов и изучить код?
>как организовать подбор предметов и инвентарь?
В первую очередь инвентарь - это список, поэтому начать следует с того, чтобы добавить список в код ноды, которая будет с инвентарём.
Причём для ясности, этот список следует называть не "инвентарь", а "содержимое". Поскольку содержимое будет у игрока, у ботов/мобов, в сундуков, у сундуков-мимиков, если таковых завезёшь.
Итак, список есть и в _Готов() он создаётся пустой. Что дальше? Дальше мы определяем, какие предметы у нас будут помещаемы в инвентарь. После этого нода каждого такого предмета должна быть обогащена следующими функциями в скрипте: ПоднятьПредмет(), БроситьПредмет(), Так же следует завести метод Содержимое, в котором будет возвращаться и задаваться ссылка на список-содержимое при обмене/облутании/краже/поднятии/бросании.
В функции ПоднятьПредмет, нужно позаботиться о том, чтобы нода отключала визуальную составляющую (а лучше вообще уничтожала), в функции БроситьПредмет, наборот, сделать включение (а лучше создание).
Так, теперь по геймплейной составляющей. Подбор предметов состоит из двух частей: Со стороны игрока - это рейкаст, направленный в точку прицела на экране и детектирующий предметы. Со стороны предмета это зона (Area) в которой игрок может дотянуться до предмета, чтобы его взять. Таким образом, если рейкаст детектирует И игрок в зоне - выводим надпись "пресс Е чтобы взять %Рейкаст.Коллайдер.ИмяПредмета%", при нажатии Е вызываем Рейкаст.Коллайдер.ПоднятьПредмет(ИнвентарьИгрока). Но перед этим всем, конечно же надо проверить коллайдер на тип, если у тебя будет несколько типов, я это не описываю, как само собой разумеющееся.
Соответственно, в обратном случае, ты нажимаешь кнопку И, открывается красивый интерфейс инвентаря, который ты нарисуешь, при своём открытии, он читает твой список "Инвентарь" типа "Содержимое" и выводит найденные предметы в ячейках (если хочешь реализовать чтоб разные предметы занимали разное количество ячеек, это отдельная тема). Допустим у тебя есть действие "Выбросить_Предмет" забинденное на ПКМ. При выполнении этого действия над предметом инвентаря (это проверяется вначале, считывается позиция курсора, определяется ячейка и индекс предмета в ней) этот предмет удаляет себя из инвентаря, вызывает у интерфейса инвентаря функцию перерисовки, у себя вызывает функцию БроситьПредмет, которая запрашивает у игрока его координаты, создаёт у предмета визуальную часть (или отображает, что хуже) и делает сцене аддчайлд(предмет) (в случае отображения придется делать телепорт).
Перемещение предметов при торговле/луте/воровстве через интерфейс, вообще реализуется проще. Там удалить из содержимого, тут добавить, послать интерфейсу команду перерисовки. Всё.
>как организовать подбор предметов и инвентарь?
В первую очередь инвентарь - это список, поэтому начать следует с того, чтобы добавить список в код ноды, которая будет с инвентарём.
Причём для ясности, этот список следует называть не "инвентарь", а "содержимое". Поскольку содержимое будет у игрока, у ботов/мобов, в сундуков, у сундуков-мимиков, если таковых завезёшь.
Итак, список есть и в _Готов() он создаётся пустой. Что дальше? Дальше мы определяем, какие предметы у нас будут помещаемы в инвентарь. После этого нода каждого такого предмета должна быть обогащена следующими функциями в скрипте: ПоднятьПредмет(), БроситьПредмет(), Так же следует завести метод Содержимое, в котором будет возвращаться и задаваться ссылка на список-содержимое при обмене/облутании/краже/поднятии/бросании.
В функции ПоднятьПредмет, нужно позаботиться о том, чтобы нода отключала визуальную составляющую (а лучше вообще уничтожала), в функции БроситьПредмет, наборот, сделать включение (а лучше создание).
Так, теперь по геймплейной составляющей. Подбор предметов состоит из двух частей: Со стороны игрока - это рейкаст, направленный в точку прицела на экране и детектирующий предметы. Со стороны предмета это зона (Area) в которой игрок может дотянуться до предмета, чтобы его взять. Таким образом, если рейкаст детектирует И игрок в зоне - выводим надпись "пресс Е чтобы взять %Рейкаст.Коллайдер.ИмяПредмета%", при нажатии Е вызываем Рейкаст.Коллайдер.ПоднятьПредмет(ИнвентарьИгрока). Но перед этим всем, конечно же надо проверить коллайдер на тип, если у тебя будет несколько типов, я это не описываю, как само собой разумеющееся.
Соответственно, в обратном случае, ты нажимаешь кнопку И, открывается красивый интерфейс инвентаря, который ты нарисуешь, при своём открытии, он читает твой список "Инвентарь" типа "Содержимое" и выводит найденные предметы в ячейках (если хочешь реализовать чтоб разные предметы занимали разное количество ячеек, это отдельная тема). Допустим у тебя есть действие "Выбросить_Предмет" забинденное на ПКМ. При выполнении этого действия над предметом инвентаря (это проверяется вначале, считывается позиция курсора, определяется ячейка и индекс предмета в ней) этот предмет удаляет себя из инвентаря, вызывает у интерфейса инвентаря функцию перерисовки, у себя вызывает функцию БроситьПредмет, которая запрашивает у игрока его координаты, создаёт у предмета визуальную часть (или отображает, что хуже) и делает сцене аддчайлд(предмет) (в случае отображения придется делать телепорт).
Перемещение предметов при торговле/луте/воровстве через интерфейс, вообще реализуется проще. Там удалить из содержимого, тут добавить, послать интерфейсу команду перерисовки. Всё.
И тут ты наверняка спросишь, а как быть, если надо подбирать предметы, а потом уходить с одной сцены на другую?
И я тебе отвечу, вообще функционал инвентаря тесно связан с функционалом сохранений и реализовывать их следует вместе.
На годот-доках есть туториал, как делать сохранения, но в нём самом написано, что это самая простейшая реализация и в реальных играх крупнее миниигор, надо делать с учётом специфики.
Инвентарь это и есть наша специфика. В этом случае сохранение придётся делать так:
Все сохраняемые сущности не должны напрямую работать с файлами. При старте игры ты создаёшь (или загружаешь из файла) в памяти структуру, в которой будет описано состояние игрового мира. При каждом изменении это состояние должно обновляться. Затем, при сохранении именно эта структура записывается а диск, а при загрузке она записывается с диска в память.
Все ноды, сцены, сущности, должны работать только с этой структурой.
Пример:
В сцене А на столе лежит яблоко. Ты подбираешь его и идешь в сцену Б. Затем сохраняешься. Идешь в сцену Ц и там тебе что-то не понравилось и ты загружаешься.
При загрузке в структуре написано, что игрок в сцене Б по таким-то координатам с яблоком в инвентаре (причем не нужно говорить, из какой сцены яблоко). Загружается сцена Б и опрашивает структуру-синглтон игрового мира на предмет изменений в себе относительно дизайнового состояния. Затем спавнится игрок в указанных координатах.
После загрузки ты идёшь в сцену А. Ну ты уже догадался, да? Грузится сцена А, опрашивает игровой мир и узнаёт, что в ней следует удалить яблоко на столе. Удаляет. После этого сппавнится игрок в точке телепорта из сцены Б.
Автонаполняемые сундуки:
Для каждого сундука, если хочешь реализовать автонаполнение, нужно реализовать свойство-таймер, которое привязано к внутреннему времени игрового мира и свойство со временем облутания.
При загрузке сцены с таким сундуком, игра сначала смотрит "облутан" не нуль? Если да, смотрит свойство таймер, и сравнивает, если времени прошло меньше чем, то загружается сохранённое содержимое, если больше, то после загрузки содержимого дополнительно запускается процедурный генератор, который что-то добавляет, что-то удаляет (в зависимости от логики игры).
Мобы:
По такому же принципу, ты должен определиться, какая часть поведения должна быть сохранена и писать её в структуру игрового мира из кода самих мобов при их активности.
Квесты:
В дополнение ко всему вышеописанному, квесты при изменении прогресса, пишут в структуру изменения для целой кучи сущностей. Ты может никогда не посещал локацию Д, но выполнив квест в локации Б, затрагивающий её, квест пишет в игровой мир эту инфу и когда локация Д загружается, она приводит себя в состояние, отвечающее состоянию при пройденном квесте (удаляет домики деревянные, усиливает охрану дворца и т.п.)
Просто скачай ассет на инвентарь. Иначе зачем пользоваться движками.
Вот первый в гугле https://www.youtube.com/watch?v=_-LgLa9PR44
>>29853
>>29855
Спасибо огромное тебе, анон. У меня, конечно, не такая комплексная игра даже не 3D Но информация полезная.
Такой вопрос: если я задам глобальный скрипт и буду туда сохранять данные инвентаря, а потом просто загружать из этого скрипта данные в другой сцене - это сработает?
>>29862
>Просто скачай ассет на инвентарь. Иначе зачем пользоваться движками
Хочу сам написать.
>если я задам глобальный скрипт и буду туда сохранять данные инвентаря, а потом просто загружать из этого скрипта данные в другой сцене - это сработает?
Да, вполне сработает. Более того, для гдскрипта, это пожалуй самый простой и логичный способ реализовать вышеописанную портянку.
Вот на шарпе я бы делал по другому. На шарпе доступ к синглтонам неудобный (надо дёргать функции дерева сцен), при этом на шарпе есть свой общепрограммистский способ создавать синглтоны и выглядит это для программиста проще и прозрачнее: в неймспейсе игры задаётся объект, инициализируется через тот же автолоад, далее обращение к его методам идёт через неймспейс. Таким же образом в шарпе искаропки есть несколько простых и удобных способов обмена данными между объектами. То, чего в гдскрипте нет "бай дизайн".
Звучит похоже на тот же автолоад. А вообще, мне, как человеку только вкатившемуся в разработку игр есть ли смысл изучять С#? Или можно продолжать жрать GDScreept?
Замечательно.
Начинай с gdscript, потом плавно перемещайся на c++. В шарп смысла лезть нет.
Небольшая иллюстрация моего пиздабольства прилагается на пикче. Этот небольшой скриптик, помещаемый в автозагрузку, создаёт в памяти словарь, который прямо на старте знает своё имя, знает позицию игрока, название стартовой локации. Кроме того, в главном цикле у него считается (реальное) время его жизни.
Если этот скрипт в автозагрузке, то любая нода, любой скрипт, в любое время может вызывать функцию gws_write() и записывать какие-то свои данные в этот словарь. А при помощи gws_read() читать какие-то данные.
Охуенная технология, которая и не снилась двемерам!
Теперь мы берём и совмещаем этот скрипт с туториалом про сохранения с официального сайта, только вместо группы "persistent" мы сохраняем один только словарь State и только его!
> как в Godot с поддержкой С++?
На уровне среды разработки. То есть, чтобы писать на плюсах, тебе надо открыть исходники движка в среде разработки и дописывать туда код, как делал анон, пытавшийся сделать клон майнкрафта на годоте год назад.
Второй вариант - нативскрипт, ничем не отличающийся по сути от реализации шарпа, но при этом поддержка шарпа удобно интегрирована в редактор, а с плюсами тебе придется пердолить консольку.
>Теперь мы берём и совмещаем этот скрипт с туториалом про сохранения с официального сайта, только вместо группы "persistent" мы сохраняем один только словарь State и только его!
То есть, вот так:
При таком подходе исчезает необходимость утомительной еботни с выгрузкой объектов, потом с загрузкой их же по путям в файле сохранения. Мы просто перезагружаем всю сцену (или просто загружаем другую, беря значение из State же), а каждая сцена у нас содержит в себе функцию, которая вызывается в _Ready(), которая синхронизирует своё состояние с данными State.
Уже вижу трабл. Если словарь будет очень большой, процесс загрузки будет нехило вешать игру.
1. В скрипте игрока держать функцию Get_UI() которая возвращает ноду юзеринтерфейса.
2. В скрипте юзеринтерфейса держать функцию Get_Player() которая возвращает ноду игрового персонажа.
Так. Протестировал это говно. Вот этим кодом:
var dt = OS.get_ticks_msec()
for i in range(0, 1000000): gws_write(i, i)
dt = (OS.get_ticks_msec() - dt) * 0.001
print("Init time: ", dt)
И вот результаты:
Init time: 1.159
Load time: 2.905
Save time: 6.51
Во время этих 6 секунд сохранения, как я и предполагал, годот наглухо виснет.
Выходной файл сохранения с миллионом записей весит 15 мегабайт.
Результаты эксперимента: Сохранения надо делать как-то иначе. Как минимум сохранять и загружать данные в файл построчно, а не одной блокирующей функцией. Второй вариант, делать через шарп и бинарный сериализатор. Чем сейчас и займусь.
Нужен отдельный слой обстракции, в нем уже функции. А то получится макаронный код.
Я заготовочки делаю.
> А то в шарпе у меня крошится чот. Лапки, хуле.
Знаете что, а у меня и в гдскрипте крошиться начало.
var t = Thread.new()
t.start(self, "load_game")
ЧЯДНТ?
Ну блин. Ну ёпт. Хотел же скопировать этот проект на флешку. Пришёл домой. Сделал похожий код в новом проекте и всё работает, не крошится.
Итак, воспроизвёл проект по своим же скринам. Всё так же. Тред крашит приложение при выполнении save_game(), а при load_game() - всё нормально.
Какие будут у вас идеи, годаны?
Хорошая попытка, но нет.
Решил проблему сам.
1. В строке 45 присваивалось значение переменной State, которая из треда не видна. Это нужно было решить либо передачей параметром, либо работой с глобальной переменной. Я решил глобальной, всё равно функционал сохранения проектирую как глобальный.
2. По несчастливому стечению обстоятельств поверх наложилась вторая проблема, которую удалось на удивление быстро отловить: присвоение словаря из миллиона элементов непустому словарю тоже вызывало какой-то сбой, который внутри треда приводил к крашу.
Потому... та-дам! Пикрелейтед.
>Хорошая попытка, но нет.
А чо, в этой параше нет режима отладки, чтобы просто показывало где оно крашится и почему?
Есть. Но работа с тредами - это известное неосиляторство Хуана, о котором даже в доках написано. Вольная цитата: "неблокирующие треды мы не осилили, заботьтесь о блокировках сами".
И финальный штрих. Добавим немного глобальных флагов, добавим непрерывное их чеканье в процессе. Охапка дров и плов готов!
Заебца. Создаётся. Почти минуту (скрин1). И файл на 170 мегабайт. Но есть одно но, при закрытии приложения, оно слегка подвисает, но закрывается без краша и в ошибках пишет скрин2. Я осторожно предполагаю, это из за висящего в памяти словаря на десять(!) миллионов(!!) строк, который уничтожается в модуле list годота. Всё же думаю, такие большие объёмы в реальной игре не встретятся, но нужно быть к этому готовым. А то, знаете ли, сегодня думаешь, что 650 килобайт хватит всем, а завтра говно по штанине потекло.
А теперь внимание, ловкость рук и никакого мошенства! После того, как распихиваем всё это барахло по синглтонам, получаем в будущей игре вот такой код:
Используя флаг is_job_active, можно выводить в интерфейсе модную анимацию процесса сохранения "не выключайте свою пека, пока видите этот значок".
О, и да! Самое главное! Функции gws_... тоже могут чекать этот флаг, чтобы пока идёт сохранение, игровой мир не модифицировался.
Что ну ну? Продолжай раз начал. Сериализация? А она что, не блокирует свой тред? Анус ставишь? А если проверю?
Подсказка: я уже проверял и майкрософтовский сериализатор вешает тред так же на отличненько, как и годотовский. При этом с ним больше еботни. А в отдельный тред оборачивать все равно придется.
И правильно делает, нахуй тебе нужна сломанная сериализация где данные во время записи успевают измениться в кадре?
>сохранять всё-всё-всё в текстовик
Вот какой текстовик выдаёт код с пикч выше. Если вычислишь, в каком месте ебут твою маму - получишь в подарок бесплатную пачку галоперидола.
Не знаю, нахуй мне нужна сломанная сериализация, но я точно знаю, что мне не нужна подвисающая на несколько секунд при сохранении или загрузке игра. Вы наслушаетесь баззвордов и носитесь с ними. Сериализация это подготовка членов класса в требуемый формат и запись на диск. Раньше под сериализацией подразумевалось сохранение только классов, сейчас все подряд называют сериализацией. Если я не хочу плодить классы? Если я хочу подготовить и записать на диск просто массив или словарь? Если настройка такой записи занимает один день? Нужна ли мне си-ри-ва-ле-за-цэя?
> но я точно знаю, что мне не нужна подвисающая на несколько секунд при сохранении или загрузке игра.
А чо, при загрузке/сохранении игры на других движках не подвисают? Точно? А нажми ф5 в какой-нибудь, ты не замечаешь, как все подвисает на пару секунд?
>потом видимо ААА-игроделы научились делать
Чекпоинты. Всего пару байт записать, на каком чекпоинте сохранился и сколько у тебя было патронов.
Почему же после загрузки чекпоинта восстанавливаются не только позиция и патроны, а ещё и все недобитые враги, несобранные картины, неоткрытые вышки, и т.д.?
>все недобитые враги
Это не везде так. Могут и сброситься в начальное состояние.
>несобранные картины, неоткрытые вышки
База данных. При открывании меняется всего 1 байт - флаг.
Кстати врагов можно так же сделать. Их будет в среднем штук 20 на обозримом между чекпоинтами участке. Хранить тольк их хитпоинты, тоже байт. Все будет мгновенно сохраняться.
Чекпоинты хорошая штука, но я не уверен, что они подойдут для РПГ. Я нацелен именно на РПГ. А вообще, о разделении сохранений на бд мира и настройки игрока я давно подумывал.8
Нормально. А что у вас в будущем все показанные в видосе фишки убрали из годота? Пойду, перейду на юнити, пока не поздно.
>> сейчас все подряд называют сериализацией
Вот, вот. Еще и пихают в нее все подряд. Нет бы данные просто сохранят, нет, будем дамп памяти всей игры пихать, чтобы ускорить загрузку на две секунды.
>будем дамп памяти всей игры пихать
Ну эт уже маршаллинг какой-то.
Впрочем, вчера перед сном я размышлял об идеальном сохранении, взвешивал все за и против и пришёл к выводу, что не всё так однозначно.
Тот метод, что описывался выше, когда сцены просто, без задней мысли загружаются и опрашивают состояние игрового мира на предмет своих переменных - он тоже не идеален. Если сцены будут большими локациями, которые сами по себе долго грузятся, то такой подход будет накладным, когда игрок, скажем, босса сражает по хардкору, выходя из сохранения каждые 5 минут - при этом он еще минуту смотрит на экран загрузки локации босса.
Таким образом, нужно проработать сбалансированную систему, в которой будут сочетаться загрузка данных, загрузка объектов (сериализация) и загрузка дампов состояния объектов (маршаллинг).
Причём, это не зависит от движка. Это общая идея.
Так дамп состояния игры - это слепок того, что сейчас есть в оперативке. Там вычленять отдельные объекты и потом их возвращать - еще дольше. Вариантов всегда два на выбор - это либо бд в каком-то виде, либо состояние твоего процесса (игры), скопированное из оперативки в файл и потом просто загружающееся оттуда обратно как есть. Первый вариант - это экономия места, но удлинение времени загрузки. Второе - наоборот. И при методе с дампами уже строго указываем в минималках игры, что требуется столько-то оперативки. И сцены, что дампаем, конструируем, чтобы гарантировано не превышали его.
Я понял. В таком случае можно применить вот какое решение. Сцена не выгружается, она просто расставляет интерактивные объекты по местам, читая данные об этом из загруженного состояния мира. Как шахматные фигуры на доске. Отсутствующие предметы создаются и рекурсивно проверяют свои дочерние предметы, например, инвентарь. Насколько это будет быстро?
Это и будет обычной загрузкой сериализованных данных из бд. Скорость для всех игр всех жанров приемлимая. Игроки почти никто не задрачивает сейф-лоад, чтобы на паре секунд более долгой загрузки заморачиваться, если она вообще достигнет таких величин.
А рекурсивная загрузка - да, можно. Ты загружаешь сначала данные игрока и данные, которые необходимы ему в ближайшие несколько секунд. Какие именно это будут данные можно вписывать в сам сейв во время сохранения. Но тут еще надо дописать модуль, который будет это анализировать. Поэтому проще сразу просто все данные сохранить в бд, потом все считать из бд и уже стартануть игру.
На это лучше пока не тратить время, потом уже когда игру напишешь, если вдруг именно это будет не устраивать, то потом легко дописать среди прочего рефакторинга.
А тебе лишь бы что сказать. Ну говорит и говорит, выучил и хорошо. Лучше бы по делу, что писал, а не пустозвонством занимался.
В зеркало посмотрись.
Крысы бегут с тонущего корабля.
Видимо баннер на наг скрине годота не приносил желаемых дивидендов.
Use csharp, Luke!
800x600, 0:49
Ога. Божественные треки легендарного Jeroen Tel - это наше детство, наша юность. Наше всё!
Спасибо!
800x600, 0:50
Твоё копротивление только делает мои скрипты твёрже.
public class Bump : Node
{
public override void _Ready()
{
GetTree().ChangeScene("2ch://gd/godothread.tscn");
}
}
Подумываю вкатиться, что перспективнее gdscript или c#?
unity
Почему движок реально годный , а ни одной нормальной игры нет?
>Почему движок реально годный , а ни одной нормальной игры нет?
Вечная проблема опенсурса: он всегда догоняющий. В большинстве случаев опенсурс - это реализация того, что уже есть на рынке. Вот и здесь, Вася из 6 б просто возьмет Unity для своей игры про срущих пингвинов. Просто потому, что Unity появился раньше, успел продвинуться, на нем сделали несколько грамких проектов.
Большинство возьмет то, что у всех на слуху, и будут им пользоваться, распространяя эту заразу по цепочке
Сначала gdscript, потом С++.
>Вечная проблема опенсурса: он всегда догоняющий.
Двачую. Вчера поставил убунту на свою пека 4 ядра 8 гигов, ПЕЧ1060. И таки шо ви думаете? В фаерфоксе тормозит плавная прокрутка. Шёл 2018 год.
Что там осиливать, лол? И не дрова, а проприетарный пакет.
Да, например, в винде посылают на сайт какой-нибудь нвидиа и качаешь себе последний драйвер под свою систему и свою карту.
Потому что он годный только для прототипирования.
Возможно также для мобилок, так как он под них затачивается авторами, но я этой парашей не интересуюсь, так что не могу достоверно сказать.
Для всего остального же там всюду торчат квадратные колёса и палки в спицах:
- Нет экспорта на консоли искаропки, даже платного.
- Нет полноценных рендер таргетов для ПК, даже опенгл. А вшивый глес умудряется тормозить на топовых пк в простеньких платформерах.
- Опенсорс на словах, а на деле этого опенсорса для акнеблядей не существует. Всё заточено под прыщеблядикс, причём авторы очень любят альтернативные тулсеты, неизвестные рядовому программисту. Настроить среду для компилирования Годо - та ещё задача.
- Побочный эффект опенсорса - никто не чинит баги, даже критические, вместо этого большую часть времени занимаются добавлением новых никому нахуй не нужных фич. Забагованных, естественно.
Да, и на данный момент Годо как продакшн-движка опять не существует. Ветка 3.0 сломана и недоделана, в стабильную фазу войдёт хорошо если через два года. А ветку 2.1 тоже сломали последними апдейтами и, похоже, забросили.
Итого - движок вроде и есть, но если рассматривать его со стороны выпуска игр для конечного пользователя, то его нет, если только ты не совсем простое дерьмо делаешь, или мобилкодерьмо.
Но для прототипирования и быстрых игр для джемов на пару дней - лучше нету. Саму концепцию и архитектуру движка я считаю очень удачной. Но блядь, как обычно, реализация подводит.
>Саму концепцию и архитектуру движка я считаю очень удачной
Просто ты слаще морковки ничего не видел. Советую установить юнити.
> Возможно также для мобилок, так как он под них затачивается авторами
Так затачивался, что gles2 до сих пор падает.
> Возможно также для мобилок, так как он под них затачивается авторами
У меня на вин7 все с первого раза завелось, под плюсы и вижуал студию. Но у меня 20 лет оптыа геймдева. Впердюлил сконс в питон, потом вот этот скрипт доработал https://gist.github.com/Calinou/6cd0c45f994b31f281eec66f0eeb401d
>Побочный эффект опенсорса - никто не чинит баги, даже критические, вместо этого большую часть времени занимаются добавлением новых никому нахуй не нужных фич.
Двачую. До сих пор охуеваю, уже Хуан объявил заморозку фич в альфе 3.1, только фиксы, но чу, все новости и коммиты начинаются со слов Мы добавили хуйнянейм.
Если для тебя критерий опенсурс, то есть cocos2d-x.
Видел я ваше юнити(когда моды на КСП делал), больше не хочу.
Концептуально юнити сосёт с проглотом у Годо. Да и реализация там не сильно лучше.
Ещё вдогонку - вот я пишу на Годо довольно крупную игру, уже год. Но в последнее время я реально задумываюсь о том, чтобы переписать всё нахуй на свой движок с человеческим рендером, оставив архитектуру и использовать в дальнейшем Годо просто как редактор сцен.
Обычный синдром NIH.
Качните кто нибудь посмотрите каким костылем он по наклонным поверхностям скачет, интересно же.
inverse kinematics что ли добавили?
Классно.
>скачайте неизвестно какую версию мастер ветки
>скачайте какую то приблуду для гита неизвестно для каких платформ
>которая качнет неизвестно откуда и какие блобы
>запустите то что получится но не факт что оно заработает
Мы еще про название форка не договорились.
Почитал я про этот ECS. Теперь понятно, почему юнька так тормозит. Броадкастить все сообщения всем, а потом фильтровать нужные.
Нихуя ты не читал.
А это мысль, нужно создать персонажа Петуха-Энтитуха, страдающего преждевременной кокоптимизацией. Чтобы он такой кокококококо внимательно в экран смотрит, задумчиво клювом водит, тут SSE-интринсик впендюрил, сразу радостное КУДАААААх , там кучу бойлерплейта написал, такой получил +5 фпс и сидит довольный, кукарекает и тут такое оказывается, что он всё это время сидел в питушином углу, его блатные сокамерники уже три игры на объектах с наследованием написали и зашиппили, а разъяренный издатель в конце этой истории засовывает ему банку с абстрактной фабрикой в анус.
В курсе, что если в одном фрейме вызвать два new Random()'а, то оба выдадут одинаковый NextDouble()? Надо одним инстансом Random'а пользоваться
В курсе. Потому что в одном фрейме у них будет одинаковый seed, который в конструкторе по умолчанию берется из таймштампа. Я уже сталкивался с этой проблемой в GenerateSpawnPoint() она сейчас уже переписана на один инстанс, заскриншотить забыл.
> A fast, type-safe C++ Entity-Component system
Нет, кресты не подойдут. Ебашить код через трипиздыколена - такое себе удовольствие.
Нужен энтитух на шарпе, например:
https://github.com/sschmid/Entitas-CSharp
https://github.com/sebas77/Svelto.ECS
Зацените.
Заодно подскажите, как навесить сигнал на автосоздаваемые чанки, чтобы избавиться от перебора словаря?
Всё равно до плюсов не дотягивает. C# Mono раза в два с половиной медленнее их.
Отказываюсь верить без бенчмарков.
Ну а что, в Mono с тех пор появились какие-нибудь убер-оптимизации в корне меняющие картину? В новых замерах добавили C# .NET Core, он пошустрее будет, но всё равно не быстрее Джавы. К тому же разрабы Годота предпочли его проигнорировать (выбрав Mono), поэтому в этом треде нет смысла про него говорить.
> Кокоптимизация, на 8 секунд быстрее, кудах
Энтитух, ты сначала игру сделай, а потом про оптимизацию думай.
>Ну а что, в Mono с тех пор появились какие-нибудь убер-оптимизации в корне меняющие картину?
Угу. AOT-компиляция называется. И это, собственно, главная причина помимо открытости исходов почему и в юньке и в годоте выбрали моно.
Тупо потому что на яблочной сперме Java запрещена.
>ты сначала игру сделай, а потом про оптимизацию думай.
> А если чё клиенту поможет мой кореш Вася из "интегрешонал солюшенз васян" - он ему топовый блейд-сервант на Xeon E7 внедрит за откатик.
> А если чё лохи с топ пекарнями на минималочках в 20 фпс поиграют, пупжик не даст соврать
Знакомая логика интырпрайзной жабомакаки, вкатившейся в геймдев.
Ваши замечания и предложения?
Код пока что абстрактный, не удивляйтесь, почему целых два словаря. По гениальной кириллозадумке, в сохраняемом словаре хранятся только индексы и координаты, а в действующем словаре хранятся координаты и инстансы. Таким образом, для выгрузки блока достаточно выгрузить инстанс из словаря и удалить запись, для повторной загрузки достаточно чекнуть индекс по ключу-координатам и снова загрудить блок с полученным индексом.
Вместо add_child() будет set_chunk(index, parent_node) внутри которого для parent_node будет уже вызываться add_child(). Таким образом можно будет строить дерево сцены любого уровня вложенности, который опять же можно будет сохранять в файл в виде простого представления, например, как строка с разделителем-слешем, или как строковое имя ноды, при этом несложно реализовать отложенную загрузку: нода-А требует в качестве родителя ноду-Б, но нода-Б ещё не загружена, нода-А тоже не загружается и записывает себя во второй проход. Первый проход, при наличии хотя бы одной записи, рекурсивно вызывает сам себя.
Что вообще за бенч? Может там программа запускается и убивается миллион раз в цикле, что предсказуемо вызывает перекомпиляцию.
А вы думали я тут с вами шуточки шучу? Завтра будем пилить сообщения и системы.
В результате нехитрого кода на скриншоте, в запущенной игре появляется полноценно управляемый персонаж. Компоненты: боди - кинематика, контроллер - просто нода с обработкой инпута в процессе, спрайт - годофейс. Самое интересное - аргументы. При задании парента компонент создаётся как потомок указанного парента. При задании экзека - происходит вызов функции, если она имеется у компонента. Это нужно, чтобы, например, спрайт следовал за телом, являясь его потомком.
Соответственно, код из первого скрина выносится в ComponentFactory, снабжаясь дополнительным аргументом Entity или eName. Экзеки вырезаются нахуй и заменяются подписками на сообщения.
Даже с JIT, работающая хрень, написанная под виртуальную машину, запущенная на реальной машине. Никогда физически не приблизится к скорости работы с той хрень, что работает просто на физической машине.
Давно уже известно (и никогда не было секретом), что преимущество языков на виртуальной машине (или фреймворке каком) не в скорости.
Дальше сам.
И виртуальные ядра центрального процесоора только мешают ядрам физическим.
>AOT-компиляция >помимо открытости исходов
.NET Core тоже открытый. И тоже имеет решение для AOT, а именно CoreRT.
>главная причина >почему >в годоте
Ну, Хуан приводил аргументы, что Mono легче интегрируется и портируется. Кроме того, там же высказывались, что .NET Core ещё пока молод и незрел, но в будущем его могут задействовать.
>>31704
benchmarksgame же. Довольно известный набор микробенчмарков.
Физику пофиксили?
Бесполезное говно без задач.
Да, мальчик. Не в скорости работы, а в скорости разработки. Поэтому каждый эффективен в своей нише, C# и Java - это бизнес-приложения.
Мальчик - твой папа по сравнению со мной, алё.
Причём встроенный счётчик фпс показывает ложь, правду показывает только профайлер.
Как ты находишь, куда ставить новые чанки? Простой перебор всех возможных мест очень сильно сказывается на производительности. Как вариант - разбивай спавн по фреймам, чтобы более Х чанков за фрейм не спавнилось.
>Как вариант - разбивай спавн по фреймам, чтобы более Х чанков за фрейм не спавнилось.
Вот, да, подумаю над этим. Спокойной ночи!
Собираемся в команду?
Код простейший. Сделай ноду на сишарпе, добавь публичное свойство с сеттером. Создай ноду на гдскрипте, любым способом добавь к ней ноду на сишарпе. Попробуй задать у нее свойство.
>сайт Godot
>REQUIREMENTS: OpenGL ES 3.0 compatible hardware
>смотрю у себя
>OpenGL Version: 3.2
>скачиваю
>ставлю
>Fatal error
>Your system's graphic drivers seem not to support OpenGL 3.3
А вообще, если ты Кирилл из соседнего треда, то вполне возможно, что на твоём некроноуте годот не взлетит.
OpenGL ES != OpenGL.
Ага, дрова 2010-го. Залез на сайт Радеона, там есть за 2015-й. Поставил. После перезагрузки черный экран. Пришлось откатываться восстановлением. Охуенные дрова, блябуду.
Если у тебя интегрированная видюха от Интел -- можно попробовать Линукс -- там оно наверняка запустится без проблем. Вообще, дрова интеловских интеграшек там по уровню поддержки OpenGL как правило опережают виндовые. Например:
>Sandy Bridge HD 3000 and 2000 Linux:OpenGL 3.3 Windows:OpenGL 3.1
Недаром Intel -- контрибьютор номер один в ядро Linux.
А, у тебя Радеон. Сорри, в глаза сношаюсь, не увидел этот пост.
И вообще, на линуксе, по крайней мере в производных от дебиана дистрибах, искаропки ставится свободный драйвер с программной поддержкой всего-всего. Годот хоть и медленно, но работает.
Попробуй в годоте переключить на GLES2
А если есть, то приведите хотя бы топ 3.
Потому что godot - это персональная афера Хуана по обогащению за счет продажи змеиного масла восторженным хипстерам.
До чего же чсвшные неймфаги у нас. "Обоже, на мой вопрос ответили на стриме! Обоже, напилю шебэмок и буду всем показывать!"
Тьфу!
Ты сейчас возмущаешься поступками больного на голову человека. Свинья срет не потому что чсв, а потому что шиза.
Ну там в порнотреде какой-то анон жалуется, что у него на квадратном мониторе полигры за экран ушло.
Пиздец, by pidors for pidors. Это они защиту от IDE запилили?
Ты наверное и с федоры для распбери-пи ржёшь, додик?
Конечно, в опенсурсе сейчас тренд такой. Принять Code of Conduct, потом заставить переименовывать master-slave в primary-replica, запретить файлы настроек whitelist и blacklist,
Он на прыщеблядиксе сидит штоле? Щёлкнуть по заголовку окна чтобы оно автоматом на экран масштабировалось не додумался?
800x620, 0:20
Оказывается, есть еще более элитный движок. https://gcup.ru/news/skidka_88_na_coppercube_5/2018-10-19-8238
фьючелист такой же как у годота:
- идеально подходит для бомжей
- игор на нем и не будет
- можно делать 3д
- можно делать качественные презентации
- мало весит
- хуй тебе, а не ассет стор
- обрабатывает ввод с клавиатуры
- можно засирать все дискачи вскукареками о своем любимом движке
Но есть и эксклюзивное преимущество:
- можно его включить и все стимодрузяшки будут видеть, что ты игродел
- можно засирать все дискачи вскукареками о своем любимом движке-который-не-годот
Не надо, у меня уже есть юнити и я засираю им все дискачи, которые вижу.
А мог бы игры делать.
Мы должны угадать, что это, если ты ни разу про это не отписывался? Вентилятор на видяхе включи.
На ведроиде мне тоже вентилятор включить? Я думал, это что-то уже всем известное, как и простой джиттеринг.
Приветствую новичков треда! Нам очень важно, что Вы присоединились к нам.
Обесняю: два треда подряд один местный юродивый кривлялся, что игры на годоте не запускаются на нищевстройках пека от интел и нищемобилах, на которых нищуки не покупают игоры, а воруют на 4пда. Сначала ему пытались объяснить, что глес2 устарел и не нужен, но быстро поняли, что он может только кривляться и паясничать.
Как видишь, у него запустилось, но не работает. Это ничем не лучше.
>юродивый
Юродивый тут только ОП треда, у которого Годот это второе пришествие Иисуса Христа, а то что не работает это просто ненастроено, и вообще юнити в тапки насрали.
>>33992
Так ты подробности давай. Лагает на пустом проекте с одним кубом? С прыгающей демкой Хуана? С каким-то твоим проектом на 100500 спрайтов? 2д, 3д?
>глес2 устарел и не нужен
Передай Хуану, что он зря на него месяцы работы потратил в таком случае.
>ОП треда, у которого Годот это второе пришествие Иисуса Христа
Лолшто? В сарказм не можешь, клоун?
Хуан повёлся на нытьё вот таких вот нищуков, и вместо того, чтобы довести до ума движок (те же фантомные подтормаживания побороть, я их тоже видел, а ещё зэтфайтинг в тайлмапах в 2д (в двадэ, Карл! зэтфайтинг!), начал пилить поддержку глес2. Позор ему.
Да вы посмотрите на этого Хуана. Типичный омежка, не умеющий сказать - нет.
Я на месте Хуана вообще бы заморозил разработку мобильных платформ до полного доведения до ума движка. А уж после того, как годот заработал бы нормально на пеках, только тогда перешел бы к реализации мобильных фич. Нужен мобильный гейминг - юзайте ветку 2.1. и ниибёт.
Ты бы еще гордился что СССР человека в космос запустило когда то.
>Integrate javascript support as scripting language
>I'd rather programmers learn GDScript and then have a good experience, than use something they know and then have a bad experience, so probably never going to happen.
Сказочный долбоеб. Зачем его только из больницы выпустили?
Напиши враппер, который подключается к годот-проекту через nativescript и выполняет код на javascript.
>ChakraCore and JavaScriptCore both perform superfast pure js calculations (50-200 times faster then GDScript)
>But using the bridge to C++ is still very slow (10-30 times slower then GDScript)
Если бы ты создал дваческрипт, ты бы тоже говорил "ну лучше вы его учили".
Ахаха! Критиковать Хуана все горазды, а сами на поверку неосиляторами оказываются!
Так в том и суть GD скрипта в легковесном "мосту" между плюсами. Ты знаешь хорошие интеграции JS с плюсами, которые работают лучше?
Я с дивана сейчас скажу, сильно не пинайте, но на мой взгляд, у гд-скрипта вообще моста нет, я со своего дивана предполагаю, что он интерпретируется при исполнении программы-проекта. А в самом движке реализован парсер, который преобразует операторы гд-скрипта в заранее написанные на плюсах функции.
В качестве пруфа, в годоте возможен такой код:
var s = GDScript.new ()
s.set_source_code ("extends Button\nfunc _pressed():\n\tget_node(\"/root/Control\").choice(" + String (c) + ")")
s.reload ()
b.set_script (s)
То есть, для мимокроков поясню, на лету создаётся скрипт и присоединяется к на лету создаваемой кнопке. То есть, на этапе компиляции проекта скрипт не существует, как скрипт. А только как строковая константа.
Таким образом, чтобы добиться сравнимой производительности, следует искать/делать не мост/враппер между сторонним интерпретатором джава-скрипта, а искать/делать сам интерпретатор и встраивать его в годот на уровне компиляции самого годота.
Мне кажется там речь идёт о тормозах именно NativeScript или как там оно называется
Примерно так и есть, но свой интерпретатор пилить это задачка та еще. В юнити пытались и получили обрезок джаваскрипта, которым никто не пользуется.
Поэтому надо не выёбываться и иметь изучение гд-скрипта, чтобы поиметь хороший опыт.
-Распиздяй
-Дрочу каждый день
-Ранее не программировал, кроме как пару раз на C#, с уроков на гикбрейнс и всё уже давно забыл.
Спасибо за мудрость, сенсей!
А что можно делать игры не уча какой-либо язык программирования?
>А что можно делать игры не уча какой-либо язык программирования?
Ага. Вот например, недавно в веге всплыл олдфажный Bioware Aurora Toolset for Neverwinter Nights - кодить не надо, только диалоги пиши и домики деревянные по карте расставляй, вся остальная игора уже сделана за тебя.
Прекрасный вариант для начинающего кирилла осознать, что программирование в создании игры - это от силы 5-10% трудозатрат.
>Bioware Aurora Toolset for Neverwinter Nights
Не, совсем не то. Там за пределы однотипной ммо рпг выйти нельзя и не сделать какой-нибудь шутан.
Это само собой, что в конструкторе модов к уже готовой игре, можно сделать только можы в том же жанре. Но суть ты не уловил, в шутанах не меньше художественной работы, чем в псевдоизометрической эрпогэ. А учитывая современные требования к графону, даже больше. Таким образом у тебя код игровой логики (рейкаст на цель, подсчёт урона, отдельный подсчёт на хедшоты, загрузка/выгрузка уровней, запись параметров в сейв) займёт у тебя гораздо меньше времени, чем моделинг/скульптинг, и настройка постобработки ползунками и мышкой.
От жанра зависит. В пошаговой эропеге ты будешь кодить половину времени, в вн будешь писать сценарий 90% времени, в клоне дварф фортресса - кодить 99% времени.
Без обид, анон, но не соглашусь. Объём кодинга зависит напрямую от проектирования приложения. Если всё правильно спроектировать - реализация пишется за несколько дней.
Конечно если писать по наитию (как я писал бомбермема) выйдет так, что к середине реализации выяснится, что выбранный способ хранения данных не подходит для реализации половины фич, о которых вспомнил по пути. И это не зависит от жанра.
Когда есть правильно расписанный диздок, дварф фортресс не отличается от пошагового эрпогэ. Даже если ты всё отрисовываешь псевдографикой.
Без обид, анон, но ты сейчас хуйню полную спизданул. Головой сам подумай, как тебе правильно расписанный диздок сделает объём кодинга трёх механик равным объёму кодинга трёх сотен механик?
>Головой сам подумай
Я это подумал лет эдак 15 назад. Берёшь и разбиваешь задачу на подзадачи.
>2Д
Нахуя если есть ГамеМакер студио или на крайняк рпгмэйкер?
>3Д
UE и Юнити. Нахуй еще что-то помимо этого?
> не может решить задачу по проектированию игровых механик без бойлерплейта и оверинжиниринга
@
> считает дебилом того кто может (и мог 15 лет назад)
Эталонный двачной дурачок-обсиратель, аж печать ставить негде.
В Анриле придётся возиться с блюпринтами, а о бесплатной версии Юнити говорили, что кошмар с оптимизацией.
Я понимаю, что ты выучил новые умные слова и тебе не терпится их применить без повода, но они не сделают тебя умнее.
Я вроде довольно просто и ясно общаюсь обычно, но, похоже, у некоторых не хватает интеллекта даже на восприятие простых и очевидных фраз.
А что у тебя не бьется на подзадачи? Мне даже чот в голову не приходит такое, что нельзя было бы разбить на более мелкие части, которые можно писать и тестировать по отдельности.
другой анон
Ну например глубоко оптимизированный цикл рассчётов массива структур, оптимизированных под процессорный кэш. Даже если в нём производится много разных и сложных рассчётов, ты не сможешь вынести их в отдельные функции, например, потому что у тебя тогда пойдёт по пизде оптимизация - засрутся очереди вызовов, прогнозирование процессорных инструкций станет вести себя непредсказуемо, да и вообще хорошо, если оно простым джампом разрешится, а иначе вызов процедуры у тебя жрать будет больше, чем сама процедура. Если это в узком месте случится, то это тебе производительность в разы просадит.
мимокрок
Если ты это написал с мыслью о GDScript или, боже упаси, Visual Script, то я даже не знаю, что тебе ответить.
А если имелись в виду кресты или шарп, то там есть такая прекрасная штука, как inline.
Бывают такие сложные зависимости А->B->С->А, что пока не напишешь все части, не заработает ничего.
Да конечно, о том и речь что бывают достаточно сложные системы, когда невозможно написать заглушку, не реализовав ее всю.
Мань, ну не пизди.
Годот не умеет импортировать 3д модели, у них там какие-то задвиги про то, что все пользуются неправильными форматами.
Сейчас каждый второй движок умеет экспорт в WebAssembly, так что твоя фраза теряет смысл.
Естественно. Первое, что попробовал - это просто импортнуть без задней мысли.
>Сейчас каждый второй движок умеет экспорт в WebAssembly, так что твоя фраза теряет смысл.
Юнити умеет в WebAssembly? Иди запусти тогда Rust в браузере, дебил.
>>35215
Вообще да, изначально собирался пилить что-то типа хоррора. А скорее даже, что-то типа лавкрафтовщины. Жуткая НЁХ в глубоких подземельях воздействует на разумы и тела людей. Потом ты такой открываешь дверь ударом ноги и перед тобой ночь, пылающий огнём пожарищ город, толпы мутантов и нужно продержаться, пока не настанет рассвет.
>А почему я должен собирать раст, а не разрабы?
А потому что тебе даже исходники если дать, то ты нихуя не поиграешь в браузере.
Ебаать! До чего техника дошла!
Для реалистичного геймплея.
>cursors can now be as large as 256×256 (needed to be exactly 32×32 before).
Wow.
Вверительную грамоту покажи?
Ну так я не про игры вообще, а про говноигры
Для тех времен–да, но сейчас такая картинка выглядит убого, да и разнообразными браузерные игры тех времен не назвать
>В этом треде предлагаю лампово собираться в дружное комьюнити вокруг годо, чтобы обмениваться идеями, подсказками, сниппетами, и запилить вместе какую-то простенькую игру.
Ну, как собрались? Запилили?
Рисуй в текстуру по пикселям, хуле тебе мешает.
Нужно же. А что ещё кроме 2d на нем делать?
Ага. Та версия только в нем и работала.
Не собрались. Не запилили.
Говноед2
Скорее всего, то что ты задумал, делается не через спрайт3д. Лучше скажи, что именно ты хочешь сделать?
Программно создать меш может этот класс https://docs.godotengine.org/ru/latest/classes/class_immediategeometry.html
Выглядеть будет уёбищно. Я б тебе рекомендовал заготовить в блендере несколько мешей для тех объектов, что ты будешь показывать и всё.
Да изначально я так и думал, но таких объектов будет много и вот думаю можно ли это сделать программно. Может у кого нибудь был такой опыт.
В инете много примеров, вот для юнити https://gist.github.com/valryon/f7b7b7d40e3fe2e12e6290a48ec439c6
Ищется по extrude 2d code
https://stackoverflow.com/questions/47845129/extrusion-of-2d-building-footprints-according-to-heights-using-python
Спасибо. То что нужно. Буду разбираться.
https://www.youtube.com/watch?v=xSX1pN_dQQA
Мегагодон.
Если добавлять сигнал через редактор, то связанная с ним функция добавляется без задней мысли в конец файла, а не в конец класса, как должно быть. Поэтому надо вручную переставить закрывающую класс скобачку. Для профи это не проблема, а новичка может ввести в ступор, почему не работает?
Нет, не умею, не хочу, лень.
Наш человек.
Всем прива в этом треде, хочу запилить свою 3д игру на годоте, как быстрее всего вкатиться???
>3д игру на годоте
>как быстрее всего вкатиться???
Лучше катись в УЕ4. Годот для двадэ. Либо жди вместе с нами, пока допилят до ума.
Главное в юнити не вкатывайся - параша та ещё.
Если денег не жалко. Валяй. Никто тебе не запрещает. Но не рекомендую. Уровень юнити - уровень бесплатных приложений. Стыдно продавать подобный продукт. УЕЧ - достоин своих денег. Юнити - нет.
Мы вообще-то платный юнити про обсуждали, туруру блядь.
640x360, 1:37
Вот мой максимум в годоте за 9 месяцев. Извиняюсь за шакальное качество, я в ебенях на адсл.
Смотрел туториалы на ютубе. Читал документацию. Много читал. На инглише.
Ну и вообще, до вката в игрострой прошлой зимой, я программировал, поэтому в кодинге вообще не новичок, знаю ООП, знаком с парой-тройкой паттернов, в частности, понимаю суть ECS и т.д.
Сап. Нужно сделать очень маленькое приложение под Android/iOS. Когда я сделал билд с пустым проектом на Unity, он весил около 40 мегабайт. Сколько, приблизительно, будет весить пустой билд на Godot?
Спроси у Петра сканера https://www.youtube.com/watch?v=5Z-5EE5-Zww он охотно с людьми общается.
Спасибо.
Как и везде. Самый быстрый способ обучения - обучение с живым преподавателем. В условиях сычевальни, самый ближайший аналог живого преподавателя - туториалы на ютубе. Ты смотришь, что объясняет тебе живой человек и обязательно повторяешь на практике. Никакого копипаста из "ссылок в описании", ставь на паузу и перепечатывай код с экрана в редактор. Это очень важно. Пока ты набираешь код руками, активируется моторная память, ты запоминаешь как набирать код. Это касается не только кода, но и работы с пикчами для спрайтов и даже с мешами для тридэ. Поэтому всю настройку проекта тоже повторяй самостоятельно, импорт пикч, например, настройку анимаций и т.п.
После того, как ты поывал на "лекции", ты обращаешься к учебникам, в которых закрепляешь полученные знания. И добавляешь новых. Вместо учебников у нас мануалы и документация.
Пиздец шиза.
Вот это поворот.
Вот например я хочу сделать 2д платформер с кукольной анимацией. Какая должна быть иерархия нод для героя?
>я хочу сделать 2д платформер с кукольной анимацией. Какая должна быть иерархия нод для героя?
Скелет и кости:
https://godotengine.org/article/godot-gets-2d-skeletal-deform
Блядь это что ещё за хуйня. А я делал по официальному тутору, где кости добавлялись не как ноды http://docs.godotengine.org/en/3.0/tutorials/animation/cutout_animation.html
И какой нахуй способ использовать?
Произвёл транзакцию тебе за щёку, проверяй
Подскажите плез как можно реализовать следы от машины в 3D. Желатьельно не текстуркой а деформацией меша??7??!199101091
вершинным шейдером например
Короче поковырялся немного в годоте, почитал доки, и оказывается охуеть как там всё просто! Какие же тут дауны сидят, если считают что годот не для 3д и за 9 месяцев смогли запилить одну демо-парашу. Ждите меня на четвертый день с востока, скоро сделаю убийцу всех ААА-прожектов.
Давай-давай! Малаца! Уделай этого недоумка.
>>36257
Во французо-курсе наконец родили 12 главу, которой не хватало.
Заодно половину курса Ben'a Tristem'а с udemy залил, вторую докину через пару дней.
https://mega.nz/#F!Q3BE2QbZ!TcYiZM4BYEZF8zh8TCpg7Q
Спасибо. Курс от GDQuest самый годный что сейчас доступен.
Моар годеточки!
Правильно я понимаю, что в самом годоте скелетную анимацию для 3д моделей создавать нельзя? Только экспортировать из блендера каждый раз заново?
Правильно понимаешь. Правда есть плагин для того чтобы на отдельные кости навешивать гизму и двигать их.
Лучи добра! Как раз вкатываться начинаю, очень уместно.
Надеюсь, мы наконец увидим игоры! Твори анон!
Как ты собрался анимировать что-то в кастрированном редакторе годота? Без нормального инструментария, автоматизации, которая есть в блендере, это проблематично.
Я не он, но рискну предположить, что в общем случае может потребоваться слегка подогнать готовую, импортированную из блендера, анимацию.
где то кнопка бильдёханья у вас есть?
Очень красивый коридор. Жалко, что в него навтыкали объектов с вырвиглазным цветом. Мистические подставки из чистой Белой Материи, блджан.
ага и польские флаги нивпизду тоже
да вы заебали нахуй, я только сегодня это дерьмо скачал, сука спрашиваю блядь у вас как сделать шо б не лагало, нахуй вы такие трудные, а ебать!?
говна пожри
А что, движок не предусматривает тупо галочки, отключить навороты?
Лол а чо это за знак короткого писюна в верхнем правом углу?
Скушный ты. Душный.
натива вроде нет, но может кто уже костыль написал?
>как сконвертить псевдопитон в ноды?
Что ты подразумеваешь? Выскажись внятно.
Псевдопитон это гдскрипт?
Что значит сконвертить в ноду?
extends "res://my_node.gd" так штоле?
ты чо блять тупишь, ты человек или интерпретатор ЭВМ уже нахуй!?
попробуй напрягать чернобурку во время чтения и ответа
ноды ебучие это блюпринты из уеча, вижуал программинг ссука, так вот как сконвертить в них местный скрипт?*??
а что бля
Ты должен явно указывать, о каких нодах в годоте речь. Тут Хуан не продумал, да.
Значит если вынуть хуй из твоего рта, вопрос будет звучать так:
Как сконвертировать гдскрипт в вижуал скрипт?
Ответ - Никак.
Следующий.
сразу видно слепых годотодебилов
Предположим, я захочу создать ноду-слушателя, которая будет собирать все сигналы от других нод. Для примера: игрок встаёт на какую-нибудь Aread2D, где выскакивает диалоговое окно. Если у меня есть такая нода-слушатель, то эта Area2D сигнал отправляет на неё, а уже внутри слушателя происходит отправка нужного сигнала другим нодам (заблокировать управление игроку, открыть окно с диалогом и так далее). Как вы считаете, будет ли это намного удобнее? Сильно ли больше нагрузки будет? Все-таки сигналов больше становится.
>будет ли это намного удобнее?
Вопрос удобства сильно субъективен. Кому-то будет удобно, кому-то нет. Годот позволяет это сделать. Если тебе это удобно - делай.
>Сильно ли больше нагрузки будет?
Нагрузка от лишнего десятка сигналов всё еще будет ниже нагрузки от геометрии и физики. Не там ты оптимизацию ищешь.
Вот тебе легендарный тред:
https://godotengine.org/qa/10650/best-way-to-create-events-between-two-nodes
Смотри второй ответ, автор Shavals.
Ого, спасибо за ссылку. Я пока разбираюсь больше с движком, чем делаю что-то серьёзное, поэтому мне любая подобная информация пригодится.
Я не планирую делать что-то в 3D или что-то сильно завязанное на физике/геометрии, скорее подобие RPG с видом сверху вниз. Сомневаюсь, что это вообще в целом имеет большую нагрузку на пк. Хотя наговнокодить можно так, что даже такое будет адски тормозить.
Норм идея. Постараюсь оказать всю возможную помощь. Я-то сам прокрастинатором оказался, хотя тоже хотел запилить эрпогэ игру мечты. Знаний много познал, а применять - лень.
Тогда сразу вопрос задам. Предположим, есть NPC, с которым можно поговорить, нажав на клавишу. То есть герой не должен проходить сквозь NPC, а если к нему вплотную и нажать кнопку, то должен срабатывать какой-то скрипт (вызов диалога, например). С Area2D я разобрался, но она не подходит для того, чтобы не давать игроку двигаться сквозь неё.
Какой тип ноды лучше подойдет?
Например, тот же StaticBody2D с CollisionShape2D работает хорошо в качестве стены, но можно ли привязать к нему какой-то детект того, что персонаж в него врезался?
Можно наверняка к StaticBody приделать дочернюю ноду в виде той же Area, но мне кажется, это какой-то костыль, и есть гораздо проще варианты.
>Можно наверняка к StaticBody приделать дочернюю ноду в виде той же Area, но мне кажется, это какой-то костыль, и есть гораздо проще варианты.
Мы же о двадэ говорим? Ничего костыльного, это самый оптимальный вариант. НПЦ состоит из RigidBody2D в который вложен CollsionShape2D с кругом радиуса 20 и там же вложена Area2D c кругом радиуса 40. При приближении в зону ареи у персонажа отображается приглашение к диалогу, при приближении до коллижона срабатывает коллизия и игрок упирается в НПЦ.
То же самое со стенами. Коллизия, чисто математически - это прикосновение (с опциональным пересечением) двух геометрических тел. При детекте коллизии физические тела посылают сигнал об этом. В годоте для отлова сигнала о коллизиях всё есть. Гугли, читай, изучай.
Да, именно о 2D. Я уже пробовал по отдельности все эти ноды, с коллизиями тоже разобрался, просто пока несколько разных по типу нодов вместе в один объект не смешивал и не был уверен, что это оптимальный вариант.
Спасибо большое за ответы, пойду разбираться.
Даже для тридэ вкладывание Area в состав какого-либо составного объекта (сцены) не является каким-то костылём. Если обратиться к официальным туториалам, там Хуан прямо пишет: "Вы повар. Вы готовите игоры-блюда из нод-продуктов. Комбинируя ноды, вы создаёте желаемое поведение."
Но в тридэ свои нюансы. Общеизвестное поведение экшенов - когда приглашение к действию отображается на экране при наличии двух условий 1) вы находитесь рядом с интерактивным объектом, 2) вы смотрите на интерактивный объект. Это поведение реализуется так: У интерактивного объекта есть Area которая сигнализирует о появлении в её поле игрока (как минимум), у игрока есть рейкаст из глаз в направлении прицела мышкой. Когда игрок получает одновременно сигнал от рейкаста, что он смотрит на определённый объект, и сигнал от эрии объекта о том, что игрок поблизости (в поле действия) тогда и только тогда на экране появляется надпись "Е - говорить".
Отлично же!
var save_dict = {}
func ingame_data_filling():
•save_dict[value1] = 1
•save_dict[value2] = 2
•save_dict[value3] = "HurrDurr"
•save_dict[value4] = Vector3(1,2,3.1415928)
func save(file_name):
•var save_file = File.new()
•save_file.open("user://"+file_name, File.WRITE)
•save_file.store_line(to_json(save_dict))
•save_file.close()
Всё, ваши данные сохранены. Достать их так же просто:
func load(file_name):
•var save_file = File.new()
•if not save_file.file_exists("user://"+file_name): return
•save_file.open("user://"+file_name, File.READ)
•save_dict = parse_json(save_file.get_string())
•save_file.close()
Естественно, функция ingame_data_filling здесь дана для наглядности, в идеале словарь save_dict должен наполняться данными в процессе игры. Об уникальности ключей в словаре разраб должен побеспокоиться самостоятельно. Итого, функция save - 4 строки, функция load - 5 строк и то за счёт проверки существования файла. Если добавить ещё проверок на дурака (например, проверку, что имя файла содержит только допустимые символы), строк может стать 6-8.
В моей игре (ну, в том подобии игры, что пока есть) есть самая главная нода World, которая является обработчиком всех сигналов от всех типов объектов в годоте очень удобно сделана настройка этих сигналов, кстати. Впрочем, другими движками я не баловался, поэтому не знаю, может, там тоже есть подобное. То есть наступил персонаж на Area2D, она посылает сигнал ноде World, а та уже, например, отрубает движения игрока, делает диалоговое окно видимым, передаёт окну текст, который должен быть. В целом мне это показалось очень удобным, но проблема в том, что есть переходы между уровнями.
Нода World пока выглядит так:
World
CanvasLayer
DialogWindow
Собственно, она еще в себе держит диалоговое окно. Просто потому, что я не придумал, куда его девать. Может, вместе с камерой в сцену самого игрока запихать?.
В процессе запуска игры грузится уровень, который нодой World добавляется в конец списка своих детей. При смене уровня игра удаляет последнюю ноду и добавляет другую ноду-уровень с переопределением всех сигналов.
Так вот, хороший ли это вариант смены уровней? И вообще такая организация нод в игре. Я читал про синглтоны и автолоады в годоте, наверно, это было бы удобно, но мне тогда придется переписывать многое. Стоит ли заморачиваться с переписыванием кода, стоит оно того?
Еще вопрос: как сильно влияют на нагрузку коллизии в 2D? Это в мониторинге пункт Collision pairs. Пока я раскидал объекты как попало, поэтому некоторые из них пересекаются, но я особо не заметил никаких проблем при 20+ коллизий. Стоит ли вообще об этом беспокоиться при составлении уровней в целях улучшения производительности?
Блядь, макаба сожрала символы. Вот так она выглядит.
>Стоит ли заморачиваться с переписыванием кода, стоит оно того?
Стоит заморачиваться. Ибо уж не думал ли ты, что у тебя с первого раза получится идеальная и удобная архитектура?
Рекомендую разделить свою логику на постоянную (например, деньги, патроны и инвентарь игрового персонажа) и уровневую (сам уровень, карта, инвентари врагов). Постоянная логика грузится через автолоад и висит в памяти всегда. Уровневая логика грузится постоянной логикой через change_scene()
Так же в постоянной части игры рекомендую организовать логику сохранений и загрузок, юзер-интерфейс, главное меню.
И вот еще кое что: Годот предполагает, что ноды в составе сцены автономны, поэтому рекомендуется не писать всю логику в отдельный скрипт, а снабжать ноды небольшими скриптами, которые делают что-то одно, но делают это хорошо.
>Стоит ли вообще об этом беспокоиться при составлении уровней в целях улучшения производительности?
Стоит. Коллизии это одна из ресурсозатратных задач физических движков. Поэтому о них всегда надо помнить. И оптимизацию начинать с них. Например, вместо разбросанных по уровню отдельных пересекающихся эрий, сделать одну с составной коллижон-формой. Или даже с коллижон-полигоном нужной тебе формы. Если я правильно понял туториалы, движок каким-то хитрым образом оптимизирует все формы внутри одного физик-объекта в одну при инициализации объекта, после чего работает с ней. Но это не точно.
>>37864
>что-то одно, но делают это хорошо.
Да, я неверно выразился. Главная нода является лишь обработчиком сигналов. Мне показалось не очень удобным иметь кучу сигналов в разных местах, чтобы то же диалоговое окно принимало по десятку за раз из разных мест, которые, в общем-то, выполняют одно и то же: делают окно видимым. Так очень легко запутаться. С моей точки зрения удобно сделать лишь одну ноду-слушателя, которая собирает все сигналы вместе и действует соответственно им. Так, это же диалоговое окно в таком случае будет всегда получать лишь один сигнал.
Именно логика поведения, скажем, врагов, конечно, будет в нодах этих самых врагов.
Хорошо, тогда попробую переписать сегодня всё под автолоад. Уровни пока все равно только тестовые, в них нет ничего, лишь проверить переходы между ними да какие-нибудь механики внутри них, но про коллизии запомню на будущее. Спасибо за советы.
>И оптимизацию начинать с них.
>Или даже с коллижон-полигоном нужной тебе формы
Ты это. Выбери что-нибудь одно, что ли?
Есть скрипт в автолоаде, который занимается обработкой сигналов. Есть Area2D, которая при коллижене с игроком отправляет сигнал смены уровня. Скрипт его принимает, но get_tree().change_scene() не работает. Точнее , сцена-то меняется, проблема в другом. Для начала, я не могу её найти в потомках рута. Видима остаётся первая сцена, но второй нет. Или вторая сцена просто заменяет первую, имя ноды остаётся такое же? Даже если так, скрипт после загрузки сцены должен переопределять все сигналы на себя заново, но он не делает это со второй сценой (если предположить, что имя осталось такое же). Как бы ноды-то сами на месте, я вижу их при передвижении по уровню, но в скрипте их не получается найти.
Вопрос: почему так? Как достать вторую сцену? Как перепривязывать сигналы? В целом, я нашел обходной путь. Нужно вручную загружать сцену, создавать её инстанс, удалять предыдущую ноду-сцену и добавлять к руту новую, тогда всё работает, все сигналы нормально переопределяются. Но я не уверен, что это хороший вариант.
> отдельный нод, который тебе сцены и меняет
Что-то такое я тут и описал: >>37860
Как раз нода World отвечала за смену сцен и была главной сценой в настройках Run проекта. Но мне предложили всё перетащить в автолоад скрипт, который со всем этим будет разбираться. В целом, в World была описана общая механика для всех сцен, поэтому мне показалось уместным практически полностью её скрипт перетащить в синглтон (Да и какая разница, к скрипту в автолоаде все равно при запуске игры создаётся выделенная нода-потомок рута).
>И сцену менять не в потомках рута, а по имени фаила сцены же.
Я разные варианты пробовал. Именно функция change_scene(путь_до_сцены) не работает ни в каком варианте. То есть, работает, сцена действительно меняется, но годот не видит эту сцену в качестве ноды. Он видит старую, со всеми её нодами-потомками, а новую отказывается показывать где-либо.
>Но мне предложили всё перетащить в автолоад скрипт, который со всем этим будет разбираться.
Воу-воу, братиш, притормози! Тебе посоветовали КАК ВАРИАНТ держать в автолоаде глобальный менеджер сцен (самописный). Это не значит, что ты должен бежать и переделывать, как тебе сказали.
Предполагалось, что ты сделаешь выводы для себя, подтянешь матчасть, поглядишь примеры и сделаешь, как тебе удобнее.
Не пизди. Автозагруженные ноды не выгружаются сами. Только если ты явно их ОСВОБОДИШЬ.
>Ты точно иеархию нодов не попутал?
Я проверю это еще раз, все-таки сцена-то грузится, значит, куда-то она прицепилась.
>Только ноды должны видеть это. У тебя есть нод "Годот" чтоле?
Я имею в виду скрипт, конечно. Такой ноды нет.
>>38033 (Del)
Что такое прелоад? Есть АВТОлоад. И я именно это уже и сделал.
Из прелоада я вижу только это: http://docs.godotengine.org/en/3.0/classes/class_resourcepreloader.html
>>38034
Ну, что сделано, то сделано, в общем-то. Обратно уже не откатишь ничего. Да и к тому же я побежал сначала писать скрипт, а прочитал, как работают синглтоны лишь потом. В итоге я убил пару часов на то, что делается одной кнопкой. Будет мне уроком.
>Из прелоада я вижу только это
Да, он имел ввиду это.
Однако он не упомянул тонкость. Загруженная прелоадом нода не отобразится на экране и в ней не заработают колбэки процессов, пока ты не добавишь её в дерево сцен. В дереве сцен текущей сценой называется последняя сцена в дереве, это можно увидеть, если при включенной отладке открыть "Удалённый" (тупо паруске звучит). Если ты добавишь туда (в крайнюю ноду, повторюсь), то как он и написал, всё предзагруженное выгрузится вместе со сценой, при выполнении get_root().change_scene()
Однако! Существует вкуснейшая возможность подгружать ноды и добавлять их в дерево как потомки автозагруженных нод. Ммм, возможности, открывающиеся в этом случае поистине безграничны!
Например, самое простое, что приходит на ум: При смене локации на экране остаётся интерфейс, отображается анимация полёта, можно принимать зелья из инвентаря, хилиться, писать смешнявки в чятек, который продолжает висеть на экране. А в это время продолжает грузиться новая локация отдельным потоком. И когда она загрузилась, камера в синглтоновой ноде с анимацией выключается, камера в новой локации включается. Ты бесшовно и без задержек попадаешь в полностью загруженную локацию.
Код покажи. А я тебе покажу, где именно ты добавлял её в дерево сцен.
Что за игра, где скочать?
Обычно делается триангуляция меша твоей поверхности, и там уже двигаешь вершины как хочешь. Но есть всякие нюансы, с растянувшемися текстурами например.
Можешь начать с готового ассета
https://godotengine.org/asset-library/asset/231
Ах да, концептуально обычно это heightmap, то есть ты прикладываешь картинку, где цветом отмечается желаемая высота.
Ты решил не терять выходные и уже обкурился?
>не не слышал?
Для кого написано, что там есть нюансы?
>рандомную
И че, бля? Тебе религия запрещает рандомно генерить пиксели?
ты чо блять как тёлка сука, а нахуй!?
корзина ебать, тебя чотко спросили нахуй -
КАК
СГЕНЕРИТЬ
РАНДОМНОЕ ГОВНО
>ну там нюансы хуе мое, а еще можышь нарисивоать хейт мапу
ага, уже побежал блядь
сука, разозлила меня, педовка хуева..
ой да говна пожри родной
русский - значит ПРОСТОЙ и истинно свободный школьников пока мамка кормит - понты кидают, а вот потомта-аА.. жизнь пальцы загнет обратно и куда надо определит
дырка в жопе, а в тиррейне отверстие
вся суть кододебильных детей, которые могут только скриптики писать на СИСТЕМНОМ япе, а как дело доходит до реального говна, где код уже хотя бы на полшишечки не выглядит уебанским прожиганием времени, они срут в штанишки и бегут размазывать это по комнате
фу блядь фу нахуй
..
>>538141 (OP)
Работаю над простенькой рпг 3 класса - маг, лучник, воен. 3 расы - хуманы, дворфы, эльфы.
Когда на форуме геймдев.сру сообщил, что использую годо, был засран и закидан тапками.
Что за предвзятость?
тема с гномом жива до сих пор, я охуел
Это копия, сохраненная 18 ноября 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.