godot QnA 31.08.2020 (ru translation)

прошу прощения за некоторую надмозговость перевода, я не кодер вот совсем, знаю только основные принципы.
если вдруг вы прям ну очень благодарны за перевод, можете отправить вашу благодарность на paypal: soundsbeard@gmail.com


2:48
- представление разработчиков

хуан работает только над 4.0, почти закончили с новыми фичами. сейчас работают только над системой частиц и оптимизацией. будут ещё добавлены некоторые незначительные улучшения. потом он создаст несколько демосцен, показывающих оптимизацию и графические новшества.

джордж работает над ГД скриптом. провёл масштабный рефактор, добавил новые фичи и исправил некоторые старые известные баги, и так же работает над оптимизацией ГДС.

фабио (на гитхабе Faless https://github.com/Faless) работает над сетевой частью и хтмл5, конкретно сейчас трудится над улучшенным экспортом хтлм5, а так же пытается портировать эдитор в веб, это будет удобно для мелких проектов и школ. следующим шагом будет возможность работы ГД натива в вебе, улучшенная поддержка мобилок

джил (на гитхабе groud https://github.com/groud), будет нанят только в ноябре. начнёт работу над эдитором, а именно над тайлмапом и тайлсет эдитором. так же будет помогать реми с пул реквестами и организовывать комьюнити.

реми. был в отпуске, большой молодец.


6:21
- недавно было добавлено кастомное шейдерное небо, вопрос насколько сложно будет вкорячить скайбокс как в движке сорс. будет ли возможность самому его впилить?

небо клёвая фича, процедурное небо может генерироваться из ваших шейдеров, будут засветы на небе, вы сможете сделать появление/исчезание звёзд, процедурные облака, смена времени суток. уверен, что с выходом 4.0 вы все начнёте постить свои офигенные шейдеры неба. небо в движке сорс это очень старая технология и она ориентирована на старое железо. тк в то время не было большого количества памяти в распоряжении, использовались текстуры низкого разрешения для неба, а при использовании больших текстур всё работало медленно. и если вам нужна была отрисовка на дальние расстояния, в буфере было только 16 бит (я не ебу это много или мало), а сейчас таких ограничений нет. по сути сорс делал пре-рендер сцены, которую вы поставите на фон в каждом кадре и только потом отрисовывал кадр. сейчас в этих заморочках нет смысла, тк в буфере 32 бита, и не должно быть зет-файта (я понятия не имею, как фоновая картинка может зетфайтить с чем-то, но ладно), просто используйте текстуру с высоким разрешением и засовывайте на фон что хотите + можно использовать скайбокс или панораму более выского разрешения (а до этого он о чём тогда говорил?). но если очень хочется скорячить такую систему, скорее всего вы сможете это сделать использовав рендер пассы, но вряд ли вам стоит таким заморачиваться.

9:40
- нужны креситики, чтобы выделять ноды в 2д. они незаметны, можно ли будет менять их размер и тд.

для людей с плохим зрением это реально проблема, будет кастомизация, будут лейблы для нод, но если на всех нодах будут лейблы, то всё смешаются в кашу. но можно будет альт-кликать как в блендере, чтобы выбрать ноду и списка наложившихся одна на другую нод.

11:58
(в этом вопросе я вообще не понял контекста.)
- would it be possible to add some sort of token into gdscript and may be into c# to a description directly to unexported value that it shows up in the pop up?

эта система частично внедрена в гдс, уже сейчас можно навести курсор на названия в эдиторе и появится поп ап (с документацией видимо?). так же это можно будет внедрить в панель экспорта, тк некоторые функции джвижка уже имеют доки. для шарпа такая фича теоретически тоже может быть введена.

13:40
- планы на сишарп в годо: можно ли будет редачить шарп прямо в годо, интегрированные доки для шарпа, так же нужно больше сишарп туториалов.

сначала мы будем доводить шарп до уровня гдс по фичам и возможностям языка, а потом остальное. запрос на редактирование шарпа прямо в годо это вообще не приортет сейчас. больше запросов на совместимость с ВСкодом и привычные щарпистам IDE, ведь там есть все привычные фичи для шарпистов, и мы будем фокусироваться на этом. доки некоторые уже добавлены, но не все, будут полные доки для шарпа наравне с ГДС. туториалы будут сильно позже, тк некторые туты будут очень сильно отличаться от аналогов на ГДС, это потребует много работы.

17:23
- json поддержка.

json это конечно реально удобно, пока планируется как плагин в библиотеке ассетов, пока интеграция не планируется, особенно визуальная часть. может скоро появится лучший автокомплит для него в эдиторе, но если вы хотите кучу графических фич, то лучше чтобы был плагин, тк иначе это раздует движок.

19:25
- будет ли батчинг для гдс3 в 3.2

начали работать над этим в гдс2 и гдс3, появится только в 3.2.4.

20:20
- когда релиз 3.3?

у нас уже 4 релиз кандидата. мы добавили поддержку моделей, которая проявила некоторую нестабильность. как только пофиксим - будет релиз

21:10
- поддержка wayland (далее ВЛ) (это графическая подсистема для линукс, замена для x11)

для 4.0 переписан композитор окон, если хотите переключаться между иксами и ВЛ - это сделать сложно. сейчас мы работаем над иксами, ВЛ сейчас не приоритет, ждём пока ВЛ будет стандартом и появится у большего количества софта и соотв на большинстве дистров по умолчанию. желающих заняться ВЛом в годо много, потому когда-нить да появится.

23:15
- апдейт сетевухи. (чувак на своей волне, объясняет что-то, что изображено у него в голове, но нам сказать забыл)

работаем над модулем по синхронизации сцены в 4.0 (с чем? с сервером? с другими разрабами? неясно). есть планы сделать серверный экспорт в годо лучше, чтобы можно было удобнее создавать игровые серваки в годо без необходимости использовать gpu (?????? я понятия не имею, как сервер и видюха связаны), и с большей производительностью.
из моих планов на будущее, т.е. то что хочу делать в своё личное время: улучшить сетевой интерфейс, нодовая репликация сцены, это когда вы создаёте инстанс сцены, и в систему делается вызов скопировать её другим игрокам. эта система позволит внедрять мультиплеер даже в те игры, где мультик не подразумевался изначально. но если вы изначально делаете игру под мультик, то скорее всего всю сетевуху вы будете настраивать ручками, тк для каждой игры своя специфика сетевого взаимодействия. тем не менее я работаю над системой, которая по умолчанию устроила бы большинство разрабов.

26:55
- когда фиксы для статтеров аудио в вебе?

это нелегко, апи для аудио в вебе ограничено. я в последнее время работаю над тем, чтобы разрабы смогли выбирать размер буфера сами, в зависимоти от нагрузки на проц в их игре. основная запара для аудио - это нагрузка на цпу. в новом аудио апи для веба есть фича по выделению отдельного ядра (потока) для звука, но вам придётся самостоятельно писать js скрипт, со всеми процессами, которые уже будут выполняться на Си в годо. но даже если мы всё это напишам прям завтра, использовать это можно будет только в нескольких браузерах.


31:18
- хуан, будут ли ещё видосы по сорскоду годо, но уже для 4.0?

в ядре 4.0 много чего переписано, в том числе много переименований, изменена низкоуровневая система взаимодействий. если такие видео и будут, то только после того, как апи для 4.0 будет утверждён.
ремарка от реми: в ютюбе есть ещё один чел, который разбирает сорскод, идите к нему, ник в ютюбе (willnationsdev https://www.youtube.com/channel/UC7uU5XaPB9uYKlowYOhEHnA/videos)

32:54
- файл project.godot постоянно выдаёт конфликты при мёрдже, но их легко поправить. можете уже написать приблуду, которая автоматически фиксила бы эти мёрдж конфликты?

это возможно. это обычная ситуация при интеграции VCS. сейчас один студент у нас занимается интеграцией системы контроля версий в vcs. на данный момент из систем контроля версий работаеть только гит, но мы планируем поддерживать и другие, и сейчас их базовые функции уже работают, но решать конфликты при мёрдже автоматически ещё пока нельзя. к моменту, как мы закончим работу, конфликты можно будет исправлять внутри скрипт эдитора, но в идеале я бы хотел добавить инспектора, который будет видеть конфликты и предлагать версию, которую надо оставить. но все эти планы пока не в приоритете.
ремарка от реми: я сам не часто меняю настройки для файла project.godot, поэтому у меня этих конфликтов нет, но вполне реально написать плагин, который бы решал это автоматически.

36:15
- сервер навигации. работал ли хуан над ним с последнего апдейта?

в годо 4.0 классы и ноды навигации перекочевали на сервер навигации. им занимается (имя, которое русскоязычному человеку не произнести), и кажется он делал какие-то апдейты, в том числе избежание столкновений (collision avoidance) и grid based queries (я без понятия, что это). насколько хорошо это работает, можно будет понять после альфы или беты годо4. так же доработана система рекаста.

38:03
- какие области движка изменятся больше всего в ближайшие 2 года? вопрос в контексте разработки игры, в каких областях разрабам нужно будет дорабатывать игру в последнюю очередь?

мы делаем 4.0 таким образом, чтобы сохранить обратную совместимость в общих чертах, а так же будут инструменты, помогающие перекинуть проект на 4.0 малой кровью, будет куда проще чем миграция с годо2 на годо3. после релиза годо4, у нас в планах только мелкие доработки и общие улучшения без кардинальных изменений, может быть добавим рейтрейсинг, но в целом ничего глобального, что могло бы помешать дальнейшей разработке вашей игры.
от реми: мы уже разрабатываем инструменты для конвертирования годо файлов в 4.0, к примеру разные системы частиц.
хуан: уже сейчас в новых именах функций есть привязки к старым именам, и годо4 автоматически всё переименует из годо3 проекта. но гдс3 и гдс4 будут несовместимы, но джордж должен продумать тулзу для первращения гдс3 в гдс4.
джорж: да, такая тулза спарсит старые имена и заменит их новыми.
реми: для тех вещей, которые не смогут автоматически ковертнуться в годо4, мы напишем инструкции по грамотному переносу из старой версии. но предсказать масштабы изменений мы пока не можем.

44:15
- какие планы у игнасио на дотнет и шарп?

в мастер ветке годо4 уже находится дотнет5, который будет использовать дотнет cli.
в версию 3.2.3 бекпортнули те же апдейты, поэтому после релиза вы уже сможете использовать дотнет5 в ваших проектах.

46:41
- повтор про тайлсеты

интерфейс тайлсетов будет перделан. после создания заявки (proposal) на гитхабе, люди смогут оставить фидбек по планируемым изменениям.

48:50
- изменятся ли минимальные системные требования для годо4?

если вы собираетесь использовать вулкан, то соотв ваше железо должно его поддерживать. на данный момент это железки среднего сегмента.
что касается мобилок, то вулкан поддерживаеся только на топовых смартфонах. но глес3 останется, возможно будет урезан.
остальное без изменений

51:12
- на какую версию вулкана нацеливаетесь?

пока только 1.0. в более современных версиях нет необходимости. если захотим добавть рейтрейсинг, то придётся использовать более новую версию, а может сможем обойтись расширением. но в отличие от опенГЛ, накручивать новые версии вулкана намного легче.


53:03
- будет ли годо поддержвать дебаг по потокам (ядрам?)

мы не уверены, что такая фича будет, и вообще дебагер уже в готовом состоянии. но такие идеи у нас были и находятся в списке.
фабио: у нас есть возможность остановить поток, может мы сможем это использовать для дебага
хуан: когда я писал гдс давным давно, я опирался на то, как другие скриптовые языки изспользуют мультипоточность, и сделал так, что гдс использует стандартный стэк, который предлагает ОС. проблема в том, что в таких условия невозможно отследить потоки в этом стэке, и чтобы прикрутить такую фичу, нужно будет симулировать этот стэк со ссылками во время дебага. но всё таки мы можем остановить поток, в котором наблюдается проблема, сейчас это используется для отлавливаения крашей, но надеюсь джордж сможет найти лучшее решение для использования мультипоточности.

55:43
(тут я не понял о чём речь, видимо человек хочет, чтобы в одном шейдере описывались разные прогоны этого шейдера?)
- will we have multipass shaders defining the same shader not in multiple separate shaders in 4.x?

нет, вам всё так же придётся использовать 1 материал на 1 шейдер. но из хороших новостей мультипасс шейдер появится в 2д

56:25
- в ГДС, будут ли сигналы поддерживать статичную типизацию тем же образом, как функции в гдскрипте?

ну тут сложно, тк сам движок не определяет никакой типизации для сигналов. но в игре вы можете предеать лююбой тип в движок и всё будет ок. сейчас это не в приоритете. (он так же упоминает, что это влияет на время компиляции, а не на запущенное приложение, но тут я боюсь спороть херню, тк я не понял сказанного)

57:46
- уже создано множество тикетов (issues) с проблемами системы плагинов, например создание системы контроля зависимостей. есть ли какие-то подвижки в решении накопившихся тикетов?

сейчас мнение у нас разделилось на 2 стороны, либо мы создаём сложную систему зависимостей, либо мы оставляем всё простым, как сейчас, тк это устраивает боьшинство юзеров. если делать сложную, то надо понмать, стоит ли оно того, тк потом эту сложную систему придётся поддерживать. мы бы сами хотели иметь контроль над зависимостями плагинов, но риск что-то запороть очень высок. вы могли сами наблюдать, как что-то в плагине ломается и вслед за этим ломается всё остальное по цепи. если мы попадём в такую ситуацию, когда нам будет не обойтись без такой системы - только тогда мы ею займёмся.

1:00:12
- будут ли улучшения импорта 3д моделей?

один из контрибьютеров переписал fbx импортер почти с ноля, gltf2 уже работает просто замечательно. так же уже улучшен импорт текстур. так же сейчас годо задействует гпу для импорта, поэтому всё импортируется быстрее. уже в альфе 4.0 вы сможете потестить эти улучшения.

1:02:22
- можно ли будет в годо4 экспортировать user defined resources? (хз что это)

да, мы над этим уже работаем. нужны будут некоторые изменения в эдиторе, но да, скоро это будет возможно.

1:03:29
- есть планы упростить жизнь тем, кто делает плагины, изменяюшие раскладку (layout) интерфейса?

джим/джил: ну для начала нам нужно переосмыслить весь эдитор, чтобы была возможность более гибкой кастомизации, хотя интерфейс уже достаточно гибкий. я пока не знаю, насколько сложный апи у интерфейса (отвечает чел, который приступит к работе только в ноябре), чтобы я мог понять, какие трудности могут возникнуть при создании плагина. пока в планах запилить новый юай, и только после этого будем смотреть на его апи и упрощать его.
реми: ТС наверное пытается спросить, будет ли юай такой же гибкий как в блендере, где можно создать себе абсолютно любую раскладку, ответ нет, это не стоит того.
джим/джил: я бы и сам хотел большей гибкости, но проблема ещё и в том, что в годо автоматически открываются определённые окна при клике в определённые места, и если мы начнём всё ломать, то есть шанс потерять эту фичу, а нам бы не хотелось.
хуан: лично я считаю, что эта фича с автоматическими переключениями лучше, чем возможность пересобирать раскладку под различные нужды, тк это больше экономит время при переходах от одних действий к другим. и мы планируем дальше развивать эту идею, чтобы ещё лучше предсказывать, какое окно захочет увидеть пользователь при клике в определённое место.

1:07:32
- есть ли в планах полная поддержка .blend файлов?

это абсолютно нецелесообразно, тк у нас уже есть отличная поддержка gltf, а имплементировать импорт бленд файлов будет очень долго. мы хотим пойти по пути юнити, чтобы при добавлении бленд файла вызывался сам блендер и автоматически экспортировал gltf в годо, но выглдяеть будет так, будто ты импортишь бленд файл.

1:08:56
- джордж, ты говорил о нативной компиляции в гдс для функций, но только в целях разработки. расскажи об этом подробнее, и будет ли возможно скомпилить всё во время экспорта?

если ты компилишь гд натив, ты не сможешь потом дебажить, тк это больше не гдс, а значит он больше не проходит через интерпретатор, а значит ты не сможешь узнать, что там происходит, а значит придётся юзать gdb или типа того, чтобы дебажить.
(а дальше попёрла конкретная кодерская духота, которая мне не по зубам)
so the idea is like only when you're reading it, this function, it runs every frame and have like double nested 'for loops' or something like that might need you run fast, then we can add an adaptation to this function and it will be compiled to gdnative and then just called the native function.
в целом рекомпилить всё не имеет смысла, тк по большей части различий не много. в теории это возможно, но особого смысла рекомпилить всё на экспорте нет. это необходимо только для функций, которые должны выполняться очень быстро.
хуан: мы с джорджем это уже обсуждали, и проблема в том, что у гдс динамическая типизация, и компилить динамический язык в ГДнейтив разницы не даст и это главное отличие от шарпа или плюсов, где язык статичный. в гдс вы можете объявить статичную функцию, чтобы что-то работало быстрее, и вы увидите в эдиторе, где вы используете инструкции для типов. и если вы хотите ускорить выполнение функции, вы можете обозначить её тип. сейчас, если вы хотите вызвать функцию, и вы не знаете её тип, её прогонят через хэшмапы и всякое такое, но если вы знаете что это за функция, когда вы компилите, вы можете просто сохранить указатель на функцию и она будет вызываться эффективнее. и даже если вы компилите не ГДнейтив, иметь типизацию будет плюсом для производительности. и мы хотим пойти дальше, если вы хотите иметь скорость как в ГДнейтив, объявляйте функцию и все её типы, у вас будет некоторый прирост. и вместо того, чтобы использовать инструкции для типов и писать на чистом ГДнейтив, вы можете использовать такую оптимизацию. но рекомпилить всё смысла не имеет, просто выбирайте то, что хотите оптимизировать, объявляйте типы, оно будет выстрее просто потому, что объявлены типы, но если вы хотите ещё прироста, то можете рекомпилить всё в нэйтив, но это уже скаорее крайняя мера.
(я представляю как сейчас охуевают кодеры от этой моей писанины)

1:13:26
- вопрос от core разрабов, можно ли нам вырезать (deprecate) импортер цветов (color dye importer)?

я не знаю, использует ли ещё кто-то импортер цветов. если он ещё работает, то не вижу особого смысла вырезать его. есть люди, которые могут до сих пор работать над старыми проектами, в которых они использовали этот импортер. давайте сначала выясним, юзает ли его ещё кто-то.

1:14:40
- планы на улучшение отображения видео?

реми: сейчас у нас в планах вырезать нынешнюю имплементацию видео. и сейчас у нас уже есть новый гдс интерфейс для видео, и мы планируем выпустить новый плагин, с раширенными возможностями кодирования в разных форматах на гдс. так сделано для того, чтобы дополнительные форматы декодирования были доступны только тем, кому они нужны.
хуан: кодеки это хрень, которая сильно увеличивает размер бинарников. и вы знаете, вообще сейчас почти все делают синематики посредствам анимаций, а не проигрывания видео, поэтому особого спроса на улучшения в эту сторону нет

1:16:05
- планы по поддержке js?

есть один контрибьютер, который уже написал некоторую поддержку ЖСа, вы уже можете собрать годо с поддержкой жс, но мы не в курсе, насколько велик спрос на жс в годо.
уже сейчас вы можете использовать модули ГДнейтив, чтобы использовать жс. мы рады всем конрибьютерам, но если мы оффициально анонсируем новый язык, значит нам надо будет написать полную документацию к нему, а это много работы.

1:18:56
- будет ли эдитор для андроида?

мы уже над ним работаем. он уже неплохо работает на некоторых планшетах, если вы подрубите мышь и клаву. как только он будет работать стабильно мы уже будем думать над тач функиями.
хуан: а так же вы уже можете использовать на ведре веб версию эдитора. если вам вдруг надо что-то срочно сделать, вы уже можете открыть проект в вебе.

1:20:44
- вопрос не про годо: а это правда, что хуан рабоал над argentum online?

нет, я не работал над этой игрой. это оч старая аргентинская ММО из нулевых. я писал им музыку, именно музыку для интро.

1:22:30
(какой-то вопрос про фиксы каких-то perks? burks? bergs? но я всё, на этом мои полномочия как бы всё)