Добро пожаловать в тред любви и взаимопомощи, круче всех этих вместе взятых!
Шапка: https://hipolink.me/godothread
Предыдущий: >>1000909 (OP)
Архивный: >>992896 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>1000909 (OP)
Архивный: >>992896 (OP)
В чем смысл MatCap? Для чего его можно применить? Я так понимаю он в первую очередь для однотонных материалов, типа слизня или бронзовой статуэтки? В чем его преимущество против обычного материала с металликом и нормалями например? Вроде как пишут что он дешевле, имеется в виду дешевле чего, видимо это потому что в нем не будет захвата окружения извне уровня. И я так понимаю освещение на него не влияет, оно уже запечено будет. Или может есть какие то эффекты когда его можно применить поверх модельки с текстурой, например?
>>08278
запеченный в изображение сферы материал. сфера представляет собой множество всех возможных нормалей. нормаль любой точки поверхности объекта присутствует где-то на сфере. остается только посмотреть цвет пикселя для этой нормали на сфере маткапа
минусы - статичный, не реагирует на свет и окружение (для добавления динамики часто применяют маткап частично), не поворачивается (для возможности поворота применяют не маткап, а кубмапы). также им можно делать только поверхностные эффекты. адекватную рефрацию через маткап не сделать. плюсы - турбореактивный, легкая математика и одна текстурка
мимо
запеченный в изображение сферы материал. сфера представляет собой множество всех возможных нормалей. нормаль любой точки поверхности объекта присутствует где-то на сфере. остается только посмотреть цвет пикселя для этой нормали на сфере маткапа
минусы - статичный, не реагирует на свет и окружение (для добавления динамики часто применяют маткап частично), не поворачивается (для возможности поворота применяют не маткап, а кубмапы). также им можно делать только поверхностные эффекты. адекватную рефрацию через маткап не сделать. плюсы - турбореактивный, легкая математика и одна текстурка
мимо
>>08266
Нахуя ты вот это вот делаешь? Просто вот чтобы что? Можешь обеснить? Это у тебя юмор такой? Мне смеяться?
Нахуя ты вот это вот делаешь? Просто вот чтобы что? Можешь обеснить? Это у тебя юмор такой? Мне смеяться?
>>08352
А мне понравилось. Потому что именно к такому приводит кооперация с рандомами в интернете. Люди, бля, катку в дноте с рандомами доиграть не могут, а тут проект на недели минимум.
А мне понравилось. Потому что именно к такому приводит кооперация с рандомами в интернете. Люди, бля, катку в дноте с рандомами доиграть не могут, а тут проект на недели минимум.
>>08351
Я примерно понимаю что он делает. Я не очень понимаю для чего это можно использовать.
Я примерно понимаю что он делает. Я не очень понимаю для чего это можно использовать.
>>08424
Прикольно
Прикольно
52 Кб, 536x592Текстуры как делать свои?
И где бесплатные и открытые ресурсы брать?
Чтобы хуяк-хуяк и в продакшн.
И где бесплатные и открытые ресурсы брать?
Чтобы хуяк-хуяк и в продакшн.
>>08590
Бля без обид, братишка, но для этого нужно не быть тупым. Тебе это не грозит. Продолжай топать ножками и требовать, вместо того, чтобы гуглить, читать и учиться.
Бля без обид, братишка, но для этого нужно не быть тупым. Тебе это не грозит. Продолжай топать ножками и требовать, вместо того, чтобы гуглить, читать и учиться.
>>08583
Сорян, не раскусил.
Сорян, не раскусил.
Репортнул
375 Кб, 1400x1400>>08591
кукарека не спросили!
если ты нуб и нихуя не знаешь, по этому и помочь не можешь, это ещё не значит, что остальные нубы и в теме не шарят.
кукарека не спросили!
если ты нуб и нихуя не знаешь, по этому и помочь не можешь, это ещё не значит, что остальные нубы и в теме не шарят.
>>08584
>>08660
Аспрайт опенсорный, если чо. Но не свободный. Можете из сорцов собрать.
Вот гитхаб аспрайта: https://github.com/aseprite/aseprite
Вот официальный гайд по сборке: https://github.com/aseprite/aseprite/blob/main/INSTALL.md
>>08660
Аспрайт опенсорный, если чо. Но не свободный. Можете из сорцов собрать.
Вот гитхаб аспрайта: https://github.com/aseprite/aseprite
Вот официальный гайд по сборке: https://github.com/aseprite/aseprite/blob/main/INSTALL.md
>>08667
Раз не свободный, то не опенсорсный, а source-available.
То есть я не могу из него взять исходники и вставить их в ту же пикселораму.
Раз не свободный, то не опенсорсный, а source-available.
>You may only compile and modify the source code of the SOFTWARE PRODUCT for your own personal purpose or to propose a contribution to the SOFTWARE PRODUCT.
То есть я не могу из него взять исходники и вставить их в ту же пикселораму.
>>08211 (OP)
Как делать модульных персонажей в стиле Godot?
Смотрю, на реддите популярно делать FSM из нод:
https://gdquest.com/tutorial/godot/design-patterns/finite-state-machine/
Но я не понимаю, каким образом можно повторно использовать чужие состояния? Пытался выяснить у нейронки, ничего не получилось. Дело в том, что если добавляется/удаляется новое состояние, это требует изменений в других состояниях, иначе как эти другие состояния узнают о том, куда им переходить?
Переходы вроде можно описать отдельно:
https://en.wikipedia.org/wiki/State-transition_table
Но, чтобы связать два состояния, нужно знать о происходящих событиях. А события знают только состояния, верно? Т.е. состояние должно следить за событиями, но если новое состояние требует некие совершенно новые события, это требует изменений остальных состояний (из которых можно перейти).
Короче, я не понимаю, как сделать так:
1. Добавили ноду - она сразу встроилась в систему.
2. Удалили ноду - система не сломалась, работает.
Utility System, по идее, решает именно эту проблему, однако нагружает систему лишними проверками и избыточна в случае, когда все переходы известны.
Вообще, что я хочу делать?
1. Есть базовый actor.tscn, он почти ничего не умеет.
2. Расширяем его способности в другой сцене.
3. В третьей сцене берём способности второй сцены и уменьшаем, т.е. вырезаем/блокируем лишний код.
1->2 легко решается любым способом. В прототипе использовал наследование, но дальше - не работает.
2->3 непонятно как решать. Композиция - понятно, но удаление состояний из FSM ломает другие состояния.
Наглядный пример: юнит А умел прыгать, т.е. у него состояние ходьбы имеет проверку "если захотели подпрыгнуть - состояние прыжка", а юнит Б должен исключать возможность прыжка. Если мы просто удаляем "прыжок" (или делаем заглушку, которая бездействует), то код ходьбы ломается. Если мы переделываем код ходьбы, то мы дублируем код.
Конечно же, Utility System решает эту проблему, но желательно избежать любых лишних вычислений, поскольку состояний и юнитов должно быть много.
Чего я не понимаю? Где та чудесная расширямость и модульность композитных FSM, которую я упускаю?
Как я понял, ECS эту проблему не решает. Система "прыгатель" должна всё знать о системе "ходитель" и наоборот, и если одну из них удалить - всё ломается.
Как делать модульных персонажей в стиле Godot?
Смотрю, на реддите популярно делать FSM из нод:
https://gdquest.com/tutorial/godot/design-patterns/finite-state-machine/
>If you need to make states that can be reused across different characters or entities. If all your character logic is imperative and contained in one script, you cannot reuse the code elsewhere.
Но я не понимаю, каким образом можно повторно использовать чужие состояния? Пытался выяснить у нейронки, ничего не получилось. Дело в том, что если добавляется/удаляется новое состояние, это требует изменений в других состояниях, иначе как эти другие состояния узнают о том, куда им переходить?
Переходы вроде можно описать отдельно:
https://en.wikipedia.org/wiki/State-transition_table
Но, чтобы связать два состояния, нужно знать о происходящих событиях. А события знают только состояния, верно? Т.е. состояние должно следить за событиями, но если новое состояние требует некие совершенно новые события, это требует изменений остальных состояний (из которых можно перейти).
Короче, я не понимаю, как сделать так:
1. Добавили ноду - она сразу встроилась в систему.
2. Удалили ноду - система не сломалась, работает.
Utility System, по идее, решает именно эту проблему, однако нагружает систему лишними проверками и избыточна в случае, когда все переходы известны.
Вообще, что я хочу делать?
1. Есть базовый actor.tscn, он почти ничего не умеет.
2. Расширяем его способности в другой сцене.
3. В третьей сцене берём способности второй сцены и уменьшаем, т.е. вырезаем/блокируем лишний код.
1->2 легко решается любым способом. В прототипе использовал наследование, но дальше - не работает.
2->3 непонятно как решать. Композиция - понятно, но удаление состояний из FSM ломает другие состояния.
Наглядный пример: юнит А умел прыгать, т.е. у него состояние ходьбы имеет проверку "если захотели подпрыгнуть - состояние прыжка", а юнит Б должен исключать возможность прыжка. Если мы просто удаляем "прыжок" (или делаем заглушку, которая бездействует), то код ходьбы ломается. Если мы переделываем код ходьбы, то мы дублируем код.
Конечно же, Utility System решает эту проблему, но желательно избежать любых лишних вычислений, поскольку состояний и юнитов должно быть много.
Чего я не понимаю? Где та чудесная расширямость и модульность композитных FSM, которую я упускаю?
Как я понял, ECS эту проблему не решает. Система "прыгатель" должна всё знать о системе "ходитель" и наоборот, и если одну из них удалить - всё ломается.
>>08211 (OP)
Как делать модульных персонажей в стиле Godot?
Смотрю, на реддите популярно делать FSM из нод:
https://gdquest.com/tutorial/godot/design-patterns/finite-state-machine/
Но я не понимаю, каким образом можно повторно использовать чужие состояния? Пытался выяснить у нейронки, ничего не получилось. Дело в том, что если добавляется/удаляется новое состояние, это требует изменений в других состояниях, иначе как эти другие состояния узнают о том, куда им переходить?
Переходы вроде можно описать отдельно:
https://en.wikipedia.org/wiki/State-transition_table
Но, чтобы связать два состояния, нужно знать о происходящих событиях. А события знают только состояния, верно? Т.е. состояние должно следить за событиями, но если новое состояние требует некие совершенно новые события, это требует изменений остальных состояний (из которых можно перейти).
Короче, я не понимаю, как сделать так:
1. Добавили ноду - она сразу встроилась в систему.
2. Удалили ноду - система не сломалась, работает.
Utility System, по идее, решает именно эту проблему, однако нагружает систему лишними проверками и избыточна в случае, когда все переходы известны.
Вообще, что я хочу делать?
1. Есть базовый actor.tscn, он почти ничего не умеет.
2. Расширяем его способности в другой сцене.
3. В третьей сцене берём способности второй сцены и уменьшаем, т.е. вырезаем/блокируем лишний код.
1->2 легко решается любым способом. В прототипе использовал наследование, но дальше - не работает.
2->3 непонятно как решать. Композиция - понятно, но удаление состояний из FSM ломает другие состояния.
Наглядный пример: юнит А умел прыгать, т.е. у него состояние ходьбы имеет проверку "если захотели подпрыгнуть - состояние прыжка", а юнит Б должен исключать возможность прыжка. Если мы просто удаляем "прыжок" (или делаем заглушку, которая бездействует), то код ходьбы ломается. Если мы переделываем код ходьбы, то мы дублируем код.
Конечно же, Utility System решает эту проблему, но желательно избежать любых лишних вычислений, поскольку состояний и юнитов должно быть много.
Чего я не понимаю? Где та чудесная расширямость и модульность композитных FSM, которую я упускаю?
Как я понял, ECS эту проблему не решает. Система "прыгатель" должна всё знать о системе "ходитель" и наоборот, и если одну из них удалить - всё ломается.
Как делать модульных персонажей в стиле Godot?
Смотрю, на реддите популярно делать FSM из нод:
https://gdquest.com/tutorial/godot/design-patterns/finite-state-machine/
>If you need to make states that can be reused across different characters or entities. If all your character logic is imperative and contained in one script, you cannot reuse the code elsewhere.
Но я не понимаю, каким образом можно повторно использовать чужие состояния? Пытался выяснить у нейронки, ничего не получилось. Дело в том, что если добавляется/удаляется новое состояние, это требует изменений в других состояниях, иначе как эти другие состояния узнают о том, куда им переходить?
Переходы вроде можно описать отдельно:
https://en.wikipedia.org/wiki/State-transition_table
Но, чтобы связать два состояния, нужно знать о происходящих событиях. А события знают только состояния, верно? Т.е. состояние должно следить за событиями, но если новое состояние требует некие совершенно новые события, это требует изменений остальных состояний (из которых можно перейти).
Короче, я не понимаю, как сделать так:
1. Добавили ноду - она сразу встроилась в систему.
2. Удалили ноду - система не сломалась, работает.
Utility System, по идее, решает именно эту проблему, однако нагружает систему лишними проверками и избыточна в случае, когда все переходы известны.
Вообще, что я хочу делать?
1. Есть базовый actor.tscn, он почти ничего не умеет.
2. Расширяем его способности в другой сцене.
3. В третьей сцене берём способности второй сцены и уменьшаем, т.е. вырезаем/блокируем лишний код.
1->2 легко решается любым способом. В прототипе использовал наследование, но дальше - не работает.
2->3 непонятно как решать. Композиция - понятно, но удаление состояний из FSM ломает другие состояния.
Наглядный пример: юнит А умел прыгать, т.е. у него состояние ходьбы имеет проверку "если захотели подпрыгнуть - состояние прыжка", а юнит Б должен исключать возможность прыжка. Если мы просто удаляем "прыжок" (или делаем заглушку, которая бездействует), то код ходьбы ломается. Если мы переделываем код ходьбы, то мы дублируем код.
Конечно же, Utility System решает эту проблему, но желательно избежать любых лишних вычислений, поскольку состояний и юнитов должно быть много.
Чего я не понимаю? Где та чудесная расширямость и модульность композитных FSM, которую я упускаю?
Как я понял, ECS эту проблему не решает. Система "прыгатель" должна всё знать о системе "ходитель" и наоборот, и если одну из них удалить - всё ломается.
>>08759
Вот это мне не понравилось.
За это после собеса не перезванивают. Я понимаю, что в галеру ты не собираешься идти, но тем не менее. Никаких вырезаний-блокирований. Если до этого дошло - то ты уже облажался с построением архитектуры.
Добавила себя в список доступных нод. Добавила в список доступных транзишенов те, которые могут привести к ней и от неё.
Удалила себя из списка доступных нод. Удалила себя из списка транзишенов.
Не только стейты - объекты, но и транзишены между стейтами - это тоже объекты. Подумай над этим.
> В третьей сцене берём способности второй сцены и уменьшаем, т.е. вырезаем/блокируем лишний код.
Вот это мне не понравилось.
За это после собеса не перезванивают. Я понимаю, что в галеру ты не собираешься идти, но тем не менее. Никаких вырезаний-блокирований. Если до этого дошло - то ты уже облажался с построением архитектуры.
> я не понимаю, как сделать так:
> 1. Добавили ноду - она сразу встроилась в систему.
Добавила себя в список доступных нод. Добавила в список доступных транзишенов те, которые могут привести к ней и от неё.
> 2. Удалили ноду - система не сломалась, работает.
Удалила себя из списка доступных нод. Удалила себя из списка транзишенов.
> Чего я не понимаю? Где та чудесная расширямость и модульность композитных FSM, которую я упускаю?
Не только стейты - объекты, но и транзишены между стейтами - это тоже объекты. Подумай над этим.
>>08759
Композиция > наследование. Проверенно.
https://www.youtube.com/watch?v=RAjgkqJ-8xQ
https://www.youtube.com/watch?v=rCu8vQrdDDI
https://www.youtube.com/watch?v=74y6zWZfQKk
Композиция > наследование. Проверенно.
https://www.youtube.com/watch?v=RAjgkqJ-8xQ
https://www.youtube.com/watch?v=rCu8vQrdDDI
https://www.youtube.com/watch?v=74y6zWZfQKk
>>08762
Ты так и не разобрался в теме. Это два разных подхода, которые друг друга не исключают и нужны в разных ситуациях
Описание в первом видео: "I'm not saying you should never use Inheritance, just be careful and use Composition where necessary."
Второе видео просто объясняет принцип композиции и не проводит сравнений с наследованием. Кстати, я слежу за автором, и он несколько раз в неделю стримит свой процесс разработки. Он использует и наследование тоже
Описание в третьем видео: "In this video we look at Inheritance vs Composition and a scenario where Composition is preferable in Godot 4"
Но в одном ты прав: судя по тому, что описывает >>08759 , именно композиция ему и нужна
Ты так и не разобрался в теме. Это два разных подхода, которые друг друга не исключают и нужны в разных ситуациях
Описание в первом видео: "I'm not saying you should never use Inheritance, just be careful and use Composition where necessary."
Второе видео просто объясняет принцип композиции и не проводит сравнений с наследованием. Кстати, я слежу за автором, и он несколько раз в неделю стримит свой процесс разработки. Он использует и наследование тоже
Описание в третьем видео: "In this video we look at Inheritance vs Composition and a scenario where Composition is preferable in Godot 4"
Но в одном ты прав: судя по тому, что описывает >>08759 , именно композиция ему и нужна
>>08761
Это понятно, но как иначе?
Абстрактный пример:
- У базовой сцены 1 способность.
- У юнита А 1 + 99 способностей.
- У юнита Б 1 + 49 из А + 50 своих.
Как избавиться от 50 лишних в Б?
Или как не дублировать 49 из А в Б?
Тут дело ещё вот в чём:
- Изменилась безовая сцена - изменились А и Б.
- Изменился А - изменился Б (на 49% или меньше).
Без наследования такого не провернуть никак.
Если что, напомню: мы обсуждаем сцены Godot.
Эх. Т.е. их нужно под каждую сцену с нуля писать?
>>08762
Как композиция сочетается с FSM?
И о какой композиции речь?
- Когда всё соединяется вручную (в коде)?
- Когда всё соединяется само (ноды в дереве)?
Как состояния FSM будут сами соединяться-то?
Если посмотреть на AnimationTree, там всё вручную.
>облажался с построением архитектуры
Это понятно, но как иначе?
Абстрактный пример:
- У базовой сцены 1 способность.
- У юнита А 1 + 99 способностей.
- У юнита Б 1 + 49 из А + 50 своих.
Как избавиться от 50 лишних в Б?
Или как не дублировать 49 из А в Б?
Тут дело ещё вот в чём:
- Изменилась безовая сцена - изменились А и Б.
- Изменился А - изменился Б (на 49% или меньше).
Без наследования такого не провернуть никак.
Если что, напомню: мы обсуждаем сцены Godot.
>транзишены между стейтами - это тоже объекты
Эх. Т.е. их нужно под каждую сцену с нуля писать?
>>08762
>Композиция > наследование
Как композиция сочетается с FSM?
И о какой композиции речь?
- Когда всё соединяется вручную (в коде)?
- Когда всё соединяется само (ноды в дереве)?
Как состояния FSM будут сами соединяться-то?
Если посмотреть на AnimationTree, там всё вручную.
>>08761
Это понятно, но как иначе?
Абстрактный пример:
- У базовой сцены 1 способность.
- У юнита А 1 + 99 способностей.
- У юнита Б 1 + 49 из А + 50 своих.
Как избавиться от 50 лишних в Б?
Или как не дублировать 49 из А в Б?
Тут дело ещё вот в чём:
- Изменилась безовая сцена - изменились А и Б.
- Изменился А - изменился Б (на 49% или меньше).
Без наследования такого не провернуть никак.
Если что, напомню: мы обсуждаем сцены Godot.
Эх. Т.е. их нужно под каждую сцену с нуля писать?
>>08762
Как композиция сочетается с FSM?
И о какой композиции речь?
- Когда всё соединяется вручную (в коде)?
- Когда всё соединяется само (ноды в дереве)?
Как состояния FSM будут сами соединяться-то?
Если посмотреть на AnimationTree, там всё вручную.
>облажался с построением архитектуры
Это понятно, но как иначе?
Абстрактный пример:
- У базовой сцены 1 способность.
- У юнита А 1 + 99 способностей.
- У юнита Б 1 + 49 из А + 50 своих.
Как избавиться от 50 лишних в Б?
Или как не дублировать 49 из А в Б?
Тут дело ещё вот в чём:
- Изменилась безовая сцена - изменились А и Б.
- Изменился А - изменился Б (на 49% или меньше).
Без наследования такого не провернуть никак.
Если что, напомню: мы обсуждаем сцены Godot.
>транзишены между стейтами - это тоже объекты
Эх. Т.е. их нужно под каждую сцену с нуля писать?
>>08762
>Композиция > наследование
Как композиция сочетается с FSM?
И о какой композиции речь?
- Когда всё соединяется вручную (в коде)?
- Когда всё соединяется само (ноды в дереве)?
Как состояния FSM будут сами соединяться-то?
Если посмотреть на AnimationTree, там всё вручную.
>>08759
Что такое "стиль Godot"?
Возможно, ты не понимаешь, что такое состояния и как их использовать. То, что ты описываешь в своем посте - компонент, не состояние. Компоненты не знают о существовании других компонентов и работают только с классом, к которому их подключают
Композиция. Выше прислали три видео, посмотри их
Если ты привязал компонент к классу, позже его удалить нельзя, поскольку связь с компонентом лежит в определении класса
Состояние ходьбы не должно содержать в себе никаких проверок. Состояниями управляет контроллер, а не сами состояния. В случае персонажа, он же и является контроллером
Композиция и машины состояний - разные понятия и решают разные задачи. Мне кажется, ты пытаешься реализовать через машину состояний то, что ей реализовывать не следует. Тебе нужна композиция
> Как делать модульных персонажей в стиле Godot?
Что такое "стиль Godot"?
> Но я не понимаю, каким образом можно повторно использовать чужие состояния?
> Дело в том, что если добавляется/удаляется новое состояние, это требует изменений в других состояниях, иначе как эти другие состояния узнают о том, куда им переходить?
Возможно, ты не понимаешь, что такое состояния и как их использовать. То, что ты описываешь в своем посте - компонент, не состояние. Компоненты не знают о существовании других компонентов и работают только с классом, к которому их подключают
> Вообще, что я хочу делать?
> 1. Есть базовый actor.tscn, он почти ничего не умеет.
> 2. Расширяем его способности в другой сцене.
Композиция. Выше прислали три видео, посмотри их
> 3. В третьей сцене берём способности второй сцены и уменьшаем, т.е. вырезаем/блокируем лишний код.
Если ты привязал компонент к классу, позже его удалить нельзя, поскольку связь с компонентом лежит в определении класса
> Наглядный пример: юнит А умел прыгать, т.е. у него состояние ходьбы имеет проверку "если захотели подпрыгнуть - состояние прыжка", а юнит Б должен исключать возможность прыжка. Если мы просто удаляем "прыжок" (или делаем заглушку, которая бездействует), то код ходьбы ломается. Если мы переделываем код ходьбы, то мы дублируем код.
Состояние ходьбы не должно содержать в себе никаких проверок. Состояниями управляет контроллер, а не сами состояния. В случае персонажа, он же и является контроллером
Композиция и машины состояний - разные понятия и решают разные задачи. Мне кажется, ты пытаешься реализовать через машину состояний то, что ей реализовывать не следует. Тебе нужна композиция
>>08211 (OP)
Что со шрифтами в 4 годоте? Какие нужно настройки поставить, чтобы они были не шакальные? В 3.5 все из коробки работало прекрасно, хоть 8 размера шрифт сделай, хоть 64 и он будет нормально выглядеть и масштабироваться, а в 4 просто шакальное месиво даже на стандартном шрифте.
Что со шрифтами в 4 годоте? Какие нужно настройки поставить, чтобы они были не шакальные? В 3.5 все из коробки работало прекрасно, хоть 8 размера шрифт сделай, хоть 64 и он будет нормально выглядеть и масштабироваться, а в 4 просто шакальное месиво даже на стандартном шрифте.
>>08781
Боженька наградил меня зрением на +2 мне похуй, как оно там шакалится.
Боженька наградил меня зрением на +2 мне похуй, как оно там шакалится.
>>08786
Пишу не с целью подушнить, а объяснить анону, что все несколько сложнее. Ведь он не слишком хорошо разбирается и может воспринять такие слова слишком буквально, что может навредить. Добра
Пишу не с целью подушнить, а объяснить анону, что все несколько сложнее. Ведь он не слишком хорошо разбирается и может воспринять такие слова слишком буквально, что может навредить. Добра
>>08789
Ладно.
Ладно.
>>08785
Если вкратце, у меня несколько направлений движения ногами, и когда я жму кнопку, анимация слишком резко меняется, а нужно плавно.
Пробовал гуглить, и там впринципе есть какие-то решения, которые я взял на заметку, но хотелось знать можэет есть решения проще.
А так, я просто сегодня заебался, щас спать буду, а с вопросом завтра разберусь
Если вкратце, у меня несколько направлений движения ногами, и когда я жму кнопку, анимация слишком резко меняется, а нужно плавно.
Пробовал гуглить, и там впринципе есть какие-то решения, которые я взял на заметку, но хотелось знать можэет есть решения проще.
А так, я просто сегодня заебался, щас спать буду, а с вопросом завтра разберусь
>>08781
Ты имеешь в виду небольшой блюр вокруг букв?
https://docs.godotengine.org/en/stable/tutorials/ui/gui_using_fonts.html
Ну и дальше по статье смотри, всё с картинками.
>чтобы они были не шакальные
Ты имеешь в виду небольшой блюр вокруг букв?
https://docs.godotengine.org/en/stable/tutorials/ui/gui_using_fonts.html
>In Godot 4.0 and later, texture filter and repeat properties are defined in the location where the texture is used, rather than on the texture itself. This also applies to fonts (both dynamic fonts and bitmap fonts).
>Fonts that have a pixel art appearance should have bilinear filtering disabled by changing the Rendering > Textures > Canvas Textures > Default Texture Filter project setting to Nearest.
Ну и дальше по статье смотри, всё с картинками.
26 Кб, 415x515>>08807
Я пробовал с разными настройками и все выглядит ужасно. Вот, для примера. Глаза от этого болят, как по мне. Особенно с учетом того, что хотелось бы поменьше размер, так как текст не должен занимать слишком много места на экране. И я понимаю, если бы это вообще невозможно было реализовать, но что в проекте на 3.5 у меня прекрасно все работало из коробки и даже мелкий шрифт было прекрасно видно, что в самом редакторе годота шрифт небольшой у меня стоит и он тоже нормально выглядит.
Я пробовал с разными настройками и все выглядит ужасно. Вот, для примера. Глаза от этого болят, как по мне. Особенно с учетом того, что хотелось бы поменьше размер, так как текст не должен занимать слишком много места на экране. И я понимаю, если бы это вообще невозможно было реализовать, но что в проекте на 3.5 у меня прекрасно все работало из коробки и даже мелкий шрифт было прекрасно видно, что в самом редакторе годота шрифт небольшой у меня стоит и он тоже нормально выглядит.
>>08780
Как/где ты устанавливаешь вектор блендспейса?
Блендспейс - это интерполяция между указанными анимациями. Если тебе нужен плавный переход, то необходимо плавно менять вектор в блендспейсе.
Например, можно попробовать такое:
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-move-toward
Множитель по ощущениям подгонишь.
>>08794
Ты уверен, что блендспейс нужен?.. Не уверен, т.к. не делал сам, но такое можно стейт-машиной сделать. Переходам xfade_time ставишь около 0.1 секунды:
https://docs.godotengine.org/en/stable/classes/class_animationnodestatemachinetransition.html#class-animationnodestatemachinetransition-property-xfade-time
Почему я так думаю? Анимация "шаг вбок" сильно отличается от анимаций "шаг назад" и "шаг вперёд", поэтому смешивание сделает какую-то фигню, нет? Диагональное движение вообще странная штука... Обычно люди корпус разворачивают в направлении движения, т.к. это наиболее естественно. Шаг вбок и задом наперёд как-то попроще, чем по диагоналям.
Но, дело твоё. Я видел модельки, где есть анимации диагонального движения. Лично предпочитаю, чтоб персонаж всегда ходил лицом/корпусом вперёд...
>как в бленд спейс 2д сделать плавный переход
Как/где ты устанавливаешь вектор блендспейса?
Блендспейс - это интерполяция между указанными анимациями. Если тебе нужен плавный переход, то необходимо плавно менять вектор в блендспейсе.
Например, можно попробовать такое:
>vec = vec.move_toward(vec_target, speed × delta)
https://docs.godotengine.org/en/stable/classes/class_vector2.html#class-vector2-method-move-toward
Множитель по ощущениям подгонишь.
>>08794
>несколько направлений движения ногами
Ты уверен, что блендспейс нужен?.. Не уверен, т.к. не делал сам, но такое можно стейт-машиной сделать. Переходам xfade_time ставишь около 0.1 секунды:
https://docs.godotengine.org/en/stable/classes/class_animationnodestatemachinetransition.html#class-animationnodestatemachinetransition-property-xfade-time
Почему я так думаю? Анимация "шаг вбок" сильно отличается от анимаций "шаг назад" и "шаг вперёд", поэтому смешивание сделает какую-то фигню, нет? Диагональное движение вообще странная штука... Обычно люди корпус разворачивают в направлении движения, т.к. это наиболее естественно. Шаг вбок и задом наперёд как-то попроще, чем по диагоналям.
Но, дело твоё. Я видел модельки, где есть анимации диагонального движения. Лично предпочитаю, чтоб персонаж всегда ходил лицом/корпусом вперёд...
>>08810
Что-то не вижу проблемы на твоём скриншоте.
Может, у тебя в настройках проекта зум установлен? Сглаживание не должно бросаться в глаза без зума. Тестируешь на своём старом проекте или на пустом?
Попробуй другие шрифты. Я как-то даже не заметил разницы в шрифтах после перехода и переноса всех старых проектов с 3.x на 4.x, но использую какой-то кастомный шрифт от гугла и люблю обводку. ИМХО, размер в 8 пикселей неиграбелен, я меньше 16 не использую во всех основных надписях, но у меня близорукость и разрешение монитора маленькое.
В принципе, в Godot можно вынести размер шрифта в настройки игры, если кому-то слишком "мыльно".
Что-то не вижу проблемы на твоём скриншоте.
Может, у тебя в настройках проекта зум установлен? Сглаживание не должно бросаться в глаза без зума. Тестируешь на своём старом проекте или на пустом?
Попробуй другие шрифты. Я как-то даже не заметил разницы в шрифтах после перехода и переноса всех старых проектов с 3.x на 4.x, но использую какой-то кастомный шрифт от гугла и люблю обводку. ИМХО, размер в 8 пикселей неиграбелен, я меньше 16 не использую во всех основных надписях, но у меня близорукость и разрешение монитора маленькое.
В принципе, в Godot можно вынести размер шрифта в настройки игры, если кому-то слишком "мыльно".
А, погоди, >>08781
Ты типа надписи через scale увеличиваешь?
Суть в том, что заданный тобой размер - это размер рендеринга в текстуру. Если ты меняешь scale (или приближаешь камеру), ты просто растягиваешь эту текстуру, не вызывая отрисовку букв заново.
Я уже не помню, что там было в 3.x, но если во время масштабирования через scale все буквы оставались чёткими, тогда это значит, что они все рендерились индивидуально, а не как растягиваемая текстура.
Если тебе нужно растягивать надписи, варианта два:
1. Ставить большой размер и уменьшать масштаб.
2. Увеличивать размер в зависимости от масштаба.
Что-то похожее происходит с Label3D, только в 3D. Аналогично - когда рендеришь GUI в SubViewport.
>нормально выглядеть и масштабироваться
Ты типа надписи через scale увеличиваешь?
Суть в том, что заданный тобой размер - это размер рендеринга в текстуру. Если ты меняешь scale (или приближаешь камеру), ты просто растягиваешь эту текстуру, не вызывая отрисовку букв заново.
Я уже не помню, что там было в 3.x, но если во время масштабирования через scale все буквы оставались чёткими, тогда это значит, что они все рендерились индивидуально, а не как растягиваемая текстура.
Если тебе нужно растягивать надписи, варианта два:
1. Ставить большой размер и уменьшать масштаб.
2. Увеличивать размер в зависимости от масштаба.
Что-то похожее происходит с Label3D, только в 3D. Аналогично - когда рендеришь GUI в SubViewport.
>>08824
Да я просто даже смотрю на image.png, написанное над скрином и то, что на скрине и прям вижу насколько текст в игре плохо смотрится. Сравниваю со старым проектом и вижу насколько он хуже.
Лейблы в CanvasLayer, так что камера влиять не должна.
На новом.
Если использовать 16, то текст подсказки получится на пол экрана. Не, может нужно было изначально делать пиксельную игрушку в 4к Видимо, Хуан решил, что игры в меньшем разрешении не должны существовать.
>>08826
Вот запускаю текст проекта и монитор сразу ухудщается.
>>08828
Нет, у меня изначально разрешение маленькое Что даже в документации годота советуется для пиксельный игр., а потом сам годот масштабирует. Пробовал и canvas items режим и 2d, все фигня.
>Что-то не вижу проблемы на твоём скриншоте.
Да я просто даже смотрю на image.png, написанное над скрином и то, что на скрине и прям вижу насколько текст в игре плохо смотрится. Сравниваю со старым проектом и вижу насколько он хуже.
>Может, у тебя в настройках проекта зум установлен?
Лейблы в CanvasLayer, так что камера влиять не должна.
>Тестируешь на своём старом проекте или на пустом?
На новом.
>ИМХО, размер в 8 пикселей неиграбелен, я меньше 16 не использую во всех основных надписях, но у меня близорукость и разрешение монитора маленькое.
Если использовать 16, то текст подсказки получится на пол экрана. Не, может нужно было изначально делать пиксельную игрушку в 4к Видимо, Хуан решил, что игры в меньшем разрешении не должны существовать.
>>08826
Вот запускаю текст проекта и монитор сразу ухудщается.
>>08828
>Ты типа надписи через scale увеличиваешь?
Нет, у меня изначально разрешение маленькое Что даже в документации годота советуется для пиксельный игр., а потом сам годот масштабирует. Пробовал и canvas items режим и 2d, все фигня.
>>08776
Сцены & ноды. Например, CollisionShape используется одновременно во всех потомках CollisionObject. А вот Container работает с любыми потомками Control. И т.д. Англоговорящие часто говорят "the Godot way".
Понятно, что принципы применимы к любому движку, просто хотелось бы удобство в редакторе сцен Godot.
Ну, хорошо, компонент-состояние:
Какая разница, как это называть? Он должен как-то обрабатывать движение. Универсально для всех возможных персонажей в одной категории. Другие компоненты-состояния не должны о нём знать.
Я знаю про композицию в ООП больше ~15 лет. Тут проблема в том, что компоненты не должны никого трогать, как, например, Control-ноды в Container не прикасаются к коду своих соседей, чтобы работать.
Если компоненты связаны, то их нельзя свободно передвигать в сцене, делать производные сцены.
Вообще, речь идёт об агрегации, но этот термин, к сожалению, редко упоминается. Ноды в сцене - в большинстве случаев агрегация, т.к. мы их часто перемещаем с места на место, добавляем/удаляем, особенно в редакторе, но также часто и в рантайме. Буквально основа всего в Godot, если ты ноды не используешь - считай, не используешь Godot...
Мы говорим про ноды в сценах - их можно удалять, перемещать и добавлять новые даже в рантайме.
Да, вот поэтому я и пытаюсь разделить код на индивидуальные состояния, но сделать это так, чтоб будущие классы-потомки или очень похожие на них использовали тот же код, что предки/другие классы.
У меня огромный скрипт в CharacterBody, я пытаюсь разрезать его так, чтоб было просто и понятно, но не выходит сделать это масштабируемо (чтоб не делать копипасту в сцены других, будущих персонажей).
Наверное, проще всего было бы забить на это. Но большая проблема в том, что Godot не даёт простого способа создать наследственную связь между уже существующими сценами. Опять всё переделывать...
Короче, ладно. Я понял - придётся лапшу навернуть.
>Что такое "стиль Godot"?
Сцены & ноды. Например, CollisionShape используется одновременно во всех потомках CollisionObject. А вот Container работает с любыми потомками Control. И т.д. Англоговорящие часто говорят "the Godot way".
Понятно, что принципы применимы к любому движку, просто хотелось бы удобство в редакторе сцен Godot.
>компонент, не состояние
Ну, хорошо, компонент-состояние:
>Movement: StateComponent
Какая разница, как это называть? Он должен как-то обрабатывать движение. Универсально для всех возможных персонажей в одной категории. Другие компоненты-состояния не должны о нём знать.
>Композиция. Выше прислали три видео
Я знаю про композицию в ООП больше ~15 лет. Тут проблема в том, что компоненты не должны никого трогать, как, например, Control-ноды в Container не прикасаются к коду своих соседей, чтобы работать.
Если компоненты связаны, то их нельзя свободно передвигать в сцене, делать производные сцены.
Вообще, речь идёт об агрегации, но этот термин, к сожалению, редко упоминается. Ноды в сцене - в большинстве случаев агрегация, т.к. мы их часто перемещаем с места на место, добавляем/удаляем, особенно в редакторе, но также часто и в рантайме. Буквально основа всего в Godot, если ты ноды не используешь - считай, не используешь Godot...
>позже его удалить нельзя, поскольку связь с компонентом лежит в определении класса
Мы говорим про ноды в сценах - их можно удалять, перемещать и добавлять новые даже в рантайме.
>Тебе нужна композиция
Да, вот поэтому я и пытаюсь разделить код на индивидуальные состояния, но сделать это так, чтоб будущие классы-потомки или очень похожие на них использовали тот же код, что предки/другие классы.
У меня огромный скрипт в CharacterBody, я пытаюсь разрезать его так, чтоб было просто и понятно, но не выходит сделать это масштабируемо (чтоб не делать копипасту в сцены других, будущих персонажей).
Наверное, проще всего было бы забить на это. Но большая проблема в том, что Godot не даёт простого способа создать наследственную связь между уже существующими сценами. Опять всё переделывать...
Короче, ладно. Я понял - придётся лапшу навернуть.
>>08776
Сцены & ноды. Например, CollisionShape используется одновременно во всех потомках CollisionObject. А вот Container работает с любыми потомками Control. И т.д. Англоговорящие часто говорят "the Godot way".
Понятно, что принципы применимы к любому движку, просто хотелось бы удобство в редакторе сцен Godot.
Ну, хорошо, компонент-состояние:
Какая разница, как это называть? Он должен как-то обрабатывать движение. Универсально для всех возможных персонажей в одной категории. Другие компоненты-состояния не должны о нём знать.
Я знаю про композицию в ООП больше ~15 лет. Тут проблема в том, что компоненты не должны никого трогать, как, например, Control-ноды в Container не прикасаются к коду своих соседей, чтобы работать.
Если компоненты связаны, то их нельзя свободно передвигать в сцене, делать производные сцены.
Вообще, речь идёт об агрегации, но этот термин, к сожалению, редко упоминается. Ноды в сцене - в большинстве случаев агрегация, т.к. мы их часто перемещаем с места на место, добавляем/удаляем, особенно в редакторе, но также часто и в рантайме. Буквально основа всего в Godot, если ты ноды не используешь - считай, не используешь Godot...
Мы говорим про ноды в сценах - их можно удалять, перемещать и добавлять новые даже в рантайме.
Да, вот поэтому я и пытаюсь разделить код на индивидуальные состояния, но сделать это так, чтоб будущие классы-потомки или очень похожие на них использовали тот же код, что предки/другие классы.
У меня огромный скрипт в CharacterBody, я пытаюсь разрезать его так, чтоб было просто и понятно, но не выходит сделать это масштабируемо (чтоб не делать копипасту в сцены других, будущих персонажей).
Наверное, проще всего было бы забить на это. Но большая проблема в том, что Godot не даёт простого способа создать наследственную связь между уже существующими сценами. Опять всё переделывать...
Короче, ладно. Я понял - придётся лапшу навернуть.
>Что такое "стиль Godot"?
Сцены & ноды. Например, CollisionShape используется одновременно во всех потомках CollisionObject. А вот Container работает с любыми потомками Control. И т.д. Англоговорящие часто говорят "the Godot way".
Понятно, что принципы применимы к любому движку, просто хотелось бы удобство в редакторе сцен Godot.
>компонент, не состояние
Ну, хорошо, компонент-состояние:
>Movement: StateComponent
Какая разница, как это называть? Он должен как-то обрабатывать движение. Универсально для всех возможных персонажей в одной категории. Другие компоненты-состояния не должны о нём знать.
>Композиция. Выше прислали три видео
Я знаю про композицию в ООП больше ~15 лет. Тут проблема в том, что компоненты не должны никого трогать, как, например, Control-ноды в Container не прикасаются к коду своих соседей, чтобы работать.
Если компоненты связаны, то их нельзя свободно передвигать в сцене, делать производные сцены.
Вообще, речь идёт об агрегации, но этот термин, к сожалению, редко упоминается. Ноды в сцене - в большинстве случаев агрегация, т.к. мы их часто перемещаем с места на место, добавляем/удаляем, особенно в редакторе, но также часто и в рантайме. Буквально основа всего в Godot, если ты ноды не используешь - считай, не используешь Godot...
>позже его удалить нельзя, поскольку связь с компонентом лежит в определении класса
Мы говорим про ноды в сценах - их можно удалять, перемещать и добавлять новые даже в рантайме.
>Тебе нужна композиция
Да, вот поэтому я и пытаюсь разделить код на индивидуальные состояния, но сделать это так, чтоб будущие классы-потомки или очень похожие на них использовали тот же код, что предки/другие классы.
У меня огромный скрипт в CharacterBody, я пытаюсь разрезать его так, чтоб было просто и понятно, но не выходит сделать это масштабируемо (чтоб не делать копипасту в сцены других, будущих персонажей).
Наверное, проще всего было бы забить на это. Но большая проблема в том, что Godot не даёт простого способа создать наследственную связь между уже существующими сценами. Опять всё переделывать...
Короче, ладно. Я понял - придётся лапшу навернуть.
>>08840
Я хрен его знает, как он это делает, я просто выставлял параметры scratch в настройках проекта. Поле scale в нодах не трогал. Единственное, что я хочу, так это вернуть отображение текста, как было в 3.5
Я хрен его знает, как он это делает, я просто выставлял параметры scratch в настройках проекта. Поле scale в нодах не трогал. Единственное, что я хочу, так это вернуть отображение текста, как было в 3.5
>>08830
Эээ... Так бы и говорил сразу, что пиксель-арт.
Встроенный шрифт и 99% свободно доступных - не предназначены для пиксель-арт игр. Если нужен пиксельный шрифт, ищи "pixel art font". Потом уже отключаешь интерполяцию (nearest neighbor filter).
Anti-aliasing пробовал отключать? По идее, должно пикселизировать любой векторный шрифт... Но вот результат будет оставлять желать лучшего, если сравнивать со специальными шрифтами.
>пиксельную игрушку
>потом сам годот масштабирует
Эээ... Так бы и говорил сразу, что пиксель-арт.
Встроенный шрифт и 99% свободно доступных - не предназначены для пиксель-арт игр. Если нужен пиксельный шрифт, ищи "pixel art font". Потом уже отключаешь интерполяцию (nearest neighbor filter).
Anti-aliasing пробовал отключать? По идее, должно пикселизировать любой векторный шрифт... Но вот результат будет оставлять желать лучшего, если сравнивать со специальными шрифтами.
>>08850
Да мне не обязательно стилизованный пиксельный шрифт, мне главное, чтоб он красиво отображался, пусть и весь сглаженный. Вот даже слева сбоку посмотри, если с компа, на ссылки на разделы. Небольшие и при этом текст смотрится хорошо, а в годоте прям глаза вытекают.
Да мне не обязательно стилизованный пиксельный шрифт, мне главное, чтоб он красиво отображался, пусть и весь сглаженный. Вот даже слева сбоку посмотри, если с компа, на ссылки на разделы. Небольшие и при этом текст смотрится хорошо, а в годоте прям глаза вытекают.
>>08854
В трёшке шрифт рендерился непрерывно, выглядел красиво, но при этом нагружал проц. Теперь шрифт рендерится один раз. Тебе об этом выше написали. Там же предложили варианты решения.
Хуле ты продолжаешь срать в тред движкосрачем про плохие-шревты-глоза-вытикают? Ёбом токнуть? Свали нахуй в движкосрач-тред и жалуйся там на шревты, скот движкосрачерский, блять.
В трёшке шрифт рендерился непрерывно, выглядел красиво, но при этом нагружал проц. Теперь шрифт рендерится один раз. Тебе об этом выше написали. Там же предложили варианты решения.
Хуле ты продолжаешь срать в тред движкосрачем про плохие-шревты-глоза-вытикают? Ёбом токнуть? Свали нахуй в движкосрач-тред и жалуйся там на шревты, скот движкосрачерский, блять.
34 Кб, 584x210>>08843
>Но большая проблема в том, что Godot не даёт простого способа создать наследственную связь между уже существующими сценами.
>>08858
Заебись, чо, испортили шрифты, молодцы.
Ничего не предложили способа, как сделать шрифт таким же.
Ты ебанулся? Какой нахуй движкосрач? Я хоть раз другой движок упоминал? Или это тред для вылизывания очка Хуану? Так и написали бы в шапке тогда, а то Godot-тредом назвались.
>В трёшке шрифт рендерился непрерывно, выглядел красиво, но при этом нагружал проц. Теперь шрифт рендерится один раз.
Заебись, чо, испортили шрифты, молодцы.
>Там же предложили варианты решения
Ничего не предложили способа, как сделать шрифт таким же.
>Хуле ты продолжаешь срать в тред движкосрачем про плохие-шревты-глоза-вытикают? Ёбом токнуть? Свали нахуй в движкосрач-тред и жалуйся там на шревты, скот движкосрачерский, блять.
Ты ебанулся? Какой нахуй движкосрач? Я хоть раз другой движок упоминал? Или это тред для вылизывания очка Хуану? Так и написали бы в шапке тогда, а то Godot-тредом назвались.
>>08861
Ну так там и есть с использованием разных фильтров. А примечание дает ответ на то "почему так всрато", а не как сделать так же круто, как было раньше.
Ну так там и есть с использованием разных фильтров. А примечание дает ответ на то "почему так всрато", а не как сделать так же круто, как было раньше.
>>08863
Вот скрин шрифта 16 px. И с ним все в порядке.
А то, что ты показываешь ,это если ноде scale увеличить в 4 раза.
А вот то же самое, сделанное без scale, но через font override font size.
А вот например с scale 4x, но включенным в настройках проекта Multichannel SDF rendering
Просто берешь и работаешь, берешь и разбираешься, перебираешь все опции пока не подберешь нужные. В чем проблема? Это заняло 5 минут.
Вот скрин шрифта 16 px. И с ним все в порядке.
А то, что ты показываешь ,это если ноде scale увеличить в 4 раза.
А вот то же самое, сделанное без scale, но через font override font size.
А вот например с scale 4x, но включенным в настройках проекта Multichannel SDF rendering
Просто берешь и работаешь, берешь и разбираешься, перебираешь все опции пока не подберешь нужные. В чем проблема? Это заняло 5 минут.
>>08868
То есть, годот мне нагло пиздит, что у меня scale 1?
>А то, что ты показываешь ,это если ноде scale увеличить в 4 раза.
То есть, годот мне нагло пиздит, что у меня scale 1?
Я устал делать игру. Надо поспать. Доделаю - больше за такой скоп не возьмусь. Меньше надо.
>>08871
Не знаю, надо дальше копать.
1. Может быть у тебя этот контрол вложен в какую-то сцену, у которой есть scale? Т.е. scale достается в наследство каскадом
2. Увеличение на уровне ОС, например 125%, 150%? Для координации с ним в настройках проекта есть галочка DPI. Пик 2 если галочки нет, шрифт увеличился и подразмылся.
3. Увеличение всей игры через window - stretch?
Не знаю, надо дальше копать.
1. Может быть у тебя этот контрол вложен в какую-то сцену, у которой есть scale? Т.е. scale достается в наследство каскадом
2. Увеличение на уровне ОС, например 125%, 150%? Для координации с ним в настройках проекта есть галочка DPI. Пик 2 если галочки нет, шрифт увеличился и подразмылся.
3. Увеличение всей игры через window - stretch?
>>08811
Я впринципе понимал это да, но вот что где как использовать не мог понять.
Да, помогло, спасибо! Теперь поворачивает как нужно.
А у меня шаг в бок на данный момент не отличается от шага вперед, я просто низ тела разворачиваю через анимацию, поэтому на мой взгляд выглядит впринципе норм. Я просто до этого модельку без костей использовал, и разворачивал всё что нужно через код, а щас всё адаптирую под кости, и теперь это так просто не получается, поэтому через анимационное дерево всё делаю.
А так хз, я пока большинство нелепостей скидываю на свои кривые анимации, может если кто-то более рукастый ими займется, то не так коряво всё будет.
>Блендспейс - это интерполяция между указанными анимациями. Если тебе нужен плавный переход, то необходимо плавно менять вектор в блендспейсе.
Я впринципе понимал это да, но вот что где как использовать не мог понять.
>Например, можно попробовать такое:
>vec = vec.move_toward(vec_target, speed × delta)
Да, помогло, спасибо! Теперь поворачивает как нужно.
>Анимация "шаг вбок" сильно отличается от анимаций "шаг назад" и "шаг вперёд", поэтому смешивание сделает какую-то фигню, нет?
А у меня шаг в бок на данный момент не отличается от шага вперед, я просто низ тела разворачиваю через анимацию, поэтому на мой взгляд выглядит впринципе норм. Я просто до этого модельку без костей использовал, и разворачивал всё что нужно через код, а щас всё адаптирую под кости, и теперь это так просто не получается, поэтому через анимационное дерево всё делаю.
А так хз, я пока большинство нелепостей скидываю на свои кривые анимации, может если кто-то более рукастый ими займется, то не так коряво всё будет.
>>08894
Skeleton3D даёт вращать любые кости из кода...
Также в 4.4 добавили удобный модификатор:
https://docs.godotengine.org/en/latest/classes/class_lookatmodifier3d.html
Просто указываешь кость и направление.
Модификатор должен быть в потомках Skeleton3D.
Покажешь? Сложно что-то посоветовать без видео.
По моему опыту, лучше сразу чётко описать, что/как персонаж должен уметь делать, как реагировать на окружающую среду и т.д. Чтоб не переделывать.
Рекомендую разделить код физики и графики на полностью независимые ноды/скрипты. Так будет проще заменить модельку без изменения механик (ощущений от управления, взаимодействия).
>низ тела разворачиваю через анимацию
>разворачивал всё что нужно через код
Skeleton3D даёт вращать любые кости из кода...
Также в 4.4 добавили удобный модификатор:
https://docs.godotengine.org/en/latest/classes/class_lookatmodifier3d.html
Просто указываешь кость и направление.
Модификатор должен быть в потомках Skeleton3D.
>нелепостей скидываю на свои кривые анимации
Покажешь? Сложно что-то посоветовать без видео.
По моему опыту, лучше сразу чётко описать, что/как персонаж должен уметь делать, как реагировать на окружающую среду и т.д. Чтоб не переделывать.
Рекомендую разделить код физики и графики на полностью независимые ноды/скрипты. Так будет проще заменить модельку без изменения механик (ощущений от управления, взаимодействия).
14,2 Мб, mp4,1148x670, 1:01
>>08972
Я вот честно пытался с этим разобраться, но по итогу крутил саму кость, а не кость с моделькой, или вообще не получалось, не помню. В общем чет не получалось и решил скостылить доп анимы направлений и сгибаний спины и головы.
Да хз на самом деле что показывать, щас каких то прям артефактов меньше, с переходом на кости.
Вот этим как раз буду заниматься через недельку. Я хочу ещё расчлененку всунуть, не посоветуешь как её нужно делать? У меня типа в голове это представляется как отсоединять кости от игрока, и в целом игрока превращать в рагдолл. Но так смотрел всякие видео, там люди уменьшают руки и вроде спавнять отдельно конечности.
>Skeleton3D даёт вращать любые кости из кода...
Я вот честно пытался с этим разобраться, но по итогу крутил саму кость, а не кость с моделькой, или вообще не получалось, не помню. В общем чет не получалось и решил скостылить доп анимы направлений и сгибаний спины и головы.
>нелепостей скидываю на свои кривые анимации
>Покажешь? Сложно что-то посоветовать без видео.
Да хз на самом деле что показывать, щас каких то прям артефактов меньше, с переходом на кости.
>Рекомендую разделить код физики и графики на полностью независимые ноды/скрипты. Так будет проще заменить модельку без изменения механик (ощущений от управления, взаимодействия)
Вот этим как раз буду заниматься через недельку. Я хочу ещё расчлененку всунуть, не посоветуешь как её нужно делать? У меня типа в голове это представляется как отсоединять кости от игрока, и в целом игрока превращать в рагдолл. Но так смотрел всякие видео, там люди уменьшают руки и вроде спавнять отдельно конечности.
>>09003
Круто выглядит, видно что постарался с механиками. Это стилизация или плейсхолдер? Если персонаж так и должен выглядеть (стилизация), то всё нормально с анимациями - продолжай. Если же это плейсхолдер и ты хочешь что-то другое визуально (будешь менять меши), то зря не трать время на эту модель - потом придётся подгонять всё под новую, возможно, другим способом.
Для элементов уровня-прототипа и теста механик/анимаций рекомендую включить на материале для геометрии уровня (пол, стены, движущиеся платформы и т.д.) uv1_triplanar:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-uv1-triplanar
Тогда любые меши с этим материалом будут автоматически покрываться повторяющейся сеткой независимо от оригинальной UV развёртки (лучше всего работает для плоских поверхностей, параллельных двум осям координат). Вместо логотипа Godot лучше нарисовать или найти в интернете (ищи "prototype textures") сетку типа шахматной, с обозначением габаритов одной текстуры (по умолчанию у трипланарных текстур 1 повтор текстуры = 1 метр игрового пространстве, но это можно изменить с помощью uv1_scale).
С этим материалом можно лепить уровень из простых CSG-шейпов и намного легче оценивать масштаб объектов и анимации персонажа - в особенности если ты хочешь, чтобы персонаж не "скользил" ногами/руками во время действий, т.к. скольжение поперёк прямых линий на глаз легко заметить. Также включи тени - без них сложно оценить, когда ноги висят в воздухе (внезапно, это не так-то просто отрегулировать с базовым CharacterBody3D, или так было на старых версиях Godot).
У тебя персонаж из цельного меша или из нескольких отдельных? Выглядят как отдельные (такое часто встречалось в древних 3D играх, когда не хватало мощности анимировать цельный меш в реальном времени). Если это отдельные меши, тогда просто делай им MeshInstance3D.visible = false (или queue_free(), если не нужно пришивать оторванные конечности обратно) и создавай в их позиции RigidBody3D с копией меша (без костей/скелета). Отделять кости от Skeleton3D не нужно, масштабировать тоже ничего не нужно. С цельным мешем сложнее, см. дальше.
Это дешёвый трюк в случае, когда у тебя один цельный меш и ты не хочешь делать дополнительные. Вообще, когда меш цельный (современных персонажей стараются делать бесшовными, т.к. швы трудно аккуратно скрывать - чаще они засунуты под одежду), есть такие способы:
1. Скукожить (scale = Vector3.ZERO) кости конечности, чтобы она стала "невидимой". Самый примитивный способ, который ты видел в тех видео. Но результат оставляет желать лучшего, т.к. "разреза" совсем нет, больше похоже на жопку упакованной колбасы или сосиски, в буквальном смысле. Такое, возможно, делали в совсем древних играх, и встречается в инди-играх с примитивной графикой типа "сплошная заливка лоуполи".
2. Изначально подготовить несколько версий меша персонажа, по-разному нарезанных. Т.е. у тебя есть полностью здоровый персонаж, однорукий, безрукий, одноногий, безногий, quadruple_amputee и т.д. Аналогично мешам одежды (при кастомизации), все эти меши привязаны к одному скелету, загружены сразу и скрыты или подгружаются по необходимости. Отображаешь (или загружаешь) в зависимости от того, что персонажу отрезало, остальное просто скрываешь. Такое делали в некоторых ААА играх, и это самый простой способ с качественным видом разреза.
3. Резать меш программно. Есть несколько бесплатных плагинов для Godot, но я не рекомендую в это лезть - там сложные алгоритмы, много потенциальных проблем, и никто это нормально не поддерживает в опенсурсе - будешь сам ковыряться. Да ещё и этот меш потом нужно на скелет натянуть. Но, вроде, некоторые инди-игры пошли этим путём, т.к. он позволяет, в теории, резать что угодно и где угодно. Только картинка разреза будет, скорее всего, нереалистичной, в отличие от предыдущего варианта, где всё заранее нарисовано.
Ragdoll в Godot сделать можно, но это как-то сложно... Кто-то делал, но у меня не получилось. Лучше сразу переключайся на Jolt Physics - Godot Physics будет колбасить по всей сцене от малейшей ошибки (т.е. всегда). Главное правило при создании ragdoll - чем меньше костей имеют физику, тем лучше. Т.е. если есть отдельные кости на каждый палец - делаешь только одну физическую кость на всю ладонь, а пальцы следуют за ней. Есть ещё вариант сделать "active ragdoll" (а-ля Euphoria из GTA IV), но тебе он, наверное, не нужен, и он намного сложнее обычного, но на реддит я видел примеры на Godot, т.е. технических ограничений нет.
Круто выглядит, видно что постарался с механиками. Это стилизация или плейсхолдер? Если персонаж так и должен выглядеть (стилизация), то всё нормально с анимациями - продолжай. Если же это плейсхолдер и ты хочешь что-то другое визуально (будешь менять меши), то зря не трать время на эту модель - потом придётся подгонять всё под новую, возможно, другим способом.
Для элементов уровня-прототипа и теста механик/анимаций рекомендую включить на материале для геометрии уровня (пол, стены, движущиеся платформы и т.д.) uv1_triplanar:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-uv1-triplanar
Тогда любые меши с этим материалом будут автоматически покрываться повторяющейся сеткой независимо от оригинальной UV развёртки (лучше всего работает для плоских поверхностей, параллельных двум осям координат). Вместо логотипа Godot лучше нарисовать или найти в интернете (ищи "prototype textures") сетку типа шахматной, с обозначением габаритов одной текстуры (по умолчанию у трипланарных текстур 1 повтор текстуры = 1 метр игрового пространстве, но это можно изменить с помощью uv1_scale).
С этим материалом можно лепить уровень из простых CSG-шейпов и намного легче оценивать масштаб объектов и анимации персонажа - в особенности если ты хочешь, чтобы персонаж не "скользил" ногами/руками во время действий, т.к. скольжение поперёк прямых линий на глаз легко заметить. Также включи тени - без них сложно оценить, когда ноги висят в воздухе (внезапно, это не так-то просто отрегулировать с базовым CharacterBody3D, или так было на старых версиях Godot).
>Я хочу ещё расчлененку всунуть
>отсоединять кости от игрока
У тебя персонаж из цельного меша или из нескольких отдельных? Выглядят как отдельные (такое часто встречалось в древних 3D играх, когда не хватало мощности анимировать цельный меш в реальном времени). Если это отдельные меши, тогда просто делай им MeshInstance3D.visible = false (или queue_free(), если не нужно пришивать оторванные конечности обратно) и создавай в их позиции RigidBody3D с копией меша (без костей/скелета). Отделять кости от Skeleton3D не нужно, масштабировать тоже ничего не нужно. С цельным мешем сложнее, см. дальше.
>люди уменьшают руки
Это дешёвый трюк в случае, когда у тебя один цельный меш и ты не хочешь делать дополнительные. Вообще, когда меш цельный (современных персонажей стараются делать бесшовными, т.к. швы трудно аккуратно скрывать - чаще они засунуты под одежду), есть такие способы:
1. Скукожить (scale = Vector3.ZERO) кости конечности, чтобы она стала "невидимой". Самый примитивный способ, который ты видел в тех видео. Но результат оставляет желать лучшего, т.к. "разреза" совсем нет, больше похоже на жопку упакованной колбасы или сосиски, в буквальном смысле. Такое, возможно, делали в совсем древних играх, и встречается в инди-играх с примитивной графикой типа "сплошная заливка лоуполи".
2. Изначально подготовить несколько версий меша персонажа, по-разному нарезанных. Т.е. у тебя есть полностью здоровый персонаж, однорукий, безрукий, одноногий, безногий, quadruple_amputee и т.д. Аналогично мешам одежды (при кастомизации), все эти меши привязаны к одному скелету, загружены сразу и скрыты или подгружаются по необходимости. Отображаешь (или загружаешь) в зависимости от того, что персонажу отрезало, остальное просто скрываешь. Такое делали в некоторых ААА играх, и это самый простой способ с качественным видом разреза.
3. Резать меш программно. Есть несколько бесплатных плагинов для Godot, но я не рекомендую в это лезть - там сложные алгоритмы, много потенциальных проблем, и никто это нормально не поддерживает в опенсурсе - будешь сам ковыряться. Да ещё и этот меш потом нужно на скелет натянуть. Но, вроде, некоторые инди-игры пошли этим путём, т.к. он позволяет, в теории, резать что угодно и где угодно. Только картинка разреза будет, скорее всего, нереалистичной, в отличие от предыдущего варианта, где всё заранее нарисовано.
>игрока превращать в рагдолл
Ragdoll в Godot сделать можно, но это как-то сложно... Кто-то делал, но у меня не получилось. Лучше сразу переключайся на Jolt Physics - Godot Physics будет колбасить по всей сцене от малейшей ошибки (т.е. всегда). Главное правило при создании ragdoll - чем меньше костей имеют физику, тем лучше. Т.е. если есть отдельные кости на каждый палец - делаешь только одну физическую кость на всю ладонь, а пальцы следуют за ней. Есть ещё вариант сделать "active ragdoll" (а-ля Euphoria из GTA IV), но тебе он, наверное, не нужен, и он намного сложнее обычного, но на реддит я видел примеры на Godot, т.е. технических ограничений нет.
>>09003
Круто выглядит, видно что постарался с механиками. Это стилизация или плейсхолдер? Если персонаж так и должен выглядеть (стилизация), то всё нормально с анимациями - продолжай. Если же это плейсхолдер и ты хочешь что-то другое визуально (будешь менять меши), то зря не трать время на эту модель - потом придётся подгонять всё под новую, возможно, другим способом.
Для элементов уровня-прототипа и теста механик/анимаций рекомендую включить на материале для геометрии уровня (пол, стены, движущиеся платформы и т.д.) uv1_triplanar:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-uv1-triplanar
Тогда любые меши с этим материалом будут автоматически покрываться повторяющейся сеткой независимо от оригинальной UV развёртки (лучше всего работает для плоских поверхностей, параллельных двум осям координат). Вместо логотипа Godot лучше нарисовать или найти в интернете (ищи "prototype textures") сетку типа шахматной, с обозначением габаритов одной текстуры (по умолчанию у трипланарных текстур 1 повтор текстуры = 1 метр игрового пространстве, но это можно изменить с помощью uv1_scale).
С этим материалом можно лепить уровень из простых CSG-шейпов и намного легче оценивать масштаб объектов и анимации персонажа - в особенности если ты хочешь, чтобы персонаж не "скользил" ногами/руками во время действий, т.к. скольжение поперёк прямых линий на глаз легко заметить. Также включи тени - без них сложно оценить, когда ноги висят в воздухе (внезапно, это не так-то просто отрегулировать с базовым CharacterBody3D, или так было на старых версиях Godot).
У тебя персонаж из цельного меша или из нескольких отдельных? Выглядят как отдельные (такое часто встречалось в древних 3D играх, когда не хватало мощности анимировать цельный меш в реальном времени). Если это отдельные меши, тогда просто делай им MeshInstance3D.visible = false (или queue_free(), если не нужно пришивать оторванные конечности обратно) и создавай в их позиции RigidBody3D с копией меша (без костей/скелета). Отделять кости от Skeleton3D не нужно, масштабировать тоже ничего не нужно. С цельным мешем сложнее, см. дальше.
Это дешёвый трюк в случае, когда у тебя один цельный меш и ты не хочешь делать дополнительные. Вообще, когда меш цельный (современных персонажей стараются делать бесшовными, т.к. швы трудно аккуратно скрывать - чаще они засунуты под одежду), есть такие способы:
1. Скукожить (scale = Vector3.ZERO) кости конечности, чтобы она стала "невидимой". Самый примитивный способ, который ты видел в тех видео. Но результат оставляет желать лучшего, т.к. "разреза" совсем нет, больше похоже на жопку упакованной колбасы или сосиски, в буквальном смысле. Такое, возможно, делали в совсем древних играх, и встречается в инди-играх с примитивной графикой типа "сплошная заливка лоуполи".
2. Изначально подготовить несколько версий меша персонажа, по-разному нарезанных. Т.е. у тебя есть полностью здоровый персонаж, однорукий, безрукий, одноногий, безногий, quadruple_amputee и т.д. Аналогично мешам одежды (при кастомизации), все эти меши привязаны к одному скелету, загружены сразу и скрыты или подгружаются по необходимости. Отображаешь (или загружаешь) в зависимости от того, что персонажу отрезало, остальное просто скрываешь. Такое делали в некоторых ААА играх, и это самый простой способ с качественным видом разреза.
3. Резать меш программно. Есть несколько бесплатных плагинов для Godot, но я не рекомендую в это лезть - там сложные алгоритмы, много потенциальных проблем, и никто это нормально не поддерживает в опенсурсе - будешь сам ковыряться. Да ещё и этот меш потом нужно на скелет натянуть. Но, вроде, некоторые инди-игры пошли этим путём, т.к. он позволяет, в теории, резать что угодно и где угодно. Только картинка разреза будет, скорее всего, нереалистичной, в отличие от предыдущего варианта, где всё заранее нарисовано.
Ragdoll в Godot сделать можно, но это как-то сложно... Кто-то делал, но у меня не получилось. Лучше сразу переключайся на Jolt Physics - Godot Physics будет колбасить по всей сцене от малейшей ошибки (т.е. всегда). Главное правило при создании ragdoll - чем меньше костей имеют физику, тем лучше. Т.е. если есть отдельные кости на каждый палец - делаешь только одну физическую кость на всю ладонь, а пальцы следуют за ней. Есть ещё вариант сделать "active ragdoll" (а-ля Euphoria из GTA IV), но тебе он, наверное, не нужен, и он намного сложнее обычного, но на реддит я видел примеры на Godot, т.е. технических ограничений нет.
Круто выглядит, видно что постарался с механиками. Это стилизация или плейсхолдер? Если персонаж так и должен выглядеть (стилизация), то всё нормально с анимациями - продолжай. Если же это плейсхолдер и ты хочешь что-то другое визуально (будешь менять меши), то зря не трать время на эту модель - потом придётся подгонять всё под новую, возможно, другим способом.
Для элементов уровня-прототипа и теста механик/анимаций рекомендую включить на материале для геометрии уровня (пол, стены, движущиеся платформы и т.д.) uv1_triplanar:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-uv1-triplanar
Тогда любые меши с этим материалом будут автоматически покрываться повторяющейся сеткой независимо от оригинальной UV развёртки (лучше всего работает для плоских поверхностей, параллельных двум осям координат). Вместо логотипа Godot лучше нарисовать или найти в интернете (ищи "prototype textures") сетку типа шахматной, с обозначением габаритов одной текстуры (по умолчанию у трипланарных текстур 1 повтор текстуры = 1 метр игрового пространстве, но это можно изменить с помощью uv1_scale).
С этим материалом можно лепить уровень из простых CSG-шейпов и намного легче оценивать масштаб объектов и анимации персонажа - в особенности если ты хочешь, чтобы персонаж не "скользил" ногами/руками во время действий, т.к. скольжение поперёк прямых линий на глаз легко заметить. Также включи тени - без них сложно оценить, когда ноги висят в воздухе (внезапно, это не так-то просто отрегулировать с базовым CharacterBody3D, или так было на старых версиях Godot).
>Я хочу ещё расчлененку всунуть
>отсоединять кости от игрока
У тебя персонаж из цельного меша или из нескольких отдельных? Выглядят как отдельные (такое часто встречалось в древних 3D играх, когда не хватало мощности анимировать цельный меш в реальном времени). Если это отдельные меши, тогда просто делай им MeshInstance3D.visible = false (или queue_free(), если не нужно пришивать оторванные конечности обратно) и создавай в их позиции RigidBody3D с копией меша (без костей/скелета). Отделять кости от Skeleton3D не нужно, масштабировать тоже ничего не нужно. С цельным мешем сложнее, см. дальше.
>люди уменьшают руки
Это дешёвый трюк в случае, когда у тебя один цельный меш и ты не хочешь делать дополнительные. Вообще, когда меш цельный (современных персонажей стараются делать бесшовными, т.к. швы трудно аккуратно скрывать - чаще они засунуты под одежду), есть такие способы:
1. Скукожить (scale = Vector3.ZERO) кости конечности, чтобы она стала "невидимой". Самый примитивный способ, который ты видел в тех видео. Но результат оставляет желать лучшего, т.к. "разреза" совсем нет, больше похоже на жопку упакованной колбасы или сосиски, в буквальном смысле. Такое, возможно, делали в совсем древних играх, и встречается в инди-играх с примитивной графикой типа "сплошная заливка лоуполи".
2. Изначально подготовить несколько версий меша персонажа, по-разному нарезанных. Т.е. у тебя есть полностью здоровый персонаж, однорукий, безрукий, одноногий, безногий, quadruple_amputee и т.д. Аналогично мешам одежды (при кастомизации), все эти меши привязаны к одному скелету, загружены сразу и скрыты или подгружаются по необходимости. Отображаешь (или загружаешь) в зависимости от того, что персонажу отрезало, остальное просто скрываешь. Такое делали в некоторых ААА играх, и это самый простой способ с качественным видом разреза.
3. Резать меш программно. Есть несколько бесплатных плагинов для Godot, но я не рекомендую в это лезть - там сложные алгоритмы, много потенциальных проблем, и никто это нормально не поддерживает в опенсурсе - будешь сам ковыряться. Да ещё и этот меш потом нужно на скелет натянуть. Но, вроде, некоторые инди-игры пошли этим путём, т.к. он позволяет, в теории, резать что угодно и где угодно. Только картинка разреза будет, скорее всего, нереалистичной, в отличие от предыдущего варианта, где всё заранее нарисовано.
>игрока превращать в рагдолл
Ragdoll в Godot сделать можно, но это как-то сложно... Кто-то делал, но у меня не получилось. Лучше сразу переключайся на Jolt Physics - Godot Physics будет колбасить по всей сцене от малейшей ошибки (т.е. всегда). Главное правило при создании ragdoll - чем меньше костей имеют физику, тем лучше. Т.е. если есть отдельные кости на каждый палец - делаешь только одну физическую кость на всю ладонь, а пальцы следуют за ней. Есть ещё вариант сделать "active ragdoll" (а-ля Euphoria из GTA IV), но тебе он, наверное, не нужен, и он намного сложнее обычного, но на реддит я видел примеры на Godot, т.е. технических ограничений нет.
>>08906
Что за левый сайт, есть же оригинал?
Что за левый сайт, есть же оригинал?
Вышла вторая часть плагина для управления вводом
https://www.youtube.com/watch?v=lEBYnQC-vJw
Плагин промышленного класса, какая же годнота, охоспаде!
https://www.youtube.com/watch?v=lEBYnQC-vJw
Плагин промышленного класса, какая же годнота, охоспаде!
И вот еще вдогонку, выпало в рекомендациях, продвинутый уровень кодинга.
https://www.youtube.com/watch?v=PrCza2z0Log
https://www.youtube.com/watch?v=PrCza2z0Log
>>09210
Не согласен. Тулскрипты, паттернматчинг, типизация на типизации, нее, это не уровень вкатуна.
Не согласен. Тулскрипты, паттернматчинг, типизация на типизации, нее, это не уровень вкатуна.
>>09055
Пасиба
Плейсхолдер, в будущем когда база будет готова, думаю найду рукастого моделлера/аниматора. А так, по идее всунуть новую модель с изменными анимами не должно составить проблем
Пасиба за совет, сделал. Я чет даже не думал об этом
У меня в общем в этой версии с костями, цельный меш, поэтому буду хуй знает на самом деле, вариант:
Звучит довольно клево и просто. Можно было бы необычные разрезы в таком случае сделать, типа череп вертикально пополам отделить. В общем над ним подумаю.
Вот это кста изначально хотел всунуть, но не получилось ни с цельным мешом, ни с разделенными по частям мешами ну точнее с разделенными впринципе получилось, но настолько всрато выглядело, что ну нахер его. А с цельным мешом физика переставала работать. Если покопаться, может и вышло бы что, но я туп.
Есть такое, я чет пытался с ним что-то мутить, но всегда как-то всрато было. Но без него увы нельзя, стандарты игровой индустрии вынуждают.
Кстати да, я видел, выглядит клево, сейчас всунуть по идее должно быть проще, но да, не факт что оно вообще нужно
Спасибо в общем, буду думать и делать
>Круто выглядит, видно что постарался с механиками
Пасиба
>Это стилизация или плейсхолдер?
Плейсхолдер, в будущем когда база будет готова, думаю найду рукастого моделлера/аниматора. А так, по идее всунуть новую модель с изменными анимами не должно составить проблем
>Вместо логотипа Godot лучше нарисовать или найти в интернете (ищи "prototype textures") сетку типа шахматной, с обозначением габаритов одной текстуры (по умолчанию у трипланарных текстур 1 повтор текстуры = 1 метр игрового пространстве, но это можно изменить с помощью uv1_scale).
Пасиба за совет, сделал. Я чет даже не думал об этом
>У тебя персонаж из цельного меша или из нескольких отдельных?
У меня в общем в этой версии с костями, цельный меш, поэтому буду хуй знает на самом деле, вариант:
>Изначально подготовить несколько версий меша персонажа
Звучит довольно клево и просто. Можно было бы необычные разрезы в таком случае сделать, типа череп вертикально пополам отделить. В общем над ним подумаю.
>Резать меш программно
Вот это кста изначально хотел всунуть, но не получилось ни с цельным мешом, ни с разделенными по частям мешами ну точнее с разделенными впринципе получилось, но настолько всрато выглядело, что ну нахер его. А с цельным мешом физика переставала работать. Если покопаться, может и вышло бы что, но я туп.
>Ragdoll в Godot сделать можно, но это как-то сложно
Есть такое, я чет пытался с ним что-то мутить, но всегда как-то всрато было. Но без него увы нельзя, стандарты игровой индустрии вынуждают.
>Есть ещё вариант сделать "active ragdoll" (а-ля Euphoria из GTA IV)
Кстати да, я видел, выглядит клево, сейчас всунуть по идее должно быть проще, но да, не факт что оно вообще нужно
Спасибо в общем, буду думать и делать
>>09234
В таком случае либо найди модельку, максимально подходящую по стилю/внешности героя, либо нужно сфокусироваться на том, что не зависит от героя.
Проблемы будут, если скелет сильно изменится, а в анимации скелет должен примерно повторять меш. Измениться могут тайминги анимации, добавиться переходные анимации, если нужен реализм. Много подводных камней - и я об них споткнулся, только поверхностно изучая тему и пробуя на практике.
"Просто" с точки зрения кода, но контента придётся в несколько раз больше делать. В худшем случае будет двойка в степени числа разрезов, например, если 4 конечности, то это 16 состояний/мешей, с головой получается 32 состояния. Хочешь менять одежду? Умножаешь это число на число нарядов. И так для каждого врага. А под конец умножаешь всё это на стоимость разработки одной модели... Конечно же, оптимизировать можно, но становится очевидным, почему в ААА почти не бывает расчленёнки: дело не столько в рейтингах/запретах, сколько в стоимости.
Я не пытаюсь демотивировать. Такие оценки затрат производятся на стадии предпроизводства, чтоб не потратиться на заведомо нереализуемые задумки. Особенно важно рассчитывать силы, когда ты инди. Собираешься платить 3D моделлеру - сразу смотри примерные цены на рынке. Если хочешь бесплатно, учитывай, что энтузиазм у людей не бесконечный, и простому проекту больше людей захочет помочь.
Новички часто недооценивают задачи и/или сильно переоценивают собственные/чужие возможности, поэтому большинство инди-игр проваливается.
Ну и самое главное, нужно сравнивать стоимость разработки фичи с её действием на игровой опыт. Основные компоненты геймплея должны получить больше ресурсов, чем что-то второстепенное. Т.е. расчленёнка не должна перетягивать на себя 80% бюджета, если твоя игра не про мясника-людоеда (условно, конечно; речь в т.ч. про сеттинг, историю).
А с кем ты конкурировать собрался, примерно?
Ragdoll не так уж обязателен для большинства игр. Проблема в том, что если ты подражаешь крупным студиям, то и бюджет твой должен соответствовать. Бесплатный ragdoll из бесплатного движка точно не вытянет игру на уровень дорогого проекта.
В любом случае, удачи.
>Плейсхолдер
В таком случае либо найди модельку, максимально подходящую по стилю/внешности героя, либо нужно сфокусироваться на том, что не зависит от героя.
>всунуть новую модель с изменными анимами
Проблемы будут, если скелет сильно изменится, а в анимации скелет должен примерно повторять меш. Измениться могут тайминги анимации, добавиться переходные анимации, если нужен реализм. Много подводных камней - и я об них споткнулся, только поверхностно изучая тему и пробуя на практике.
>>несколько версий меша персонажа
>Звучит довольно клево и просто.
"Просто" с точки зрения кода, но контента придётся в несколько раз больше делать. В худшем случае будет двойка в степени числа разрезов, например, если 4 конечности, то это 16 состояний/мешей, с головой получается 32 состояния. Хочешь менять одежду? Умножаешь это число на число нарядов. И так для каждого врага. А под конец умножаешь всё это на стоимость разработки одной модели... Конечно же, оптимизировать можно, но становится очевидным, почему в ААА почти не бывает расчленёнки: дело не столько в рейтингах/запретах, сколько в стоимости.
Я не пытаюсь демотивировать. Такие оценки затрат производятся на стадии предпроизводства, чтоб не потратиться на заведомо нереализуемые задумки. Особенно важно рассчитывать силы, когда ты инди. Собираешься платить 3D моделлеру - сразу смотри примерные цены на рынке. Если хочешь бесплатно, учитывай, что энтузиазм у людей не бесконечный, и простому проекту больше людей захочет помочь.
Новички часто недооценивают задачи и/или сильно переоценивают собственные/чужие возможности, поэтому большинство инди-игр проваливается.
Ну и самое главное, нужно сравнивать стоимость разработки фичи с её действием на игровой опыт. Основные компоненты геймплея должны получить больше ресурсов, чем что-то второстепенное. Т.е. расчленёнка не должна перетягивать на себя 80% бюджета, если твоя игра не про мясника-людоеда (условно, конечно; речь в т.ч. про сеттинг, историю).
>>ragdoll
>стандарты игровой индустрии вынуждают
А с кем ты конкурировать собрался, примерно?
Ragdoll не так уж обязателен для большинства игр. Проблема в том, что если ты подражаешь крупным студиям, то и бюджет твой должен соответствовать. Бесплатный ragdoll из бесплатного движка точно не вытянет игру на уровень дорогого проекта.
В любом случае, удачи.
>>09234
В таком случае либо найди модельку, максимально подходящую по стилю/внешности героя, либо нужно сфокусироваться на том, что не зависит от героя.
Проблемы будут, если скелет сильно изменится, а в анимации скелет должен примерно повторять меш. Измениться могут тайминги анимации, добавиться переходные анимации, если нужен реализм. Много подводных камней - и я об них споткнулся, только поверхностно изучая тему и пробуя на практике.
"Просто" с точки зрения кода, но контента придётся в несколько раз больше делать. В худшем случае будет двойка в степени числа разрезов, например, если 4 конечности, то это 16 состояний/мешей, с головой получается 32 состояния. Хочешь менять одежду? Умножаешь это число на число нарядов. И так для каждого врага. А под конец умножаешь всё это на стоимость разработки одной модели... Конечно же, оптимизировать можно, но становится очевидным, почему в ААА почти не бывает расчленёнки: дело не столько в рейтингах/запретах, сколько в стоимости.
Я не пытаюсь демотивировать. Такие оценки затрат производятся на стадии предпроизводства, чтоб не потратиться на заведомо нереализуемые задумки. Особенно важно рассчитывать силы, когда ты инди. Собираешься платить 3D моделлеру - сразу смотри примерные цены на рынке. Если хочешь бесплатно, учитывай, что энтузиазм у людей не бесконечный, и простому проекту больше людей захочет помочь.
Новички часто недооценивают задачи и/или сильно переоценивают собственные/чужие возможности, поэтому большинство инди-игр проваливается.
Ну и самое главное, нужно сравнивать стоимость разработки фичи с её действием на игровой опыт. Основные компоненты геймплея должны получить больше ресурсов, чем что-то второстепенное. Т.е. расчленёнка не должна перетягивать на себя 80% бюджета, если твоя игра не про мясника-людоеда (условно, конечно; речь в т.ч. про сеттинг, историю).
А с кем ты конкурировать собрался, примерно?
Ragdoll не так уж обязателен для большинства игр. Проблема в том, что если ты подражаешь крупным студиям, то и бюджет твой должен соответствовать. Бесплатный ragdoll из бесплатного движка точно не вытянет игру на уровень дорогого проекта.
В любом случае, удачи.
>Плейсхолдер
В таком случае либо найди модельку, максимально подходящую по стилю/внешности героя, либо нужно сфокусироваться на том, что не зависит от героя.
>всунуть новую модель с изменными анимами
Проблемы будут, если скелет сильно изменится, а в анимации скелет должен примерно повторять меш. Измениться могут тайминги анимации, добавиться переходные анимации, если нужен реализм. Много подводных камней - и я об них споткнулся, только поверхностно изучая тему и пробуя на практике.
>>несколько версий меша персонажа
>Звучит довольно клево и просто.
"Просто" с точки зрения кода, но контента придётся в несколько раз больше делать. В худшем случае будет двойка в степени числа разрезов, например, если 4 конечности, то это 16 состояний/мешей, с головой получается 32 состояния. Хочешь менять одежду? Умножаешь это число на число нарядов. И так для каждого врага. А под конец умножаешь всё это на стоимость разработки одной модели... Конечно же, оптимизировать можно, но становится очевидным, почему в ААА почти не бывает расчленёнки: дело не столько в рейтингах/запретах, сколько в стоимости.
Я не пытаюсь демотивировать. Такие оценки затрат производятся на стадии предпроизводства, чтоб не потратиться на заведомо нереализуемые задумки. Особенно важно рассчитывать силы, когда ты инди. Собираешься платить 3D моделлеру - сразу смотри примерные цены на рынке. Если хочешь бесплатно, учитывай, что энтузиазм у людей не бесконечный, и простому проекту больше людей захочет помочь.
Новички часто недооценивают задачи и/или сильно переоценивают собственные/чужие возможности, поэтому большинство инди-игр проваливается.
Ну и самое главное, нужно сравнивать стоимость разработки фичи с её действием на игровой опыт. Основные компоненты геймплея должны получить больше ресурсов, чем что-то второстепенное. Т.е. расчленёнка не должна перетягивать на себя 80% бюджета, если твоя игра не про мясника-людоеда (условно, конечно; речь в т.ч. про сеттинг, историю).
>>ragdoll
>стандарты игровой индустрии вынуждают
А с кем ты конкурировать собрался, примерно?
Ragdoll не так уж обязателен для большинства игр. Проблема в том, что если ты подражаешь крупным студиям, то и бюджет твой должен соответствовать. Бесплатный ragdoll из бесплатного движка точно не вытянет игру на уровень дорогого проекта.
В любом случае, удачи.
>>08892
Нет, так даже на новой сцене с одним контролом.
Галочка стоит
Да.
Хотя я уже сдался с этим вопросом.
>1. Может быть у тебя этот контрол вложен в какую-то сцену, у которой есть scale?
Нет, так даже на новой сцене с одним контролом.
>Пик 2 если галочки нет, шрифт увеличился и подразмылся.
Галочка стоит
>3. Увеличение всей игры через window - stretch?
Да.
Хотя я уже сдался с этим вопросом.
544 Кб, 1920x1080>>09250
По мне так есть 2 тру подхода.
1. Не пользоваться window stretch. Саму игру рисовать в лоу пиксельарте и увеличивать шейдером или масштабом вьюпорта. Поверх рисовать hd-шрифты.
2. Делать всю игру и шрифты пиксельные.
Судя по всему баг пока нерешенный https://github.com/godotengine/godot/issues/86563
Ленивый вариант - попробовать включить галочку SDF шрифтов. Но что то мне показалось что она при window stretch не помогла.
По мне так есть 2 тру подхода.
1. Не пользоваться window stretch. Саму игру рисовать в лоу пиксельарте и увеличивать шейдером или масштабом вьюпорта. Поверх рисовать hd-шрифты.
2. Делать всю игру и шрифты пиксельные.
Судя по всему баг пока нерешенный https://github.com/godotengine/godot/issues/86563
Ленивый вариант - попробовать включить галочку SDF шрифтов. Но что то мне показалось что она при window stretch не помогла.
745 Кб, 917x878Чел изучает годот микрозадачками https://quietgodot.itch.io/
Может кто найдет себе что полезное или вдохновится.
Может кто найдет себе что полезное или вдохновится.
410 Кб, 708x800Не движкосрач, почитайте картинки и комменты:
https://reddit.com/r/Unity3D/comments/1il6733/
А как вы управляетесь со "scene management"?
Я просто добавляю ноду в дерево, типа такого:
Сцена - это иллюзия...
https://reddit.com/r/Unity3D/comments/1il6733/
А как вы управляетесь со "scene management"?
Я просто добавляю ноду в дерево, типа такого:
>@export var world_scene: PackedScene
>add_child(world_scene.instantiate())
Сцена - это иллюзия...
Кстати про ноды. Если отфильтровать в дереве по имени, то перетаскивать ноды нельзя - в четверке это тоже так? А то я на тройке, понял что моя сцена распухла, начал упорядочивать и перетаскивать туда-сюда и оказывается при фильтре не перетаскивается ничего.
>>09434
Scene management в юнити - это вопрос в основном к тем, кто не использует zenject либо не пишет его аналог в виде глобального состояния живущего в notdestroy. Короче вопрос к гиперказуальщикам (и то не всем), к прототипистам и дебилам которые все ещё не поняли что нужно либо брать zenject либо рожать его аналог.
Scene management в юнити - это вопрос в основном к тем, кто не использует zenject либо не пишет его аналог в виде глобального состояния живущего в notdestroy. Короче вопрос к гиперказуальщикам (и то не всем), к прототипистам и дебилам которые все ещё не поняли что нужно либо брать zenject либо рожать его аналог.
Привет!
Скажите, ребята, игры на Годовом уже появились?
Интересует не кал шизофреников типа Cruelty Squad, а именно игры.
Скажите, ребята, игры на Годовом уже появились?
Интересует не кал шизофреников типа Cruelty Squad, а именно игры.
>>09457
Ну и зачем ты появился, чмонь?
Ну и зачем ты появился, чмонь?
Деды на ассемблерах в гаражах в метель-мороз игры хуярили, а вы на всем готовом ленитесь.
24 Кб, 318x195Тому, кто эту галочку по умолчанию включил в параметрах импорта 3д с анимациями, руки бы повыдирать. Целый день пытался разобраться, почему у меня одни анимации другие ломают.
>>09523
А как у тебя устроена анимация, что это повлияло? У меня обычно RESET = T-Pose и вроде этого хватает.
А как у тебя устроена анимация, что это повлияло? У меня обычно RESET = T-Pose и вроде этого хватает.
>>09529
Аддон GRT для блендера запекает с контрол рига на геймреди. Там каждый кадр каждой кости проставляется. Поломалось и с моим RESET-ом в том числе, который я каждый раз переимпортирую в годо, когда мне нужно обновить ресет блендшейпов. Эта галка просто большую часть каналов костей порезала.
Аддон GRT для блендера запекает с контрол рига на геймреди. Там каждый кадр каждой кости проставляется. Поломалось и с моим RESET-ом в том числе, который я каждый раз переимпортирую в годо, когда мне нужно обновить ресет блендшейпов. Эта галка просто большую часть каналов костей порезала.
RC2 вышел. Скоро релиз 4.4
Между тем чел сделал что-то лютое для шейдеров в Годоте. Настолько лютое, что я даже не очень понимаю, зачем оно нужно.
https://www.youtube.com/watch?v=5y1Oin7CcI4
https://www.youtube.com/watch?v=5y1Oin7CcI4
>>09749
Судя по всему, какой-то свой диалект opengl GLSL, с препроцессором для распараллеливания, хз.
Судя по всему, какой-то свой диалект opengl GLSL, с препроцессором для распараллеливания, хз.
>>09764
И не надо мне рассказывать, какой у тебя В2 инглиш. Есть здесь незаметный подвох, когда слушаешь слова, понимаешь слова, а общую суть не улавливаешь.
И не надо мне рассказывать, какой у тебя В2 инглиш. Есть здесь незаметный подвох, когда слушаешь слова, понимаешь слова, а общую суть не улавливаешь.
>>09445
Нельзя. Я на 99% уверен, что это осознанное решение: защита от дурака. Если ты фильтруешь дерево сцены, естественно, что оно огромное у тебя. Но если вдруг начинаешь двигать, можешь куда-то не туда кинуть. Замучаешься потом искать ошибки и исправлять их.
1. Объединяй похожие по смыслу/функции ноды под общим предком, даже если предок пока не требуется.
2. Декомпозиция: ПКМ > "Save Branch as Scene..." - помогает, даже если в этом нет необходимости.
3. Вместо "Editable Children", если часто используешь, создавай отдельную специально настроенную сцену; также добавляй параметры в @export главной ноды.
Честно, я за 5+ лет с Godot впервые попробовал эту фильтрацию дерева... Как-то не приходило в голову.
>перетаскивать ноды нельзя
Нельзя. Я на 99% уверен, что это осознанное решение: защита от дурака. Если ты фильтруешь дерево сцены, естественно, что оно огромное у тебя. Но если вдруг начинаешь двигать, можешь куда-то не туда кинуть. Замучаешься потом искать ошибки и исправлять их.
>понял что моя сцена распухла
1. Объединяй похожие по смыслу/функции ноды под общим предком, даже если предок пока не требуется.
2. Декомпозиция: ПКМ > "Save Branch as Scene..." - помогает, даже если в этом нет необходимости.
3. Вместо "Editable Children", если часто используешь, создавай отдельную специально настроенную сцену; также добавляй параметры в @export главной ноды.
Честно, я за 5+ лет с Godot впервые попробовал эту фильтрацию дерева... Как-то не приходило в голову.
>>09764
Ты потраченный, углепластик? Охлади трахание вниз.
>>09767
О да, конечно, а переводчик вообще без подвохов.
Учи мемы, идиомы, чтобы не быть баттхёртом.
"Идиома" - это, если что, не синоним "идиота":
https://ru.wiktionary.org/wiki/идиома
Пример. Читаю реддит, вижу: "out of left field". Чё?
Гугл: "из левого поля".
Дипл: "из левого поля".
Claude: "из левого поля".
Яндекс: "вне левого поля".
Охренеть, спасибо, молодцы, мы вам перезвоним.
https://en.wikipedia.org/wiki/Out_of_left_field
Справедливости ради, некоторые LLM понимают.
Яндекс вроде встроил в окно цитату из Википедии.
Т.е. хотите понимать факин инглиш - учите мемы.
Впрочем, это справедливо для любого языка...
>Юзай плагин нейроозвучки
Ты потраченный, углепластик? Охлади трахание вниз.
>>09767
>Есть здесь незаметный подвох
О да, конечно, а переводчик вообще без подвохов.
>понимаешь слова, а общую суть не улавливаешь
Учи мемы, идиомы, чтобы не быть баттхёртом.
"Идиома" - это, если что, не синоним "идиота":
https://ru.wiktionary.org/wiki/идиома
Пример. Читаю реддит, вижу: "out of left field". Чё?
Гугл: "из левого поля".
Дипл: "из левого поля".
Claude: "из левого поля".
Яндекс: "вне левого поля".
Охренеть, спасибо, молодцы, мы вам перезвоним.
https://en.wikipedia.org/wiki/Out_of_left_field
Справедливости ради, некоторые LLM понимают.
Яндекс вроде встроил в окно цитату из Википедии.
Т.е. хотите понимать факин инглиш - учите мемы.
Впрочем, это справедливо для любого языка...
>>09780
А нет, Яндекс тоже жиденько обосрамся с его LLM...
Но, хотя бы попытался. За попытку ставлю 3 из 5.
>Яндекс вроде встроил в окно цитату из Википедии.
А нет, Яндекс тоже жиденько обосрамся с его LLM...
Но, хотя бы попытался. За попытку ставлю 3 из 5.
>>09780
Нет ты, сладенький.
Нет. Выше чел не понял содержимое видеоролика. Я ради интереса включил нейроозвучку (которая не может в идиомы) и узнал, что чел на видео переходит с юнити на годот и запилил себе свою собственную реализацию высокоуровневого шейдерного языка, с транслятором в годотовы шейдеры и с менеджером который автоматически обновляет код и перекомпилирует, показал на видео как этот язык работает, сравнил с исходным и предложил кому надо юзать по ссылкам в описании.
Я это понял несмотря на то, что LLM не могут в идиомы, а анонимус выше этого не понял, несмотря на то, что он может в идиомы.
> Ты потраченный, углепластик?
Нет ты, сладенький.
> хотите понимать факин инглиш
Нет. Выше чел не понял содержимое видеоролика. Я ради интереса включил нейроозвучку (которая не может в идиомы) и узнал, что чел на видео переходит с юнити на годот и запилил себе свою собственную реализацию высокоуровневого шейдерного языка, с транслятором в годотовы шейдеры и с менеджером который автоматически обновляет код и перекомпилирует, показал на видео как этот язык работает, сравнил с исходным и предложил кому надо юзать по ссылкам в описании.
Я это понял несмотря на то, что LLM не могут в идиомы, а анонимус выше этого не понял, несмотря на то, что он может в идиомы.
>>09530
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_3d_scenes/import_configuration.html#using-the-import-dock
Зачем тебе значения по умолчанию в треках?
>>09523
Потому что не ставишь ключ в начале трека там, где необходимо вернуться в состояние по умолчанию? Соответственно, остаётся значение из предыдущей анимации, которая использовала этот трек...
Чтоб несколько анимаций можно было проигрывать одновременно, у тебя должны быть пустые треки на каждой анимации. Зачем устанавливать значения по умолчанию там, где анимация не нужна?
У AnimationTree есть опция для исключения влияния анимации на конкретные кости, но это геморрой... ПРОСТО не устанавливай значения по умолчанию в местах, которые ты никак не анимируешь, и всё.
Намёк на то, что твой пайплайн какой-то странный.
Какая-то старая васянка с итча. Хуан одобрил?
Специфичный вкус... И тебе такое нравится?
>большую часть каналов костей порезала
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_3d_scenes/import_configuration.html#using-the-import-dock
>Remove Immutable Tracks: Remove animation tracks that only contain default values. This can reduce output file size and memory usage with certain 3D scenes, depending on the contents of their animation tracks.
Зачем тебе значения по умолчанию в треках?
>>09523
>почему у меня одни анимации другие ломают
Потому что не ставишь ключ в начале трека там, где необходимо вернуться в состояние по умолчанию? Соответственно, остаётся значение из предыдущей анимации, которая использовала этот трек...
Чтоб несколько анимаций можно было проигрывать одновременно, у тебя должны быть пустые треки на каждой анимации. Зачем устанавливать значения по умолчанию там, где анимация не нужна?
У AnimationTree есть опция для исключения влияния анимации на конкретные кости, но это геморрой... ПРОСТО не устанавливай значения по умолчанию в местах, которые ты никак не анимируешь, и всё.
>кто эту галочку по умолчанию включил
Намёк на то, что твой пайплайн какой-то странный.
>Аддон GRT для блендера
Какая-то старая васянка с итча. Хуан одобрил?
>каждый кадр каждой кости проставляется
Специфичный вкус... И тебе такое нравится?
>>09749
>>09783
Ещё раз: конкретно зачем его велосипед нужен?
Что-то мешает выучить шейдерный язык Godot?
Я видео не смотрел, но по названию
Звучит так, будто это что-то для упрощения.
ИМХО, в юнити шейдеры намного сложнее...
>даже не очень понимаю, зачем оно нужно.
>>09783
>переходит с юнити на годот и запилил [велосипед]
Ещё раз: конкретно зачем его велосипед нужен?
Что-то мешает выучить шейдерный язык Godot?
Я видео не смотрел, но по названию
>How Game Engines Make Shaders Easy
Звучит так, будто это что-то для упрощения.
ИМХО, в юнити шейдеры намного сложнее...
>>09771
Слышал что в четверке фильтр еще покруче стал, не только по именам но и по данными ноды. А так да, разбиваю на подсцены, просто с фильтром это было бы удобнее.
Слышал что в четверке фильтр еще покруче стал, не только по именам но и по данными ноды. А так да, разбиваю на подсцены, просто с фильтром это было бы удобнее.
>>09788
У меня даже превьюшки не грузятся, а через прокси мучиться с погрузкой видео в 144p не хочу. Любимый скачиватель видео с ютуба тоже отвалился, видимо, из-за обновления API ютуба (они постоянно борятся с людьми, которые не хотят смотреть рекомендации и из-за них тратить весь день на бесполезные видео).
Алсо, видеотуториалы - говно. Если он там эту свою васянку куда-то выложил - постите сразу ссылку на васянку вместо тупого видео, где аффтар 15 минут мямлит что-то про жызнь тяжёлую, кота, жену и т.д.
Статью можно глазами пробежать, поняв примерно ценность и перейдя сразу к важному. Видео - нельзя, видеоформат - всегда кот в мешке, даже от хорошо известных каналов, которые регулярно сливаются.
Многие можно смотреть только на скорости x2~x4. Медленнее x1.5 начинаешь засыпать и забывать услышанное раньше, чем афтар закончит фразу.
>>09789
Я так понимаю: если это что-то высокоуровневое, то теоретически его можно было бы расширять всякой васянской спецификой, по типу визуальной лапши.
Но если это просто транспилер с юнити - не нужно.
У меня даже превьюшки не грузятся, а через прокси мучиться с погрузкой видео в 144p не хочу. Любимый скачиватель видео с ютуба тоже отвалился, видимо, из-за обновления API ютуба (они постоянно борятся с людьми, которые не хотят смотреть рекомендации и из-за них тратить весь день на бесполезные видео).
Алсо, видеотуториалы - говно. Если он там эту свою васянку куда-то выложил - постите сразу ссылку на васянку вместо тупого видео, где аффтар 15 минут мямлит что-то про жызнь тяжёлую, кота, жену и т.д.
Статью можно глазами пробежать, поняв примерно ценность и перейдя сразу к важному. Видео - нельзя, видеоформат - всегда кот в мешке, даже от хорошо известных каналов, которые регулярно сливаются.
Многие можно смотреть только на скорости x2~x4. Медленнее x1.5 начинаешь засыпать и забывать услышанное раньше, чем афтар закончит фразу.
>>09789
Я так понимаю: если это что-то высокоуровневое, то теоретически его можно было бы расширять всякой васянской спецификой, по типу визуальной лапши.
Но если это просто транспилер с юнити - не нужно.
>>09792
pip install --upgrade yt-dlp
>Любимый скачиватель видео с ютуба тоже отвалился, видимо, из-за обновления API ютуба
pip install --upgrade yt-dlp
>>09791
Подсказка предлагает по типам:
И по группам:
Например:
Базовые Node почему-то игнорирует (t:node).
Во-первых, меню ПКМ доступно как обычно.
Во-вторых:
1. Фильтруешь.
2. Выделяешь.
3. Ctrl+X.
4. Снимаешь фильтр.
5. Ctrl+V в нужном месте.
Я проверил (4.4) - вроде норм работает.
>по данными ноды
Подсказка предлагает по типам:
>type:
>t:
И по группам:
>group:
>g:
Например:
>t:control - потомки Control
>t:node2d - потомки Node2D
>t:node3d - потомки Node3D
Базовые Node почему-то игнорирует (t:node).
>просто с фильтром это было бы удобнее
Во-первых, меню ПКМ доступно как обычно.
Во-вторых:
1. Фильтруешь.
2. Выделяешь.
3. Ctrl+X.
4. Снимаешь фильтр.
5. Ctrl+V в нужном месте.
Я проверил (4.4) - вроде норм работает.
>>09785
Вот на секундочку просто имаджинируй, что Хуан с командой разрабов на (почти) одном энтузиазме могли где-то ошибиться. И подумай своей головой. Да, у меня странный пайплайн. Да, делаю RESET вручную. Странность в том, что галка обрезает большую часть ключей RESET "анимации", а какие-то оставляет. А ведь вообще все косточки в их стандартных положениях.
Я ставлю ключи для всех костей в начале и в конце для loop анимаций, а GRT их еще и на каждый кадр запекает. Без понятия, как годо принимает решение их зарезать как immutable.
Мне нужно, чтоб анимации ни в коем случае не смешивались. У меня вообще с этим в годо плохо, приходится еще на всякий случай на один кадр RESET запускать, чтоб все анимации и шейпы сбросить.
>Зачем
>Зачем
>Намёк
>васянка
>Хуан
Вот на секундочку просто имаджинируй, что Хуан с командой разрабов на (почти) одном энтузиазме могли где-то ошибиться. И подумай своей головой. Да, у меня странный пайплайн. Да, делаю RESET вручную. Странность в том, что галка обрезает большую часть ключей RESET "анимации", а какие-то оставляет. А ведь вообще все косточки в их стандартных положениях.
>Потому что не ставишь ключ в начале трека там, где необходимо вернуться в состояние по умолчанию?
Я ставлю ключи для всех костей в начале и в конце для loop анимаций, а GRT их еще и на каждый кадр запекает. Без понятия, как годо принимает решение их зарезать как immutable.
>Чтоб несколько анимаций можно было проигрывать одновременно
>Специфичный вкус... И тебе такое нравится?
>Зачем устанавливать значения по умолчанию там, где анимация не нужна?
Мне нужно, чтоб анимации ни в коем случае не смешивались. У меня вообще с этим в годо плохо, приходится еще на всякий случай на один кадр RESET запускать, чтоб все анимации и шейпы сбросить.
>>09858
Не понял, обрезает внутри RESET или снаружи него? Возможно, это баг/регрессия в движке? Анимацию с именем "reset" галочка, по идее, трогать не должна. Пробовал искать по issues на гитхабе подобное?
А вот интересно - зачем? Godot и без этого работает. Смотрел, GRT этот для множества движков. Может, подобное нужно для каких-то старых движков?
Пипец, какой-то огромный костыль. Не осуждаю, но пытаюсь разобраться, зачем тебе это нужно? Что ты анимируешь такое, что обязательно нужен RESET, но нельзя ничего совместить/смешать? Смешивание анимаций нужно для упрощения работы - вместо комбинированных анимаций у тебя компоненты, соединяющиеся в реальном времени. Т.е. отказ от смешивания увеличивает число ручных анимаций.
Сброс через RESET... Смотри, у тебя в AnimationTree конечный автомат должен быть, переключающий анимации полуавтоматически по запросу. RESET вставляешь между двумя состояниями автомата? Получается, у тебя резкие переходы между двумя анимациями? Иначе будет дёргать в Т-позу, лол. Из личного опыта, резкие переходы бросаются в глаза, выглядят неестественно. Лучше заюзать xfade_time.
>обрезает большую часть ключей RESET "анимации"
Не понял, обрезает внутри RESET или снаружи него? Возможно, это баг/регрессия в движке? Анимацию с именем "reset" галочка, по идее, трогать не должна. Пробовал искать по issues на гитхабе подобное?
>GRT их еще и на каждый кадр запекает
А вот интересно - зачем? Godot и без этого работает. Смотрел, GRT этот для множества движков. Может, подобное нужно для каких-то старых движков?
>анимации ни в коем случае не смешивались
>на всякий случай на один кадр RESET запускать
Пипец, какой-то огромный костыль. Не осуждаю, но пытаюсь разобраться, зачем тебе это нужно? Что ты анимируешь такое, что обязательно нужен RESET, но нельзя ничего совместить/смешать? Смешивание анимаций нужно для упрощения работы - вместо комбинированных анимаций у тебя компоненты, соединяющиеся в реальном времени. Т.е. отказ от смешивания увеличивает число ручных анимаций.
Сброс через RESET... Смотри, у тебя в AnimationTree конечный автомат должен быть, переключающий анимации полуавтоматически по запросу. RESET вставляешь между двумя состояниями автомата? Получается, у тебя резкие переходы между двумя анимациями? Иначе будет дёргать в Т-позу, лол. Из личного опыта, резкие переходы бросаются в глаза, выглядят неестественно. Лучше заюзать xfade_time.
>>09867
Нейронка выдала случайные числа, подходящие семантически под текст, а мясной мешок поверил.
LLM не имеют доступа к своей "training data", даже не получают все эти данные за один цикл обучения. Максимум что они знают - это "knowledge cutoff date", который им потом внушают/подставляют в промпт. Следовательно, у LLM нет технической возможности проанализировать соотношение каких-либо тем в собственном обучающем датасете. Почему нейронка отвечает так самоуверенно о том, чего не знает? А ей никто не запрещает так делать - так почему бы и нет? Популярные запросы корректируют через файнтюн и RLHF, но на какой-то там "Godot" 99.9999% населения Земли плевать, следовательно, нейронку никто не отучивает выдумывать бред на эту тему.
Алсо, LLM в любом случае будет выдавать тебе несуществующие API, если ты её не натаскиваешь специально на API Godot. Представь себе человека, обладающего знаниями по миллионам API, которые сильно похожи друг на друга, но всё же отличаются; ошибочные ответы неизбежны и Godot 3 не виноват.
Нейронка выдала случайные числа, подходящие семантически под текст, а мясной мешок поверил.
LLM не имеют доступа к своей "training data", даже не получают все эти данные за один цикл обучения. Максимум что они знают - это "knowledge cutoff date", который им потом внушают/подставляют в промпт. Следовательно, у LLM нет технической возможности проанализировать соотношение каких-либо тем в собственном обучающем датасете. Почему нейронка отвечает так самоуверенно о том, чего не знает? А ей никто не запрещает так делать - так почему бы и нет? Популярные запросы корректируют через файнтюн и RLHF, но на какой-то там "Godot" 99.9999% населения Земли плевать, следовательно, нейронку никто не отучивает выдумывать бред на эту тему.
Алсо, LLM в любом случае будет выдавать тебе несуществующие API, если ты её не натаскиваешь специально на API Godot. Представь себе человека, обладающего знаниями по миллионам API, которые сильно похожи друг на друга, но всё же отличаются; ошибочные ответы неизбежны и Godot 3 не виноват.
>>09961
Точнее, там в начале системного промпта прописано, что-то вроде инфы как когда ты комп включаешь, какая у тебя версия биос и какого года.
Точнее, там в начале системного промпта прописано, что-то вроде инфы как когда ты комп включаешь, какая у тебя версия биос и какого года.
>>09962 >>09963
Ты про RAG? Чтобы RAG мог ответить тебе на такой вопрос, где-то в данных должен лежать ответ или подсказка для ответа. Там может быть что-то типа:
RAG передаёт это LLM и LLM сочиняет ответ, рисуя циферки, примерно подходящие (70>30) под запрос.
Т.е. RAG не анализирует данные на реальное число вхождений какой-то информации, а отдаёт кусочки, тематически соответствующие заданному запросу.
Я это к тому, что это бестолковые числа. Ответ-то правильный, в теории, по Godot 3 больше всего (хотя сомнительно, т.к. движок стал популярнее после 4.0), только числа нейронка "для красоты" нарисовала.
Короч. Лучше не забивать себе голову процентами, спрашивать сразу по делу - "как сделать в Godot 4..." Получилось? Хорошо. Не получилось? Исправишь. Измерять отношение G3/G4 в нейронке глупо, если нейронка хорошо справляется с твоими задачами.
Лучше б принёс примеры кода на GDScript от неё.
Ты про RAG? Чтобы RAG мог ответить тебе на такой вопрос, где-то в данных должен лежать ответ или подсказка для ответа. Там может быть что-то типа:
>(Reddit) Насколько хороши LLM для Godot?
>(Ответ) Godot 3 хорошо знают, а Godot 4 плохо...
RAG передаёт это LLM и LLM сочиняет ответ, рисуя циферки, примерно подходящие (70>30) под запрос.
Т.е. RAG не анализирует данные на реальное число вхождений какой-то информации, а отдаёт кусочки, тематически соответствующие заданному запросу.
Я это к тому, что это бестолковые числа. Ответ-то правильный, в теории, по Godot 3 больше всего (хотя сомнительно, т.к. движок стал популярнее после 4.0), только числа нейронка "для красоты" нарисовала.
Короч. Лучше не забивать себе голову процентами, спрашивать сразу по делу - "как сделать в Godot 4..." Получилось? Хорошо. Не получилось? Исправишь. Измерять отношение G3/G4 в нейронке глупо, если нейронка хорошо справляется с твоими задачами.
Лучше б принёс примеры кода на GDScript от неё.
Ебаный скоп
>>09972
Кранчей легко избежать. Нет дедлайна - нет и кранча. Компании просто ставят невыполнимые дедлайны и требуют сделать игру чётко к сроку. Отсюда кранч. У индюшек кранч бывает только из-за шизы, т.е. бреда величия, когда индюк воображает себя ААА студией, набирает непосильных задач и ставит себе дедлайн.
Рейтинги низкие часто из-за обманутых ожиданий: маркетинг неправильный; наобещали и не сделали; выглядит красиво, но играется отвратно; свою ЦА игнорируют, пытаясь изобретать велосипед в уже устоявшемся жанре и т.п. Нужно быть скромным, прислушиваться к ЦА и полировать игру до блеска.
А критику/угрозы от школоты можно игнорировать. Хейтеры на что угодно найдутся, также, как и фаны. Единственное, что нужно иметь в виду - фанат может конвертироваться в хейтера, если ты обманываешь ожидания, см. предыдущий пункт. Яндередева так загнобили банально из-за того, что он сильно тянул с разработкой, наобещав кучу всего. Если б он осилил доставить обещанное, или не обещал лишнего, то на персональные качества всем было бы плевать.
Суммируя:
1. Трезво оценивай свои возможности.
2. Найди, изучай и слушай только свою ЦА.
3. Не обещай того, в чём ты не разбираешься.
4. Полируй техническую часть не хуже графики.
>>10019
Квартплату, еду и интернет ты не учитываешь? Игра "выйдет в плюс", только если принесёт тебе больше суммарной зарплаты за всё время разработки. Т.е. заработать $1000 за игру, что делал год по 8 часов каждый день - полный провал, т.к. это з/п за месяц грузчиком в не самом большом городе.
Кранчей легко избежать. Нет дедлайна - нет и кранча. Компании просто ставят невыполнимые дедлайны и требуют сделать игру чётко к сроку. Отсюда кранч. У индюшек кранч бывает только из-за шизы, т.е. бреда величия, когда индюк воображает себя ААА студией, набирает непосильных задач и ставит себе дедлайн.
Рейтинги низкие часто из-за обманутых ожиданий: маркетинг неправильный; наобещали и не сделали; выглядит красиво, но играется отвратно; свою ЦА игнорируют, пытаясь изобретать велосипед в уже устоявшемся жанре и т.п. Нужно быть скромным, прислушиваться к ЦА и полировать игру до блеска.
А критику/угрозы от школоты можно игнорировать. Хейтеры на что угодно найдутся, также, как и фаны. Единственное, что нужно иметь в виду - фанат может конвертироваться в хейтера, если ты обманываешь ожидания, см. предыдущий пункт. Яндередева так загнобили банально из-за того, что он сильно тянул с разработкой, наобещав кучу всего. Если б он осилил доставить обещанное, или не обещал лишнего, то на персональные качества всем было бы плевать.
Суммируя:
1. Трезво оценивай свои возможности.
2. Найди, изучай и слушай только свою ЦА.
3. Не обещай того, в чём ты не разбираешься.
4. Полируй техническую часть не хуже графики.
>>10019
>в минус, учитывая fee за публикацию.
Квартплату, еду и интернет ты не учитываешь? Игра "выйдет в плюс", только если принесёт тебе больше суммарной зарплаты за всё время разработки. Т.е. заработать $1000 за игру, что делал год по 8 часов каждый день - полный провал, т.к. это з/п за месяц грузчиком в не самом большом городе.
>>10123
Это не вполне провал, так как приятное времяпровождение в уютном кресле дома, а не таскание тяжестей в кругу быдла.
Это не вполне провал, так как приятное времяпровождение в уютном кресле дома, а не таскание тяжестей в кругу быдла.
98 Кб, 960x960А вот подскажите на счет 3D графики. Вот я весь такой молодец (нет) и иду в ногу со временем (тоже нет) и делаю модельки в игре в стиле PSX.
Какие настройки графики мне нужно прикручивать? Подозреваю, что из-за малого кол-ва полигонов можно хрен на это забить вообще.
А что с разрешением делать? Движок автоматически при выборе разрешения будет подстраиваться или мне под каждое разрешение нужна своя моделька?
Я в 3д графике вообще не шарю, могу только код писать. Есть какое-то видео/статья по годоту, где пояснялось бы за основы?
Какие настройки графики мне нужно прикручивать? Подозреваю, что из-за малого кол-ва полигонов можно хрен на это забить вообще.
А что с разрешением делать? Движок автоматически при выборе разрешения будет подстраиваться или мне под каждое разрешение нужна своя моделька?
Я в 3д графике вообще не шарю, могу только код писать. Есть какое-то видео/статья по годоту, где пояснялось бы за основы?
>>10143
Делай разрешение игры меньше чем разрешение окна. Выше производительность плюс ближе к пс-стайл с его толстыми хрустящими пикселями.
Я свою на мобилки планирую портануть вообще в микроразрешении, потому что хуй кто чего там увидит, а фпс на дороге не валяются.
Делай разрешение игры меньше чем разрешение окна. Выше производительность плюс ближе к пс-стайл с его толстыми хрустящими пикселями.
Я свою на мобилки планирую портануть вообще в микроразрешении, потому что хуй кто чего там увидит, а фпс на дороге не валяются.
>>10123
Почему проваливаются игры от крупных студий? Они не знают всей этой базы и не могут нанять кого-то, кто им расскажет?
Почему проваливаются игры от крупных студий? Они не знают всей этой базы и не могут нанять кого-то, кто им расскажет?
>>10147
Я не знаю. Знаю что на годоте написана bosca ceoil blue, может подойдет.
Я не знаю. Знаю что на годоте написана bosca ceoil blue, может подойдет.
>>10132
Некоторые интеллектуальные задачи заставляют мечтать о том, чтобы их было возможно решить упорным применением грубой силы... Грузчик на расслабоне мешки таскает, у него тело прокачано специально для этого, а быдло вокруг - его друзья.
>>10145
1. У крупных студий есть План. По плану, от рабочих требуется выполнить то-то за столько-то времени. В худшем случае немного дольше, но уже без премий.
2. План составляется заранее, когда ещё ничего нет, согласовывается с инвесторами, которые всё это спонсируют в надежде на прибыль в будущем. Им необходимы гарантии, а не "по ходу дела увидим".
3. Рабочих даже не десятки, а сотни или тысячи, и практически никто не видит проект в совокупности, выполняют положенные им задачи как приказано.
4. Даже если кто-то в какой-то момент понимает, что установленный 5 лет назад план не сработает, взять и отказаться или переделать уже не выйдет - иначе получается плюс несколько лет разработки и на это требуется ещё больше денег. Попробуй убеди...
5. В конечном итоге, все сидят на зарплате. Какая разница, взлетит ли игра, если разработка оплачена? Провал игры - проблема инвесторов, а не разрабов...
Вот так сидят 8 лет в кубиклах, пилят Конкорд по заложенному плану убицы Овервотча, закономерно фейлят релиз, закрываются, со спокойной совестью расходятся по домам или по другим студиям. Они-то сделали всё, что от них требовали - не за что винить.
Алсо, по той же причине ААА штампуют одно и то же: однажды сработавший план имеет больше шансов сработать повторно, чем какая-то "гениальная идея", будь ты хоть трижды гениальный Кокодзима. Никто не хочет увеличивать риск, когда на кону $500 млн.
У инди в этом плане большое преимущество: можно дропнуть неудачный проект на полпути и побыстрее запилить совершенно новый, практически ничего не потеряв в процессе. И ничего не планировать, ибо отчитываться о выполнении плана просто некому.
Но обязательно найдётся Васян, который увидел отплытие очередного Титаника, плюхнулся в свою надувную лодочку, и стремится переплыть океан...
TL;DR: крупной студией намного тяжелее управлять, принципы разработки там отличаются от инди-игр - обойтись без чётко заложенного плана там нельзя, отсюда дедлайны, кранчи, факапы, эпик фейлы и бесконечный конвейер безликих клонов клонов со смешными, на первый взгляд, багами и глюками.
>приятное времяпровождение
Некоторые интеллектуальные задачи заставляют мечтать о том, чтобы их было возможно решить упорным применением грубой силы... Грузчик на расслабоне мешки таскает, у него тело прокачано специально для этого, а быдло вокруг - его друзья.
>>10145
1. У крупных студий есть План. По плану, от рабочих требуется выполнить то-то за столько-то времени. В худшем случае немного дольше, но уже без премий.
2. План составляется заранее, когда ещё ничего нет, согласовывается с инвесторами, которые всё это спонсируют в надежде на прибыль в будущем. Им необходимы гарантии, а не "по ходу дела увидим".
3. Рабочих даже не десятки, а сотни или тысячи, и практически никто не видит проект в совокупности, выполняют положенные им задачи как приказано.
4. Даже если кто-то в какой-то момент понимает, что установленный 5 лет назад план не сработает, взять и отказаться или переделать уже не выйдет - иначе получается плюс несколько лет разработки и на это требуется ещё больше денег. Попробуй убеди...
5. В конечном итоге, все сидят на зарплате. Какая разница, взлетит ли игра, если разработка оплачена? Провал игры - проблема инвесторов, а не разрабов...
Вот так сидят 8 лет в кубиклах, пилят Конкорд по заложенному плану убицы Овервотча, закономерно фейлят релиз, закрываются, со спокойной совестью расходятся по домам или по другим студиям. Они-то сделали всё, что от них требовали - не за что винить.
Алсо, по той же причине ААА штампуют одно и то же: однажды сработавший план имеет больше шансов сработать повторно, чем какая-то "гениальная идея", будь ты хоть трижды гениальный Кокодзима. Никто не хочет увеличивать риск, когда на кону $500 млн.
У инди в этом плане большое преимущество: можно дропнуть неудачный проект на полпути и побыстрее запилить совершенно новый, практически ничего не потеряв в процессе. И ничего не планировать, ибо отчитываться о выполнении плана просто некому.
Но обязательно найдётся Васян, который увидел отплытие очередного Титаника, плюхнулся в свою надувную лодочку, и стремится переплыть океан...
TL;DR: крупной студией намного тяжелее управлять, принципы разработки там отличаются от инди-игр - обойтись без чётко заложенного плана там нельзя, отсюда дедлайны, кранчи, факапы, эпик фейлы и бесконечный конвейер безликих клонов клонов со смешными, на первый взгляд, багами и глюками.
>>10132
Некоторые интеллектуальные задачи заставляют мечтать о том, чтобы их было возможно решить упорным применением грубой силы... Грузчик на расслабоне мешки таскает, у него тело прокачано специально для этого, а быдло вокруг - его друзья.
>>10145
1. У крупных студий есть План. По плану, от рабочих требуется выполнить то-то за столько-то времени. В худшем случае немного дольше, но уже без премий.
2. План составляется заранее, когда ещё ничего нет, согласовывается с инвесторами, которые всё это спонсируют в надежде на прибыль в будущем. Им необходимы гарантии, а не "по ходу дела увидим".
3. Рабочих даже не десятки, а сотни или тысячи, и практически никто не видит проект в совокупности, выполняют положенные им задачи как приказано.
4. Даже если кто-то в какой-то момент понимает, что установленный 5 лет назад план не сработает, взять и отказаться или переделать уже не выйдет - иначе получается плюс несколько лет разработки и на это требуется ещё больше денег. Попробуй убеди...
5. В конечном итоге, все сидят на зарплате. Какая разница, взлетит ли игра, если разработка оплачена? Провал игры - проблема инвесторов, а не разрабов...
Вот так сидят 8 лет в кубиклах, пилят Конкорд по заложенному плану убицы Овервотча, закономерно фейлят релиз, закрываются, со спокойной совестью расходятся по домам или по другим студиям. Они-то сделали всё, что от них требовали - не за что винить.
Алсо, по той же причине ААА штампуют одно и то же: однажды сработавший план имеет больше шансов сработать повторно, чем какая-то "гениальная идея", будь ты хоть трижды гениальный Кокодзима. Никто не хочет увеличивать риск, когда на кону $500 млн.
У инди в этом плане большое преимущество: можно дропнуть неудачный проект на полпути и побыстрее запилить совершенно новый, практически ничего не потеряв в процессе. И ничего не планировать, ибо отчитываться о выполнении плана просто некому.
Но обязательно найдётся Васян, который увидел отплытие очередного Титаника, плюхнулся в свою надувную лодочку, и стремится переплыть океан...
TL;DR: крупной студией намного тяжелее управлять, принципы разработки там отличаются от инди-игр - обойтись без чётко заложенного плана там нельзя, отсюда дедлайны, кранчи, факапы, эпик фейлы и бесконечный конвейер безликих клонов клонов со смешными, на первый взгляд, багами и глюками.
>приятное времяпровождение
Некоторые интеллектуальные задачи заставляют мечтать о том, чтобы их было возможно решить упорным применением грубой силы... Грузчик на расслабоне мешки таскает, у него тело прокачано специально для этого, а быдло вокруг - его друзья.
>>10145
1. У крупных студий есть План. По плану, от рабочих требуется выполнить то-то за столько-то времени. В худшем случае немного дольше, но уже без премий.
2. План составляется заранее, когда ещё ничего нет, согласовывается с инвесторами, которые всё это спонсируют в надежде на прибыль в будущем. Им необходимы гарантии, а не "по ходу дела увидим".
3. Рабочих даже не десятки, а сотни или тысячи, и практически никто не видит проект в совокупности, выполняют положенные им задачи как приказано.
4. Даже если кто-то в какой-то момент понимает, что установленный 5 лет назад план не сработает, взять и отказаться или переделать уже не выйдет - иначе получается плюс несколько лет разработки и на это требуется ещё больше денег. Попробуй убеди...
5. В конечном итоге, все сидят на зарплате. Какая разница, взлетит ли игра, если разработка оплачена? Провал игры - проблема инвесторов, а не разрабов...
Вот так сидят 8 лет в кубиклах, пилят Конкорд по заложенному плану убицы Овервотча, закономерно фейлят релиз, закрываются, со спокойной совестью расходятся по домам или по другим студиям. Они-то сделали всё, что от них требовали - не за что винить.
Алсо, по той же причине ААА штампуют одно и то же: однажды сработавший план имеет больше шансов сработать повторно, чем какая-то "гениальная идея", будь ты хоть трижды гениальный Кокодзима. Никто не хочет увеличивать риск, когда на кону $500 млн.
У инди в этом плане большое преимущество: можно дропнуть неудачный проект на полпути и побыстрее запилить совершенно новый, практически ничего не потеряв в процессе. И ничего не планировать, ибо отчитываться о выполнении плана просто некому.
Но обязательно найдётся Васян, который увидел отплытие очередного Титаника, плюхнулся в свою надувную лодочку, и стремится переплыть океан...
TL;DR: крупной студией намного тяжелее управлять, принципы разработки там отличаются от инди-игр - обойтись без чётко заложенного плана там нельзя, отсюда дедлайны, кранчи, факапы, эпик фейлы и бесконечный конвейер безликих клонов клонов со смешными, на первый взгляд, багами и глюками.
>>10143
Что-то типа такого?
https://reddit.com/r/ps1graphics/top/?t=all
Начни с простого, уменьши разрешение:
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
Можно динамически подстраиваться под размер конкретного экрана, а можно установить одно разрешение для всех и "растягивать пиксели".
Настройки по умолчанию в Godot - "низкие", но что-то можно снизить ещё больше. Например, пиксельные тени, если ты вообще используешь тени в сценах.
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html
В настройках проекта уменьши размер shadow map, отключи сглаживание (не помню, как называется).
В материалах по умолчанию пиксельное затенение (наилучшее). В старых играх такого не было; больше подойдёт per-vertex shading, его в 4.4 реализовали:
https://docs.godotengine.org/en/stable/tutorials/3d/standard_material_3d.html#shading-mode (Godot 4.3)
https://docs.godotengine.org/en/latest/tutorials/3d/standard_material_3d.html#shading-mode (Godot 4.4)
По умолчанию Environment больше не создаётся, но в настройках много чего интересного, посмотри. Тебя главным образом должен интересовать ретро туман ("depth fog"), потому что в старых играх им скрывали очень низкую дальность прорисовки объектов.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
Можно также накинуть свой собственный шейдер на весь экран, чтобы, например, снизить палитру.
https://godotshaders.com/shader/4-level-posterization-fragment/
Ещё можно попробовать добавить в шейдер шум...
https://docs.godotengine.org/en/stable/classes/class_noisetexture2d.html
Много разных эффектов создаётся из шума, самый дешёвый способ стилизации без ручного рисования (после сплошной заливки одним цветом, лол).
Также, возможно, тебе стоит ограничить FPS до 30. Возможно стоит ограничить FPS у анимаций. А вот физический движок лучше не ограничивать, у него точность результатов зависит от числа тиков.
Полного соответствия старому железу, увы, ты не добьёшься без копания в исходниках движка, т.к. современные видеокарты по-другому рендерят. Но стилизация "как на PS1", по идее, не такая строгая.
>>10144
Мобильные GPU работают по квадратикам экрана, поэтому снижение разрешения может оказаться бесполезным или даже вредным. Обычные GPU "брутфорсят" пиксели, мобильные - пытаются умно предугадать, что им рендерить. GPU делит экран на квадратики и сортирует треугольники в каждом квадратике... Не знаю, как это сочетается с мелким разрешением экрана - нужно провести стресс-тест.
Алсо, прежде чем снижать разрешение, убедись, что сделал всё остальные оптимизации. Если это порт, наверняка будет лучше сделать более лоупольные модельки с более мелкими треугольниками.
Про тени/свет всё очевидно, но я читал, что скайбокс сильно съедает производительность. Наверное, есть смысл сделать свой собственный скайбокс в виде гигантского куба. Но сам я пока не тестировал.
Что-то типа такого?
https://reddit.com/r/ps1graphics/top/?t=all
Начни с простого, уменьши разрешение:
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
Можно динамически подстраиваться под размер конкретного экрана, а можно установить одно разрешение для всех и "растягивать пиксели".
Настройки по умолчанию в Godot - "низкие", но что-то можно снизить ещё больше. Например, пиксельные тени, если ты вообще используешь тени в сценах.
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html
В настройках проекта уменьши размер shadow map, отключи сглаживание (не помню, как называется).
В материалах по умолчанию пиксельное затенение (наилучшее). В старых играх такого не было; больше подойдёт per-vertex shading, его в 4.4 реализовали:
https://docs.godotengine.org/en/stable/tutorials/3d/standard_material_3d.html#shading-mode (Godot 4.3)
https://docs.godotengine.org/en/latest/tutorials/3d/standard_material_3d.html#shading-mode (Godot 4.4)
>You can also use per-vertex lighting to achieve a retro look.
По умолчанию Environment больше не создаётся, но в настройках много чего интересного, посмотри. Тебя главным образом должен интересовать ретро туман ("depth fog"), потому что в старых играх им скрывали очень низкую дальность прорисовки объектов.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
Можно также накинуть свой собственный шейдер на весь экран, чтобы, например, снизить палитру.
https://godotshaders.com/shader/4-level-posterization-fragment/
Ещё можно попробовать добавить в шейдер шум...
https://docs.godotengine.org/en/stable/classes/class_noisetexture2d.html
Много разных эффектов создаётся из шума, самый дешёвый способ стилизации без ручного рисования (после сплошной заливки одним цветом, лол).
Также, возможно, тебе стоит ограничить FPS до 30. Возможно стоит ограничить FPS у анимаций. А вот физический движок лучше не ограничивать, у него точность результатов зависит от числа тиков.
Полного соответствия старому железу, увы, ты не добьёшься без копания в исходниках движка, т.к. современные видеокарты по-другому рендерят. Но стилизация "как на PS1", по идее, не такая строгая.
>>10144
>на мобилки планирую портануть
Мобильные GPU работают по квадратикам экрана, поэтому снижение разрешения может оказаться бесполезным или даже вредным. Обычные GPU "брутфорсят" пиксели, мобильные - пытаются умно предугадать, что им рендерить. GPU делит экран на квадратики и сортирует треугольники в каждом квадратике... Не знаю, как это сочетается с мелким разрешением экрана - нужно провести стресс-тест.
Алсо, прежде чем снижать разрешение, убедись, что сделал всё остальные оптимизации. Если это порт, наверняка будет лучше сделать более лоупольные модельки с более мелкими треугольниками.
Про тени/свет всё очевидно, но я читал, что скайбокс сильно съедает производительность. Наверное, есть смысл сделать свой собственный скайбокс в виде гигантского куба. Но сам я пока не тестировал.
>>10143
Что-то типа такого?
https://reddit.com/r/ps1graphics/top/?t=all
Начни с простого, уменьши разрешение:
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
Можно динамически подстраиваться под размер конкретного экрана, а можно установить одно разрешение для всех и "растягивать пиксели".
Настройки по умолчанию в Godot - "низкие", но что-то можно снизить ещё больше. Например, пиксельные тени, если ты вообще используешь тени в сценах.
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html
В настройках проекта уменьши размер shadow map, отключи сглаживание (не помню, как называется).
В материалах по умолчанию пиксельное затенение (наилучшее). В старых играх такого не было; больше подойдёт per-vertex shading, его в 4.4 реализовали:
https://docs.godotengine.org/en/stable/tutorials/3d/standard_material_3d.html#shading-mode (Godot 4.3)
https://docs.godotengine.org/en/latest/tutorials/3d/standard_material_3d.html#shading-mode (Godot 4.4)
По умолчанию Environment больше не создаётся, но в настройках много чего интересного, посмотри. Тебя главным образом должен интересовать ретро туман ("depth fog"), потому что в старых играх им скрывали очень низкую дальность прорисовки объектов.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
Можно также накинуть свой собственный шейдер на весь экран, чтобы, например, снизить палитру.
https://godotshaders.com/shader/4-level-posterization-fragment/
Ещё можно попробовать добавить в шейдер шум...
https://docs.godotengine.org/en/stable/classes/class_noisetexture2d.html
Много разных эффектов создаётся из шума, самый дешёвый способ стилизации без ручного рисования (после сплошной заливки одним цветом, лол).
Также, возможно, тебе стоит ограничить FPS до 30. Возможно стоит ограничить FPS у анимаций. А вот физический движок лучше не ограничивать, у него точность результатов зависит от числа тиков.
Полного соответствия старому железу, увы, ты не добьёшься без копания в исходниках движка, т.к. современные видеокарты по-другому рендерят. Но стилизация "как на PS1", по идее, не такая строгая.
>>10144
Мобильные GPU работают по квадратикам экрана, поэтому снижение разрешения может оказаться бесполезным или даже вредным. Обычные GPU "брутфорсят" пиксели, мобильные - пытаются умно предугадать, что им рендерить. GPU делит экран на квадратики и сортирует треугольники в каждом квадратике... Не знаю, как это сочетается с мелким разрешением экрана - нужно провести стресс-тест.
Алсо, прежде чем снижать разрешение, убедись, что сделал всё остальные оптимизации. Если это порт, наверняка будет лучше сделать более лоупольные модельки с более мелкими треугольниками.
Про тени/свет всё очевидно, но я читал, что скайбокс сильно съедает производительность. Наверное, есть смысл сделать свой собственный скайбокс в виде гигантского куба. Но сам я пока не тестировал.
Что-то типа такого?
https://reddit.com/r/ps1graphics/top/?t=all
Начни с простого, уменьши разрешение:
https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html
Можно динамически подстраиваться под размер конкретного экрана, а можно установить одно разрешение для всех и "растягивать пиксели".
Настройки по умолчанию в Godot - "низкие", но что-то можно снизить ещё больше. Например, пиксельные тени, если ты вообще используешь тени в сценах.
https://docs.godotengine.org/en/stable/tutorials/3d/lights_and_shadows.html
В настройках проекта уменьши размер shadow map, отключи сглаживание (не помню, как называется).
В материалах по умолчанию пиксельное затенение (наилучшее). В старых играх такого не было; больше подойдёт per-vertex shading, его в 4.4 реализовали:
https://docs.godotengine.org/en/stable/tutorials/3d/standard_material_3d.html#shading-mode (Godot 4.3)
https://docs.godotengine.org/en/latest/tutorials/3d/standard_material_3d.html#shading-mode (Godot 4.4)
>You can also use per-vertex lighting to achieve a retro look.
По умолчанию Environment больше не создаётся, но в настройках много чего интересного, посмотри. Тебя главным образом должен интересовать ретро туман ("depth fog"), потому что в старых играх им скрывали очень низкую дальность прорисовки объектов.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html#fog
Можно также накинуть свой собственный шейдер на весь экран, чтобы, например, снизить палитру.
https://godotshaders.com/shader/4-level-posterization-fragment/
Ещё можно попробовать добавить в шейдер шум...
https://docs.godotengine.org/en/stable/classes/class_noisetexture2d.html
Много разных эффектов создаётся из шума, самый дешёвый способ стилизации без ручного рисования (после сплошной заливки одним цветом, лол).
Также, возможно, тебе стоит ограничить FPS до 30. Возможно стоит ограничить FPS у анимаций. А вот физический движок лучше не ограничивать, у него точность результатов зависит от числа тиков.
Полного соответствия старому железу, увы, ты не добьёшься без копания в исходниках движка, т.к. современные видеокарты по-другому рендерят. Но стилизация "как на PS1", по идее, не такая строгая.
>>10144
>на мобилки планирую портануть
Мобильные GPU работают по квадратикам экрана, поэтому снижение разрешения может оказаться бесполезным или даже вредным. Обычные GPU "брутфорсят" пиксели, мобильные - пытаются умно предугадать, что им рендерить. GPU делит экран на квадратики и сортирует треугольники в каждом квадратике... Не знаю, как это сочетается с мелким разрешением экрана - нужно провести стресс-тест.
Алсо, прежде чем снижать разрешение, убедись, что сделал всё остальные оптимизации. Если это порт, наверняка будет лучше сделать более лоупольные модельки с более мелкими треугольниками.
Про тени/свет всё очевидно, но я читал, что скайбокс сильно съедает производительность. Наверное, есть смысл сделать свой собственный скайбокс в виде гигантского куба. Но сам я пока не тестировал.
>>10143
Посмотри какие уже есть PS1-стайл проекты, как в них сделано, их не меньше 10 штук точно наберется.
Посмотри какие уже есть PS1-стайл проекты, как в них сделано, их не меньше 10 штук точно наберется.
7,4 Мб, mp4,1920x1080, 0:30
>we’re making a final final release candidate
https://godotengine.org/article/release-candidate-godot-4-4-rc-3/
Готовьтесь анимировать сиськи и попки, ребята!
https://docs.godotengine.org/en/latest/classes/class_springbonesimulator3d.html
Видео отсюда:
https://reddit.com/r/godot/comments/1itx6rf/
А как правильно анимировать текст в лейбле? Я вот по-простому сделал анимейшнплеер, изменил позицию лейбла с 900 до 950 по Y, а потом при смене режима с фулскрин на оконное текст съехал. Я правильно понял, что так делать не стоит и при изменении разрешения все развалится нах? А как тогда? Через твин вроде то же самое будет.
>>10176
Зачем ты спрашиваешь
Если тебе нужно
? https://ru.wikipedia.org/wiki/Проблема_XY
Буквально "анимировать текст" по буквам:
visible_ratio: от 0.0 (ничего) до 1.0 (весь текст).
visible_characters: от 0 до длины текста (-1 = весь).
https://docs.godotengine.org/en/stable/classes/class_label.html#class-label-property-visible-ratio
Так делаются имитации "печатной машинки".
Изменять позицию - это ты Control дёргаешь:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-position
Причины
Может быть две. Первая - Container в предке:
https://docs.godotengine.org/en/stable/classes/class_container.html
Вторая - у тебя так настроены якоря Control:
https://docs.godotengine.org/en/stable/tutorials/ui/size_and_anchors.html
Якоря ОЧЕНЬ полезны для адаптивного UI, который подстраивается автоматически под разные экраны, размеры окна, предпочтения пользователей. В вебе называется адаптивным дизайном. Для того же используются контейнеры, получается так:
1. Расставляем контейнеры.
2. Засовываем в контейнеры ноды.
3. Настраиваем якоря у контейнеров.
Если очень хочется анимировать позицию Control независимо от разрешения экрана, тогда установи:
Во всех нодах-наследниках Control в предках этого Control. Либо выдели его на отдельный CanvasLayer. Также можно поместить в потомки простой Node.
Этот пресет ставит все 4 якоря на 0.5, т.е. "центр..." (родительской ноды, слоя, окна или экрана). Центр субъективно одинаковый у любого монитора, т.е. смещение относительно центра будет одинаковым.
Но есть нюанс! Одинаковым смещение будет с т.з. пикселей. Если ты сместил Control на 100 пикселей относительно позиции 750 пикселей вниз по Y, ты вылетаешь за пределы окна высотой 800 пикселей. Обычно, это значит, что твой UI сломался на экране пользователя - ведь он не видит твою надпись. Вот поэтому придумали якоря, которые автоматически корректируют позиции относительно границ окна.
Поэтому подобные анимации нужно делать очень аккуратно... Или не делать вообще. UI - это, обычно, утилитарная часть игры, а не развлекательная, и избыточные анимации в UI могут раздражать.
Твины тут никаким боком вообще, они всего лишь изменяют значения параметров - каких скажешь. Однако динамичные анимации UI лучше делать с помощью твинов, т.к. в AnimationPlayer ты просто замучаешься тыкаться, если захочешь какие-то параметры анимаций быстро поменять. Был опыт.
Ах да, ещё любопытный момент: Container не всегда сортирует элементы, а только после изменения своих размеров. Т.е. можно анимировать Control из некоей позиции в "нормальную" позицию, например, когда открываешь меню: узнаёшь свою позицию, которую принудительно устанавливает Container, сразу же телепортируешься куда-то и твинишься обратно. Аналогично можно твиниться при закрытии меню, отбрасывая свои Control куда-то за границу экрана. Главное правило: если что-то остановилось, то оно остановилось в правильном месте своего Container.
Зачем ты спрашиваешь
>анимировать текст в лейбле
Если тебе нужно
>изменил позицию лейбла
? https://ru.wikipedia.org/wiki/Проблема_XY
Буквально "анимировать текст" по буквам:
visible_ratio: от 0.0 (ничего) до 1.0 (весь текст).
visible_characters: от 0 до длины текста (-1 = весь).
https://docs.godotengine.org/en/stable/classes/class_label.html#class-label-property-visible-ratio
Так делаются имитации "печатной машинки".
Изменять позицию - это ты Control дёргаешь:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-position
Причины
>текст съехал
Может быть две. Первая - Container в предке:
https://docs.godotengine.org/en/stable/classes/class_container.html
>A Container automatically arranges its child controls in a certain way.
Вторая - у тебя так настроены якоря Control:
https://docs.godotengine.org/en/stable/tutorials/ui/size_and_anchors.html
Якоря ОЧЕНЬ полезны для адаптивного UI, который подстраивается автоматически под разные экраны, размеры окна, предпочтения пользователей. В вебе называется адаптивным дизайном. Для того же используются контейнеры, получается так:
1. Расставляем контейнеры.
2. Засовываем в контейнеры ноды.
3. Настраиваем якоря у контейнеров.
Если очень хочется анимировать позицию Control независимо от разрешения экрана, тогда установи:
>LayoutPreset PRESET_CENTER
Во всех нодах-наследниках Control в предках этого Control. Либо выдели его на отдельный CanvasLayer. Также можно поместить в потомки простой Node.
Этот пресет ставит все 4 якоря на 0.5, т.е. "центр..." (родительской ноды, слоя, окна или экрана). Центр субъективно одинаковый у любого монитора, т.е. смещение относительно центра будет одинаковым.
Но есть нюанс! Одинаковым смещение будет с т.з. пикселей. Если ты сместил Control на 100 пикселей относительно позиции 750 пикселей вниз по Y, ты вылетаешь за пределы окна высотой 800 пикселей. Обычно, это значит, что твой UI сломался на экране пользователя - ведь он не видит твою надпись. Вот поэтому придумали якоря, которые автоматически корректируют позиции относительно границ окна.
Поэтому подобные анимации нужно делать очень аккуратно... Или не делать вообще. UI - это, обычно, утилитарная часть игры, а не развлекательная, и избыточные анимации в UI могут раздражать.
Твины тут никаким боком вообще, они всего лишь изменяют значения параметров - каких скажешь. Однако динамичные анимации UI лучше делать с помощью твинов, т.к. в AnimationPlayer ты просто замучаешься тыкаться, если захочешь какие-то параметры анимаций быстро поменять. Был опыт.
Ах да, ещё любопытный момент: Container не всегда сортирует элементы, а только после изменения своих размеров. Т.е. можно анимировать Control из некоей позиции в "нормальную" позицию, например, когда открываешь меню: узнаёшь свою позицию, которую принудительно устанавливает Container, сразу же телепортируешься куда-то и твинишься обратно. Аналогично можно твиниться при закрытии меню, отбрасывая свои Control куда-то за границу экрана. Главное правило: если что-то остановилось, то оно остановилось в правильном месте своего Container.
>>10176
Зачем ты спрашиваешь
Если тебе нужно
? https://ru.wikipedia.org/wiki/Проблема_XY
Буквально "анимировать текст" по буквам:
visible_ratio: от 0.0 (ничего) до 1.0 (весь текст).
visible_characters: от 0 до длины текста (-1 = весь).
https://docs.godotengine.org/en/stable/classes/class_label.html#class-label-property-visible-ratio
Так делаются имитации "печатной машинки".
Изменять позицию - это ты Control дёргаешь:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-position
Причины
Может быть две. Первая - Container в предке:
https://docs.godotengine.org/en/stable/classes/class_container.html
Вторая - у тебя так настроены якоря Control:
https://docs.godotengine.org/en/stable/tutorials/ui/size_and_anchors.html
Якоря ОЧЕНЬ полезны для адаптивного UI, который подстраивается автоматически под разные экраны, размеры окна, предпочтения пользователей. В вебе называется адаптивным дизайном. Для того же используются контейнеры, получается так:
1. Расставляем контейнеры.
2. Засовываем в контейнеры ноды.
3. Настраиваем якоря у контейнеров.
Если очень хочется анимировать позицию Control независимо от разрешения экрана, тогда установи:
Во всех нодах-наследниках Control в предках этого Control. Либо выдели его на отдельный CanvasLayer. Также можно поместить в потомки простой Node.
Этот пресет ставит все 4 якоря на 0.5, т.е. "центр..." (родительской ноды, слоя, окна или экрана). Центр субъективно одинаковый у любого монитора, т.е. смещение относительно центра будет одинаковым.
Но есть нюанс! Одинаковым смещение будет с т.з. пикселей. Если ты сместил Control на 100 пикселей относительно позиции 750 пикселей вниз по Y, ты вылетаешь за пределы окна высотой 800 пикселей. Обычно, это значит, что твой UI сломался на экране пользователя - ведь он не видит твою надпись. Вот поэтому придумали якоря, которые автоматически корректируют позиции относительно границ окна.
Поэтому подобные анимации нужно делать очень аккуратно... Или не делать вообще. UI - это, обычно, утилитарная часть игры, а не развлекательная, и избыточные анимации в UI могут раздражать.
Твины тут никаким боком вообще, они всего лишь изменяют значения параметров - каких скажешь. Однако динамичные анимации UI лучше делать с помощью твинов, т.к. в AnimationPlayer ты просто замучаешься тыкаться, если захочешь какие-то параметры анимаций быстро поменять. Был опыт.
Ах да, ещё любопытный момент: Container не всегда сортирует элементы, а только после изменения своих размеров. Т.е. можно анимировать Control из некоей позиции в "нормальную" позицию, например, когда открываешь меню: узнаёшь свою позицию, которую принудительно устанавливает Container, сразу же телепортируешься куда-то и твинишься обратно. Аналогично можно твиниться при закрытии меню, отбрасывая свои Control куда-то за границу экрана. Главное правило: если что-то остановилось, то оно остановилось в правильном месте своего Container.
Зачем ты спрашиваешь
>анимировать текст в лейбле
Если тебе нужно
>изменил позицию лейбла
? https://ru.wikipedia.org/wiki/Проблема_XY
Буквально "анимировать текст" по буквам:
visible_ratio: от 0.0 (ничего) до 1.0 (весь текст).
visible_characters: от 0 до длины текста (-1 = весь).
https://docs.godotengine.org/en/stable/classes/class_label.html#class-label-property-visible-ratio
Так делаются имитации "печатной машинки".
Изменять позицию - это ты Control дёргаешь:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-position
Причины
>текст съехал
Может быть две. Первая - Container в предке:
https://docs.godotengine.org/en/stable/classes/class_container.html
>A Container automatically arranges its child controls in a certain way.
Вторая - у тебя так настроены якоря Control:
https://docs.godotengine.org/en/stable/tutorials/ui/size_and_anchors.html
Якоря ОЧЕНЬ полезны для адаптивного UI, который подстраивается автоматически под разные экраны, размеры окна, предпочтения пользователей. В вебе называется адаптивным дизайном. Для того же используются контейнеры, получается так:
1. Расставляем контейнеры.
2. Засовываем в контейнеры ноды.
3. Настраиваем якоря у контейнеров.
Если очень хочется анимировать позицию Control независимо от разрешения экрана, тогда установи:
>LayoutPreset PRESET_CENTER
Во всех нодах-наследниках Control в предках этого Control. Либо выдели его на отдельный CanvasLayer. Также можно поместить в потомки простой Node.
Этот пресет ставит все 4 якоря на 0.5, т.е. "центр..." (родительской ноды, слоя, окна или экрана). Центр субъективно одинаковый у любого монитора, т.е. смещение относительно центра будет одинаковым.
Но есть нюанс! Одинаковым смещение будет с т.з. пикселей. Если ты сместил Control на 100 пикселей относительно позиции 750 пикселей вниз по Y, ты вылетаешь за пределы окна высотой 800 пикселей. Обычно, это значит, что твой UI сломался на экране пользователя - ведь он не видит твою надпись. Вот поэтому придумали якоря, которые автоматически корректируют позиции относительно границ окна.
Поэтому подобные анимации нужно делать очень аккуратно... Или не делать вообще. UI - это, обычно, утилитарная часть игры, а не развлекательная, и избыточные анимации в UI могут раздражать.
Твины тут никаким боком вообще, они всего лишь изменяют значения параметров - каких скажешь. Однако динамичные анимации UI лучше делать с помощью твинов, т.к. в AnimationPlayer ты просто замучаешься тыкаться, если захочешь какие-то параметры анимаций быстро поменять. Был опыт.
Ах да, ещё любопытный момент: Container не всегда сортирует элементы, а только после изменения своих размеров. Т.е. можно анимировать Control из некоей позиции в "нормальную" позицию, например, когда открываешь меню: узнаёшь свою позицию, которую принудительно устанавливает Container, сразу же телепортируешься куда-то и твинишься обратно. Аналогично можно твиниться при закрытии меню, отбрасывая свои Control куда-то за границу экрана. Главное правило: если что-то остановилось, то оно остановилось в правильном месте своего Container.
>>08211 (OP)
Какие игры вообще на этом движке есть?
Знаю только Cruelty squad, ну и psycho patrol R от того же разраба скоро выйдет. Есть ли еще ГОДНОТА? И насколько жопобольно на нем что то писать?
Какие игры вообще на этом движке есть?
Знаю только Cruelty squad, ну и psycho patrol R от того же разраба скоро выйдет. Есть ли еще ГОДНОТА? И насколько жопобольно на нем что то писать?
Напомните в 4-ке в вебе звук не трещит, например в threads варианте? В проекте на 3-ке у меня Howler.js, но в одном пет проекте хочется не вникать в js.
>>10190
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot/#browse
Сортируй по топ продажам.
https://store.steampowered.com/curator/41324400-Is-it-made-with-Godot/#browse
Сортируй по топ продажам.
7 Кб, 373x132Нашел для себя возможность писать простенькие скрипты, не заморачиваясь с полноценными плагинами. Пихаешь код в _run, запускаешь по Файл -> Запустить (Ctrl+Shit+X), и оно отрабатывает в редакторе. Переупорядочил 600+ нод, поправив их родителей и имена.
>>10207
Прикольно, а я просто писал в _ready и переоткрывал сцену, и переименовывал в _not_ready когда не надо.
Прикольно, а я просто писал в _ready и переоткрывал сцену, и переименовывал в _not_ready когда не надо.
>>10181
Спасибо. Да, я по тупому просто лейбл разместил на экране. Чувствую придется с контейнерами и маргинами ебаться.
Спасибо. Да, я по тупому просто лейбл разместил на экране. Чувствую придется с контейнерами и маргинами ебаться.
893 Кб, 1024x574Ладно блять, я сейчас за 15 минут и пятерку суммарных промтов к клоду и о3 нахуярил grid-based аналог скаттера, который после рисования мышью в 3д делит меши на группы как мне надо и конвертит их в мультимеши.
Зе фьюче ис нау.
Зе фьюче ис нау.
>>08211 (OP)
Есть идей как сделать производительно в 3д, чтобы когда открываешь дверь на себя, за ней была одна комната, а когда от себя - другая?
Есть идей как сделать производительно в 3д, чтобы когда открываешь дверь на себя, за ней была одна комната, а когда от себя - другая?
>>10279 >>10281
Смена позиций может быть сложной, если в комнате множество RigidBody валяется. Вместо перемещения можно просто скрывать и отключать ноды:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-constant-process-mode-disabled
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-disable-mode
А если нод не так много, то можно просто извлечь из дерева сцены и вставить обратно по необходимости.
По моему опыту, основные источники тормозов:
1. Использование load().
2. Компиляция шейдеров в первый раз.
3. Добавление сотен нод в дерево по 1 штучке.
4. Добавление/смещение множества CSG-шейпов.
Вообще: сначала сделай самым простым, грязным способом. Не заботься о производительности пока. Если производительность станет проблемой, тогда необходимо вычислить источник самого сильного замедления и работать с ним. Пишешь тесты, что учитывают особенности твоей игры, сравниваешь различные реализации, выбираешь оптимальную.
Самых лучших способов нет, всё индивидуально.
Смена позиций может быть сложной, если в комнате множество RigidBody валяется. Вместо перемещения можно просто скрывать и отключать ноды:
>room.visible = false
>room.process_mode = PROCESS_MODE_DISABLED
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-constant-process-mode-disabled
https://docs.godotengine.org/en/stable/classes/class_collisionobject3d.html#class-collisionobject3d-property-disable-mode
А если нод не так много, то можно просто извлечь из дерева сцены и вставить обратно по необходимости.
По моему опыту, основные источники тормозов:
1. Использование load().
2. Компиляция шейдеров в первый раз.
3. Добавление сотен нод в дерево по 1 штучке.
4. Добавление/смещение множества CSG-шейпов.
Вообще: сначала сделай самым простым, грязным способом. Не заботься о производительности пока. Если производительность станет проблемой, тогда необходимо вычислить источник самого сильного замедления и работать с ним. Пишешь тесты, что учитывают особенности твоей игры, сравниваешь различные реализации, выбираешь оптимальную.
Самых лучших способов нет, всё индивидуально.
>>10280
Зачем ты у всех ИТТ скрины кода просишь? Коллекционируешь? Это теперь моя интеллектуальная собственность.
Зачем ты у всех ИТТ скрины кода просишь? Коллекционируешь? Это теперь моя интеллектуальная собственность.
>>10207
Можно ещё так, независимо от редактора:
https://docs.godotengine.org/en/3.6/tutorials/editor/command_line_tutorial.html#running-a-script
>>10232
Для прототипа за вечер сойдёт. Для чего-то более серьёзного это слишком большая затрата во время загрузки сцены колеса. Нужно экспортировать CSG в файл .obj или .gltf и импортировать как модельку, а в идеале - пофиксить косяки меша через блендер.
>>10236
Можешь использовать это:
https://docs.godotengine.org/en/3.6/classes/class_node.html#class-node-method-get-node-or-null
"if not x" - срабатывает, если x == null или уничтожен.
Уж лучше использовать рекомендованный формат именования файлов - "snake_case". Его легче читать, потенциально меньше проблем с разными ОС - нет возможности ошибиться с размером букв. В 4.x при сохранении сцен сразу этот формат предлагается.
Привыкай юзать форматирование, оно лучше:
Читать проще и запись в целом короче.
https://docs.godotengine.org/en/3.6/tutorials/scripting/gdscript/gdscript_format_string.html
>>10290
Да кому твой говнокод нужен, у нас у всех свой есть. Полагаю, анонам здесь интересно смотреть, как/что делают другие, даже если сам по себе код фигня.
Алсо, если ты никак не правил код от нейронки - он по определению находится в публичном достоянии: никаких прав ты на него не имеешь, но зато несёшь за него ответственность в случае каких-то ошибок.
>код в _run, запускаешь по Файл -> Запустить
>возможность писать простенькие скрипты
Можно ещё так, независимо от редактора:
https://docs.godotengine.org/en/3.6/tutorials/editor/command_line_tutorial.html#running-a-script
>>10232
>Генерация колеса
>CSG
Для прототипа за вечер сойдёт. Для чего-то более серьёзного это слишком большая затрата во время загрузки сцены колеса. Нужно экспортировать CSG в файл .obj или .gltf и импортировать как модельку, а в идеале - пофиксить косяки меша через блендер.
>>10236
>has_node()
Можешь использовать это:
https://docs.godotengine.org/en/3.6/classes/class_node.html#class-node-method-get-node-or-null
>var blocks := root.get_node_or_null("path")
>if not blocks: blocks = _new_blocks_container()
># дальше твой обычный код
"if not x" - срабатывает, если x == null или уничтожен.
>Cut.tscn
Уж лучше использовать рекомендованный формат именования файлов - "snake_case". Его легче читать, потенциально меньше проблем с разными ОС - нет возможности ошибиться с размером букв. В 4.x при сохранении сцен сразу этот формат предлагается.
>str()
Привыкай юзать форматирование, оно лучше:
>print("Moved %d nodes" % blocks_cut.size())
Читать проще и запись в целом короче.
https://docs.godotengine.org/en/3.6/tutorials/scripting/gdscript/gdscript_format_string.html
>>10290
>моя интеллектуальная собственность
Да кому твой говнокод нужен, у нас у всех свой есть. Полагаю, анонам здесь интересно смотреть, как/что делают другие, даже если сам по себе код фигня.
Алсо, если ты никак не правил код от нейронки - он по определению находится в публичном достоянии: никаких прав ты на него не имеешь, но зато несёшь за него ответственность в случае каких-то ошибок.
>>10207
Можно ещё так, независимо от редактора:
https://docs.godotengine.org/en/3.6/tutorials/editor/command_line_tutorial.html#running-a-script
>>10232
Для прототипа за вечер сойдёт. Для чего-то более серьёзного это слишком большая затрата во время загрузки сцены колеса. Нужно экспортировать CSG в файл .obj или .gltf и импортировать как модельку, а в идеале - пофиксить косяки меша через блендер.
>>10236
Можешь использовать это:
https://docs.godotengine.org/en/3.6/classes/class_node.html#class-node-method-get-node-or-null
"if not x" - срабатывает, если x == null или уничтожен.
Уж лучше использовать рекомендованный формат именования файлов - "snake_case". Его легче читать, потенциально меньше проблем с разными ОС - нет возможности ошибиться с размером букв. В 4.x при сохранении сцен сразу этот формат предлагается.
Привыкай юзать форматирование, оно лучше:
Читать проще и запись в целом короче.
https://docs.godotengine.org/en/3.6/tutorials/scripting/gdscript/gdscript_format_string.html
>>10290
Да кому твой говнокод нужен, у нас у всех свой есть. Полагаю, анонам здесь интересно смотреть, как/что делают другие, даже если сам по себе код фигня.
Алсо, если ты никак не правил код от нейронки - он по определению находится в публичном достоянии: никаких прав ты на него не имеешь, но зато несёшь за него ответственность в случае каких-то ошибок.
>код в _run, запускаешь по Файл -> Запустить
>возможность писать простенькие скрипты
Можно ещё так, независимо от редактора:
https://docs.godotengine.org/en/3.6/tutorials/editor/command_line_tutorial.html#running-a-script
>>10232
>Генерация колеса
>CSG
Для прототипа за вечер сойдёт. Для чего-то более серьёзного это слишком большая затрата во время загрузки сцены колеса. Нужно экспортировать CSG в файл .obj или .gltf и импортировать как модельку, а в идеале - пофиксить косяки меша через блендер.
>>10236
>has_node()
Можешь использовать это:
https://docs.godotengine.org/en/3.6/classes/class_node.html#class-node-method-get-node-or-null
>var blocks := root.get_node_or_null("path")
>if not blocks: blocks = _new_blocks_container()
># дальше твой обычный код
"if not x" - срабатывает, если x == null или уничтожен.
>Cut.tscn
Уж лучше использовать рекомендованный формат именования файлов - "snake_case". Его легче читать, потенциально меньше проблем с разными ОС - нет возможности ошибиться с размером букв. В 4.x при сохранении сцен сразу этот формат предлагается.
>str()
Привыкай юзать форматирование, оно лучше:
>print("Moved %d nodes" % blocks_cut.size())
Читать проще и запись в целом короче.
https://docs.godotengine.org/en/3.6/tutorials/scripting/gdscript/gdscript_format_string.html
>>10290
>моя интеллектуальная собственность
Да кому твой говнокод нужен, у нас у всех свой есть. Полагаю, анонам здесь интересно смотреть, как/что делают другие, даже если сам по себе код фигня.
Алсо, если ты никак не правил код от нейронки - он по определению находится в публичном достоянии: никаких прав ты на него не имеешь, но зато несёшь за него ответственность в случае каких-то ошибок.
>>10295
CamelCase получается от "наследования" имен нод. MeshInstance, например, по инерции переименовываешь в условный MyMeshInstance и сохраняешь с таким же именем.
>>Cut.tscn
>Уж лучше использовать рекомендованный формат именования файлов - "snake_case"
CamelCase получается от "наследования" имен нод. MeshInstance, например, по инерции переименовываешь в условный MyMeshInstance и сохраняешь с таким же именем.
>>10295
Ты неправильное форматирование юзаешь. Я и сам не смог приучить себя к правильному - питоновскому. Тоже использую стародавнее. Скобки кажутся более громоздкими.
>Привыкай юзать форматирование, оно лучше
Ты неправильное форматирование юзаешь. Я и сам не смог приучить себя к правильному - питоновскому. Тоже использую стародавнее. Скобки кажутся более громоздкими.
>>10299
В Godot 4.x немного изменили поведение:
1. Создаёшь сцену из ноды MeshInstance3D.
2. Нажимаешь ctrl+s для сохранения...
3. Видишь в окне сохранения:
Т.е. всё автоматически конвертируется.
Аналогично для ресурсов и скриптов.
>>10300
Ты про String.format()?
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_format_string.html#string-format-method
Этот метод ограничен:
Он нужен только для плейсходеров, типа:
А плейсхолдеры нужны для переводчиков:
https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html#placeholders
Так что это отдельный инструмент. Для GUI:
Для вывода, например, каких-то чисел в консоль:
А если, например, нужны числа в GUI:
>>10302 >>10303
В питоне есть format(), просто он немного устарел:
https://w3schools.com/python/python_string_formatting.asp
В Godot String.format() не имеет всех его функций.
>получается от "наследования" имен нод
В Godot 4.x немного изменили поведение:
1. Создаёшь сцену из ноды MeshInstance3D.
2. Нажимаешь ctrl+s для сохранения...
3. Видишь в окне сохранения:
>mesh_instance_3d.tscn
Т.е. всё автоматически конвертируется.
Аналогично для ресурсов и скриптов.
>>10300
>неправильное форматирование
>правильному - питоновскому
Ты про String.format()?
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_format_string.html#string-format-method
Этот метод ограничен:
>Combining both the String.format method and the % operator could be useful, as String.format does not have a way to manipulate the representation of numbers.
Он нужен только для плейсходеров, типа:
>"Hello, {player_name}! How's your {pet_name}?".format("player_name": player.name, "pet_name": player.pet.name)
А плейсхолдеры нужны для переводчиков:
>"Привет! Как твой {pet_name}, {player_name}?".format("player_name": player.name, "pet_name": player.pet.name)
https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html#placeholders
Так что это отдельный инструмент. Для GUI:
>label.text = tr(greeting).format(player_data)
Для вывода, например, каких-то чисел в консоль:
>print(debug_line % debug_data)
А если, например, нужны числа в GUI:
>tr("I'll give you ${money}.").format({"money": "%.2f" % quest.reward.money})
>>10302 >>10303
В питоне есть format(), просто он немного устарел:
https://w3schools.com/python/python_string_formatting.asp
В Godot String.format() не имеет всех его функций.
>>10299
В Godot 4.x немного изменили поведение:
1. Создаёшь сцену из ноды MeshInstance3D.
2. Нажимаешь ctrl+s для сохранения...
3. Видишь в окне сохранения:
Т.е. всё автоматически конвертируется.
Аналогично для ресурсов и скриптов.
>>10300
Ты про String.format()?
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_format_string.html#string-format-method
Этот метод ограничен:
Он нужен только для плейсходеров, типа:
А плейсхолдеры нужны для переводчиков:
https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html#placeholders
Так что это отдельный инструмент. Для GUI:
Для вывода, например, каких-то чисел в консоль:
А если, например, нужны числа в GUI:
>>10302 >>10303
В питоне есть format(), просто он немного устарел:
https://w3schools.com/python/python_string_formatting.asp
В Godot String.format() не имеет всех его функций.
>получается от "наследования" имен нод
В Godot 4.x немного изменили поведение:
1. Создаёшь сцену из ноды MeshInstance3D.
2. Нажимаешь ctrl+s для сохранения...
3. Видишь в окне сохранения:
>mesh_instance_3d.tscn
Т.е. всё автоматически конвертируется.
Аналогично для ресурсов и скриптов.
>>10300
>неправильное форматирование
>правильному - питоновскому
Ты про String.format()?
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_format_string.html#string-format-method
Этот метод ограничен:
>Combining both the String.format method and the % operator could be useful, as String.format does not have a way to manipulate the representation of numbers.
Он нужен только для плейсходеров, типа:
>"Hello, {player_name}! How's your {pet_name}?".format("player_name": player.name, "pet_name": player.pet.name)
А плейсхолдеры нужны для переводчиков:
>"Привет! Как твой {pet_name}, {player_name}?".format("player_name": player.name, "pet_name": player.pet.name)
https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html#placeholders
Так что это отдельный инструмент. Для GUI:
>label.text = tr(greeting).format(player_data)
Для вывода, например, каких-то чисел в консоль:
>print(debug_line % debug_data)
А если, например, нужны числа в GUI:
>tr("I'll give you ${money}.").format({"money": "%.2f" % quest.reward.money})
>>10302 >>10303
В питоне есть format(), просто он немного устарел:
https://w3schools.com/python/python_string_formatting.asp
В Godot String.format() не имеет всех его функций.
>>10308
Это форматирование текста, в debug_line должна быть строка с шаблоном, в котором значения подставятся из debug_data.
Это форматирование текста, в debug_line должна быть строка с шаблоном, в котором значения подставятся из debug_data.
>>10306
Что? Читай документацию.
>>10308
Это просто сокращение.
Например, описываешь выводимую строку:
Перечисляешь данные:
https://docs.godotengine.org/en/stable/classes/class_performance.html
Выводишь:
Или на экран:
Здесь переменные, конечно, не особо нужны.
Что? Читай документацию.
>>10308
>>print(debug_line % debug_data)
>Что тут происходит?
Это просто сокращение.
Например, описываешь выводимую строку:
>var debug_line := "FPS: %d (%.3f ms, %.3f ms)"
Перечисляешь данные:
>var debug_data := [
>Performance.get_monitor(Performance.TIME_FPS),
>Performance.get_monitor(Performance.TIME_PROCESS) × 1000,
>Performance.get_monitor(Performance.TIME_PHYSICS_PROCESS) × 1000,
>]
https://docs.godotengine.org/en/stable/classes/class_performance.html
Выводишь:
>print(debug_line % debug_data)
Или на экран:
>label.text = debug_line % debug_data
Здесь переменные, конечно, не особо нужны.
>>10305
нет я про f"string"
>>10320
Python provides several ways to format strings. Here are some common methods:
---
### 1. The `%` Operator (Old-Style Formatting)
This is one of the earliest methods for string formatting in Python.
```python
name = "Alice"
age = 30
formatted_string = "Hello, %s. You are %d years old." % (name, age)
print(formatted_string)
```
Notes:
- `%s` is used for strings.
- `%d` is used for integers.
- There are other specifiers, like `%f` for floating-point numbers.
- This method is considered less modern, though it's still valid.
---
### 2. The `str.format()` Method
Introduced in Python 2.6/3.0, this method is more flexible and powerful than the `%` operator.
```python
name = "Alice"
age = 30
formatted_string = "Hello, {}. You are {} years old.".format(name, age)
print(formatted_string)
```
Using positional or keyword arguments:
```python
formatted_string = "Hello, {name}. You are {age} years old.".format(name="Alice", age=30)
print(formatted_string)
```
You can also format numbers:
```python
import math
formatted_string = "The value of pi is approximately {:.2f}.".format(math.pi)
print(formatted_string)
```
- `{}` can include format specifications, alignment, width, etc.
---
### 3. f-Strings (Literal String Interpolation)
Available from Python 3.6 onward, f-strings provide an even more concise way to format strings while embedding expressions directly in the string literals.
```python
name = "Alice"
age = 30
formatted_string = f"Hello, {name}. You are {age} years old."
print(formatted_string)
```
You can also include expressions:
```python
import math
formatted_string = f"The value of pi is approximately {math.pi:.2f}."
print(formatted_string)
```
- Expressions inside `{}` are evaluated at runtime.
- f-strings are generally preferred for their readability and performance.
---
### 4. Template Strings (from the string module)
This is another method provided by the `string` module, which can be useful in situations where you're using user-provided format strings, as it offers some security benefits by avoiding direct code execution.
```python
from string import Template
name = "Alice"
age = 30
template = Template("Hello, $name. You are $age years old.")
formatted_string = template.substitute(name=name, age=age)
print(formatted_string)
```
Notes:
- The `$`-based syntax is simpler and may help prevent injection vulnerabilities in certain contexts.
- The `substitute` method will raise an exception if placeholders are missing; alternatively, you can use `safe_substitute` to avoid this.
---
### Summary
- `%` Operator: Older and less flexible.
- `str.format()`: More expressive and flexible.
- f-Strings: Modern, concise, and powerful.
- Template Strings: Useful for safe substitutions with user-controlled data.
Choose the method that best suits your project’s requirements and the Python version you're using.
>Ты про String.format()?
нет я про f"string"
>>10320
Python provides several ways to format strings. Here are some common methods:
---
### 1. The `%` Operator (Old-Style Formatting)
This is one of the earliest methods for string formatting in Python.
```python
name = "Alice"
age = 30
formatted_string = "Hello, %s. You are %d years old." % (name, age)
print(formatted_string)
```
Notes:
- `%s` is used for strings.
- `%d` is used for integers.
- There are other specifiers, like `%f` for floating-point numbers.
- This method is considered less modern, though it's still valid.
---
### 2. The `str.format()` Method
Introduced in Python 2.6/3.0, this method is more flexible and powerful than the `%` operator.
```python
name = "Alice"
age = 30
formatted_string = "Hello, {}. You are {} years old.".format(name, age)
print(formatted_string)
```
Using positional or keyword arguments:
```python
formatted_string = "Hello, {name}. You are {age} years old.".format(name="Alice", age=30)
print(formatted_string)
```
You can also format numbers:
```python
import math
formatted_string = "The value of pi is approximately {:.2f}.".format(math.pi)
print(formatted_string)
```
- `{}` can include format specifications, alignment, width, etc.
---
### 3. f-Strings (Literal String Interpolation)
Available from Python 3.6 onward, f-strings provide an even more concise way to format strings while embedding expressions directly in the string literals.
```python
name = "Alice"
age = 30
formatted_string = f"Hello, {name}. You are {age} years old."
print(formatted_string)
```
You can also include expressions:
```python
import math
formatted_string = f"The value of pi is approximately {math.pi:.2f}."
print(formatted_string)
```
- Expressions inside `{}` are evaluated at runtime.
- f-strings are generally preferred for their readability and performance.
---
### 4. Template Strings (from the string module)
This is another method provided by the `string` module, which can be useful in situations where you're using user-provided format strings, as it offers some security benefits by avoiding direct code execution.
```python
from string import Template
name = "Alice"
age = 30
template = Template("Hello, $name. You are $age years old.")
formatted_string = template.substitute(name=name, age=age)
print(formatted_string)
```
Notes:
- The `$`-based syntax is simpler and may help prevent injection vulnerabilities in certain contexts.
- The `substitute` method will raise an exception if placeholders are missing; alternatively, you can use `safe_substitute` to avoid this.
---
### Summary
- `%` Operator: Older and less flexible.
- `str.format()`: More expressive and flexible.
- f-Strings: Modern, concise, and powerful.
- Template Strings: Useful for safe substitutions with user-controlled data.
Choose the method that best suits your project’s requirements and the Python version you're using.
>>10305
нет я про f"string"
>>10320
Python provides several ways to format strings. Here are some common methods:
---
### 1. The `%` Operator (Old-Style Formatting)
This is one of the earliest methods for string formatting in Python.
```python
name = "Alice"
age = 30
formatted_string = "Hello, %s. You are %d years old." % (name, age)
print(formatted_string)
```
Notes:
- `%s` is used for strings.
- `%d` is used for integers.
- There are other specifiers, like `%f` for floating-point numbers.
- This method is considered less modern, though it's still valid.
---
### 2. The `str.format()` Method
Introduced in Python 2.6/3.0, this method is more flexible and powerful than the `%` operator.
```python
name = "Alice"
age = 30
formatted_string = "Hello, {}. You are {} years old.".format(name, age)
print(formatted_string)
```
Using positional or keyword arguments:
```python
formatted_string = "Hello, {name}. You are {age} years old.".format(name="Alice", age=30)
print(formatted_string)
```
You can also format numbers:
```python
import math
formatted_string = "The value of pi is approximately {:.2f}.".format(math.pi)
print(formatted_string)
```
- `{}` can include format specifications, alignment, width, etc.
---
### 3. f-Strings (Literal String Interpolation)
Available from Python 3.6 onward, f-strings provide an even more concise way to format strings while embedding expressions directly in the string literals.
```python
name = "Alice"
age = 30
formatted_string = f"Hello, {name}. You are {age} years old."
print(formatted_string)
```
You can also include expressions:
```python
import math
formatted_string = f"The value of pi is approximately {math.pi:.2f}."
print(formatted_string)
```
- Expressions inside `{}` are evaluated at runtime.
- f-strings are generally preferred for their readability and performance.
---
### 4. Template Strings (from the string module)
This is another method provided by the `string` module, which can be useful in situations where you're using user-provided format strings, as it offers some security benefits by avoiding direct code execution.
```python
from string import Template
name = "Alice"
age = 30
template = Template("Hello, $name. You are $age years old.")
formatted_string = template.substitute(name=name, age=age)
print(formatted_string)
```
Notes:
- The `$`-based syntax is simpler and may help prevent injection vulnerabilities in certain contexts.
- The `substitute` method will raise an exception if placeholders are missing; alternatively, you can use `safe_substitute` to avoid this.
---
### Summary
- `%` Operator: Older and less flexible.
- `str.format()`: More expressive and flexible.
- f-Strings: Modern, concise, and powerful.
- Template Strings: Useful for safe substitutions with user-controlled data.
Choose the method that best suits your project’s requirements and the Python version you're using.
>Ты про String.format()?
нет я про f"string"
>>10320
Python provides several ways to format strings. Here are some common methods:
---
### 1. The `%` Operator (Old-Style Formatting)
This is one of the earliest methods for string formatting in Python.
```python
name = "Alice"
age = 30
formatted_string = "Hello, %s. You are %d years old." % (name, age)
print(formatted_string)
```
Notes:
- `%s` is used for strings.
- `%d` is used for integers.
- There are other specifiers, like `%f` for floating-point numbers.
- This method is considered less modern, though it's still valid.
---
### 2. The `str.format()` Method
Introduced in Python 2.6/3.0, this method is more flexible and powerful than the `%` operator.
```python
name = "Alice"
age = 30
formatted_string = "Hello, {}. You are {} years old.".format(name, age)
print(formatted_string)
```
Using positional or keyword arguments:
```python
formatted_string = "Hello, {name}. You are {age} years old.".format(name="Alice", age=30)
print(formatted_string)
```
You can also format numbers:
```python
import math
formatted_string = "The value of pi is approximately {:.2f}.".format(math.pi)
print(formatted_string)
```
- `{}` can include format specifications, alignment, width, etc.
---
### 3. f-Strings (Literal String Interpolation)
Available from Python 3.6 onward, f-strings provide an even more concise way to format strings while embedding expressions directly in the string literals.
```python
name = "Alice"
age = 30
formatted_string = f"Hello, {name}. You are {age} years old."
print(formatted_string)
```
You can also include expressions:
```python
import math
formatted_string = f"The value of pi is approximately {math.pi:.2f}."
print(formatted_string)
```
- Expressions inside `{}` are evaluated at runtime.
- f-strings are generally preferred for their readability and performance.
---
### 4. Template Strings (from the string module)
This is another method provided by the `string` module, which can be useful in situations where you're using user-provided format strings, as it offers some security benefits by avoiding direct code execution.
```python
from string import Template
name = "Alice"
age = 30
template = Template("Hello, $name. You are $age years old.")
formatted_string = template.substitute(name=name, age=age)
print(formatted_string)
```
Notes:
- The `$`-based syntax is simpler and may help prevent injection vulnerabilities in certain contexts.
- The `substitute` method will raise an exception if placeholders are missing; alternatively, you can use `safe_substitute` to avoid this.
---
### Summary
- `%` Operator: Older and less flexible.
- `str.format()`: More expressive and flexible.
- f-Strings: Modern, concise, and powerful.
- Template Strings: Useful for safe substitutions with user-controlled data.
Choose the method that best suits your project’s requirements and the Python version you're using.
>>10324
Есть такая штука, похожая на eval():
https://docs.godotengine.org/en/stable/tutorials/scripting/evaluating_expressions.html
Но как-то громоздко получается.
F-string могут реализовать позже (4.5+):
https://github.com/godotengine/godot-proposals/issues/157
https://github.com/godotengine/godot/pull/103239
>embedding expressions directly in the string literals
Есть такая штука, похожая на eval():
https://docs.godotengine.org/en/stable/tutorials/scripting/evaluating_expressions.html
Но как-то громоздко получается.
F-string могут реализовать позже (4.5+):
https://github.com/godotengine/godot-proposals/issues/157
https://github.com/godotengine/godot/pull/103239
>>10335
Там разные способы предложили, типа такого:
Использование, например, такое:
С локальными переменными работать не будет.
Но есть нюанс: inst_to_dict() переносит поля Object в Dictionary. Это может быть затратно, если часто это используете на классе с большим числом полей.
https://docs.godotengine.org/en/stable/classes/ciErlass_ ANUSgdscrip*u+t PUNCTUMhtm#GQl #class-gdscript-method-inst-to-dict
Ещё, если я правильно понял, f-string не позволяют использовать tr(), т.е. переводить строки с ключами. Предлагают реализовать ещё ftr"" или типа того.
Но даже если б позволяли - допустим, у нас есть:
В переводах у нас лежат такие строки:
Теперь представьте, что вы отрефакторили класс:
Теперь pet_name не существует, нужен костыль:
В случае с format():
...хотя это не сильно лучше отдельного var...
...Нет, всё-таки лучше, т.к. строчка:
Выдаст ошибку ещё до запуска проекта.
Может, и для f-string можно проверку прикрутить?..
Там разные способы предложили, типа такого:
>class_name S
>static func f(vars: Object, text: String) -> String:
>_ return text.format(inst_to_dict(vars))
Использование, например, такое:
>var user_name := "Anon"
>var pet_name := "Godot"
>func greet() -> void:
>_ print(S.f(self, "Hi, {user_name}! How's {pet_name}?"))
С локальными переменными работать не будет.
Но есть нюанс: inst_to_dict() переносит поля Object в Dictionary. Это может быть затратно, если часто это используете на классе с большим числом полей.
https://docs.godotengine.org/en/stable/classes/
Ещё, если я правильно понял, f-string не позволяют использовать tr(), т.е. переводить строки с ключами. Предлагают реализовать ещё ftr"" или типа того.
Но даже если б позволяли - допустим, у нас есть:
>text = ftr"How's your {pet_name}?"
В переводах у нас лежат такие строки:
>"How's your {pet_name}?"
>"Как поживает {pet_name}?"
Теперь представьте, что вы отрефакторили класс:
>var pet_name: String # было
>var pet: Pet # стало
Теперь pet_name не существует, нужен костыль:
>var pet_name := pet.name # извлекаем
>text = ftr"How's your {pet_name}?"
В случае с format():
>text = tr("How's your {pet_name}?").format(
>{"pet_name": pet.name}) # просто меняем эту строку
...хотя это не сильно лучше отдельного var...
...Нет, всё-таки лучше, т.к. строчка:
>{"pet_name": pet_name}) # pet_name не существует
Выдаст ошибку ещё до запуска проекта.
Может, и для f-string можно проверку прикрутить?..
>>10335
Там разные способы предложили, типа такого:
Использование, например, такое:
С локальными переменными работать не будет.
Но есть нюанс: inst_to_dict() переносит поля Object в Dictionary. Это может быть затратно, если часто это используете на классе с большим числом полей.
https://docs.godotengine.org/en/stable/classes/ciErlass_ ANUSgdscrip*u+t PUNCTUMhtm#GQl #class-gdscript-method-inst-to-dict
Ещё, если я правильно понял, f-string не позволяют использовать tr(), т.е. переводить строки с ключами. Предлагают реализовать ещё ftr"" или типа того.
Но даже если б позволяли - допустим, у нас есть:
В переводах у нас лежат такие строки:
Теперь представьте, что вы отрефакторили класс:
Теперь pet_name не существует, нужен костыль:
В случае с format():
...хотя это не сильно лучше отдельного var...
...Нет, всё-таки лучше, т.к. строчка:
Выдаст ошибку ещё до запуска проекта.
Может, и для f-string можно проверку прикрутить?..
Там разные способы предложили, типа такого:
>class_name S
>static func f(vars: Object, text: String) -> String:
>_ return text.format(inst_to_dict(vars))
Использование, например, такое:
>var user_name := "Anon"
>var pet_name := "Godot"
>func greet() -> void:
>_ print(S.f(self, "Hi, {user_name}! How's {pet_name}?"))
С локальными переменными работать не будет.
Но есть нюанс: inst_to_dict() переносит поля Object в Dictionary. Это может быть затратно, если часто это используете на классе с большим числом полей.
https://docs.godotengine.org/en/stable/classes/
Ещё, если я правильно понял, f-string не позволяют использовать tr(), т.е. переводить строки с ключами. Предлагают реализовать ещё ftr"" или типа того.
Но даже если б позволяли - допустим, у нас есть:
>text = ftr"How's your {pet_name}?"
В переводах у нас лежат такие строки:
>"How's your {pet_name}?"
>"Как поживает {pet_name}?"
Теперь представьте, что вы отрефакторили класс:
>var pet_name: String # было
>var pet: Pet # стало
Теперь pet_name не существует, нужен костыль:
>var pet_name := pet.name # извлекаем
>text = ftr"How's your {pet_name}?"
В случае с format():
>text = tr("How's your {pet_name}?").format(
>{"pet_name": pet.name}) # просто меняем эту строку
...хотя это не сильно лучше отдельного var...
...Нет, всё-таки лучше, т.к. строчка:
>{"pet_name": pet_name}) # pet_name не существует
Выдаст ошибку ещё до запуска проекта.
Может, и для f-string можно проверку прикрутить?..
>>10336
Можно пойти други путем, и отрефакторить свои фстринги тоже:
>Теперь pet_name не существует, нужен костыль:
Можно пойти други путем, и отрефакторить свои фстринги тоже:
>text = ftr"How's your {pet.name}?"
>>10447
uuooohh
uuooohh
Сап. Как сделать так чтобы в годот игрок бежал всегда прямо? Независимо от того как идет земля под ним, под углом, верхногами. Плевать, он должен бежать вперед и поворачивать вместе с ней, вот как будто поезд по рельсам. И еще чтобы мог перемещаться влево и вправо, но только тоже как будто спрыгивая с одних рельс на другие(всего три условные линии должно быть)
Делаю что-то типа раннера. В итоге отказался уже от всяких кривых и под углом, бежит у меня челик прямо, я просто ротейчу мир когда мне нужно. Но столкнулся с проблемой, на "трамплинах" кент взлетает и под импульсом отскакивает от земли после приземления(вопрос какого-хрена у него же нет никакого баунса в логике)
На видрил показываю.
Попробовал решить это дело "магнитными" тригерами, где я сбрасываю велосити игроку и как бы приземляю его в нужно точке. Помогло, но только на маленьком промежутке, уже где побольше все тоже самое осталось. Может кто помочь? Может гайд есть по такой теме как у меня, а я найти не могу.
Пик 1 - "магнитный" тригер
Пик 2 - реализация снапа к поверхности
Делаю что-то типа раннера. В итоге отказался уже от всяких кривых и под углом, бежит у меня челик прямо, я просто ротейчу мир когда мне нужно. Но столкнулся с проблемой, на "трамплинах" кент взлетает и под импульсом отскакивает от земли после приземления(вопрос какого-хрена у него же нет никакого баунса в логике)
На видрил показываю.
Попробовал решить это дело "магнитными" тригерами, где я сбрасываю велосити игроку и как бы приземляю его в нужно точке. Помогло, но только на маленьком промежутке, уже где побольше все тоже самое осталось. Может кто помочь? Может гайд есть по такой теме как у меня, а я найти не могу.
Пик 1 - "магнитный" тригер
Пик 2 - реализация снапа к поверхности
>>10526
На первом трамплине отпрыгивает, а на втором уже нормально плавно приземляется. В чем проблема не могу понять
На первом трамплине отпрыгивает, а на втором уже нормально плавно приземляется. В чем проблема не могу понять
478 Кб, 1175x943>>10526
Ой да спизди ты код с ютуба и не парься.
Ой да спизди ты код с ютуба и не парься.
>>10526
Попробуй создать телу физический материал, там есть параметр bouncines (и галочка чтобы сделать его наоборот absorb). Может быть надо и полу сделать такое, не помню.
Попробуй создать телу физический материал, там есть параметр bouncines (и галочка чтобы сделать его наоборот absorb). Может быть надо и полу сделать такое, не помню.
>>10526
Прикольно что оно разобрало твой код со скринов.
Прикольно что оно разобрало твой код со скринов.
>>10526
Алсо, по крайней мере раньше так было, может сейчас что-то поменяли, но velocity и позицию нельзя было менять в произвольный момент времени (а сигнал body_entered это в некотором смысле произвольный с точки зрения физического тика), а надо делать внутри _physics_process, а то и только внутри _integrate_forces. То есть тебе надо в обрабочтчике сигнала в какую-то переменную записывать "хочу поменять на такую-то скорость", а уже в _physics_process эту переменную приплюсовывать,и скорее всего сбрасывать. И следить что она умножается на delta где надо.
Алсо, по крайней мере раньше так было, может сейчас что-то поменяли, но velocity и позицию нельзя было менять в произвольный момент времени (а сигнал body_entered это в некотором смысле произвольный с точки зрения физического тика), а надо делать внутри _physics_process, а то и только внутри _integrate_forces. То есть тебе надо в обрабочтчике сигнала в какую-то переменную записывать "хочу поменять на такую-то скорость", а уже в _physics_process эту переменную приплюсовывать,и скорее всего сбрасывать. И следить что она умножается на delta где надо.
>>10533
Да там по прямой, судя по всему, делают. Но я это по превьюшкам посудил, надо посмотреть.
Да там по прямой, судя по всему, делают. Но я это по превьюшкам посудил, надо посмотреть.
>>10537
Вот у меня были на это подозрения. Но через print() вывел, что в момент тригера и в момент приземления velocity равен (0, 0, 0) (я до этого пытался). Мне не понятно, почему где-то это работает, и игрок плавно приземляется, а где-то нет. Я и стопить физик процесс пробовал на момент "примагничивания", ноль толку.
Вот у меня были на это подозрения. Но через print() вывел, что в момент тригера и в момент приземления velocity равен (0, 0, 0) (я до этого пытался). Мне не понятно, почему где-то это работает, и игрок плавно приземляется, а где-то нет. Я и стопить физик процесс пробовал на момент "примагничивания", ноль толку.
>>10526
Так а может это и не баунсинг тогда. Убери на время tween. Может быть он у тебя просто ловит рейкастом какой то коллайдер и он остается в floor_height.
Так а может это и не баунсинг тогда. Убери на время tween. Может быть он у тебя просто ловит рейкастом какой то коллайдер и он остается в floor_height.
>>10605
Нихера себе. Неужели теперь игры придется делать?
Пойду у Майка обзор смотреть, 18 минут ебать: https://www.youtube.com/watch?v=4Q46A_UaY_4
Нихера себе. Неужели теперь игры придется делать?
Пойду у Майка обзор смотреть, 18 минут ебать: https://www.youtube.com/watch?v=4Q46A_UaY_4
>>10609
гд скрипт слишком нишевый, никакие нейронки его не чекают, максимум по тройке можешь спросить, даже если будешь уточнять по 4, то он извинится и всё равно напишет код по 3
но какие-то концепции всё равно можно и так понять
хотя наверняка есть и по 4 знания у них, но скорее поверхностные, чем какие-то предметные
гд скрипт слишком нишевый, никакие нейронки его не чекают, максимум по тройке можешь спросить, даже если будешь уточнять по 4, то он извинится и всё равно напишет код по 3
но какие-то концепции всё равно можно и так понять
хотя наверняка есть и по 4 знания у них, но скорее поверхностные, чем какие-то предметные
>>10608
Хороший релиз. Мне понравился.
Не, серьёзно. Делать игоры прямо в виар - это то о чём я мечтал. Теперь можно уже начинать копить деньги на шлем.
Хороший релиз. Мне понравился.
Не, серьёзно. Делать игоры прямо в виар - это то о чём я мечтал. Теперь можно уже начинать копить деньги на шлем.
>>10610
Лол. Вот и вот мои посты >>10276 >>10236, весь гдскрипт был написан чатгпт о3 мини и клодом 3.7 соннет. Кучка шейдеров в готовом проекте тоже ими написаны, потому что ебал я шейдеры сам пилить.
>>10609
На данный момент - свежий claude лучше всего. Ты только ему явно версию годота указывай и добавляй что это важно, иначе придется тратить драгоценные запросы на исправление.
Лол. Вот и вот мои посты >>10276 >>10236, весь гдскрипт был написан чатгпт о3 мини и клодом 3.7 соннет. Кучка шейдеров в готовом проекте тоже ими написаны, потому что ебал я шейдеры сам пилить.
>>10609
На данный момент - свежий claude лучше всего. Ты только ему явно версию годота указывай и добавляй что это важно, иначе придется тратить драгоценные запросы на исправление.
>>10385
А если 10 языков по 10000 строк в CSV файлах...
>>10444
Зумер, гугли "транспилер" (transpiler).
Нет, это не "мальчик, пьющий эстроген".
https://duckduckgo.com/?q=gdscript+transpiler
https://github.com/search?q=gdscript+transpiler
>отрефакторить свои фстринги тоже:
>>text = ftr"How's your {pet.name}?"
А если 10 языков по 10000 строк в CSV файлах...
>>10444
>придти к ИИ и сказать "перепиши
Зумер, гугли "транспилер" (transpiler).
Нет, это не "мальчик, пьющий эстроген".
https://duckduckgo.com/?q=gdscript+transpiler
https://github.com/search?q=gdscript+transpiler
>>10619
Он платный что ли? И зачем он нужен платно? Ещё и с регистрацией.
>>10609
GDScript - сам, а поболтать - на http://duck.ai без смс и регистрации.
ИМХО, генерация кода в LLM - это как "визуальная лапша" - не нужно.
>>10608
Зачем смотреть видео от васяна, если разработчики статью написали?
>тратить драгоценные запросы
Он платный что ли? И зачем он нужен платно? Ещё и с регистрацией.
>>10609
>кто какие ии использует для гд скрипта?
GDScript - сам, а поболтать - на http://duck.ai без смс и регистрации.
ИМХО, генерация кода в LLM - это как "визуальная лапша" - не нужно.
>>10608
>Пойду у Майка обзор смотреть, 18 минут
Зачем смотреть видео от васяна, если разработчики статью написали?
>>10660
Есть бесплатные запросы, обновляющиеся каждый день. А про регистрацию - ну сорян, сиди без удобного инструмента тогда. Спойлер - тебе еще иностранный номер для получения смс потребовался бы. И иностранный прокси.
Если сильно не хотеть то причины всегда найдутся, верно?
>Он платный что ли? И зачем он нужен платно? Ещё и с регистрацией.
Есть бесплатные запросы, обновляющиеся каждый день. А про регистрацию - ну сорян, сиди без удобного инструмента тогда. Спойлер - тебе еще иностранный номер для получения смс потребовался бы. И иностранный прокси.
Если сильно не хотеть то причины всегда найдутся, верно?
>>10663
Удобный инструмент - это coze со своим ботом в телеге. Там есть клод 3.5, так что и 3.7 скорее всего завезут. И никаких прокси не надо и с временным номером париться не нужно.
Удобный инструмент - это coze со своим ботом в телеге. Там есть клод 3.5, так что и 3.7 скорее всего завезут. И никаких прокси не надо и с временным номером париться не нужно.
133 Кб, 746x903>>10666
Все норм
Все норм
>>10663
Очередной бредогенератор же. Пока не перейдут с архитектуры Transformer на что-то другое (принципиально другое, а не очередной "что-то-former"), смысла переходить с одной модели на другую нет - что та бред выдает, что эта. Для задачи "кинуть идею и посмотреть как нейронка на это среагирует (какой бред выдаст)" подойдёт любой трансформер, а для чего-то, требующего 100% точности/надёжности/актуальности/отказоустойчивости и т.п. трансформеры принципиально не подходят, потому что это просто генератор "статистически наиболее вероятного токена" (бреда).
Я хотел бы, но на 100% локально, чтобы можно было с ней что-то делать (тренировать и т.п.).
Вообще смешно. Может, ещё фото паспорта нужно для доступа к порции отборного бреда?
>удобного инструмента
Очередной бредогенератор же. Пока не перейдут с архитектуры Transformer на что-то другое (принципиально другое, а не очередной "что-то-former"), смысла переходить с одной модели на другую нет - что та бред выдает, что эта. Для задачи "кинуть идею и посмотреть как нейронка на это среагирует (какой бред выдаст)" подойдёт любой трансформер, а для чего-то, требующего 100% точности/надёжности/актуальности/отказоустойчивости и т.п. трансформеры принципиально не подходят, потому что это просто генератор "статистически наиболее вероятного токена" (бреда).
>Если сильно не хотеть
Я хотел бы, но на 100% локально, чтобы можно было с ней что-то делать (тренировать и т.п.).
>номер для получения смс
Вообще смешно. Может, ещё фото паспорта нужно для доступа к порции отборного бреда?
>>10526
Читать документацию когда-нибудь пробовал?
Физика тут вообще не нужна, используй Path3D и PathFollow3D:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
Для определения ошибок/промахов расставляй простые Area3D.
Если по скриншоту не сможешь разобраться:
1. Делаешь Player класса PathFollow3D, ему ставишь loop = false (т.к. у нас будет много обрезков пути и бегать по кругу нам не нужно). Всё визуальное помещаешь в Node3D, у которой ставишь top_level = true, чтобы можно было плавно интерполировать движения независимо от позиции PathFollow3D, который всегда автоматически прилипает к своему Path3D. Учитывай, что по умолчанию PathFollow3D ещё и вращается, но ты можешь это контролировать. Также делаешь ему Area3D, чтобы можно было зафиксировать падения в ямы, столкновения с препятствиями и т.д. Учитывай, что останавливаться Area3D не будет, ты просто прекращаешь двигаться и проигрываешь анимацию провала над точкой "столкновения".
2. Дорожку начинаешь создавать с Path3D. Скорее всего ты хочешь подставлять следующие участки в рантайме, поэтому придётся наделать кучу сцен разных видов - у каждой свой Path3D, но это не страшно. Главное, чтобы конечная точка одного участка более-менее совпадала с начальной точкой следующего участка, иначе PathFollow3D мгновенно перепрыгнет образовавшуюся дырку. Модельки, триггеры провала (Area3D) и всё такое вешаешь на эту Path3D. Заполнять Path3D точками можно из инспектора, а можно визуально - смотри кнопки сверху окна 3D вида, там по всплывающим подсказкам всё понятно. Если будешь визуально, переключайся на вид сбоку, сверху или спереди (кнопки на numpad), чтобы было проще двигать всё в одной плоскости.
3. Добавляешь первый участок пути, на него вешаешь своего "игрока", начинаешь двигать его через поле progress (в метрах от начала Path3D) или progress_ratio (в процентах от всего пути Path3D). Проверить движение можно через инспектор прямо в редакторе, если что. Когда доходишь до конца имеющегося пути (progress_ratio == 1), достаточно просто "перепрыгнуть" по дереву на следующий Path3D: reparent(следующий_участок). Откуда ты возьмёшь этот следующий участок - дело твоё, я в примере кода беру из текущего участка.
4. Также понадобится какой-то менеджер дорожек, который будет переносить игрока на соседнюю дорожку - принцип тот же, что и при переходе между участками одного пути, только добавишь какую-нибудь анимацию для своей визуальной Node3D - PathFollow3D в любом случае будет мгновенно переключаться (пока находится в потомках какого-либо Path3D). И ещё, наверное, придётся как-то синхронизировать позицию в соседних дорожках (см. функцию get_closest_point() у Curve3D, который в Path3D). Зависит от твоего дизайна дорожек - экспериментируй сам. Можно создать сколько угодно параллельных дорожек, дорожки-развилки и т.д. О, такая идея: делать "зоны перехода" только близко друг другу, т.е. игрок может перепрыгнуть на соседнюю дорожку только пока они рядом; можно просто Area3D навесить.
Скорее всего, твой импульс отправляет CharacterBody3D немного внутрь платформы (буквально - шаг физики меньше запрошенного тобой сдвига, и тело "перешагивает" препятствие), что приводит к резкому отскоку в попытке выйти из препятствия. Это нормальное поведение, просто у тебя слишком мощный импульс - обычно персонажи так резко не двигаются (в физическом плане).
Но повторюсь, тебе здесь CharacterBody3D вообще не нужен, поскольку он предназначен для свободного движения со скольжением вдоль произвольных препятствий - стен, склонов и т.п. Если очень хочется "прилипать ногами к земле", а выставлять Path3D ровно по земле лень - тогда можешь заменить CharacterBody3D простым Raycast3D, который будет определять точку контакта ног от позиции PathFollow3D вниз. Тогда ты точно не слетишь никуда с пути, но будешь иметь контакт ног с физической поверхностью пола. Однако, такую игру можно вообще без StaticBody3D реализовать, отмечая только зоны проигрыша (дырки в полу, стенки, врагов и т.д.), если достаточно точно и ровно провести все Path3D. Кстати, Path3D позволяет создать кривые, которые было бы сложно или затратно реализовывать через коллизии.
Хочу заметить, что скорость движения в типичном раннере очень высокая (относительно обычных экшн игр, где используется CharacterBody3D), и если ещё и графика стилизована мультяшно (плоская заливка и т.п.) - положение ног относительно земли не так важно, как динамичность движений персонажа, которую легко убить "реализмом" точной физической симуляции. Т.е. я б на твоём месте забил на коллизии с землёй и двигал строго по Path3D, ловя только пересечения с препятствиями. Но, конечно, дело твоё, как это решать.
На видео зелёным блоком отмечено начало каждого участка пути - они очень короткие, приблизительно каждые 2 секунды начинается следующий участок. На некоторых участках повороты выглядят слишком резкими - мне было лень возиться со сглаживанием.
Хммм... Может, мне тоже свой раннер сделать?..
Читать документацию когда-нибудь пробовал?
>вот как будто поезд по рельсам
Физика тут вообще не нужна, используй Path3D и PathFollow3D:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
Для определения ошибок/промахов расставляй простые Area3D.
Если по скриншоту не сможешь разобраться:
1. Делаешь Player класса PathFollow3D, ему ставишь loop = false (т.к. у нас будет много обрезков пути и бегать по кругу нам не нужно). Всё визуальное помещаешь в Node3D, у которой ставишь top_level = true, чтобы можно было плавно интерполировать движения независимо от позиции PathFollow3D, который всегда автоматически прилипает к своему Path3D. Учитывай, что по умолчанию PathFollow3D ещё и вращается, но ты можешь это контролировать. Также делаешь ему Area3D, чтобы можно было зафиксировать падения в ямы, столкновения с препятствиями и т.д. Учитывай, что останавливаться Area3D не будет, ты просто прекращаешь двигаться и проигрываешь анимацию провала над точкой "столкновения".
2. Дорожку начинаешь создавать с Path3D. Скорее всего ты хочешь подставлять следующие участки в рантайме, поэтому придётся наделать кучу сцен разных видов - у каждой свой Path3D, но это не страшно. Главное, чтобы конечная точка одного участка более-менее совпадала с начальной точкой следующего участка, иначе PathFollow3D мгновенно перепрыгнет образовавшуюся дырку. Модельки, триггеры провала (Area3D) и всё такое вешаешь на эту Path3D. Заполнять Path3D точками можно из инспектора, а можно визуально - смотри кнопки сверху окна 3D вида, там по всплывающим подсказкам всё понятно. Если будешь визуально, переключайся на вид сбоку, сверху или спереди (кнопки на numpad), чтобы было проще двигать всё в одной плоскости.
3. Добавляешь первый участок пути, на него вешаешь своего "игрока", начинаешь двигать его через поле progress (в метрах от начала Path3D) или progress_ratio (в процентах от всего пути Path3D). Проверить движение можно через инспектор прямо в редакторе, если что. Когда доходишь до конца имеющегося пути (progress_ratio == 1), достаточно просто "перепрыгнуть" по дереву на следующий Path3D: reparent(следующий_участок). Откуда ты возьмёшь этот следующий участок - дело твоё, я в примере кода беру из текущего участка.
4. Также понадобится какой-то менеджер дорожек, который будет переносить игрока на соседнюю дорожку - принцип тот же, что и при переходе между участками одного пути, только добавишь какую-нибудь анимацию для своей визуальной Node3D - PathFollow3D в любом случае будет мгновенно переключаться (пока находится в потомках какого-либо Path3D). И ещё, наверное, придётся как-то синхронизировать позицию в соседних дорожках (см. функцию get_closest_point() у Curve3D, который в Path3D). Зависит от твоего дизайна дорожек - экспериментируй сам. Можно создать сколько угодно параллельных дорожек, дорожки-развилки и т.д. О, такая идея: делать "зоны перехода" только близко друг другу, т.е. игрок может перепрыгнуть на соседнюю дорожку только пока они рядом; можно просто Area3D навесить.
>под импульсом отскакивает от земли после приземления
Скорее всего, твой импульс отправляет CharacterBody3D немного внутрь платформы (буквально - шаг физики меньше запрошенного тобой сдвига, и тело "перешагивает" препятствие), что приводит к резкому отскоку в попытке выйти из препятствия. Это нормальное поведение, просто у тебя слишком мощный импульс - обычно персонажи так резко не двигаются (в физическом плане).
Но повторюсь, тебе здесь CharacterBody3D вообще не нужен, поскольку он предназначен для свободного движения со скольжением вдоль произвольных препятствий - стен, склонов и т.п. Если очень хочется "прилипать ногами к земле", а выставлять Path3D ровно по земле лень - тогда можешь заменить CharacterBody3D простым Raycast3D, который будет определять точку контакта ног от позиции PathFollow3D вниз. Тогда ты точно не слетишь никуда с пути, но будешь иметь контакт ног с физической поверхностью пола. Однако, такую игру можно вообще без StaticBody3D реализовать, отмечая только зоны проигрыша (дырки в полу, стенки, врагов и т.д.), если достаточно точно и ровно провести все Path3D. Кстати, Path3D позволяет создать кривые, которые было бы сложно или затратно реализовывать через коллизии.
Хочу заметить, что скорость движения в типичном раннере очень высокая (относительно обычных экшн игр, где используется CharacterBody3D), и если ещё и графика стилизована мультяшно (плоская заливка и т.п.) - положение ног относительно земли не так важно, как динамичность движений персонажа, которую легко убить "реализмом" точной физической симуляции. Т.е. я б на твоём месте забил на коллизии с землёй и двигал строго по Path3D, ловя только пересечения с препятствиями. Но, конечно, дело твоё, как это решать.
На видео зелёным блоком отмечено начало каждого участка пути - они очень короткие, приблизительно каждые 2 секунды начинается следующий участок. На некоторых участках повороты выглядят слишком резкими - мне было лень возиться со сглаживанием.
Хммм... Может, мне тоже свой раннер сделать?..
>>10526
Читать документацию когда-нибудь пробовал?
Физика тут вообще не нужна, используй Path3D и PathFollow3D:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
Для определения ошибок/промахов расставляй простые Area3D.
Если по скриншоту не сможешь разобраться:
1. Делаешь Player класса PathFollow3D, ему ставишь loop = false (т.к. у нас будет много обрезков пути и бегать по кругу нам не нужно). Всё визуальное помещаешь в Node3D, у которой ставишь top_level = true, чтобы можно было плавно интерполировать движения независимо от позиции PathFollow3D, который всегда автоматически прилипает к своему Path3D. Учитывай, что по умолчанию PathFollow3D ещё и вращается, но ты можешь это контролировать. Также делаешь ему Area3D, чтобы можно было зафиксировать падения в ямы, столкновения с препятствиями и т.д. Учитывай, что останавливаться Area3D не будет, ты просто прекращаешь двигаться и проигрываешь анимацию провала над точкой "столкновения".
2. Дорожку начинаешь создавать с Path3D. Скорее всего ты хочешь подставлять следующие участки в рантайме, поэтому придётся наделать кучу сцен разных видов - у каждой свой Path3D, но это не страшно. Главное, чтобы конечная точка одного участка более-менее совпадала с начальной точкой следующего участка, иначе PathFollow3D мгновенно перепрыгнет образовавшуюся дырку. Модельки, триггеры провала (Area3D) и всё такое вешаешь на эту Path3D. Заполнять Path3D точками можно из инспектора, а можно визуально - смотри кнопки сверху окна 3D вида, там по всплывающим подсказкам всё понятно. Если будешь визуально, переключайся на вид сбоку, сверху или спереди (кнопки на numpad), чтобы было проще двигать всё в одной плоскости.
3. Добавляешь первый участок пути, на него вешаешь своего "игрока", начинаешь двигать его через поле progress (в метрах от начала Path3D) или progress_ratio (в процентах от всего пути Path3D). Проверить движение можно через инспектор прямо в редакторе, если что. Когда доходишь до конца имеющегося пути (progress_ratio == 1), достаточно просто "перепрыгнуть" по дереву на следующий Path3D: reparent(следующий_участок). Откуда ты возьмёшь этот следующий участок - дело твоё, я в примере кода беру из текущего участка.
4. Также понадобится какой-то менеджер дорожек, который будет переносить игрока на соседнюю дорожку - принцип тот же, что и при переходе между участками одного пути, только добавишь какую-нибудь анимацию для своей визуальной Node3D - PathFollow3D в любом случае будет мгновенно переключаться (пока находится в потомках какого-либо Path3D). И ещё, наверное, придётся как-то синхронизировать позицию в соседних дорожках (см. функцию get_closest_point() у Curve3D, который в Path3D). Зависит от твоего дизайна дорожек - экспериментируй сам. Можно создать сколько угодно параллельных дорожек, дорожки-развилки и т.д. О, такая идея: делать "зоны перехода" только близко друг другу, т.е. игрок может перепрыгнуть на соседнюю дорожку только пока они рядом; можно просто Area3D навесить.
Скорее всего, твой импульс отправляет CharacterBody3D немного внутрь платформы (буквально - шаг физики меньше запрошенного тобой сдвига, и тело "перешагивает" препятствие), что приводит к резкому отскоку в попытке выйти из препятствия. Это нормальное поведение, просто у тебя слишком мощный импульс - обычно персонажи так резко не двигаются (в физическом плане).
Но повторюсь, тебе здесь CharacterBody3D вообще не нужен, поскольку он предназначен для свободного движения со скольжением вдоль произвольных препятствий - стен, склонов и т.п. Если очень хочется "прилипать ногами к земле", а выставлять Path3D ровно по земле лень - тогда можешь заменить CharacterBody3D простым Raycast3D, который будет определять точку контакта ног от позиции PathFollow3D вниз. Тогда ты точно не слетишь никуда с пути, но будешь иметь контакт ног с физической поверхностью пола. Однако, такую игру можно вообще без StaticBody3D реализовать, отмечая только зоны проигрыша (дырки в полу, стенки, врагов и т.д.), если достаточно точно и ровно провести все Path3D. Кстати, Path3D позволяет создать кривые, которые было бы сложно или затратно реализовывать через коллизии.
Хочу заметить, что скорость движения в типичном раннере очень высокая (относительно обычных экшн игр, где используется CharacterBody3D), и если ещё и графика стилизована мультяшно (плоская заливка и т.п.) - положение ног относительно земли не так важно, как динамичность движений персонажа, которую легко убить "реализмом" точной физической симуляции. Т.е. я б на твоём месте забил на коллизии с землёй и двигал строго по Path3D, ловя только пересечения с препятствиями. Но, конечно, дело твоё, как это решать.
На видео зелёным блоком отмечено начало каждого участка пути - они очень короткие, приблизительно каждые 2 секунды начинается следующий участок. На некоторых участках повороты выглядят слишком резкими - мне было лень возиться со сглаживанием.
Хммм... Может, мне тоже свой раннер сделать?..
Читать документацию когда-нибудь пробовал?
>вот как будто поезд по рельсам
Физика тут вообще не нужна, используй Path3D и PathFollow3D:
https://docs.godotengine.org/en/stable/classes/class_path3d.html
Для определения ошибок/промахов расставляй простые Area3D.
Если по скриншоту не сможешь разобраться:
1. Делаешь Player класса PathFollow3D, ему ставишь loop = false (т.к. у нас будет много обрезков пути и бегать по кругу нам не нужно). Всё визуальное помещаешь в Node3D, у которой ставишь top_level = true, чтобы можно было плавно интерполировать движения независимо от позиции PathFollow3D, который всегда автоматически прилипает к своему Path3D. Учитывай, что по умолчанию PathFollow3D ещё и вращается, но ты можешь это контролировать. Также делаешь ему Area3D, чтобы можно было зафиксировать падения в ямы, столкновения с препятствиями и т.д. Учитывай, что останавливаться Area3D не будет, ты просто прекращаешь двигаться и проигрываешь анимацию провала над точкой "столкновения".
2. Дорожку начинаешь создавать с Path3D. Скорее всего ты хочешь подставлять следующие участки в рантайме, поэтому придётся наделать кучу сцен разных видов - у каждой свой Path3D, но это не страшно. Главное, чтобы конечная точка одного участка более-менее совпадала с начальной точкой следующего участка, иначе PathFollow3D мгновенно перепрыгнет образовавшуюся дырку. Модельки, триггеры провала (Area3D) и всё такое вешаешь на эту Path3D. Заполнять Path3D точками можно из инспектора, а можно визуально - смотри кнопки сверху окна 3D вида, там по всплывающим подсказкам всё понятно. Если будешь визуально, переключайся на вид сбоку, сверху или спереди (кнопки на numpad), чтобы было проще двигать всё в одной плоскости.
3. Добавляешь первый участок пути, на него вешаешь своего "игрока", начинаешь двигать его через поле progress (в метрах от начала Path3D) или progress_ratio (в процентах от всего пути Path3D). Проверить движение можно через инспектор прямо в редакторе, если что. Когда доходишь до конца имеющегося пути (progress_ratio == 1), достаточно просто "перепрыгнуть" по дереву на следующий Path3D: reparent(следующий_участок). Откуда ты возьмёшь этот следующий участок - дело твоё, я в примере кода беру из текущего участка.
4. Также понадобится какой-то менеджер дорожек, который будет переносить игрока на соседнюю дорожку - принцип тот же, что и при переходе между участками одного пути, только добавишь какую-нибудь анимацию для своей визуальной Node3D - PathFollow3D в любом случае будет мгновенно переключаться (пока находится в потомках какого-либо Path3D). И ещё, наверное, придётся как-то синхронизировать позицию в соседних дорожках (см. функцию get_closest_point() у Curve3D, который в Path3D). Зависит от твоего дизайна дорожек - экспериментируй сам. Можно создать сколько угодно параллельных дорожек, дорожки-развилки и т.д. О, такая идея: делать "зоны перехода" только близко друг другу, т.е. игрок может перепрыгнуть на соседнюю дорожку только пока они рядом; можно просто Area3D навесить.
>под импульсом отскакивает от земли после приземления
Скорее всего, твой импульс отправляет CharacterBody3D немного внутрь платформы (буквально - шаг физики меньше запрошенного тобой сдвига, и тело "перешагивает" препятствие), что приводит к резкому отскоку в попытке выйти из препятствия. Это нормальное поведение, просто у тебя слишком мощный импульс - обычно персонажи так резко не двигаются (в физическом плане).
Но повторюсь, тебе здесь CharacterBody3D вообще не нужен, поскольку он предназначен для свободного движения со скольжением вдоль произвольных препятствий - стен, склонов и т.п. Если очень хочется "прилипать ногами к земле", а выставлять Path3D ровно по земле лень - тогда можешь заменить CharacterBody3D простым Raycast3D, который будет определять точку контакта ног от позиции PathFollow3D вниз. Тогда ты точно не слетишь никуда с пути, но будешь иметь контакт ног с физической поверхностью пола. Однако, такую игру можно вообще без StaticBody3D реализовать, отмечая только зоны проигрыша (дырки в полу, стенки, врагов и т.д.), если достаточно точно и ровно провести все Path3D. Кстати, Path3D позволяет создать кривые, которые было бы сложно или затратно реализовывать через коллизии.
Хочу заметить, что скорость движения в типичном раннере очень высокая (относительно обычных экшн игр, где используется CharacterBody3D), и если ещё и графика стилизована мультяшно (плоская заливка и т.п.) - положение ног относительно земли не так важно, как динамичность движений персонажа, которую легко убить "реализмом" точной физической симуляции. Т.е. я б на твоём месте забил на коллизии с землёй и двигал строго по Path3D, ловя только пересечения с препятствиями. Но, конечно, дело твоё, как это решать.
На видео зелёным блоком отмечено начало каждого участка пути - они очень короткие, приблизительно каждые 2 секунды начинается следующий участок. На некоторых участках повороты выглядят слишком резкими - мне было лень возиться со сглаживанием.
Хммм... Может, мне тоже свой раннер сделать?..
>>10526 >>10674
Забыл про прыжки. У меня в коде прыжков нет (все прыжки на видео "запечены" в Path3D), но для их реализации предлагаю двигать только Node3D, следующий за PathFollow3D ("Visuals"). Т.е. прыжок будет исключительно вдоль оси Y локальной системы координат PathFollow3D, который автоматически вращается вокруг пути Path3D. В общем, должно быть несложно сделать. Т.к. Area3D будет связана с Visuals, тогда PathFollow3D может проходить сквозь все препятствия, пока Visuals пытается их избежать прыжками.
Генерацию пути я сделал прямо внутри PathPart, потому что так было проще. Для множества параллельных путей это лучше делать снаружи (PathManager), чтобы они не пересекались.
Алсо, если раннер бесконечный, то не забывай удалять пройденные участки - queue_free(). А то новички порой жалуются на падение производительности, забывая удалять лишние объекты.
PathPartLibrary - это потомок Resource:
Чтобы избежать циклической зависимости (в процессе считывания сцен с диска), он должен быть в PathManager. Текст ошибки непонятный если вдруг попытаешься сохранить этот ресурс в @export внутри PathPart (которые потом помещаются в массив) - Godot почему-то пытается рекурсивно загружать уже загруженные сцены и спотыкается об это, заменяя указанные тобой сцены на null и жалуясь на то, что не может найти null (лол).
Алсо, Path3D используется не только для таких примитивных игр, но и там, где свободный CharacterBody3D или RigidBody3D должен проехать по маршруту - например, в играх про скейтборд или паркур могут быть специальные зоны фиксированного маршрута - там игрок запрыгивает на PathFollow3D. По крайней мере, это способ, удобный в Godot. Физика при этом замораживается (в случае RigidBody3D) и move_and_slide() (в случае CharacterBody3D) не используется - просто меняешь transform, пока рельса не закончится.
Поезда в опенворлд экшн играх (GTA-like) примерно похожим образом делаются, поэтому они чаще всего "неуязвимые" - невозможно сдвинуть с места через столкновение с другим транспортом, хотя казалось бы - обычный физический транспорт. Просто у них физики как таковой нет - это движущийся строго по маршруту StaticBody3D или что-то вроде того.
Но в принципе, можно "тащить" позади PathFollow3D реальный физический объект с полной физической симуляцией, чтоб он стукался об препятствия, подпрыгивал и т.д. Только он скорее всего где-нибудь застрянет и будет сложно вернуть его на положенное место.
А ещё с помощью Path3D можно сделать змейку...
Забыл про прыжки. У меня в коде прыжков нет (все прыжки на видео "запечены" в Path3D), но для их реализации предлагаю двигать только Node3D, следующий за PathFollow3D ("Visuals"). Т.е. прыжок будет исключительно вдоль оси Y локальной системы координат PathFollow3D, который автоматически вращается вокруг пути Path3D. В общем, должно быть несложно сделать. Т.к. Area3D будет связана с Visuals, тогда PathFollow3D может проходить сквозь все препятствия, пока Visuals пытается их избежать прыжками.
Генерацию пути я сделал прямо внутри PathPart, потому что так было проще. Для множества параллельных путей это лучше делать снаружи (PathManager), чтобы они не пересекались.
Алсо, если раннер бесконечный, то не забывай удалять пройденные участки - queue_free(). А то новички порой жалуются на падение производительности, забывая удалять лишние объекты.
PathPartLibrary - это потомок Resource:
>@export var parts: Array[PackedScene]
Чтобы избежать циклической зависимости (в процессе считывания сцен с диска), он должен быть в PathManager. Текст ошибки непонятный если вдруг попытаешься сохранить этот ресурс в @export внутри PathPart (которые потом помещаются в массив) - Godot почему-то пытается рекурсивно загружать уже загруженные сцены и спотыкается об это, заменяя указанные тобой сцены на null и жалуясь на то, что не может найти null (лол).
Алсо, Path3D используется не только для таких примитивных игр, но и там, где свободный CharacterBody3D или RigidBody3D должен проехать по маршруту - например, в играх про скейтборд или паркур могут быть специальные зоны фиксированного маршрута - там игрок запрыгивает на PathFollow3D. По крайней мере, это способ, удобный в Godot. Физика при этом замораживается (в случае RigidBody3D) и move_and_slide() (в случае CharacterBody3D) не используется - просто меняешь transform, пока рельса не закончится.
Поезда в опенворлд экшн играх (GTA-like) примерно похожим образом делаются, поэтому они чаще всего "неуязвимые" - невозможно сдвинуть с места через столкновение с другим транспортом, хотя казалось бы - обычный физический транспорт. Просто у них физики как таковой нет - это движущийся строго по маршруту StaticBody3D или что-то вроде того.
Но в принципе, можно "тащить" позади PathFollow3D реальный физический объект с полной физической симуляцией, чтоб он стукался об препятствия, подпрыгивал и т.д. Только он скорее всего где-нибудь застрянет и будет сложно вернуть его на положенное место.
А ещё с помощью Path3D можно сделать змейку...
>>10526 >>10674
Забыл про прыжки. У меня в коде прыжков нет (все прыжки на видео "запечены" в Path3D), но для их реализации предлагаю двигать только Node3D, следующий за PathFollow3D ("Visuals"). Т.е. прыжок будет исключительно вдоль оси Y локальной системы координат PathFollow3D, который автоматически вращается вокруг пути Path3D. В общем, должно быть несложно сделать. Т.к. Area3D будет связана с Visuals, тогда PathFollow3D может проходить сквозь все препятствия, пока Visuals пытается их избежать прыжками.
Генерацию пути я сделал прямо внутри PathPart, потому что так было проще. Для множества параллельных путей это лучше делать снаружи (PathManager), чтобы они не пересекались.
Алсо, если раннер бесконечный, то не забывай удалять пройденные участки - queue_free(). А то новички порой жалуются на падение производительности, забывая удалять лишние объекты.
PathPartLibrary - это потомок Resource:
Чтобы избежать циклической зависимости (в процессе считывания сцен с диска), он должен быть в PathManager. Текст ошибки непонятный если вдруг попытаешься сохранить этот ресурс в @export внутри PathPart (которые потом помещаются в массив) - Godot почему-то пытается рекурсивно загружать уже загруженные сцены и спотыкается об это, заменяя указанные тобой сцены на null и жалуясь на то, что не может найти null (лол).
Алсо, Path3D используется не только для таких примитивных игр, но и там, где свободный CharacterBody3D или RigidBody3D должен проехать по маршруту - например, в играх про скейтборд или паркур могут быть специальные зоны фиксированного маршрута - там игрок запрыгивает на PathFollow3D. По крайней мере, это способ, удобный в Godot. Физика при этом замораживается (в случае RigidBody3D) и move_and_slide() (в случае CharacterBody3D) не используется - просто меняешь transform, пока рельса не закончится.
Поезда в опенворлд экшн играх (GTA-like) примерно похожим образом делаются, поэтому они чаще всего "неуязвимые" - невозможно сдвинуть с места через столкновение с другим транспортом, хотя казалось бы - обычный физический транспорт. Просто у них физики как таковой нет - это движущийся строго по маршруту StaticBody3D или что-то вроде того.
Но в принципе, можно "тащить" позади PathFollow3D реальный физический объект с полной физической симуляцией, чтоб он стукался об препятствия, подпрыгивал и т.д. Только он скорее всего где-нибудь застрянет и будет сложно вернуть его на положенное место.
А ещё с помощью Path3D можно сделать змейку...
Забыл про прыжки. У меня в коде прыжков нет (все прыжки на видео "запечены" в Path3D), но для их реализации предлагаю двигать только Node3D, следующий за PathFollow3D ("Visuals"). Т.е. прыжок будет исключительно вдоль оси Y локальной системы координат PathFollow3D, который автоматически вращается вокруг пути Path3D. В общем, должно быть несложно сделать. Т.к. Area3D будет связана с Visuals, тогда PathFollow3D может проходить сквозь все препятствия, пока Visuals пытается их избежать прыжками.
Генерацию пути я сделал прямо внутри PathPart, потому что так было проще. Для множества параллельных путей это лучше делать снаружи (PathManager), чтобы они не пересекались.
Алсо, если раннер бесконечный, то не забывай удалять пройденные участки - queue_free(). А то новички порой жалуются на падение производительности, забывая удалять лишние объекты.
PathPartLibrary - это потомок Resource:
>@export var parts: Array[PackedScene]
Чтобы избежать циклической зависимости (в процессе считывания сцен с диска), он должен быть в PathManager. Текст ошибки непонятный если вдруг попытаешься сохранить этот ресурс в @export внутри PathPart (которые потом помещаются в массив) - Godot почему-то пытается рекурсивно загружать уже загруженные сцены и спотыкается об это, заменяя указанные тобой сцены на null и жалуясь на то, что не может найти null (лол).
Алсо, Path3D используется не только для таких примитивных игр, но и там, где свободный CharacterBody3D или RigidBody3D должен проехать по маршруту - например, в играх про скейтборд или паркур могут быть специальные зоны фиксированного маршрута - там игрок запрыгивает на PathFollow3D. По крайней мере, это способ, удобный в Godot. Физика при этом замораживается (в случае RigidBody3D) и move_and_slide() (в случае CharacterBody3D) не используется - просто меняешь transform, пока рельса не закончится.
Поезда в опенворлд экшн играх (GTA-like) примерно похожим образом делаются, поэтому они чаще всего "неуязвимые" - невозможно сдвинуть с места через столкновение с другим транспортом, хотя казалось бы - обычный физический транспорт. Просто у них физики как таковой нет - это движущийся строго по маршруту StaticBody3D или что-то вроде того.
Но в принципе, можно "тащить" позади PathFollow3D реальный физический объект с полной физической симуляцией, чтоб он стукался об препятствия, подпрыгивал и т.д. Только он скорее всего где-нибудь застрянет и будет сложно вернуть его на положенное место.
А ещё с помощью Path3D можно сделать змейку...
>>10674
Кому интересно: в старом коде движение равномерное, но это нереалистично. Можно очень легко симулировать замедление на подъёме и ускорение на спуске, если добавить ресурс Curve к пути (каждому участку свой) и умножая полученное значение на собственную скорость. Где это может быть полезно? Например, американские горки... Знаю, можно было бы записать в AnimationPlayer, но мне кажется, что подход с Curve в инспекторе более наглядный и его проще править.
Полное отсутствие физики позволяет получить больше контроля над скоростью и траекторией, что может быть важно в таком линейном аттракционе.
Кому интересно: в старом коде движение равномерное, но это нереалистично. Можно очень легко симулировать замедление на подъёме и ускорение на спуске, если добавить ресурс Curve к пути (каждому участку свой) и умножая полученное значение на собственную скорость. Где это может быть полезно? Например, американские горки... Знаю, можно было бы записать в AnimationPlayer, но мне кажется, что подход с Curve в инспекторе более наглядный и его проще править.
Полное отсутствие физики позволяет получить больше контроля над скоростью и траекторией, что может быть важно в таком линейном аттракционе.
>>10674
Спасибо за такой подробный гайд. Документацию я читаю, сенсей! Утром и вечером, вместо библии. хД.
Я думал про Path3D, но чего-то он мне не понравился. Наверное, потому что еще есть идея снять ограничения в виде линий передвижения и дать свободно перемещаться по платформе. Аля игры про сноуборды\лыжи.
Делой. Я лично стал пробовать разные жанры. Так понял, это ловушка новичка. Два года делал только платформеры, ни чему не научился, ни хрена не сделал. А вот на новый год решил перемены устроить. 2д головоломка, потом тридэ карточные войны, а теперь вот раннер пробую. По ощущениям, гораздо больше стал понимать.
По твоим наставлениям попробую Path, по крайней мере уже буду знать чаво это такое. Еще раз санкью.
>>10678
Блин, да это супер удобно. Я раньше подобное либо через твины делал, либо через AnimationPlayer.
Спасибо за такой подробный гайд. Документацию я читаю, сенсей! Утром и вечером, вместо библии. хД.
Я думал про Path3D, но чего-то он мне не понравился. Наверное, потому что еще есть идея снять ограничения в виде линий передвижения и дать свободно перемещаться по платформе. Аля игры про сноуборды\лыжи.
>Хммм... Может, мне тоже свой раннер сделать?..
Делой. Я лично стал пробовать разные жанры. Так понял, это ловушка новичка. Два года делал только платформеры, ни чему не научился, ни хрена не сделал. А вот на новый год решил перемены устроить. 2д головоломка, потом тридэ карточные войны, а теперь вот раннер пробую. По ощущениям, гораздо больше стал понимать.
По твоим наставлениям попробую Path, по крайней мере уже буду знать чаво это такое. Еще раз санкью.
>>10678
Блин, да это супер удобно. Я раньше подобное либо через твины делал, либо через AnimationPlayer.
>>10671
Не читал твой бредогенератор.
Это ты пару тредов назад про это вопрошал? Тебе уже объясняли "как", но смотрю ты все еще "хотел бы".
Не читал твой бредогенератор.
>Я хотел бы, но на 100% локально
Это ты пару тредов назад про это вопрошал? Тебе уже объясняли "как", но смотрю ты все еще "хотел бы".
4,8 Мб, mp4,1280x720, 0:41
Новая реализация CSG
>>10689
Толщеходы наоборот с узколазами.
Толщеходы наоборот с узколазами.
147 Кб, 1024x702>>10812
Годот-менеджер есть в репах? Наверняка есть. Ставишь его, а движок уже им грузишь.
Годот-менеджер есть в репах? Наверняка есть. Ставишь его, а движок уже им грузишь.
30 Кб, 772x342Шаблоны экспорта всё жирнее становятся.
Зачем качать все платформы, если мне из них потребуется только винда64?
Зачем качать все платформы, если мне из них потребуется только винда64?
>>10824
Ну не качай весь. Сегодня какой то набег неосиляторов?
https://stackoverflow.com/questions/8543214/is-it-possible-to-download-just-part-of-a-zip-archive-e-g-one-file
Ну не качай весь. Сегодня какой то набег неосиляторов?
https://stackoverflow.com/questions/8543214/is-it-possible-to-download-just-part-of-a-zip-archive-e-g-one-file
>>10829
Ты какой-то туповатый. Хорошо, обьясню как для дебилов: Покажи как это делает движок искаропки в его движковом окне загрузки шаблонов, о чем речь изначально и была. Не покажешь, потому что ты влез в тред с какой-то кразноглазой хуйнёй, и хвастаешься своим красноглазием. С понтом будто я не осилил твою хуйню, о которой я в принципе никогда не думал.
Ты какой-то туповатый. Хорошо, обьясню как для дебилов: Покажи как это делает движок искаропки в его движковом окне загрузки шаблонов, о чем речь изначально и была. Не покажешь, потому что ты влез в тред с какой-то кразноглазой хуйнёй, и хвастаешься своим красноглазием. С понтом будто я не осилил твою хуйню, о которой я в принципе никогда не думал.
>>10830
Не устану повторять - не будь рабом компьютера, учись, развивайся. Тебе надо скачать только один файл из зипа - выясни где находится этот зип и как скачать оттуда один файл, не будь рабом мышки и менюшек.
Не устану повторять - не будь рабом компьютера, учись, развивайся. Тебе надо скачать только один файл из зипа - выясни где находится этот зип и как скачать оттуда один файл, не будь рабом мышки и менюшек.
>>10830
Никогда не пользовался этим окошком. Не вижу в нем нужды. Ведь темплейты всегда ссылкой рядом со ссылкой на скачивание самого движка. Ну раз такой дерзкий, иди и напиши PR чтобы скачивалась только нужная платформа, если не умеешь - то напиши пропозал или если он уже есть, найди и залайкай в топ.
Никогда не пользовался этим окошком. Не вижу в нем нужды. Ведь темплейты всегда ссылкой рядом со ссылкой на скачивание самого движка. Ну раз такой дерзкий, иди и напиши PR чтобы скачивалась только нужная платформа, если не умеешь - то напиши пропозал или если он уже есть, найди и залайкай в топ.
Чет на ютубе и реддите тишина про убершейдеры. Чому так? Где же эти видосы в которых инсейнебала говорят что фризов больше нет?
Аноны, подскажите, какой переход можно сделать между двумя 3д камерами? Искал, но ничего толком полезного не нашёл.
>>10880
Подскажи для начала что ты подразумеваешь под "переходом между двумя 3д камерами".
Подскажи для начала что ты подразумеваешь под "переходом между двумя 3д камерами".
>>10882
Можешь твинить трансформ первой камеры до трансформа другой, если надо физически двигать. Если плавный переход картинки-в-картинку - я бы делал скриншот первой камеры (get_texture/get_image), переключался на вторую, наложив сверху скриншот первой через TextureRect, и плавно бы снижал скрину прозрачность.
Можешь твинить трансформ первой камеры до трансформа другой, если надо физически двигать. Если плавный переход картинки-в-картинку - я бы делал скриншот первой камеры (get_texture/get_image), переключался на вторую, наложив сверху скриншот первой через TextureRect, и плавно бы снижал скрину прозрачность.
>>10883
Спасибо
Спасибо
>>10880
Чекни PhantomCamera для 4 или VCamera для 3
Чекни PhantomCamera для 4 или VCamera для 3
Пришло время делать игры.
Не можешь начать? Скачай один из шаблонов вместо создания пустого проекта. Там уже много шаблонов, среди них есть даже годные. Я помню времена 3.0.6 когда в ассетлибе были 3,5 кривых шаблона, написанных лично Хуаном. С тех пор многое изменилось. Хуан уже не пишет шаблоны, теперь их пишут ютуберы, сопровождая сериями видеоуроков по использованию.
То есть, прямо сейчас уже ты можешь скачать шаблон, в котором уже реализованы базовые механики, контроллеры, меню, компонентные системы, и просто добавляешь свой контент.
Давай, делай, делай игры!
Не можешь начать? Скачай один из шаблонов вместо создания пустого проекта. Там уже много шаблонов, среди них есть даже годные. Я помню времена 3.0.6 когда в ассетлибе были 3,5 кривых шаблона, написанных лично Хуаном. С тех пор многое изменилось. Хуан уже не пишет шаблоны, теперь их пишут ютуберы, сопровождая сериями видеоуроков по использованию.
То есть, прямо сейчас уже ты можешь скачать шаблон, в котором уже реализованы базовые механики, контроллеры, меню, компонентные системы, и просто добавляешь свой контент.
Давай, делай, делай игры!
>>10679
Там вполне может быть такой же "захардкоженный" Path3D, т.е. смещение по горизонтали - имитация. Аналогично описанному выше прыжку, смещаешь отдельную Node3D с графикой и триггерами Area3D, оставляя PathFollow3D катиться вдоль Path3D. Т.е. позволяешь игроку уклоняться от препятствий одновременно по двум осям, но автоматически продолжаешь движение вдоль третьей оси. Можно придумать что-то вроде движения внтури трубы.
Использование CharacterBody3D имеет смысл, если планируешь полноценный 3D платформер, где игрок получает свободу двигаться куда и как угодно, т.е. предсказать его маршрут становится невозможно; скольжение и отскоки нужны именно для того, чтоб избежать застреваний в каком-нибудь узком месте, которое игрок случайно обнаружил, бегая по карте.
Ну, чему-то же ты научился, наверное. В жанре 2D платформеров многое можно реализовать. Чисто технически, Terraria - "всего лишь" 2D платформер...
Это хорошо, но имхо, главное - внимательно изучать существующие игры, когда играешь в них, а также стремиться реализовать то, во что нравится играть. Конечно, в соло не сделать ААА экшн эдвенчуру, но зачем тратить время на жанры, которые тебя не привлекают? Для разработки полноценной игры требуется масса времени - делая что-то, что тебя не привлекает, ты рискуешь потерять мотивацию...
Например, я б мог сделать гоночку, файтинг, всякие головоломки. Т.е. я понимаю в общих чертах как это делается, но мотивации делать игры таких жанров вообще нет, а контента там нужно много, и много подводных камней в геймплее. Игроки будут ждать определённых классических фишек, а я сам в игры данных жанров почти не играл и не хочу играть. Т.е. получится технически рабочая, но скучная игра.
Часто встречаю подобные игры в интернете: да, игра рабочая, но чувствуется, что она безразлична своему разработчику. Зачем, спрашивается, делал? Понятно, хотелось заработать, но в результате вышло нечто бессмысленное: вторичное, безыдейное, клон клона. Игроки предпочтут игру от автора, который шарит в конкретном жанре, а шарят люди обычно в том, что привлекает их больше всего, т.е. во что они играют регулярно или больше всего остального.
Так что я б не рекомендовал делать игры лишь ради абстрактного "опыта игр разных жанров". Чисто ради разностороннего опыта нужно поиграть игры разных жанров; разрабатывать нужно то, что тебя цепляет.
Нет, одного игрового опыта недостаточно для игры, геймдизайн требует много чего ещё, чего игроки не замечают на поверхности. Но и совсем без опыта и мотивации как игрока не получится быть хорошим геймдизайнером в неинтересном для тебя жанре.
Это, наверное, самое большое отличие геймдева от остальных направлений айти и инженерии в целом: геймдизайнер должен быть первым пользователем, иначе получится бессмысленная хрень ни для кого.
>Аля игры про сноуборды\лыжи.
Там вполне может быть такой же "захардкоженный" Path3D, т.е. смещение по горизонтали - имитация. Аналогично описанному выше прыжку, смещаешь отдельную Node3D с графикой и триггерами Area3D, оставляя PathFollow3D катиться вдоль Path3D. Т.е. позволяешь игроку уклоняться от препятствий одновременно по двум осям, но автоматически продолжаешь движение вдоль третьей оси. Можно придумать что-то вроде движения внтури трубы.
Использование CharacterBody3D имеет смысл, если планируешь полноценный 3D платформер, где игрок получает свободу двигаться куда и как угодно, т.е. предсказать его маршрут становится невозможно; скольжение и отскоки нужны именно для того, чтоб избежать застреваний в каком-нибудь узком месте, которое игрок случайно обнаружил, бегая по карте.
>делал только платформеры, ни чему не научился
Ну, чему-то же ты научился, наверное. В жанре 2D платформеров многое можно реализовать. Чисто технически, Terraria - "всего лишь" 2D платформер...
>стал пробовать разные жанры
Это хорошо, но имхо, главное - внимательно изучать существующие игры, когда играешь в них, а также стремиться реализовать то, во что нравится играть. Конечно, в соло не сделать ААА экшн эдвенчуру, но зачем тратить время на жанры, которые тебя не привлекают? Для разработки полноценной игры требуется масса времени - делая что-то, что тебя не привлекает, ты рискуешь потерять мотивацию...
Например, я б мог сделать гоночку, файтинг, всякие головоломки. Т.е. я понимаю в общих чертах как это делается, но мотивации делать игры таких жанров вообще нет, а контента там нужно много, и много подводных камней в геймплее. Игроки будут ждать определённых классических фишек, а я сам в игры данных жанров почти не играл и не хочу играть. Т.е. получится технически рабочая, но скучная игра.
Часто встречаю подобные игры в интернете: да, игра рабочая, но чувствуется, что она безразлична своему разработчику. Зачем, спрашивается, делал? Понятно, хотелось заработать, но в результате вышло нечто бессмысленное: вторичное, безыдейное, клон клона. Игроки предпочтут игру от автора, который шарит в конкретном жанре, а шарят люди обычно в том, что привлекает их больше всего, т.е. во что они играют регулярно или больше всего остального.
Так что я б не рекомендовал делать игры лишь ради абстрактного "опыта игр разных жанров". Чисто ради разностороннего опыта нужно поиграть игры разных жанров; разрабатывать нужно то, что тебя цепляет.
Нет, одного игрового опыта недостаточно для игры, геймдизайн требует много чего ещё, чего игроки не замечают на поверхности. Но и совсем без опыта и мотивации как игрока не получится быть хорошим геймдизайнером в неинтересном для тебя жанре.
Это, наверное, самое большое отличие геймдева от остальных направлений айти и инженерии в целом: геймдизайнер должен быть первым пользователем, иначе получится бессмысленная хрень ни для кого.
>>10679
Там вполне может быть такой же "захардкоженный" Path3D, т.е. смещение по горизонтали - имитация. Аналогично описанному выше прыжку, смещаешь отдельную Node3D с графикой и триггерами Area3D, оставляя PathFollow3D катиться вдоль Path3D. Т.е. позволяешь игроку уклоняться от препятствий одновременно по двум осям, но автоматически продолжаешь движение вдоль третьей оси. Можно придумать что-то вроде движения внтури трубы.
Использование CharacterBody3D имеет смысл, если планируешь полноценный 3D платформер, где игрок получает свободу двигаться куда и как угодно, т.е. предсказать его маршрут становится невозможно; скольжение и отскоки нужны именно для того, чтоб избежать застреваний в каком-нибудь узком месте, которое игрок случайно обнаружил, бегая по карте.
Ну, чему-то же ты научился, наверное. В жанре 2D платформеров многое можно реализовать. Чисто технически, Terraria - "всего лишь" 2D платформер...
Это хорошо, но имхо, главное - внимательно изучать существующие игры, когда играешь в них, а также стремиться реализовать то, во что нравится играть. Конечно, в соло не сделать ААА экшн эдвенчуру, но зачем тратить время на жанры, которые тебя не привлекают? Для разработки полноценной игры требуется масса времени - делая что-то, что тебя не привлекает, ты рискуешь потерять мотивацию...
Например, я б мог сделать гоночку, файтинг, всякие головоломки. Т.е. я понимаю в общих чертах как это делается, но мотивации делать игры таких жанров вообще нет, а контента там нужно много, и много подводных камней в геймплее. Игроки будут ждать определённых классических фишек, а я сам в игры данных жанров почти не играл и не хочу играть. Т.е. получится технически рабочая, но скучная игра.
Часто встречаю подобные игры в интернете: да, игра рабочая, но чувствуется, что она безразлична своему разработчику. Зачем, спрашивается, делал? Понятно, хотелось заработать, но в результате вышло нечто бессмысленное: вторичное, безыдейное, клон клона. Игроки предпочтут игру от автора, который шарит в конкретном жанре, а шарят люди обычно в том, что привлекает их больше всего, т.е. во что они играют регулярно или больше всего остального.
Так что я б не рекомендовал делать игры лишь ради абстрактного "опыта игр разных жанров". Чисто ради разностороннего опыта нужно поиграть игры разных жанров; разрабатывать нужно то, что тебя цепляет.
Нет, одного игрового опыта недостаточно для игры, геймдизайн требует много чего ещё, чего игроки не замечают на поверхности. Но и совсем без опыта и мотивации как игрока не получится быть хорошим геймдизайнером в неинтересном для тебя жанре.
Это, наверное, самое большое отличие геймдева от остальных направлений айти и инженерии в целом: геймдизайнер должен быть первым пользователем, иначе получится бессмысленная хрень ни для кого.
>Аля игры про сноуборды\лыжи.
Там вполне может быть такой же "захардкоженный" Path3D, т.е. смещение по горизонтали - имитация. Аналогично описанному выше прыжку, смещаешь отдельную Node3D с графикой и триггерами Area3D, оставляя PathFollow3D катиться вдоль Path3D. Т.е. позволяешь игроку уклоняться от препятствий одновременно по двум осям, но автоматически продолжаешь движение вдоль третьей оси. Можно придумать что-то вроде движения внтури трубы.
Использование CharacterBody3D имеет смысл, если планируешь полноценный 3D платформер, где игрок получает свободу двигаться куда и как угодно, т.е. предсказать его маршрут становится невозможно; скольжение и отскоки нужны именно для того, чтоб избежать застреваний в каком-нибудь узком месте, которое игрок случайно обнаружил, бегая по карте.
>делал только платформеры, ни чему не научился
Ну, чему-то же ты научился, наверное. В жанре 2D платформеров многое можно реализовать. Чисто технически, Terraria - "всего лишь" 2D платформер...
>стал пробовать разные жанры
Это хорошо, но имхо, главное - внимательно изучать существующие игры, когда играешь в них, а также стремиться реализовать то, во что нравится играть. Конечно, в соло не сделать ААА экшн эдвенчуру, но зачем тратить время на жанры, которые тебя не привлекают? Для разработки полноценной игры требуется масса времени - делая что-то, что тебя не привлекает, ты рискуешь потерять мотивацию...
Например, я б мог сделать гоночку, файтинг, всякие головоломки. Т.е. я понимаю в общих чертах как это делается, но мотивации делать игры таких жанров вообще нет, а контента там нужно много, и много подводных камней в геймплее. Игроки будут ждать определённых классических фишек, а я сам в игры данных жанров почти не играл и не хочу играть. Т.е. получится технически рабочая, но скучная игра.
Часто встречаю подобные игры в интернете: да, игра рабочая, но чувствуется, что она безразлична своему разработчику. Зачем, спрашивается, делал? Понятно, хотелось заработать, но в результате вышло нечто бессмысленное: вторичное, безыдейное, клон клона. Игроки предпочтут игру от автора, который шарит в конкретном жанре, а шарят люди обычно в том, что привлекает их больше всего, т.е. во что они играют регулярно или больше всего остального.
Так что я б не рекомендовал делать игры лишь ради абстрактного "опыта игр разных жанров". Чисто ради разностороннего опыта нужно поиграть игры разных жанров; разрабатывать нужно то, что тебя цепляет.
Нет, одного игрового опыта недостаточно для игры, геймдизайн требует много чего ещё, чего игроки не замечают на поверхности. Но и совсем без опыта и мотивации как игрока не получится быть хорошим геймдизайнером в неинтересном для тебя жанре.
Это, наверное, самое большое отличие геймдева от остальных направлений айти и инженерии в целом: геймдизайнер должен быть первым пользователем, иначе получится бессмысленная хрень ни для кого.
>>10824
Игру сначала сделай. Пока сделаешь, уже 6.0 будет.
>>10833
Предложенные тобой решения требуют куда больше времени и сил, чем "просто подождать скачивания". Запускать игры можно вообще без экспорта, т.е. это совершенно бесполезная фича для типичного инди (который никогда ни одной игры не релизнет нигде).
>>10834
https://github.com/godotengine/godot-proposals/issues/647
Кому вообще эти экспорты нужны, игорникам?
>Шаблоны экспорта всё жирнее становятся.
Игру сначала сделай. Пока сделаешь, уже 6.0 будет.
>>10833
>не будь рабом компьютера
Предложенные тобой решения требуют куда больше времени и сил, чем "просто подождать скачивания". Запускать игры можно вообще без экспорта, т.е. это совершенно бесполезная фича для типичного инди (который никогда ни одной игры не релизнет нигде).
>>10834
>дерзкий, иди и напиши PR чтобы скачивалась
https://github.com/godotengine/godot-proposals/issues/647
>opened on Mar 29, 2020
>47 лайкусиков
>3.5 комментария
Кому вообще эти экспорты нужны, игорникам?
>>10977
Чтоб заниматься дисциплиной, нужна какая-то цель, а цель должна быть осмысленной, а не "просто так".
Чтоб заниматься дисциплиной, нужна какая-то цель, а цель должна быть осмысленной, а не "просто так".
>>10979
Смотрю твоей дисциплины не хватает даже на нахождение цели. Ну хз, найди хозяина, он укажет.
Смотрю твоей дисциплины не хватает даже на нахождение цели. Ну хз, найди хозяина, он укажет.
>>10983
При чём тут дисциплина вообще? Значение знаешь?
Какой порядок установить, чтобы найти смысл?
Вот поиграл на днях в демку Lost Skies...
https://store.steampowered.com/app/3361040/
Даже 1% такой игры никогда не сделаю, но не из-за нехватки бюджета, а просто мотивации нет. Это же очередная бестолковая гриндилка. Собрал мусор, попукал в кого-то, попрыгал с веревкой, полетал на дырявом ведре. Ощущение бессмысленности лишь усилилось. Зачем всё это? Ради чего это делать?
Извини за негатив, но "скачай готовый шаблон" - неправильный совет на "не можешь начать". И ни дисциплина, ни начальник эту проблему не решат. Подозреваю, что я тут не один такой...
При чём тут дисциплина вообще? Значение знаешь?
>обязательное следование установленному порядку
Какой порядок установить, чтобы найти смысл?
Вот поиграл на днях в демку Lost Skies...
https://store.steampowered.com/app/3361040/
Даже 1% такой игры никогда не сделаю, но не из-за нехватки бюджета, а просто мотивации нет. Это же очередная бестолковая гриндилка. Собрал мусор, попукал в кого-то, попрыгал с веревкой, полетал на дырявом ведре. Ощущение бессмысленности лишь усилилось. Зачем всё это? Ради чего это делать?
Извини за негатив, но "скачай готовый шаблон" - неправильный совет на "не можешь начать". И ни дисциплина, ни начальник эту проблему не решат. Подозреваю, что я тут не один такой...
19 Кб, 319x310>>11000
Демка по ссылке бездушная воук-ссанина. Да ещё и саппорт курент ссынг.
Твоя намного круче.
Делай игру. Как же хочется релиза.
мимо фанат твоей карлицы
Демка по ссылке бездушная воук-ссанина. Да ещё и саппорт курент ссынг.
Твоя намного круче.
Делай игру. Как же хочется релиза.
мимо фанат твоей карлицы
Записи стримов Асмонгольда сейчас смотрю (даа, а мог бы игры делать), так вот он там говорит:
Так что думойте.
> это молодёжь, им нужны тяночки с большими сиськами, большие мечи и крутые пушки, и минимум диалогов
Так что думойте.
>>11025
В геншине/хонкае много диалогов, прям ПИЗДЕЦ как много, это практически визуальне новелки. Правда их скипать можно, но когда не скипаешь, получаешь сильный философский прогруз. В остальном да, always been.
В геншине/хонкае много диалогов, прям ПИЗДЕЦ как много, это практически визуальне новелки. Правда их скипать можно, но когда не скипаешь, получаешь сильный философский прогруз. В остальном да, always been.
189 Кб, 1280x720>>11025
Стрим из 2007?
Стрим из 2007?
Посоветуйте террейн для годота, чтобы модульно грузился с возможностью свои чанки добавлять. Да-да, буду пилить свой скайрим мечты в одно ебало с пустыми контенентами на тысячи километров.
>>11129
Вообще без понятия, не пользуюсь таким. Ищи сам:
http://godotengine.org/asset-library/asset?filter=terrain
Но, мне интересно: а разве "модульный" ландшафт не делают изначально кусочками? Т.е. левел-дизайнер сидит и делает отдельные кусочки (любым способом), которые потом движок соединяет самостоятельно в рантайме. Скрипт для загрузки сцен-чанков (.tscn или .tres) очень прост - вся сложность ландшафта в том, чтобы вычислить правильные нормали и наложить несколько десятков текстур на один полигон (две текстуры - очень легко; многие аддоны не поддерживают больше 8 или 16, т.к. чем больше, тем сложнее).
Имхо, если ты не можешь свой загрузчик сцен сделать, то об игре уровня скайрима тебе мечтать пока рано. Лучше делай мод на оригинальный скайрим, если хочешь прийти на всё готовое и добавить нескучные квесты... А базовые механики можно сделать совсем без ландшафта, и если думаешь, что ландшафт сделает тебе игру - ты глубоко заблуждаешься.
Вообще без понятия, не пользуюсь таким. Ищи сам:
http://godotengine.org/asset-library/asset?filter=terrain
Но, мне интересно: а разве "модульный" ландшафт не делают изначально кусочками? Т.е. левел-дизайнер сидит и делает отдельные кусочки (любым способом), которые потом движок соединяет самостоятельно в рантайме. Скрипт для загрузки сцен-чанков (.tscn или .tres) очень прост - вся сложность ландшафта в том, чтобы вычислить правильные нормали и наложить несколько десятков текстур на один полигон (две текстуры - очень легко; многие аддоны не поддерживают больше 8 или 16, т.к. чем больше, тем сложнее).
Имхо, если ты не можешь свой загрузчик сцен сделать, то об игре уровня скайрима тебе мечтать пока рано. Лучше делай мод на оригинальный скайрим, если хочешь прийти на всё готовое и добавить нескучные квесты... А базовые механики можно сделать совсем без ландшафта, и если думаешь, что ландшафт сделает тебе игру - ты глубоко заблуждаешься.
451 Кб, 600x360>>11025
А что он говорит про уборку своей комнаты?
А что он говорит про уборку своей комнаты?
17 Кб, 426x286Как же вы заебали со своими обновлениями. Дайте мне проект доделывать. Сейчас опять уйму кода придется переписывать
59 Кб, 1026x700>>11202
Ох бой хир ви го эгейн.
Я сто раз обеснял, что есть годот-менеджер, в котором чётко сопоставлены проект и версия.
Или ты как та сорока - видишь новое и не можешь удержаться?
Ох бой хир ви го эгейн.
Я сто раз обеснял, что есть годот-менеджер, в котором чётко сопоставлены проект и версия.
Или ты как та сорока - видишь новое и не можешь удержаться?
>>11202
Доделывай. Тебе синий робот угрожает пистолетом? Я вообще на 3.6 доделываю.
>Дайте мне проект доделывать.
Доделывай. Тебе синий робот угрожает пистолетом? Я вообще на 3.6 доделываю.
>>11202
Качай с https://godotengine.org/ - сам по себе не обновляется.
Вроде бы ничего существенного не изменили.
>>11217 >>11237
У него, скорее всего, Godot установлен через Steam, и Steam его обновил.
>>11265
Есть немного, но только что-то очень редкое:
https://docs.godotengine.org/en/4.4/tutorials/migrating/upgrading_to_godot_4.4.html
>со своими обновлениями
Качай с https://godotengine.org/ - сам по себе не обновляется.
>опять уйму кода придется переписывать
Вроде бы ничего существенного не изменили.
>>11217 >>11237
У него, скорее всего, Godot установлен через Steam, и Steam его обновил.
>>11265
>breaking changes
Есть немного, но только что-то очень редкое:
https://docs.godotengine.org/en/4.4/tutorials/migrating/upgrading_to_godot_4.4.html
>>11275
Как только годот не "устанавливают", ебать. Скачать-запустить с официального сайта один экзешник? Не, давайте короче возьмем годот менеджер, опакетим его в рач через аур, но так чтобы он запускался через стим, а стим конечно во флатпаке, а оттуда уже через менеджер поставим сам годот. Тогда и игры начнем делать.
>Godot установлен через Steam
Как только годот не "устанавливают", ебать. Скачать-запустить с официального сайта один экзешник? Не, давайте короче возьмем годот менеджер, опакетим его в рач через аур, но так чтобы он запускался через стим, а стим конечно во флатпаке, а оттуда уже через менеджер поставим сам годот. Тогда и игры начнем делать.
>>11278
Слыыышш! Не пизди на годот-менеджер. Это хаб-пирложение которое есть у всех конкурентов, и оно реально нужно, в отличие от стим-раздачи и прчих репозиториев. Можно вручную скачать менеджер, и подключить к нему вручную скачанный движок, если ты такой уж упёртый виндовс-бой с виндовс-веем.
алсо, виндовс-вей-хуевей, но даже майкрософт запилили winget
Слыыышш! Не пизди на годот-менеджер. Это хаб-пирложение которое есть у всех конкурентов, и оно реально нужно, в отличие от стим-раздачи и прчих репозиториев. Можно вручную скачать менеджер, и подключить к нему вручную скачанный движок, если ты такой уж упёртый виндовс-бой с виндовс-веем.
алсо, виндовс-вей-хуевей, но даже майкрософт запилили winget
>>11338
Не нужно. Когда мне надо запустить 4, я запускаю свежую 4, когда 3, запускаю 3.6. Случаи когда надо запустить конкретную версию бывают раз в год и я просто скачиваю в отдельную папку ту версию.
Вообще не аргумент, скорее аргумент не иметь его просто ради того чтобы повторять за конкурентами.
>и оно реально нужно
Не нужно. Когда мне надо запустить 4, я запускаю свежую 4, когда 3, запускаю 3.6. Случаи когда надо запустить конкретную версию бывают раз в год и я просто скачиваю в отдельную папку ту версию.
>хаб-пирложение которое есть у всех конкурентов
Вообще не аргумент, скорее аргумент не иметь его просто ради того чтобы повторять за конкурентами.
>>11341
Короче вкусовщина. Не нравится не ешь. Я показал как делаю я.
Одно нажатие кнопки в менеджере и у тебя нужная версия движка для отдельных задач.
Короче вкусовщина. Не нравится не ешь. Я показал как делаю я.
> просто скачиваю в отдельную папку
Одно нажатие кнопки в менеджере и у тебя нужная версия движка для отдельных задач.
935 Кб, mp4,400x600, 0:26
>>10173
Попробовал и немножко заигрался.
Теперь меня разрывает между:
1) Скатиться в эротику. Мои вкусы специфичны...
2) Наконец-то реализовать ту идею с NPC, которую вынашиваю уже года 4 как минимум, если считать конкретно эту игру с дирижаблями - до этого было множество идей, похожих в том или ином виде, но откладывал постоянно или ничего не получалось.
В теории, могу совместить, но стоит ли оно того?
>>11003
Ты слишком льстишь...
>>11361 >>11379 >>11386
Не забудьте снять бикини и смазаться маслом.
https://ru.wikipedia.org/wiki/Масляная_борьба
>SpringBoneSimulator3D
Попробовал и немножко заигрался.
Теперь меня разрывает между:
1) Скатиться в эротику. Мои вкусы специфичны...
2) Наконец-то реализовать ту идею с NPC, которую вынашиваю уже года 4 как минимум, если считать конкретно эту игру с дирижаблями - до этого было множество идей, похожих в том или ином виде, но откладывал постоянно или ничего не получалось.
В теории, могу совместить, но стоит ли оно того?
>>11003
Ты слишком льстишь...
>>11361 >>11379 >>11386
Не забудьте снять бикини и смазаться маслом.
https://ru.wikipedia.org/wiki/Масляная_борьба
>>11394
Только очень тонкими намёками уровня случайного вибромассажёра в инвентаре, после которого игрок узнаёт что персонаж шликает. Только так. Иначе моментально улетаешь в яму порноделов и не вылезаешь из неё уже никогда. Если дойдёшь до релиза, то пусть фанаты модами допиливают.
Обращайся за помощью ИТТ. С удовольствием помогу.
> Скатиться в эротику.
Только очень тонкими намёками уровня случайного вибромассажёра в инвентаре, после которого игрок узнаёт что персонаж шликает. Только так. Иначе моментально улетаешь в яму порноделов и не вылезаешь из неё уже никогда. Если дойдёшь до релиза, то пусть фанаты модами допиливают.
> откладывал постоянно или ничего не получалось
Обращайся за помощью ИТТ. С удовольствием помогу.
>>11445
Кстати, во времена тройки был какой-то Мод Лоадер, позволяющий пользователю изи модифицировать игру на годоте. Помню мне после релиза моей игры про него чего-то писали, но я поленился вникать. Хз что с ним сейчас.
>фанаты модами допиливают
Кстати, во времена тройки был какой-то Мод Лоадер, позволяющий пользователю изи модифицировать игру на годоте. Помню мне после релиза моей игры про него чего-то писали, но я поленился вникать. Хз что с ним сейчас.
>>11448
В годоте система пак-архивов сделана с учётом модов/длц. Если игра рассчитана на загрузку кастомных паков, то просто делаешь свой кастомный пак и грузишь.
В годоте система пак-архивов сделана с учётом модов/длц. Если игра рассчитана на загрузку кастомных паков, то просто делаешь свой кастомный пак и грузишь.
41 Кб, 919x788Насколько норм вот такой вот подход к организации кода?
На пике красным выделены обычные Node3D, к которым прикручены скрипты. Соответственно каждый скрипт за свой функционал отвечает.
Вроде недавно тут что-то такое обсуждали
На пике красным выделены обычные Node3D, к которым прикручены скрипты. Соответственно каждый скрипт за свой функционал отвечает.
Вроде недавно тут что-то такое обсуждали
>>11501
Главное, чтобы тебе нравилось и приводило к твоей продуктивности.
Да норм-норм. Пили уже игру.
Главное, чтобы тебе нравилось и приводило к твоей продуктивности.
> Насколько норм вот такой вот подход к организации кода?
Да норм-норм. Пили уже игру.
>>11501
Называется "компонентный подход". Повсеместно встречается в геймдеве.
Называется "компонентный подход". Повсеместно встречается в геймдеве.
>>11501
Мне не нравится. А что если ты потом захочешь добавить мультиплеер в свою игру? Надо заранее такое продумать.
Мне не нравится. А что если ты потом захочешь добавить мультиплеер в свою игру? Надо заранее такое продумать.
Приснилось сегодня что у меня коммерчески успешная игра мечты..
>>11640 (Del)
А вдруг вы украдете мою успешную идею?
А вдруг вы украдете мою успешную идею?
>>11653
Успешны не идеи, успешны реализации. Идея ничто. Вот я бережно хранил свои идеи, никому не рассказывал, но при этом я лентяй, и нихуя не реализовывал. И что ты думаешь? Год за годом я видел как мои идеи каким-то мистическим образом реализуются то в том кине, то в этой книге, то в тех играх.
Так что, если ты не работаешь над своей идеей прямо сейчас, можешь не париться, она прямо во время твоего сновидения утекла через разонанс шумана в инфополе, и над ней уже работают в том или ином виде прямо сейчас.
Фрагмент моей идеи.
Успешны не идеи, успешны реализации. Идея ничто. Вот я бережно хранил свои идеи, никому не рассказывал, но при этом я лентяй, и нихуя не реализовывал. И что ты думаешь? Год за годом я видел как мои идеи каким-то мистическим образом реализуются то в том кине, то в этой книге, то в тех играх.
Так что, если ты не работаешь над своей идеей прямо сейчас, можешь не париться, она прямо во время твоего сновидения утекла через разонанс шумана в инфополе, и над ней уже работают в том или ином виде прямо сейчас.
Фрагмент моей идеи.
>>11668
Ты это я. Неоднократно уже видел буквально свои игры, которые еще и достаточно успешными в индисегменте оказывались
>Вот я бережно хранил свои идеи, никому не рассказывал, но при этом я лентяй, и нихуя не реализовывал. И что ты думаешь? Год за годом я видел как мои идеи каким-то мистическим образом реализуются то в том кине, то в этой книге, то в тех играх.
Ты это я. Неоднократно уже видел буквально свои игры, которые еще и достаточно успешными в индисегменте оказывались
>>11705
Так заебись же, твою идею реализовали а ты заплатил им ноль за работу. Продолжай в том же духе, игродел!
Так заебись же, твою идею реализовали а ты заплатил им ноль за работу. Продолжай в том же духе, игродел!
1,1 Мб, mp4,512x464, 0:11
>>11707
Но и мне не заплатили, заметь.
Но и мне не заплатили, заметь.
15 Кб, 953x205Если кто под андроид публикуется - у гугла есть firebase test lab, позволяет потестить игру на разных девайсах, бесплатно но с квотой. Сейчас пытаюсь поймать баг, который происходит на каком-то донном китайском чипсете. А то заебали эти индийские нищуки единичку в отзыв лепить.
24,2 Мб, mp4,1920x1080, 1:42
А я тут короче музон слушал и так вдохновился, что решил вдохновляющий видос сделать для треда. Наслаждайтесь.
>>11501
Скорее всего, тебе это не понадобится никак. Т.е. передвижение можешь сунуть в ...Body3D. А то так разделишь на отдельные направления (W, A, S, D...), отдельные шаги разной длины... Зачем? Будь проще.
GDQuest, кстати, больше не рекомендует так сильно разделять код (в смысле на отдельные ноды):
https://gdquest.com/tutorial/godot/design-patterns/finite-state-machine/
Это про конечный автомат, но суть та же - слишком сильное разделение кода на компоненты вредит.
Вот это другое дело, только не "Shoot", а "Pistol". Т.е. отдельная сцена с оружием, которое обрабатывает автоматически всё, что касается стрельбы из него. Абстрагируясь от персонажа, можно потом дать этот пистолет чему угодно, хоть на стену повесить, чтобы стреляло при открытии двери в комнату.
Как-то так можно абстрагироваться:
Т.е. пистолет не слушает кнопки, а только стреляет.
>Move: Node3D
Скорее всего, тебе это не понадобится никак. Т.е. передвижение можешь сунуть в ...Body3D. А то так разделишь на отдельные направления (W, A, S, D...), отдельные шаги разной длины... Зачем? Будь проще.
GDQuest, кстати, больше не рекомендует так сильно разделять код (в смысле на отдельные ноды):
https://gdquest.com/tutorial/godot/design-patterns/finite-state-machine/
>These days, I tend to choose different implementations over the state pattern. Using nodes and separate scripts fragments the code too much for my taste, and you end up trading a bit of productivity for it. Whenever possible, I favor a simpler approach, like the one we saw before with the single variable.
Это про конечный автомат, но суть та же - слишком сильное разделение кода на компоненты вредит.
>Shoot: Node3D
Вот это другое дело, только не "Shoot", а "Pistol". Т.е. отдельная сцена с оружием, которое обрабатывает автоматически всё, что касается стрельбы из него. Абстрагируясь от персонажа, можно потом дать этот пистолет чему угодно, хоть на стену повесить, чтобы стреляло при открытии двери в комнату.
Как-то так можно абстрагироваться:
>Персонаж # симулирует движение и т.п.
>_ Инструменты # слушает кнопки 1-9, мышь...
>_ _ Пистолет # запускает стрельбу по запросу
Т.е. пистолет не слушает кнопки, а только стреляет.
Если кто-то кроме меня заметил, что Godot слишком загружает процессор после обновления на 4.4 - вот:
https://github.com/godotengine/godot/issues/102914
Скорее всего пофиксят в 4.4.1, тестовый билд есть:
https://github.com/godotengine/godot/pull/103773
Но главное, если кто-то делает приложение, которое большую часть времени в фоне - пока лучше его не обновлять до 4.4, а то загрузка в фоне ощутимая.
TL;DR: low processor mode "сломан", но скоро фикс.
Вроде бы касается только Windows, но не уверен.
https://github.com/godotengine/godot/issues/102914
Скорее всего пофиксят в 4.4.1, тестовый билд есть:
https://github.com/godotengine/godot/pull/103773
Но главное, если кто-то делает приложение, которое большую часть времени в фоне - пока лучше его не обновлять до 4.4, а то загрузка в фоне ощутимая.
TL;DR: low processor mode "сломан", но скоро фикс.
Вроде бы касается только Windows, но не уверен.
>>11757
Вообще никак не связано. Там просто поменяли код, выполняющийся в фоне, чтоб приложение не висло:
https://github.com/godotengine/godot/pull/99833
Его поменяли, чтобы выровнять FPS на Windows:
https://github.com/godotengine/godot/issues/99728
Calinou уже сделал фикс для low processor mode.
>на uid'ах своих моднявых
Вообще никак не связано. Там просто поменяли код, выполняющийся в фоне, чтоб приложение не висло:
https://github.com/godotengine/godot/pull/99833
Его поменяли, чтобы выровнять FPS на Windows:
https://github.com/godotengine/godot/issues/99728
Calinou уже сделал фикс для low processor mode.
>>11759
Ты с дауненком-срачером разговариваешь.
Ты с дауненком-срачером разговариваешь.
>>11794
Это у богатых - у меня до 8% скачет. И это свёрнутый редактор, в котором вообще ничего не должно никак обсчитываться в это время. Но заметил это, когда попробовал запустить в 4.4 свою утилитку, которую планировал держать в фоне 24/7. Раньше было 0.1%, поэтому аж 8% на пустую UI сцену бросаются в глаза.
И это 4-х ядерный 3.0 ГГц процессор, могу играть во множество современных игр. Представь себе что-то двухядерное на 1 ГГц в нетбуке школьника, что хочет освоить геймдев на "самом доступном движке".
Так что это не такая уж мелочь, как кажется.
Алсо нагрузка суммируется, если у тебя несколько независимых проектов открыто (альт-табаешься).
>1% CPU
Это у богатых - у меня до 8% скачет. И это свёрнутый редактор, в котором вообще ничего не должно никак обсчитываться в это время. Но заметил это, когда попробовал запустить в 4.4 свою утилитку, которую планировал держать в фоне 24/7. Раньше было 0.1%, поэтому аж 8% на пустую UI сцену бросаются в глаза.
И это 4-х ядерный 3.0 ГГц процессор, могу играть во множество современных игр. Представь себе что-то двухядерное на 1 ГГц в нетбуке школьника, что хочет освоить геймдев на "самом доступном движке".
Так что это не такая уж мелочь, как кажется.
Алсо нагрузка суммируется, если у тебя несколько независимых проектов открыто (альт-табаешься).
>>11805
Годот - игровой движок. Игры ебошат не в фоне и могут использовать все 100% процессора. То что им можно пользоваться и для создания утилит - совершенно побочный нишевый эффект. Короче, не проблема вообще. Дальше уже вообще в какие то страшилки спустился, мол если запустить 20 программ то они будут жрать в 20 раз больше.
Годот - игровой движок. Игры ебошат не в фоне и могут использовать все 100% процессора. То что им можно пользоваться и для создания утилит - совершенно побочный нишевый эффект. Короче, не проблема вообще. Дальше уже вообще в какие то страшилки спустился, мол если запустить 20 программ то они будут жрать в 20 раз больше.
>>11759
Что они там делают. Обычно в таком случае просто блокируется поток на ожидании windows сообщений окну и все, ноль загрузки.
Что они там делают. Обычно в таком случае просто блокируется поток на ожидании windows сообщений окну и все, ноль загрузки.
>>11810
Как ты себе это представляешь? По-моему, все GUI приложения имеют бесконечный while true, который и обрабатывает сообщения от Windows, а всё остальное время он обращается к системному sleep(), чтобы не крутиться в цикле лишний раз. Как иначе сделать?
>>11809
Godot Editor - это приложение на Godot Engine...
Godot Editor - побочный нишевый продукт?
Есть целый жанр idle-игр. И многие игроки держат запущенную игру в фоне: на паузе, в каком-то меню, очереди на матч - это распространённая практика.
Однако, здесь речь идёт конкретно о "low processor mode", предназначенном для прикладных программ. Понимаешь? Разработчки движка сделали это для разработки прикладных программ. На движке.
С математикой дружишь? Смотри:
Что если n выросло с 0.1 до 1?
- было 2% - вообще не замечал;
- стало 20% - уже немного больно.
Я уж молчу про 5~10% на слабых ЦПУ.
Добавь сюда % от ОС, браузера, плеера и т.д.
Ещё раз, мы про приложения на фоне - как тот же процедурный генератор материалов на/для Godot, пиксельный редактор Pixelorama (тоже Godot) и т.д.
>блокируется поток на ожидании windows
Как ты себе это представляешь? По-моему, все GUI приложения имеют бесконечный while true, который и обрабатывает сообщения от Windows, а всё остальное время он обращается к системному sleep(), чтобы не крутиться в цикле лишний раз. Как иначе сделать?
>>11809
>Годот - игровой движок
Godot Editor - это приложение на Godot Engine...
>совершенно побочный нишевый
Godot Editor - побочный нишевый продукт?
>Игры ебошат не в фоне
Есть целый жанр idle-игр. И многие игроки держат запущенную игру в фоне: на паузе, в каком-то меню, очереди на матч - это распространённая практика.
Однако, здесь речь идёт конкретно о "low processor mode", предназначенном для прикладных программ. Понимаешь? Разработчки движка сделали это для разработки прикладных программ. На движке.
>будут жрать в 20 раз больше
С математикой дружишь? Смотри:
>n × 20
Что если n выросло с 0.1 до 1?
- было 2% - вообще не замечал;
- стало 20% - уже немного больно.
Я уж молчу про 5~10% на слабых ЦПУ.
Добавь сюда % от ОС, браузера, плеера и т.д.
Ещё раз, мы про приложения на фоне - как тот же процедурный генератор материалов на/для Godot, пиксельный редактор Pixelorama (тоже Godot) и т.д.
>>11813
Еще раз для непонятливых - Godot это игровой движок.
Возможность делать на нем приложения - абсолютно побочный сторонний эффект.
Галочка добавлена как минимальная вещь которую легко добавить, это не значит что теперь все должны броситься поддерживать движок как универсальную платформу для скоростных приложений любого типа.
Не запускай 20 утилит одновременно, годот для этого не предназначался и под это не оптимизировался. Пиши на голом Си если тебе нужна какая то особая скорость.
Еще раз для непонятливых - Godot это игровой движок.
Возможность делать на нем приложения - абсолютно побочный сторонний эффект.
Галочка добавлена как минимальная вещь которую легко добавить, это не значит что теперь все должны броситься поддерживать движок как универсальную платформу для скоростных приложений любого типа.
Не запускай 20 утилит одновременно, годот для этого не предназначался и под это не оптимизировался. Пиши на голом Си если тебе нужна какая то особая скорость.
>>11815
Я не он и не вникал в вас, но сорян, ты чет гонишь и все твои аргументы "яскозал" разбиваются о тот факт, что сам годот, уй-приложение, написан на годоте же, и запускается и летает где только можно, в том числе на ебучих древних андроидах. То, что где-то вылез баг (который уже пофиксили), не меняет этот факт и не делает твои яскозальные аргументы менее яскозальными.
Я не он и не вникал в вас, но сорян, ты чет гонишь и все твои аргументы "яскозал" разбиваются о тот факт, что сам годот, уй-приложение, написан на годоте же, и запускается и летает где только можно, в том числе на ебучих древних андроидах. То, что где-то вылез баг (который уже пофиксили), не меняет этот факт и не делает твои яскозальные аргументы менее яскозальными.
>>11820
Если ты чего-то не понимаешь - лучше не пиши, а сначала разберись о чем вообще идет речь. Причем тут андроид, у которого в фоне приложения просто обрубаются?
Если ты чего-то не понимаешь - лучше не пиши, а сначала разберись о чем вообще идет речь. Причем тут андроид, у которого в фоне приложения просто обрубаются?
Годаны, я там смотрю стрим по Split Fiction...
Там короче толщеходы запилили. Будущее наступило.
Там короче толщеходы запилили. Будущее наступило.
>>11445
Повторю: мои вкусы специфичны, массы не поймут.
Меня сейчас волнует: что делать, если компаньон игрока застрял где-то/не может к нему вернуться? Просто телепортировать? Это выглядит тупо, меня раздражает подобная телепортация в других играх. Компаньон должен быть рядом, нигде не застревая, однако иметь полную физическую симуляцию тела.
Повторю: мои вкусы специфичны, массы не поймут.
>Обращайся за помощью
Меня сейчас волнует: что делать, если компаньон игрока застрял где-то/не может к нему вернуться? Просто телепортировать? Это выглядит тупо, меня раздражает подобная телепортация в других играх. Компаньон должен быть рядом, нигде не застревая, однако иметь полную физическую симуляцию тела.
>>11839
Когда бот в зоне видимости игрока, он физически симулируется, когда на отдалении, включается следование по навмешу.
Кроме того, я бы сделал специальный тестовый уровень, в котором собраны все известные препятствия и тренировал бы там ботов.
Когда бот в зоне видимости игрока, он физически симулируется, когда на отдалении, включается следование по навмешу.
Кроме того, я бы сделал специальный тестовый уровень, в котором собраны все известные препятствия и тренировал бы там ботов.
>>11897
Пизда юбисофту!
Пизда юбисофту!
>>11897
Этот анон настолько жирный, что в окно еле пролез.
Но круто. Теней не хватает. Хотя бы blob shadows.
Этот анон настолько жирный, что в окно еле пролез.
Но круто. Теней не хватает. Хотя бы blob shadows.
>>11730
Короче некоторое китайское барахло тупо не грузит "большие" спрайтщиты. Например, redmi a6.
>Сейчас пытаюсь поймать баг, который происходит на каком-то донном китайском чипсете. А то заебали эти индийские нищуки единичку в отзыв лепить.
Короче некоторое китайское барахло тупо не грузит "большие" спрайтщиты. Например, redmi a6.
>>11928
Да не, спасибо, я уже через гугловский файрбейз потестил. Просто информирую что на мобилках даже такая проблема может всплыть. Теперь думаю как порезать спрайтщит на куски, чтобы код-анимации не перерабатывать.
Да не, спасибо, я уже через гугловский файрбейз потестил. Просто информирую что на мобилках даже такая проблема может всплыть. Теперь думаю как порезать спрайтщит на куски, чтобы код-анимации не перерабатывать.
>>11929
Вот это было реально досадно. Сначала они говорят нам, что отдельные пикчи неоптимальны, юзайте атлас, а теперь такие, ваш атлас не умещается в оперативку, режьте его на отдельные пикчи.
Вот это было реально досадно. Сначала они говорят нам, что отдельные пикчи неоптимальны, юзайте атлас, а теперь такие, ваш атлас не умещается в оперативку, режьте его на отдельные пикчи.
102 Кб, 1295x479>>11967
Не знаю кто такие "они", но в документации сказано что на мобильники надо делать текстуры поменьше и желательно квадратные с размером степени двойки, например 2048x2048
Не знаю кто такие "они", но в документации сказано что на мобильники надо делать текстуры поменьше и желательно квадратные с размером степени двойки, например 2048x2048
>>11929
Оптимальный вариант - просто сжать все текстуры в несколько раз. Во-первых, на мобилках чаще всего небольшие дисплеи и разница в качестве текстур не сильно заметна. Во-вторых, очень часто нехватка и постоянной памяти, и оперативной. В-третьих, твои текстурки наверняка имеют чрезмерно большое разрешение, если у тебя не пиксель-арт. Многие портированные на мобилки игры имеют сильно скукоженные текстуры и это правильно.
>>11967
Просто переключение между текстурами тратит драгоценное время кадра. Ещё на атласе попроще разместить неровные объекты, сэкономив память. Впрочем, сегодня это всё не настолько актуально, особенно на ПК, где может быть 24+ Гб VRAM.
Разве кто-то говорил, что ты можешь впихнуть всю графику игры в одну текстуру? Очевидно, что есть ограничения на размер одной текстуры, иначе не существовало бы концепции "текстуры" - всё бы хранилось в рамках одной сплошной текстуры.
Как упомянул >>11970, у разного железа разные ограничения - у мобилок строже. Любопытно, что графические API позволяют узнать максимально допустимый размер текстуры, в Godot это здесь:
https://docs.godotengine.org/en/stable/classes/class_renderingdevice.html#class-renderingdevice-method-limit-get
Теоретически, можно иметь набор из нескольких текстур, чтобы выбирать оптимальную под железо.
Алсо, есть один трюк - создание атласов в рантайме. Исходные кадры анимации хранятся по отдельности, рендерятся в атлас во время загрузки игры, учитывая ограничения железа, потом используется атлас. Ещё можно сохранить его на диск - ускорить загрузку.
Но это всё низкоуровневые оптимизации. Если твоя игрушка - примитивная поделка, проще запретить слабым устройствам её скачивание, чем париться с оптимизацией под какие-то древние устройства.
>думаю как порезать спрайтщит на куски
Оптимальный вариант - просто сжать все текстуры в несколько раз. Во-первых, на мобилках чаще всего небольшие дисплеи и разница в качестве текстур не сильно заметна. Во-вторых, очень часто нехватка и постоянной памяти, и оперативной. В-третьих, твои текстурки наверняка имеют чрезмерно большое разрешение, если у тебя не пиксель-арт. Многие портированные на мобилки игры имеют сильно скукоженные текстуры и это правильно.
>>11967
>отдельные пикчи неоптимальны, юзайте атлас
Просто переключение между текстурами тратит драгоценное время кадра. Ещё на атласе попроще разместить неровные объекты, сэкономив память. Впрочем, сегодня это всё не настолько актуально, особенно на ПК, где может быть 24+ Гб VRAM.
>ваш атлас не умещается
Разве кто-то говорил, что ты можешь впихнуть всю графику игры в одну текстуру? Очевидно, что есть ограничения на размер одной текстуры, иначе не существовало бы концепции "текстуры" - всё бы хранилось в рамках одной сплошной текстуры.
Как упомянул >>11970, у разного железа разные ограничения - у мобилок строже. Любопытно, что графические API позволяют узнать максимально допустимый размер текстуры, в Godot это здесь:
https://docs.godotengine.org/en/stable/classes/class_renderingdevice.html#class-renderingdevice-method-limit-get
>LIMIT_MAX_TEXTURE_SIZE_2D
>Maximum supported 2-dimensional texture size (in pixels on a single axis).
Теоретически, можно иметь набор из нескольких текстур, чтобы выбирать оптимальную под железо.
Алсо, есть один трюк - создание атласов в рантайме. Исходные кадры анимации хранятся по отдельности, рендерятся в атлас во время загрузки игры, учитывая ограничения железа, потом используется атлас. Ещё можно сохранить его на диск - ускорить загрузку.
Но это всё низкоуровневые оптимизации. Если твоя игрушка - примитивная поделка, проще запретить слабым устройствам её скачивание, чем париться с оптимизацией под какие-то древние устройства.
>>11985
Тру пиксельарт и рисуется исходя из 8х8, 16х16, так что само сходится. Переделывай.
Тру пиксельарт и рисуется исходя из 8х8, 16х16, так что само сходится. Переделывай.
25 Кб, 384x192>>11986
Это если у тебя отдельные спрайты, а не атлас, в который ты уместил свои степеннодвойковые спрайты чтобы потом нарезать в движке.
Картинку с опенгеймарта притащил для примера.
Это если у тебя отдельные спрайты, а не атлас, в который ты уместил свои степеннодвойковые спрайты чтобы потом нарезать в движке.
Картинку с опенгеймарта притащил для примера.
>>11985
Размер в пикселях-то какой? А лучше скинь сюда. Сожми в JPG в очень низком качестве (<30%), если боишься, что украдут. Глянем, что можно сделать.
Ты знал про атласы, но не знал про степени двойки?
>>11990
Суть в том, что видеокарты выделяют тебе память исключительно по степеням двойки, например, твоя текстура размером 384x192 займёт область памяти размером 512x256, при том остальные пиксели будут зарезервированы, но не могут использоваться тобой.
В древние времена ты вообще не мог отправить на видеокарту картинку неправильного размера, однако сегодня драйверы автоматически расширяют размер картинки до подходящего, поэтому стало возможно закидывать произвольную картинку как текстуру.
Почему видеокарты выделяют видеопамять такими блоками? Для оптимизации доступа. Предполагаю, принцип аналогичен блокам FS и страницам RAM - устройству физически проще считать целый блок, поэтому все операции выполняются с блоками.
Короче, ты можешь юзать текстуры 384x192, но это приводит к избыточному выделению VRAM. Или как минимум приводило раньше/на старых устройствах.
>всего 120 килобайт
Размер в пикселях-то какой? А лучше скинь сюда. Сожми в JPG в очень низком качестве (<30%), если боишься, что украдут. Глянем, что можно сделать.
>Пиздец цирк.
Ты знал про атласы, но не знал про степени двойки?
>>11990
Суть в том, что видеокарты выделяют тебе память исключительно по степеням двойки, например, твоя текстура размером 384x192 займёт область памяти размером 512x256, при том остальные пиксели будут зарезервированы, но не могут использоваться тобой.
В древние времена ты вообще не мог отправить на видеокарту картинку неправильного размера, однако сегодня драйверы автоматически расширяют размер картинки до подходящего, поэтому стало возможно закидывать произвольную картинку как текстуру.
Почему видеокарты выделяют видеопамять такими блоками? Для оптимизации доступа. Предполагаю, принцип аналогичен блокам FS и страницам RAM - устройству физически проще считать целый блок, поэтому все операции выполняются с блоками.
Короче, ты можешь юзать текстуры 384x192, но это приводит к избыточному выделению VRAM. Или как минимум приводило раньше/на старых устройствах.
>>11996
Да. Ок, спасибо
Да. Ок, спасибо
>>11858
Не бот (моб), а компаньон - разница большая. Мобам разрешено застревать - они не важны. Компаньон же обязательно должен быть рядом с игроком - если он заблудится где-то/застрянет, игрок его потеряет; это уникальная сущность, а не какой-то наёмник. Т.е. телепортация и пролёт сквозь стены - вроде бы как единственные универсальные средства. Нет?
Не понял, предлагаешь пролетать стены насквозь? Вообще, вопрос не про поиск пути. Я спрашиваю о ситуации, когда маршрута ТОЧНО нет - персонаж окончательно застрял поблизости от игрока. Ну, допустим, на него сверху RigidBody3D упал. Просто пролететь насквозь - будет некрасиво выглядеть; оставлять позади игрока недопустимо по задумке - необходимо как-то выбраться из-под препятствия.
Хочу добавлять их позже + они могут двигаться. Концептуально статичных препятствий вообще нет, использую StaticBody3D только для прототипов, т.е. решение должно быть достаточно стабильным...
Наверное, идея нереалистична и придётся чем-то пожертвовать, например, всё-таки телепортировать компаньона куда-то вне зоны видимости камеры: отвернулся от застрявшего персонажа, посмотрел повторно - а он уже рядом тусуется. Как удалось выбраться? Не важно. Главное - без рывков и без прохождения препятствия на экране насквозь.
А, ещё кое-что: эта проблема возникает только при движении к игроку. Если компаньон не смог найти маршрут до другой цели - не страшно, можно просто вернуться к игроку. Проблема возникает, когда этот возврат к игроку тоже почему-либо невозможен. Т.е. вопрос настолько важный, что достоин костыля, но желательно чтоб это не нарушало игровую физику...
>бот
Не бот (моб), а компаньон - разница большая. Мобам разрешено застревать - они не важны. Компаньон же обязательно должен быть рядом с игроком - если он заблудится где-то/застрянет, игрок его потеряет; это уникальная сущность, а не какой-то наёмник. Т.е. телепортация и пролёт сквозь стены - вроде бы как единственные универсальные средства. Нет?
>следование по навмешу
Не понял, предлагаешь пролетать стены насквозь? Вообще, вопрос не про поиск пути. Я спрашиваю о ситуации, когда маршрута ТОЧНО нет - персонаж окончательно застрял поблизости от игрока. Ну, допустим, на него сверху RigidBody3D упал. Просто пролететь насквозь - будет некрасиво выглядеть; оставлять позади игрока недопустимо по задумке - необходимо как-то выбраться из-под препятствия.
>все известные препятствия
Хочу добавлять их позже + они могут двигаться. Концептуально статичных препятствий вообще нет, использую StaticBody3D только для прототипов, т.е. решение должно быть достаточно стабильным...
Наверное, идея нереалистична и придётся чем-то пожертвовать, например, всё-таки телепортировать компаньона куда-то вне зоны видимости камеры: отвернулся от застрявшего персонажа, посмотрел повторно - а он уже рядом тусуется. Как удалось выбраться? Не важно. Главное - без рывков и без прохождения препятствия на экране насквозь.
А, ещё кое-что: эта проблема возникает только при движении к игроку. Если компаньон не смог найти маршрут до другой цели - не страшно, можно просто вернуться к игроку. Проблема возникает, когда этот возврат к игроку тоже почему-либо невозможен. Т.е. вопрос настолько важный, что достоин костыля, но желательно чтоб это не нарушало игровую физику...
>>12025
Ты лучше сделай тестовый уровень с кучей ригид тел, а то окажется что твою идею в принципе годот не вывезет.
>>12034
Может быть у него зачатки интеллекта и он силой переворачивает завал.
А если бы это была собачка? Как бы она себя вела? Она бы или звала на помощь, или была на поводке и игрок не мог от нее отойти.
А почему игроку нельзя идти без нее? Какое то ограничение? Можно сделать чекпоинт где ему говорят пока не заберешь компаньона дальше не пройдешь. Раз уж он такой бесчувственный
Ты лучше сделай тестовый уровень с кучей ригид тел, а то окажется что твою идею в принципе годот не вывезет.
>>12034
Может быть у него зачатки интеллекта и он силой переворачивает завал.
А если бы это была собачка? Как бы она себя вела? Она бы или звала на помощь, или была на поводке и игрок не мог от нее отойти.
А почему игроку нельзя идти без нее? Какое то ограничение? Можно сделать чекпоинт где ему говорят пока не заберешь компаньона дальше не пройдешь. Раз уж он такой бесчувственный
Годаны, у меня шокирующее откровение. Я тут осваиваю плюсы и всё больше осознаю, насколько гдскрипт на них похож. Хотя нет, "похож" неправильное слово. Скорее - насколько вытор гдскрипта привык мыслить по-цппшному. Ничего удивительного, конечно, но насколько ж это становится заметно, когда познаёшь оба языка.
Ну и да, ещё заметно, что гдскрипт - это заточенный инструмент, призванный решать сугубо практические задачи. Не абстрактная красиво выстроенная конструкция с Идеей, как какой-нибудь луа, а прямо вот чисто вот под задачи.
Такие дела. Скоро научусь приделывать к Годоту плюсовые модули, ух тогда заживём.
Ну и да, ещё заметно, что гдскрипт - это заточенный инструмент, призванный решать сугубо практические задачи. Не абстрактная красиво выстроенная конструкция с Идеей, как какой-нибудь луа, а прямо вот чисто вот под задачи.
Такие дела. Скоро научусь приделывать к Годоту плюсовые модули, ух тогда заживём.
>>12077
Как и весь годот. За это и люблю.
>это заточенный инструмент, призванный решать сугубо практические задачи
Как и весь годот. За это и люблю.
>>12077
Он просто похож на всё хорошее. Я вижу похожесть на паскаль, когда запилили автовыведение типа через олдовый символ присвоения := с уроков информатики. Я уже говорил об этом ранее. Ранее, когда все кодили в паскале, этот знак воспринимался как атомарный (просто потому что), а гдскрипт теперь вкладывает в него смысл Name : Type (auto) = init value
Он просто похож на всё хорошее. Я вижу похожесть на паскаль, когда запилили автовыведение типа через олдовый символ присвоения := с уроков информатики. Я уже говорил об этом ранее. Ранее, когда все кодили в паскале, этот знак воспринимался как атомарный (просто потому что), а гдскрипт теперь вкладывает в него смысл Name : Type (auto) = init value
>>11839
Анон, ты тут?
Если не секрет, поделись, что выбрал? Эротику / не эротику? И почему.
Сам стою перед такой дилеммой. С одной стороны в играх с геймплеем и сюжетом секс не нужен, с другой стороны - добавить очень хочется.
Анон, ты тут?
Если не секрет, поделись, что выбрал? Эротику / не эротику? И почему.
Сам стою перед такой дилеммой. С одной стороны в играх с геймплеем и сюжетом секс не нужен, с другой стороны - добавить очень хочется.
>>12531
10 из 10 ГОТИ, бессмертная классика.
10 из 10 ГОТИ, бессмертная классика.
>>12534
Если честно, почти вся игра - моё фетиш-топливо... Короче, речь шла не о каком-то банальном сексе, а, например, о полупрозрачном шейдере с бликами... Менюшечка круглая тоже доставляет удовольствие одним своим видом. Однако, многие мои интересы просто выходят за рамки тех ограничений, которые наложил на эту игру я сам, в начальном концепте: например, острова должны падать, поэтому в них невозможно разместить водоёмы, а без воды ряд интересных вещей теряет смысл и выглядит глупо. Снимать ограничения равно делать другой проект.
Вот я и думаю: >>11000 >>11394
1. Делать новую игру ради 100% совместимости?
2. Отказаться от своих интересов для этой игры?
3. Попытаться совместить всё в одну песочницу?
Подумываю об этом уже давно...
Попробуй сначала подрочить. Обычно после этого больше не хочется добавлять в игру ничего такого, потому что это желание было вызвано похотью. Сэкономишь кучу времени на разработку игры.
Если честно, почти вся игра - моё фетиш-топливо... Короче, речь шла не о каком-то банальном сексе, а, например, о полупрозрачном шейдере с бликами... Менюшечка круглая тоже доставляет удовольствие одним своим видом. Однако, многие мои интересы просто выходят за рамки тех ограничений, которые наложил на эту игру я сам, в начальном концепте: например, острова должны падать, поэтому в них невозможно разместить водоёмы, а без воды ряд интересных вещей теряет смысл и выглядит глупо. Снимать ограничения равно делать другой проект.
Вот я и думаю: >>11000 >>11394
1. Делать новую игру ради 100% совместимости?
2. Отказаться от своих интересов для этой игры?
3. Попытаться совместить всё в одну песочницу?
Подумываю об этом уже давно...
>добавить очень хочется
Попробуй сначала подрочить. Обычно после этого больше не хочется добавлять в игру ничего такого, потому что это желание было вызвано похотью. Сэкономишь кучу времени на разработку игры.
>>12555
Это если плотность воды ниже, чем у грунта, а ты просто установи себе метрику, что вода плотнее грунта, и всё, скорость падения выше у более плотного вещества. Поскольку острова окружены воздухом, то падение объектов не является свободным по правилам классической механики.
> острова должны падать, поэтому в них невозможно разместить водоёмы
Это если плотность воды ниже, чем у грунта, а ты просто установи себе метрику, что вода плотнее грунта, и всё, скорость падения выше у более плотного вещества. Поскольку острова окружены воздухом, то падение объектов не является свободным по правилам классической механики.
>>12550
>>12555
Не, ни так, ни эдак не получится. Акцент будет не на самом сексе, а на том, как к нему придут и ситуации с этим связанные. Нужно его наличие в сюжетном плане.
Понимаю, одобряю.
Почему бы не попробовать совместить. Хотя бы частично, чтоб за рамки не вышло.
>>12555
>Вот, зацени пост
>Попробуй сначала подрочить.
Не, ни так, ни эдак не получится. Акцент будет не на самом сексе, а на том, как к нему придут и ситуации с этим связанные. Нужно его наличие в сюжетном плане.
>Если честно, почти вся игра - моё фетиш-топливо...
Понимаю, одобряю.
>Подумываю об этом уже давно...
Почему бы не попробовать совместить. Хотя бы частично, чтоб за рамки не вышло.
>>12555
Можно подумать остальная игра у тебя абсолютно реалистична. Вот из-за таких загонов мы и не можем иметь хорошие вещи.
>острова должны падать, поэтому в них невозможно разместить водоёмы
Можно подумать остальная игра у тебя абсолютно реалистична. Вот из-за таких загонов мы и не можем иметь хорошие вещи.
Вы недооцениваете удобство embedded скриптов. Мой уровень реагирует на действия игрока, тут так, тут иначе. Я сделал заготовку class_name CustomScript, в него экспорт nodepath'ов. На уровне создаю кастом скрипт, указываю ему на какие ноды смотреть и на что реагировать, и дальше херачу в нем embedded скрипт. Например тут игрока придавит этим камнем, но только если он имеет в инвентаре Х, а тут уровень ожидает от игрока именно такую последовательность действий, а тут паззл решается вот так и никак иначе, и скрипт проверяет на правильное решение, ресетя паззл при неправильном. Даже катсцены через них. Все это - одноразовые встроенные скрипты на 5-10 строк. Не представляю какую дичь пришлось бы городить без них.
>>12577
К примеру стелс экшен на тему эксгибиционизма как формы эскапизма от жизненных проблем. Вступление в интим - вариант, а не сюжетная рельса и повлияет на героиню. Вырезать секс из изначально 18+ игры нет никакого смысла, но большого акцента на самом процессе не будет.
И ко второму примеру пост апокалипсис рпг с инопланетным вирусом, вызывающим необратимые мутации тела. Инстинкт размножения насильственно вызывается вирусом, с выделением феромонов. Эту часть можно вырезать без большого ущерба для сюжета и геймплея. Это ударит по взаимодействию с нпс.
Чисто хентай идеи, тут без интима никак. Плюс свой взгляд на фетиши.
Ну и необоснованные эро вставки - чисто для привлечения внимания. Либо я просто сделаю игру и на неё обратит внимание 100 человек, либо байт эротикой и внимание обратит 10000 человек.
К примеру стелс экшен на тему эксгибиционизма как формы эскапизма от жизненных проблем. Вступление в интим - вариант, а не сюжетная рельса и повлияет на героиню. Вырезать секс из изначально 18+ игры нет никакого смысла, но большого акцента на самом процессе не будет.
И ко второму примеру пост апокалипсис рпг с инопланетным вирусом, вызывающим необратимые мутации тела. Инстинкт размножения насильственно вызывается вирусом, с выделением феромонов. Эту часть можно вырезать без большого ущерба для сюжета и геймплея. Это ударит по взаимодействию с нпс.
Чисто хентай идеи, тут без интима никак. Плюс свой взгляд на фетиши.
Ну и необоснованные эро вставки - чисто для привлечения внимания. Либо я просто сделаю игру и на неё обратит внимание 100 человек, либо байт эротикой и внимание обратит 10000 человек.
>>12613
Двачую. Я вот тоже автоматически конструирую 18+ геймплей. Например, ГГ на объекте дежурит, и к нему пробирается на объект тянка, чтобы с объекта важный артефакт украсть. Ну казалось бы, бери и делай. Нет. Обязательно тянка должна оказаться сбежавшей с нелегальной молочной фермы по выдойке человечьего молока. И у неё вооот такиииие сисяндры. И их надо доить периодически, по таймеру, мини-игра. Без этого геймплей не клеится.
Двачую. Я вот тоже автоматически конструирую 18+ геймплей. Например, ГГ на объекте дежурит, и к нему пробирается на объект тянка, чтобы с объекта важный артефакт украсть. Ну казалось бы, бери и делай. Нет. Обязательно тянка должна оказаться сбежавшей с нелегальной молочной фермы по выдойке человечьего молока. И у неё вооот такиииие сисяндры. И их надо доить периодически, по таймеру, мини-игра. Без этого геймплей не клеится.
>>12619
Так, хорошо. Допустим делаешь игру, не мелочь уровня геймджема, но и не непосильно большой проект. Как много людей в него поиграет? Как много людей не прокликает мимо? Понятно, что много людей не поиграет, но всё равно обидно будет, если вообще никто внимания не обратит.
Так, хорошо. Допустим делаешь игру, не мелочь уровня геймджема, но и не непосильно большой проект. Как много людей в него поиграет? Как много людей не прокликает мимо? Понятно, что много людей не поиграет, но всё равно обидно будет, если вообще никто внимания не обратит.
>>12599
Кто?
Просто сохранял бы .gd-скрипты в одну папку с .tscn файлом сцены уровня или что там у тебя. Суть этих встроенных скриптов только в том, чтобы не было дополнительных файлов отдельно от сцены. В остальном у них сплошные недостатки.
Я их использую в основном чтобы побыстрее наговнокодить прототип фичи, который потом наверняка удалю. Если не удалю - сохраню в .gd.
Напоминаю:
1. Ты не обязан давать скриптам class_name.
2. При том class_name не зависит от имени файла.
3. Ты можешь иметь кучу одноимённых скриптов, разложенных по разным папкам - без коллизий.
4. Можно обращаться через относительные пути:
Это загрузит файл из папки текущего скрипта.
Это - из папки выше уровнем текущего скрипта.
Это - из папки-соседа папки текущего скрипта.
Разработчики Godot рекомендуют помещать все ресурсы и скрипты в папку сцены-пользователя. Скапливать все скрипты в одной папке не нужно.
Вместо:
Рекомендуется такая организация:
GUI редактора сцен/скриптов это поддерживает.
Алсо, NodePath - легаси, сейчас можно сразу класс интересующей тебя ноды экспортировать - вместо:
Можно и намного удобнее использовать это, что автоматически фильтрует меню выбора нод:
NodePath сохранили для чего-то другого.
>Вы
Кто?
>какую дичь пришлось бы городить без них
Просто сохранял бы .gd-скрипты в одну папку с .tscn файлом сцены уровня или что там у тебя. Суть этих встроенных скриптов только в том, чтобы не было дополнительных файлов отдельно от сцены. В остальном у них сплошные недостатки.
Я их использую в основном чтобы побыстрее наговнокодить прототип фичи, который потом наверняка удалю. Если не удалю - сохраню в .gd.
Напоминаю:
1. Ты не обязан давать скриптам class_name.
2. При том class_name не зависит от имени файла.
3. Ты можешь иметь кучу одноимённых скриптов, разложенных по разным папкам - без коллизий.
4. Можно обращаться через относительные пути:
>var script := load("script.gd")
Это загрузит файл из папки текущего скрипта.
>var script := load("../script.gd")
Это - из папки выше уровнем текущего скрипта.
>var script := load("../sub/script.gd")
Это - из папки-соседа папки текущего скрипта.
Разработчики Godot рекомендуют помещать все ресурсы и скрипты в папку сцены-пользователя. Скапливать все скрипты в одной папке не нужно.
Вместо:
>scripts/script1.gd
>scripts/script2.gd
>scenes/scene1.tscn
>scenes/scene2.tscn
Рекомендуется такая организация:
>scene1/scene.tscn
>scene1/script.gd
>scene2/scene.tscn
>scene2/script.gd
GUI редактора сцен/скриптов это поддерживает.
Алсо, NodePath - легаси, сейчас можно сразу класс интересующей тебя ноды экспортировать - вместо:
>@export node_path: NodePath # любой путь сойдёт
>@onready node: Node = get_node(node_path)
Можно и намного удобнее использовать это, что автоматически фильтрует меню выбора нод:
>@export node: Node # нужна только такая нода
NodePath сохранили для чего-то другого.
>>12599
Кто?
Просто сохранял бы .gd-скрипты в одну папку с .tscn файлом сцены уровня или что там у тебя. Суть этих встроенных скриптов только в том, чтобы не было дополнительных файлов отдельно от сцены. В остальном у них сплошные недостатки.
Я их использую в основном чтобы побыстрее наговнокодить прототип фичи, который потом наверняка удалю. Если не удалю - сохраню в .gd.
Напоминаю:
1. Ты не обязан давать скриптам class_name.
2. При том class_name не зависит от имени файла.
3. Ты можешь иметь кучу одноимённых скриптов, разложенных по разным папкам - без коллизий.
4. Можно обращаться через относительные пути:
Это загрузит файл из папки текущего скрипта.
Это - из папки выше уровнем текущего скрипта.
Это - из папки-соседа папки текущего скрипта.
Разработчики Godot рекомендуют помещать все ресурсы и скрипты в папку сцены-пользователя. Скапливать все скрипты в одной папке не нужно.
Вместо:
Рекомендуется такая организация:
GUI редактора сцен/скриптов это поддерживает.
Алсо, NodePath - легаси, сейчас можно сразу класс интересующей тебя ноды экспортировать - вместо:
Можно и намного удобнее использовать это, что автоматически фильтрует меню выбора нод:
NodePath сохранили для чего-то другого.
>Вы
Кто?
>какую дичь пришлось бы городить без них
Просто сохранял бы .gd-скрипты в одну папку с .tscn файлом сцены уровня или что там у тебя. Суть этих встроенных скриптов только в том, чтобы не было дополнительных файлов отдельно от сцены. В остальном у них сплошные недостатки.
Я их использую в основном чтобы побыстрее наговнокодить прототип фичи, который потом наверняка удалю. Если не удалю - сохраню в .gd.
Напоминаю:
1. Ты не обязан давать скриптам class_name.
2. При том class_name не зависит от имени файла.
3. Ты можешь иметь кучу одноимённых скриптов, разложенных по разным папкам - без коллизий.
4. Можно обращаться через относительные пути:
>var script := load("script.gd")
Это загрузит файл из папки текущего скрипта.
>var script := load("../script.gd")
Это - из папки выше уровнем текущего скрипта.
>var script := load("../sub/script.gd")
Это - из папки-соседа папки текущего скрипта.
Разработчики Godot рекомендуют помещать все ресурсы и скрипты в папку сцены-пользователя. Скапливать все скрипты в одной папке не нужно.
Вместо:
>scripts/script1.gd
>scripts/script2.gd
>scenes/scene1.tscn
>scenes/scene2.tscn
Рекомендуется такая организация:
>scene1/scene.tscn
>scene1/script.gd
>scene2/scene.tscn
>scene2/script.gd
GUI редактора сцен/скриптов это поддерживает.
Алсо, NodePath - легаси, сейчас можно сразу класс интересующей тебя ноды экспортировать - вместо:
>@export node_path: NodePath # любой путь сойдёт
>@onready node: Node = get_node(node_path)
Можно и намного удобнее использовать это, что автоматически фильтрует меню выбора нод:
>@export node: Node # нужна только такая нода
NodePath сохранили для чего-то другого.
>>12626
Это всё лотерея, бро, ИМХО. Если повезёт словишь лютый хайп, как автор онли-ап, который от свалившегося на него успеха окуклился и всё поудалял.
Это всё лотерея, бро, ИМХО. Если повезёт словишь лютый хайп, как автор онли-ап, который от свалившегося на него успеха окуклился и всё поудалял.
Смотрим туториал https://www.youtube.com/watch?v=7Bha0jEqec0
>>12627
class_name содержит бойлерплейт, одинаковый для всех скриптов, непосредственно используемых на уровне. Заваливать файловую структуру одноразовыми "написал и забыл" скриптами я не хочу.
Да, я на тройке.
Какие? Пока не нашел.
class_name содержит бойлерплейт, одинаковый для всех скриптов, непосредственно используемых на уровне. Заваливать файловую структуру одноразовыми "написал и забыл" скриптами я не хочу.
>NodePath - легаси
Да, я на тройке.
>В остальном у них сплошные недостатки.
Какие? Пока не нашел.
>>12645
Годотеры делятся на две группы:
1. я пишу эмбед скрипты, а вы их недооцениваете;
2. блять, после того как работа трёх месяцев внезапно после миссклика безвозвратно исчезла, я ни в коем случае не пишу эмбед скрипты, и воще воздерживаюсь от эмбеда ресурсов в ресурсы.
Годотеры делятся на две группы:
1. я пишу эмбед скрипты, а вы их недооцениваете;
2. блять, после того как работа трёх месяцев внезапно после миссклика безвозвратно исчезла, я ни в коем случае не пишу эмбед скрипты, и воще воздерживаюсь от эмбеда ресурсов в ресурсы.
>>12654
Все так + иногда просто поправить скрипт в блокноте.
Все так + иногда просто поправить скрипт в блокноте.
>>12660
Умники делятся на пять групп:
1. Я у мамы умный, ваяю вооот такой код в блокноте.
2. Теперь я делаю архивы (winrar) раз в неделю, после того случая.
3. Теперь я делаю бэкапы на два разных устройства, после того случая.
4. Теперь я храню свой код в системе контроля версий, после того случая.
5. И делаю бэкапы!
Умники делятся на пять групп:
1. Я у мамы умный, ваяю вооот такой код в блокноте.
2. Теперь я делаю архивы (winrar) раз в неделю, после того случая.
3. Теперь я делаю бэкапы на два разных устройства, после того случая.
4. Теперь я храню свой код в системе контроля версий, после того случая.
5. И делаю бэкапы!
>>12669
6. Делаю распечатки кода на принтере, на случай апокалипсиса. Потом вручную наберу, если что.
Некоторые языки дизайнили для этого (язык Ada).
6. Делаю распечатки кода на принтере, на случай апокалипсиса. Потом вручную наберу, если что.
Некоторые языки дизайнили для этого (язык Ada).
>>12670
Проект это не только код, особенно в геймдеве, где кода процентов 20 от всего проекта. И как раз где-то на уровне 4 приходит понимание, что всю эту требуху ресурсов надо как-то грамотно разложить по полочкам, а не просто в архив запихать.
Проект это не только код, особенно в геймдеве, где кода процентов 20 от всего проекта. И как раз где-то на уровне 4 приходит понимание, что всю эту требуху ресурсов надо как-то грамотно разложить по полочкам, а не просто в архив запихать.
Годаны, я щас смотрел видос про типы боеприпасов и мне пришла в голову отличная идея, пользуйтесь:
В общем есть у нас допустим в игре баллистическое оружие нескольких типов, и соответственно боеприпасы к нему, и крафт боеприпасов. И есть у нас энергетическое оружие, и боеприпасы к нему. И крафт боеприпасов. Какие виды крафта напрашиваются сюда? Я думаю все сразу в один голос разложили патроны на гильзу, пулю и порох, а батарейки разложили на банки. Так?
А вот я припомнил, что в 20 веке пытались делать лазерные пистолеты на пороховом заряде. И вот я не припомню игор, где такое есть, чтобы скажем коробку пистолетных патронов переделать в бластерные и продолжить валить монстров.
В общем есть у нас допустим в игре баллистическое оружие нескольких типов, и соответственно боеприпасы к нему, и крафт боеприпасов. И есть у нас энергетическое оружие, и боеприпасы к нему. И крафт боеприпасов. Какие виды крафта напрашиваются сюда? Я думаю все сразу в один голос разложили патроны на гильзу, пулю и порох, а батарейки разложили на банки. Так?
А вот я припомнил, что в 20 веке пытались делать лазерные пистолеты на пороховом заряде. И вот я не припомню игор, где такое есть, чтобы скажем коробку пистолетных патронов переделать в бластерные и продолжить валить монстров.
>>12654
Использую гит и бекапы. А проебать таким образом можно что угодно - хоть обычный скрипт.gd перезаписать.
Использую гит и бекапы. А проебать таким образом можно что угодно - хоть обычный скрипт.gd перезаписать.
>>12671
По каким полочкам и как именно разложить?
У меня СДВГ и ОКР, так что контроль версий - из разряда фантастических усилий... Лучше потерять свой старый проект и начать с нуля, чем сидеть ковыряться в истории и что-то где-то сохранять.
В лучшем случае залью одну версию на гитхаб и оставлю на волю случайных желающих копаться - пускай мазохисты головной болью мучаются, а не я.
>грамотно разложить по полочкам
По каким полочкам и как именно разложить?
У меня СДВГ и ОКР, так что контроль версий - из разряда фантастических усилий... Лучше потерять свой старый проект и начать с нуля, чем сидеть ковыряться в истории и что-то где-то сохранять.
В лучшем случае залью одну версию на гитхаб и оставлю на волю случайных желающих копаться - пускай мазохисты головной болью мучаются, а не я.
>>12672
Какой смысл несёт для геймплея твой крафт?
Разные патроны для разных пушек в играх - это для ограничения использования. Если ты нашёл крутую пушку, а патронов всего 5, ты не будешь ею махать, сохранишь на бой с сильным боссом или толпой.
Если ты можешь слепить из говна и палок любой боеприпас, то будешь делать только самый лучший. Например, зачем делать обычные патроны, если ты можешь делать лазерные, которые во всём круче?
А так, игры позволяют дать игроку "3D принтер" для создания любых предметов в любом количестве из ничего. Но такое подходит только песочницам.
Ограничения в играх нужны, чтобы вести игрока за ручку в направлении фанового геймплея. Без этих ограничений игроку быстро станет скучно играть.
Какой смысл несёт для геймплея твой крафт?
Разные патроны для разных пушек в играх - это для ограничения использования. Если ты нашёл крутую пушку, а патронов всего 5, ты не будешь ею махать, сохранишь на бой с сильным боссом или толпой.
Если ты можешь слепить из говна и палок любой боеприпас, то будешь делать только самый лучший. Например, зачем делать обычные патроны, если ты можешь делать лазерные, которые во всём круче?
А так, игры позволяют дать игроку "3D принтер" для создания любых предметов в любом количестве из ничего. Но такое подходит только песочницам.
Ограничения в играх нужны, чтобы вести игрока за ручку в направлении фанового геймплея. Без этих ограничений игроку быстро станет скучно играть.
>>12672
>>12676
А я этим утром листал тред на реддите, где через коммент люди ненавидели кривожопые крафтовые системы, которые ААА гейдевы пихают в свои поделки "лишь бы было".
https://old.reddit.com/r/gaming/comments/1j8degi
>>12676
А я этим утром листал тред на реддите, где через коммент люди ненавидели кривожопые крафтовые системы, которые ААА гейдевы пихают в свои поделки "лишь бы было".
https://old.reddit.com/r/gaming/comments/1j8degi
Смотрим таймлапсики https://www.youtube.com/watch?v=NuskiZzLWyg
Отдохнули и за работу!
Отдохнули и за работу!
Чел ужимает экзешники годота, 93MB -> 6.4MB
https://popcar.bearblog.dev/how-to-minify-godots-build-size/
https://popcar.bearblog.dev/how-to-minify-godots-build-size/
>>12702
В годоте все равно нет симуляции 3д жидкости (ну по крайней мере когда я последний раз чекал... может кто уже доделал плагин). Так что тебе придется самому выкручиваться. Смотри - ведь острова в обычной физике летать не могут. Значит, они чем то поднимаются - а значит, эта сила может и воду притягивать при любом наклоне.. Ну для красоты можно сделать несколько капающих струек визуально.
Или сделать что-то типа пузырей воды в невесомости, которые будут обвивать остров извне и автовыравниваться.
В годоте все равно нет симуляции 3д жидкости (ну по крайней мере когда я последний раз чекал... может кто уже доделал плагин). Так что тебе придется самому выкручиваться. Смотри - ведь острова в обычной физике летать не могут. Значит, они чем то поднимаются - а значит, эта сила может и воду притягивать при любом наклоне.. Ну для красоты можно сделать несколько капающих струек визуально.
Или сделать что-то типа пузырей воды в невесомости, которые будут обвивать остров извне и автовыравниваться.
>>12713
optimize='size' насколько я помню может хуже сказаться на производительности.
Disabling 3D это не всем подойдет. Мне так он в основном для 3д нужен.
Text server - интересная идея, полмегабайта веб билда это заметно. Продвинутый гуй - хз, richtextlabel ходовая. И не уверен что в 3-ке они одним флагом отключаются.
SVG и WebP скорее да.
UPX проблемная технология на которую дуют потому что в нее прячут вирусы, да.
Wasm opt вроде как почти не повлиял на размер, а Brotli если правильно помню медленно распаковывает, поэтому ускорение от передачи меньшего файла съедается, лол.
В общем как теоретическое упражнение хорошо.
optimize='size' насколько я помню может хуже сказаться на производительности.
Disabling 3D это не всем подойдет. Мне так он в основном для 3д нужен.
Text server - интересная идея, полмегабайта веб билда это заметно. Продвинутый гуй - хз, richtextlabel ходовая. И не уверен что в 3-ке они одним флагом отключаются.
SVG и WebP скорее да.
UPX проблемная технология на которую дуют потому что в нее прячут вирусы, да.
Wasm opt вроде как почти не повлиял на размер, а Brotli если правильно помню медленно распаковывает, поэтому ускорение от передачи меньшего файла съедается, лол.
В общем как теоретическое упражнение хорошо.
>>12676
Я просто мимо читал, но твои возражения совсем не в кассу.
Допустим, инструменты для крафта лазерных патронов появляются только в лейтгейме. Зато ты можешь переделать уже ненужную тебе гору огнестрельных.
Из 100 огнестрельных получается 1 лазерный.
Анон не уточнял, про какой жанр речь.
Всё в игре нужно, чтобы воплотить идею автора. Ограничения в том числе имеют разные предназначения, в зависимости от задач. Даже геймплей не всегда цель, иногда это средство.
Я просто мимо читал, но твои возражения совсем не в кассу.
>Если ты можешь слепить из говна и палок любой боеприпас, то будешь делать только самый лучший
>Если ты можешь
Допустим, инструменты для крафта лазерных патронов появляются только в лейтгейме. Зато ты можешь переделать уже ненужную тебе гору огнестрельных.
>для ограничения использования
Из 100 огнестрельных получается 1 лазерный.
>Но такое подходит только песочницам.
Анон не уточнял, про какой жанр речь.
>Ограничения в играх нужны, чтобы
Всё в игре нужно, чтобы воплотить идею автора. Ограничения в том числе имеют разные предназначения, в зависимости от задач. Даже геймплей не всегда цель, иногда это средство.
>>12702
А, ты это имел ввиду. Так и надо было сразу написать не "острова должны падать", а "любой остров можно перевернуть". Симуляция жидкостей в годоте возможна. Я видел. Твоё отрубывание острова на гифке процесс интерактивный, а это значит, что мы для экономии вычислительных ресурсов, можем сделать статичную area с водным шейдером, пока всё статично, и подменить её на симуляцию жидкости в тот момент когда всё оторвётся и наклонится.
> Не понимаете проблему...
А, ты это имел ввиду. Так и надо было сразу написать не "острова должны падать", а "любой остров можно перевернуть". Симуляция жидкостей в годоте возможна. Я видел. Твоё отрубывание острова на гифке процесс интерактивный, а это значит, что мы для экономии вычислительных ресурсов, можем сделать статичную area с водным шейдером, пока всё статично, и подменить её на симуляцию жидкости в тот момент когда всё оторвётся и наклонится.
>>12744
Делал чел который ecs пилил и потом на уе5 перешел. Но он подключал либу Flex от Nvidia и не выкладывал на гитхаб
https://youtu.be/L-OEPLdQpKI?si=GSHnXbs81bWZt2PF&t=4
>Симуляция жидкостей в годоте возможна. Я видел.
Делал чел который ecs пилил и потом на уе5 перешел. Но он подключал либу Flex от Nvidia и не выкладывал на гитхаб
https://youtu.be/L-OEPLdQpKI?si=GSHnXbs81bWZt2PF&t=4
>>12751
Ну надо подождать. Там джолт спешит на помощь. Но надо ещё чуть-чуть подождать.
https://www.youtube.com/watch?v=2fP9uioaEaA
Ну надо подождать. Там джолт спешит на помощь. Но надо ещё чуть-чуть подождать.
https://www.youtube.com/watch?v=2fP9uioaEaA
>>12752
Этодругое... Скорее всего не получится адекватно разрывать или склеивать софтбоди еще и в объеме. чтобы разделять на несколько капель. Я кроме SPH ничего не знаю подходящего. Это когда симулируется много частиц, а потом шейдером сглаживается (плюс математика для бликов и прочего). И как понимаю это лучше делать в compute shader, а jolt не уверен что так умеет. Либо писать c++ модуль с использованием AVX по максимуму.
Читал еще про tall cell grid, но это относится скорее к океану как альтернатива волновым алгоритмам (которые обычно в годоте для океана используют). Так что скорее всего для более полной симуляции все равно нужно оба подхода, для струй и капель SPH, для основной массы height field или grid based.
Хз, может попробую за год с помощью опенсорс либ и нейронок сделать
Этодругое... Скорее всего не получится адекватно разрывать или склеивать софтбоди еще и в объеме. чтобы разделять на несколько капель. Я кроме SPH ничего не знаю подходящего. Это когда симулируется много частиц, а потом шейдером сглаживается (плюс математика для бликов и прочего). И как понимаю это лучше делать в compute shader, а jolt не уверен что так умеет. Либо писать c++ модуль с использованием AVX по максимуму.
Читал еще про tall cell grid, но это относится скорее к океану как альтернатива волновым алгоритмам (которые обычно в годоте для океана используют). Так что скорее всего для более полной симуляции все равно нужно оба подхода, для струй и капель SPH, для основной массы height field или grid based.
Хз, может попробую за год с помощью опенсорс либ и нейронок сделать
>>12702
>>12744
>>12776
Просто скажите что у вас superfluid, и она протекает сквозь остров: https://www.youtube.com/watch?v=2Z6UJbwxBZI
>>12744
>>12776
>симуляция жидкостей
Просто скажите что у вас superfluid, и она протекает сквозь остров: https://www.youtube.com/watch?v=2Z6UJbwxBZI
>>12776
Я псмотрел на пикчи и у меня родилась мысль, если сделать симуляцию жидкости через ригид-боди-шары, настроенные так, что друг с другом не сталкиваются, а с окружением сталкиваются, и вот мы их высыпаем из корзинки и они выглядят (предположительно) как жидкость.
Я псмотрел на пикчи и у меня родилась мысль, если сделать симуляцию жидкости через ригид-боди-шары, настроенные так, что друг с другом не сталкиваются, а с окружением сталкиваются, и вот мы их высыпаем из корзинки и они выглядят (предположительно) как жидкость.
>>12781
А хотя нет, ригиды тоже стакиваются, только у шейпа диаметр скажем метр, а у меша диаметр полтора. И получим эффект волнистой шевелящейся поверхности. Потом туда на меш ещё шейдер ебануть хитрый и - в продакшон.
А хотя нет, ригиды тоже стакиваются, только у шейпа диаметр скажем метр, а у меша диаметр полтора. И получим эффект волнистой шевелящейся поверхности. Потом туда на меш ещё шейдер ебануть хитрый и - в продакшон.
7 Кб, 423x119>>12782
Их надо слишком много чтобы физон вытягивал без ухищрений с c++/AVX или комьют шейдерами.
А насчет шейдера, в 2д я видел какой то простой способ, а в 3д чтобы metaball сделать, кажется без marching cubes не обойтись, а это тоже недешево.
Их надо слишком много чтобы физон вытягивал без ухищрений с c++/AVX или комьют шейдерами.
А насчет шейдера, в 2д я видел какой то простой способ, а в 3д чтобы metaball сделать, кажется без marching cubes не обойтись, а это тоже недешево.
>>12715 >>12744 >>12776 >>12782
Достаточно было б наклонять плоскость жидкости, спускаясь по Y в локальных координатах. Вы ведь наблюдали за напитком в кружке? Вот как-то так - симулировать отдельные капли/сферы не нужно, поверхность жидкости просто наклоняется...
Теоретически должно было нормально выглядеть. Однако, на практике полигон придётся ещё и как-то скукоживать или строить заново, т.к. даже круглое отверстие при наклоне не так-то просто меняется... Наверняка есть ещё много скрытых проблем, но главный вывод: каждый такой сосуд пришлось бы настраивать по отдельности - мне лень это делать.
Чем, чем - воздушными шарами они поднимаются. Правдоподобно, разве нет?.. Достаточно плотная атмосфера и низкая гравитация позволяют этим "островам" держаться за счёт газа легче воздуха в растениях относительно небольшого размера. По существу, это астероиды в газовом тороиде, но функционально ближе всего к аэростатам. См. концептуальную схему мира - тор развернуть на плоскость очень легко - симулировать можно без искажения координат/векторов (верх всегда +Y).
Я теперь думаю, может, зря я так вцепился в идею разрушения островов. Многие потенциальные идеи невозможно или очень трудно реализовать в мире, исключающим стабильную землю (StaticBody3D). Жидкости-то не особо нужны, но с NPC всё сложно. Изначально хотел делать хардкорный выживач, что требовал бы трястись за каждое полено и шарик с летучим газом, а теперь склоняюсь к чему-то более спокойному, но чтоб механики передвижения были интересными (прыжки с верёвкой хочу сохранить).
Мне просто не хочется делать банальную плоскость, ландшафт - всё это я уже пробовал и мне совсем не понравилось: нужно заполнять огромную, лишнюю территорию каким-то контентом и потом ещё этот массивный копипастный контент оптимизировать. Летающие острова позволяют забить на всё это и сфокусироваться на отдельных точках интереса, тривиально скрывая остальные в сером тумане. Опенворлд, но без лишнего мусора на дорогах и с интересными механиками передвижения, а не зажиманием одной кнопки несколько минут.
Т.е. на самом деле мне хотелось бы песочницу, где возможно просто часами аутировать без дела, но в компании интересных NPC, а не выживалку... Но абсолютные песочницы меня не привлекают, т.е. требуется какой-то базовый геймплейный цикл.
Идея прикольная, вот здесь что-то такое описано:
https://en.wikipedia.org/wiki/The_Integral_Trees
Но я сомневаюсь, как это всё сочетать, т.к. у меня гравитация действует строго в направлении -Y... И переходить к невесомости как-то не хочется. Т.е. космический симулятор делать я не планирую...
Ладно. Нужно ещё подумать. Приходится думать одновременно о геймплее, физике и графике, чтоб интересно игралось, не глючило, не тормозило, но выглядело красиво и правдоподобно (не путать с реалистичностью: речь тут о заданных правилах вымышленного мира, т.е. если "ящик" падает, то и "жидкость" тоже падает, иначе нарушение правил). Фантазии у меня, правда, не хватает на такое...
>>12783
Судя по твоему рисунку - достаточно нормали в вершинном шейдере повернуть, чтоб из обрубка визуально получилась гладкая гантеля. Вы тут всё слишком усложняете - моделирование жидкостей используется только в научных работах, не в играх. Исключение - всякие The Powder Toy, Terraria, где взаимодействия с жидкостью - основа всей игры. Большинству игр достаточно шума на плоскости.
>симуляции 3д жидкости
Достаточно было б наклонять плоскость жидкости, спускаясь по Y в локальных координатах. Вы ведь наблюдали за напитком в кружке? Вот как-то так - симулировать отдельные капли/сферы не нужно, поверхность жидкости просто наклоняется...
Теоретически должно было нормально выглядеть. Однако, на практике полигон придётся ещё и как-то скукоживать или строить заново, т.к. даже круглое отверстие при наклоне не так-то просто меняется... Наверняка есть ещё много скрытых проблем, но главный вывод: каждый такой сосуд пришлось бы настраивать по отдельности - мне лень это делать.
>острова в обычной физике летать не могут
>они чем то поднимаются
Чем, чем - воздушными шарами они поднимаются. Правдоподобно, разве нет?.. Достаточно плотная атмосфера и низкая гравитация позволяют этим "островам" держаться за счёт газа легче воздуха в растениях относительно небольшого размера. По существу, это астероиды в газовом тороиде, но функционально ближе всего к аэростатам. См. концептуальную схему мира - тор развернуть на плоскость очень легко - симулировать можно без искажения координат/векторов (верх всегда +Y).
Я теперь думаю, может, зря я так вцепился в идею разрушения островов. Многие потенциальные идеи невозможно или очень трудно реализовать в мире, исключающим стабильную землю (StaticBody3D). Жидкости-то не особо нужны, но с NPC всё сложно. Изначально хотел делать хардкорный выживач, что требовал бы трястись за каждое полено и шарик с летучим газом, а теперь склоняюсь к чему-то более спокойному, но чтоб механики передвижения были интересными (прыжки с верёвкой хочу сохранить).
Мне просто не хочется делать банальную плоскость, ландшафт - всё это я уже пробовал и мне совсем не понравилось: нужно заполнять огромную, лишнюю территорию каким-то контентом и потом ещё этот массивный копипастный контент оптимизировать. Летающие острова позволяют забить на всё это и сфокусироваться на отдельных точках интереса, тривиально скрывая остальные в сером тумане. Опенворлд, но без лишнего мусора на дорогах и с интересными механиками передвижения, а не зажиманием одной кнопки несколько минут.
Т.е. на самом деле мне хотелось бы песочницу, где возможно просто часами аутировать без дела, но в компании интересных NPC, а не выживалку... Но абсолютные песочницы меня не привлекают, т.е. требуется какой-то базовый геймплейный цикл.
>пузырей воды в невесомости
Идея прикольная, вот здесь что-то такое описано:
https://en.wikipedia.org/wiki/The_Integral_Trees
Но я сомневаюсь, как это всё сочетать, т.к. у меня гравитация действует строго в направлении -Y... И переходить к невесомости как-то не хочется. Т.е. космический симулятор делать я не планирую...
Ладно. Нужно ещё подумать. Приходится думать одновременно о геймплее, физике и графике, чтоб интересно игралось, не глючило, не тормозило, но выглядело красиво и правдоподобно (не путать с реалистичностью: речь тут о заданных правилах вымышленного мира, т.е. если "ящик" падает, то и "жидкость" тоже падает, иначе нарушение правил). Фантазии у меня, правда, не хватает на такое...
>>12783
Судя по твоему рисунку - достаточно нормали в вершинном шейдере повернуть, чтоб из обрубка визуально получилась гладкая гантеля. Вы тут всё слишком усложняете - моделирование жидкостей используется только в научных работах, не в играх. Исключение - всякие The Powder Toy, Terraria, где взаимодействия с жидкостью - основа всей игры. Большинству игр достаточно шума на плоскости.
>>12715 >>12744 >>12776 >>12782
Достаточно было б наклонять плоскость жидкости, спускаясь по Y в локальных координатах. Вы ведь наблюдали за напитком в кружке? Вот как-то так - симулировать отдельные капли/сферы не нужно, поверхность жидкости просто наклоняется...
Теоретически должно было нормально выглядеть. Однако, на практике полигон придётся ещё и как-то скукоживать или строить заново, т.к. даже круглое отверстие при наклоне не так-то просто меняется... Наверняка есть ещё много скрытых проблем, но главный вывод: каждый такой сосуд пришлось бы настраивать по отдельности - мне лень это делать.
Чем, чем - воздушными шарами они поднимаются. Правдоподобно, разве нет?.. Достаточно плотная атмосфера и низкая гравитация позволяют этим "островам" держаться за счёт газа легче воздуха в растениях относительно небольшого размера. По существу, это астероиды в газовом тороиде, но функционально ближе всего к аэростатам. См. концептуальную схему мира - тор развернуть на плоскость очень легко - симулировать можно без искажения координат/векторов (верх всегда +Y).
Я теперь думаю, может, зря я так вцепился в идею разрушения островов. Многие потенциальные идеи невозможно или очень трудно реализовать в мире, исключающим стабильную землю (StaticBody3D). Жидкости-то не особо нужны, но с NPC всё сложно. Изначально хотел делать хардкорный выживач, что требовал бы трястись за каждое полено и шарик с летучим газом, а теперь склоняюсь к чему-то более спокойному, но чтоб механики передвижения были интересными (прыжки с верёвкой хочу сохранить).
Мне просто не хочется делать банальную плоскость, ландшафт - всё это я уже пробовал и мне совсем не понравилось: нужно заполнять огромную, лишнюю территорию каким-то контентом и потом ещё этот массивный копипастный контент оптимизировать. Летающие острова позволяют забить на всё это и сфокусироваться на отдельных точках интереса, тривиально скрывая остальные в сером тумане. Опенворлд, но без лишнего мусора на дорогах и с интересными механиками передвижения, а не зажиманием одной кнопки несколько минут.
Т.е. на самом деле мне хотелось бы песочницу, где возможно просто часами аутировать без дела, но в компании интересных NPC, а не выживалку... Но абсолютные песочницы меня не привлекают, т.е. требуется какой-то базовый геймплейный цикл.
Идея прикольная, вот здесь что-то такое описано:
https://en.wikipedia.org/wiki/The_Integral_Trees
Но я сомневаюсь, как это всё сочетать, т.к. у меня гравитация действует строго в направлении -Y... И переходить к невесомости как-то не хочется. Т.е. космический симулятор делать я не планирую...
Ладно. Нужно ещё подумать. Приходится думать одновременно о геймплее, физике и графике, чтоб интересно игралось, не глючило, не тормозило, но выглядело красиво и правдоподобно (не путать с реалистичностью: речь тут о заданных правилах вымышленного мира, т.е. если "ящик" падает, то и "жидкость" тоже падает, иначе нарушение правил). Фантазии у меня, правда, не хватает на такое...
>>12783
Судя по твоему рисунку - достаточно нормали в вершинном шейдере повернуть, чтоб из обрубка визуально получилась гладкая гантеля. Вы тут всё слишком усложняете - моделирование жидкостей используется только в научных работах, не в играх. Исключение - всякие The Powder Toy, Terraria, где взаимодействия с жидкостью - основа всей игры. Большинству игр достаточно шума на плоскости.
>симуляции 3д жидкости
Достаточно было б наклонять плоскость жидкости, спускаясь по Y в локальных координатах. Вы ведь наблюдали за напитком в кружке? Вот как-то так - симулировать отдельные капли/сферы не нужно, поверхность жидкости просто наклоняется...
Теоретически должно было нормально выглядеть. Однако, на практике полигон придётся ещё и как-то скукоживать или строить заново, т.к. даже круглое отверстие при наклоне не так-то просто меняется... Наверняка есть ещё много скрытых проблем, но главный вывод: каждый такой сосуд пришлось бы настраивать по отдельности - мне лень это делать.
>острова в обычной физике летать не могут
>они чем то поднимаются
Чем, чем - воздушными шарами они поднимаются. Правдоподобно, разве нет?.. Достаточно плотная атмосфера и низкая гравитация позволяют этим "островам" держаться за счёт газа легче воздуха в растениях относительно небольшого размера. По существу, это астероиды в газовом тороиде, но функционально ближе всего к аэростатам. См. концептуальную схему мира - тор развернуть на плоскость очень легко - симулировать можно без искажения координат/векторов (верх всегда +Y).
Я теперь думаю, может, зря я так вцепился в идею разрушения островов. Многие потенциальные идеи невозможно или очень трудно реализовать в мире, исключающим стабильную землю (StaticBody3D). Жидкости-то не особо нужны, но с NPC всё сложно. Изначально хотел делать хардкорный выживач, что требовал бы трястись за каждое полено и шарик с летучим газом, а теперь склоняюсь к чему-то более спокойному, но чтоб механики передвижения были интересными (прыжки с верёвкой хочу сохранить).
Мне просто не хочется делать банальную плоскость, ландшафт - всё это я уже пробовал и мне совсем не понравилось: нужно заполнять огромную, лишнюю территорию каким-то контентом и потом ещё этот массивный копипастный контент оптимизировать. Летающие острова позволяют забить на всё это и сфокусироваться на отдельных точках интереса, тривиально скрывая остальные в сером тумане. Опенворлд, но без лишнего мусора на дорогах и с интересными механиками передвижения, а не зажиманием одной кнопки несколько минут.
Т.е. на самом деле мне хотелось бы песочницу, где возможно просто часами аутировать без дела, но в компании интересных NPC, а не выживалку... Но абсолютные песочницы меня не привлекают, т.е. требуется какой-то базовый геймплейный цикл.
>пузырей воды в невесомости
Идея прикольная, вот здесь что-то такое описано:
https://en.wikipedia.org/wiki/The_Integral_Trees
Но я сомневаюсь, как это всё сочетать, т.к. у меня гравитация действует строго в направлении -Y... И переходить к невесомости как-то не хочется. Т.е. космический симулятор делать я не планирую...
Ладно. Нужно ещё подумать. Приходится думать одновременно о геймплее, физике и графике, чтоб интересно игралось, не глючило, не тормозило, но выглядело красиво и правдоподобно (не путать с реалистичностью: речь тут о заданных правилах вымышленного мира, т.е. если "ящик" падает, то и "жидкость" тоже падает, иначе нарушение правил). Фантазии у меня, правда, не хватает на такое...
>>12783
Судя по твоему рисунку - достаточно нормали в вершинном шейдере повернуть, чтоб из обрубка визуально получилась гладкая гантеля. Вы тут всё слишком усложняете - моделирование жидкостей используется только в научных работах, не в играх. Исключение - всякие The Powder Toy, Terraria, где взаимодействия с жидкостью - основа всей игры. Большинству игр достаточно шума на плоскости.
131 Кб, 976x175>>12784
Не, там в другом суть.
Если у тебя частицы, допустим сферы, то просто нет материала, вершин, из которых состоит связующая их кривая поверхность.
>Судя по твоему рисунку - достаточно нормали в вершинном шейдере повернуть, чтоб из обрубка визуально получилась гладкая гантеля
Не, там в другом суть.
Если у тебя частицы, допустим сферы, то просто нет материала, вершин, из которых состоит связующая их кривая поверхность.
>>12787
Зы а известный способ их добавить - это упомянутый Marching cubes
Тот же алгоритм, что используется в сглаженном воксельном террейне годота от Zylann.
Зы а известный способ их добавить - это упомянутый Marching cubes
Тот же алгоритм, что используется в сглаженном воксельном террейне годота от Zylann.
>>12787 >>12789
А ты не делай сетку кубов размером 0.000001 метра, и тогда нагрузка будет не такой большой. Вот только такая симуляция в принципе не нужна игре. Это же несущественная декорация в данном случае.
>>12785
Не еш, подумой. Тебе точно нужно с этим возиться?
Напоминаю, с чего всё началось: было сказано, что водную гладь (не шары, не симуляцию капель, лишь "водяное" блюдце на одном шейдере) добавлять нет возможности, потому что она не будет нормально реагировать на наклон своего родителя. Никто не спрашивал как сделать реалистичную воду, и про моделирование водяных капель я минимум 10 лет слышал и видел все эти крутые демонстрации, которые не запустить в реальном времени.
Есть фундаментальные механики и есть декорации. Водичка в данном случае декоративная и поэтому симуляции никакой быть не должно. Можно сделать хитроумный костыль, но стоит ли он таких усилий?
А ты не делай сетку кубов размером 0.000001 метра, и тогда нагрузка будет не такой большой. Вот только такая симуляция в принципе не нужна игре. Это же несущественная декорация в данном случае.
>>12785
Не еш, подумой. Тебе точно нужно с этим возиться?
Напоминаю, с чего всё началось: было сказано, что водную гладь (не шары, не симуляцию капель, лишь "водяное" блюдце на одном шейдере) добавлять нет возможности, потому что она не будет нормально реагировать на наклон своего родителя. Никто не спрашивал как сделать реалистичную воду, и про моделирование водяных капель я минимум 10 лет слышал и видел все эти крутые демонстрации, которые не запустить в реальном времени.
Есть фундаментальные механики и есть декорации. Водичка в данном случае декоративная и поэтому симуляции никакой быть не должно. Можно сделать хитроумный костыль, но стоит ли он таких усилий?
4 Кб, 256x256>>12807
Ну если тебе нужна декорация то добавь фейковый водопад, в чем проблема
Есть всякие WaterWays, но в качесве лулзов подумалось что можно сделать водопад по типу MeshTrail
Которые можно еще смешно подвесить чтобы они болтались на костях и качались.
Ну если тебе нужна декорация то добавь фейковый водопад, в чем проблема
Есть всякие WaterWays, но в качесве лулзов подумалось что можно сделать водопад по типу MeshTrail
Которые можно еще смешно подвесить чтобы они болтались на костях и качались.
Сайтец с несколькими примерами кода и статьями на разные штуки, под MIT лицензией.
https://thegodotbarn.com/snippets
https://thegodotbarn.com/snippets
>>12812
Отличная тренировочная дата для нейросети.
Отличная тренировочная дата для нейросети.
>>12807
Удваиваю фейковый водопад на шейдерах. Все делоют и ты делой. А я попытался сделать симуляцию, но получилась какая-то атомная решетка, на 7 ФПС. Несмотря на то что я заморочился с мультимешем и джолт на физике. Даже записать не удалось толком.
Идея интересная, надо применить где-нибудь ещё. Не для симуляции воды уж точно.
Главное, чтобы в итоге всей возни получить бесценный опыт. Вот я мультимеши освоил на практике.
Удваиваю фейковый водопад на шейдерах. Все делоют и ты делой. А я попытался сделать симуляцию, но получилась какая-то атомная решетка, на 7 ФПС. Несмотря на то что я заморочился с мультимешем и джолт на физике. Даже записать не удалось толком.
Идея интересная, надо применить где-нибудь ещё. Не для симуляции воды уж точно.
> Тебе точно нужно с этим возиться?
Главное, чтобы в итоге всей возни получить бесценный опыт. Вот я мультимеши освоил на практике.
>>12821
Попробуй в настройках материала:
Это должно убрать лишние градиенты.
Там много причин может быть. Какие CPU и GPU? Настройки рендеринга? Число треугольников? Количество физических тел в сцене? И т.д.
По-моему, они не предназначены для подвижных объектов... Ты, получается, делаешь x100 запросов изменения данных на видеокарте каждый кадр, а оптимизация в мультимеше подразумевает, что ты отправляешь все данные один раз и не трогаешь их.
>>12811
Проблема в том, что он должен быть со стороны, на которую накренился остров из-за действий игрока...
Не важно, забудьте, это всё - моя прокрастинация.
Больше всего в геймдеве меня привлекали NPC. Но вместо хоть какой-то работы над ними очень много лет занимаюсь всякой ненужной фигнёй, которая создаёт иллюзию, будто я делаю что-то полезное.
Это всё моя прокрастинация. Я уверен, что мне не удастся реализовать желаемое поведение NPC, и поэтому откладываю разочарование на потом...
>получилась какая-то атомная решетка
Попробуй в настройках материала:
>DIFFUSE_TOON
>SPECULAR_TOON
Это должно убрать лишние градиенты.
>на 7 ФПС
Там много причин может быть. Какие CPU и GPU? Настройки рендеринга? Число треугольников? Количество физических тел в сцене? И т.д.
>мультимеши освоил на практике
По-моему, они не предназначены для подвижных объектов... Ты, получается, делаешь x100 запросов изменения данных на видеокарте каждый кадр, а оптимизация в мультимеше подразумевает, что ты отправляешь все данные один раз и не трогаешь их.
>>12811
>фейковый водопад, в чем проблема
Проблема в том, что он должен быть со стороны, на которую накренился остров из-за действий игрока...
Не важно, забудьте, это всё - моя прокрастинация.
Больше всего в геймдеве меня привлекали NPC. Но вместо хоть какой-то работы над ними очень много лет занимаюсь всякой ненужной фигнёй, которая создаёт иллюзию, будто я делаю что-то полезное.
Это всё моя прокрастинация. Я уверен, что мне не удастся реализовать желаемое поведение NPC, и поэтому откладываю разочарование на потом...
>>12822
Ужасные. Я аццкий нищеброд.
Десять дровколов. Или я чего-то не понимаю.
Именно из-за тел и тормозит.
Я планировал на софтбоди перейти от спавна отдельных тел, но софтбоди это как будто бы нечто совсем другое.
В общем, не вышло.
> Какие CPU и GPU?
Ужасные. Я аццкий нищеброд.
> получается, делаешь x100 запросов изменения данных на видеокарте каждый кадр
Десять дровколов. Или я чего-то не понимаю.
> Количество физических тел в сцене?
Именно из-за тел и тормозит.
Я планировал на софтбоди перейти от спавна отдельных тел, но софтбоди это как будто бы нечто совсем другое.
В общем, не вышло.
160 Кб, 1633x887>>12822
Понимаю. Я сам как то попытался в поведение NPC, чтобы симулировать каждого жителя в каждом доме и чтобы в каждую квартиру заходить можно было да так и застрял тоже на всяких мелких системах и уже давно забыл что цель игры мечты была изучение ИИ, а не вот это все.
Понимаю. Я сам как то попытался в поведение NPC, чтобы симулировать каждого жителя в каждом доме и чтобы в каждую квартиру заходить можно было да так и застрял тоже на всяких мелких системах и уже давно забыл что цель игры мечты была изучение ИИ, а не вот это все.
148 Кб, 849x827>>12825
Да и вспомнив про профайлер, я выяснил, что это какие-то не настоящие дровколлы. Не может их быть так мало. (Добавил простой меш куб в тела).
Да и вспомнив про профайлер, я выяснил, что это какие-то не настоящие дровколлы. Не может их быть так мало. (Добавил простой меш куб в тела).
>>12828
В этом смысл мультимеша.
В этом смысл мультимеша.
>По-моему, они не предназначены для подвижных объектов... Ты, получается, делаешь x100 запросов изменения данных на видеокарте каждый кадр, а оптимизация в мультимеше подразумевает, что ты отправляешь все данные один раз и не трогаешь их.
Предназначены, в Хоппе же 100 комаров летает (еще и индивидуально анимированных, с помощью VAT).
Очевидно когда ты делаешь instance_set_transform просто записывает данные в масстив на стороне компьютера, а уже раз в кадр их отсылает. Но даже если это не так, то можно самому собирать PackedArray и передавать один раз, там же есть и такой метод.
>>12807
Не согласен. Вот эта демка на WebGL 50000 партиклов у меня на 3060 работает на 37 фпс. В вебе. Так что выглядит как вполне доступная технология на сегодня. Но и с меньшим количеством уже можно использовать для геймплея. Вон в Портале 2 было же уже, порталы оттуда все копируют, а жидкость все тянут.
https://xuxmin.github.io/pbf/
>про моделирование водяных капель
>все эти крутые демонстрации, которые не запустить в реальном времени.
Не согласен. Вот эта демка на WebGL 50000 партиклов у меня на 3060 работает на 37 фпс. В вебе. Так что выглядит как вполне доступная технология на сегодня. Но и с меньшим количеством уже можно использовать для геймплея. Вон в Портале 2 было же уже, порталы оттуда все копируют, а жидкость все тянут.
https://xuxmin.github.io/pbf/
Вот весёлый дядька с завитыми усиками сделал внутриигровую консоль, чтобы не пришлось делать тебе.
https://www.youtube.com/watch?v=M_ymfQtZad4
https://www.youtube.com/watch?v=M_ymfQtZad4
А мог бы чем-то полезным заниматься...
>>12826
Текст на скриншоте почему-то кажется знакомым...
Смотрю, ты много запланировал, что в итоге смог реализовать? ИМХО, нужно сначала фреймоворк разработать и обкатать на базовых возможностях, прежде чем зарываться в эти детали психологии. Психология изучает то, что в мозге находится на толстой стопке абстракций. Без этих абстракций (примитивных потребностей, "инстинктов" и т.п.) высокоуровневые системы вряд ли заработают.
А я просто от одиночества мучаюсь, вот и хочется разработать ИИ компаньона. Раньше пробовал в различные онлайн-игры играть, но там такие же проблемы с людьми, как и в реальной жизни... А в одиночных играх практически не бывает умных дружественных NPC, или я их где-то не там ищу.
Тоже, кстати, несколько лет планировал заполнить виртуальное поселение ИИ-агентами, но ничего не получилось. Со временем понял, что делать сразу масштабную симуляцию ради одного компаньона бессмысленно, т.к. куча сил уйдёт на оптимизации алгоритмов вместо добавления интересных фич.
Текст на скриншоте почему-то кажется знакомым...
>цель игры мечты была изучение ИИ
Смотрю, ты много запланировал, что в итоге смог реализовать? ИМХО, нужно сначала фреймоворк разработать и обкатать на базовых возможностях, прежде чем зарываться в эти детали психологии. Психология изучает то, что в мозге находится на толстой стопке абстракций. Без этих абстракций (примитивных потребностей, "инстинктов" и т.п.) высокоуровневые системы вряд ли заработают.
А я просто от одиночества мучаюсь, вот и хочется разработать ИИ компаньона. Раньше пробовал в различные онлайн-игры играть, но там такие же проблемы с людьми, как и в реальной жизни... А в одиночных играх практически не бывает умных дружественных NPC, или я их где-то не там ищу.
Тоже, кстати, несколько лет планировал заполнить виртуальное поселение ИИ-агентами, но ничего не получилось. Со временем понял, что делать сразу масштабную симуляцию ради одного компаньона бессмысленно, т.к. куча сил уйдёт на оптимизации алгоритмов вместо добавления интересных фич.
29 Кб, 1200x510>>12869
Полезное сделол. Порадовал дедушку новыми видосами с жопастенькой внучкой.
Алсоу, вот я тут нашёл канал с годоновостями: https://www.youtube.com/watch?v=m1OazkVUBZQ
Полезное сделол. Порадовал дедушку новыми видосами с жопастенькой внучкой.
Алсоу, вот я тут нашёл канал с годоновостями: https://www.youtube.com/watch?v=m1OazkVUBZQ
Неразрушающее прототипирование террейна на CSG/кривых
https://godotengine.org/asset-library/asset/3786
https://github.com/SpockBauru/CSG_Terrain
https://godotengine.org/asset-library/asset/3786
https://github.com/SpockBauru/CSG_Terrain
>>12926
Охуенный чел, кстати. Когда если релизните свои игры - у него на сайте можно отправить игру к нему на рассмотрение, окажешься в этом видосе. Я так дважды попадал, хороший буст к популярности.
>канал с годоновостями
Охуенный чел, кстати. Когда если релизните свои игры - у него на сайте можно отправить игру к нему на рассмотрение, окажешься в этом видосе. Я так дважды попадал, хороший буст к популярности.
А вот кстати, вчера поговорили, а тут и порекомендовали.
https://www.youtube.com/watch?v=Qk_O-q_9YIQ
https://www.youtube.com/watch?v=Qk_O-q_9YIQ
Искал инфу по теме жидкостей, и нашёл в глубинах кроличьей норы вот такое
https://github.com/fnaith/godot-fluid-hierarchical-task-network
https://www.gameaipro.com/GameAIPro/GameAIPro_Chapter12_Exploring_HTN_Planners_through_Example.pdf
Забирайте, кому нужны ИИ на основе иерархических сетей задач.
https://github.com/fnaith/godot-fluid-hierarchical-task-network
https://www.gameaipro.com/GameAIPro/GameAIPro_Chapter12_Exploring_HTN_Planners_through_Example.pdf
Забирайте, кому нужны ИИ на основе иерархических сетей задач.
>>12992
Похоже на то. Но не совсем понятна разница.
>>12965
Кому нужны - сами найдут. Сложные планировщики редко встречаются в играх, ибо не нужны. Не берите микроскоп для забивания гвоздей, даже если он бесплатный и под свободной лицензией...
Тем более что это на GDScript, а значит, будет очень медленно для регулярного использования кучей ИИ. Стоит дважды подумать, прежде чем тащить в игру.
Всё-таки GDScript предназначен для "glue code", а низкоуровневые библиотеки лучше делать на C++.
Похоже на то. Но не совсем понятна разница.
>>12965
>кому нужны
Кому нужны - сами найдут. Сложные планировщики редко встречаются в играх, ибо не нужны. Не берите микроскоп для забивания гвоздей, даже если он бесплатный и под свободной лицензией...
Тем более что это на GDScript, а значит, будет очень медленно для регулярного использования кучей ИИ. Стоит дважды подумать, прежде чем тащить в игру.
Всё-таки GDScript предназначен для "glue code", а низкоуровневые библиотеки лучше делать на C++.
28 Кб, 1112x218>>12994
Аналогично
С таких утверждений выпал.
Мы вставили тебе в HTN GOAP чтобы решать GOAP через GOAP
>Но не совсем понятна разница.
Аналогично
С таких утверждений выпал.
Мы вставили тебе в HTN GOAP чтобы решать GOAP через GOAP
>>12995
Я тут, кстати, недавно лайфхак вычитал на форумах: построить карту действий GOAP как граф, и искать последовательность действий с помощью... А-стар. ВНЕЗАПНО всё становится на свои места: если все действия - шаги на пути к цели, то что мешает взять построить оптимальный путь с помощью А-стар?
Это если тебе нужен оптимальный путь...
>find a path... GOAP
Я тут, кстати, недавно лайфхак вычитал на форумах: построить карту действий GOAP как граф, и искать последовательность действий с помощью... А-стар. ВНЕЗАПНО всё становится на свои места: если все действия - шаги на пути к цели, то что мешает взять построить оптимальный путь с помощью А-стар?
Это если тебе нужен оптимальный путь...
>>13065
игру хоть сделал?
игру хоть сделал?
Я вчера предавался аутизму: нагенерировал террейн 8 на 8 километров с горами выше скайримских и бродил там простеньким контроллером, без геймплея, без нихуя, в 10 ФПС, блеать, весь вечер. Нахуй мне делать игры? У меня и так весь геймплей, весь отыгрыш в голове происходил и происходит.
>>13089
Игра нужна, чтобы:
- установить чёткие правила и следовать им;
- сохранять прогресс, не полагаясь на память;
- делиться скриншотами с другими людьми;
- крутить симуляцию вне твоего внимания;
- иметь везде стабильно чёткую картинку.
Мозг на это всё не способен.
>весь отыгрыш в голове
Игра нужна, чтобы:
- установить чёткие правила и следовать им;
- сохранять прогресс, не полагаясь на память;
- делиться скриншотами с другими людьми;
- крутить симуляцию вне твоего внимания;
- иметь везде стабильно чёткую картинку.
Мозг на это всё не способен.
>>13089
Но ведь годот не может в 3д
Но ведь годот не может в 3д
https://godotengine.org/article/release-candidate-godot-4-4-1-rc-1/
4.4.1 сун, можно игры будет делать.
4.4.1 сун, можно игры будет делать.
>>13131
Можно просто открыть редактор и не делать игру.
>more efficient sleep approach when low-processor
Можно просто открыть редактор и не делать игру.
Может кто объяснить как работало освещение в старых играх? Вот например игра на анрил энжине 2 (пик 1-2), 2002 год, эпоха слабого железа, не способного в полноценное динамическое освещение. Предполагаю что почти все освещение - запеченное. Как тогда были реализованы спеллы, подсвечивающие вокруг себя все, пока летят? Моделька персонажа тоже реагировала на освещение.
Или УТ, 99 год (пик 3-4) - каждый предмет освещал область вокруг себя.
Как подобное реализовать сегодня в годоте, не вставляя омнилайт в каждую дыру?
Или УТ, 99 год (пик 3-4) - каждый предмет освещал область вокруг себя.
Как подобное реализовать сегодня в годоте, не вставляя омнилайт в каждую дыру?
>>13190
Так и работало. Это и был аналог омнилайта. После рендера читались положения источников света и в этих местах подкрашивалось, омнилайт так же на стадии light() шейдера делает. Не понял зачем вставлять омнилайт в дыру, когда очевидно его надо вставлять в летящую ракету или взрыв.
Так и работало. Это и был аналог омнилайта. После рендера читались положения источников света и в этих местах подкрашивалось, омнилайт так же на стадии light() шейдера делает. Не понял зачем вставлять омнилайт в дыру, когда очевидно его надо вставлять в летящую ракету или взрыв.
>>13190
полагаю, там было вертексное освещение по Гуро (Gouraud)
а ещё раньше (Quake 2 например) было ещё более дешёвое освещение, на уровне меша или целой модели: модель попадает в сферу/куб света - все вершины меняют vertex color
полагаю, там было вертексное освещение по Гуро (Gouraud)
а ещё раньше (Quake 2 например) было ещё более дешёвое освещение, на уровне меша или целой модели: модель попадает в сферу/куб света - все вершины меняют vertex color
>>13193
Образно. Но да - в каждую ракету. В КАЖДУЮ. В каждый пикап, в каждый эффект, в каждый взрыв. Учитывая что игра мультиплеерная, таких омнилайтов на экране под 30 набиралось. Поэтому мне сложно поверить что в те древние байтоебские времена они не придумали чего-то похитрее.
>Не понял зачем вставлять омнилайт в дыру, когда очевидно его надо вставлять в летящую ракету или взрыв.
Образно. Но да - в каждую ракету. В КАЖДУЮ. В каждый пикап, в каждый эффект, в каждый взрыв. Учитывая что игра мультиплеерная, таких омнилайтов на экране под 30 набиралось. Поэтому мне сложно поверить что в те древние байтоебские времена они не придумали чего-то похитрее.
>>13190
Что тебя смущает в омнилайтах?
OpenGL 1.0 вышел в 1992, сразу имея освещение, реализованное в железе видеокарт тех лет:
https://en.wikipedia.org/wiki/Gouraud_shading
Сегодня ты можешь натыкать сотни омнилайтов совершенно без каких-либо либо проблем в плане производительности. Ибо шейдинг (закрашивание треугольников градиентом) всегда был дешёвым. Ограничение только по числу омнилайтов на меш.
Ты, скорее всего, путаешь освещение с тенями. Это отдельные понятия в компьютерной графике: можно освещать без теней и кастовать тени без освещения. Создание теней требует сложных операций, в случае большинства игр - рендеринг всей сцены со стороны источника света, поэтому каждый источник света с включёнными тенями и каждый меш, бросающий собственную тень, снижает производительность. Шейдинг же делается сразу, без теней.
Просто выключи тени на своих омнилайтах.
>>13193
Он имел в виду "делать слишком много омнилайт".
"... в каждую дыру" == "... избыточно много".
>>13196
Думаю, что лампочки вдалеке от игрока заменялись обычным спрайтом с градиентом, т.к. вроде бы было хардварное ограничение на 8 источников света.
Погугли, как GTA 5 рендерит фары в ночном городе.
>полноценное динамическое освещение
>не вставляя омнилайт
Что тебя смущает в омнилайтах?
OpenGL 1.0 вышел в 1992, сразу имея освещение, реализованное в железе видеокарт тех лет:
https://en.wikipedia.org/wiki/Gouraud_shading
Сегодня ты можешь натыкать сотни омнилайтов совершенно без каких-либо либо проблем в плане производительности. Ибо шейдинг (закрашивание треугольников градиентом) всегда был дешёвым. Ограничение только по числу омнилайтов на меш.
Ты, скорее всего, путаешь освещение с тенями. Это отдельные понятия в компьютерной графике: можно освещать без теней и кастовать тени без освещения. Создание теней требует сложных операций, в случае большинства игр - рендеринг всей сцены со стороны источника света, поэтому каждый источник света с включёнными тенями и каждый меш, бросающий собственную тень, снижает производительность. Шейдинг же делается сразу, без теней.
Просто выключи тени на своих омнилайтах.
>>13193
>Не понял зачем вставлять омнилайт в дыру
Он имел в виду "делать слишком много омнилайт".
"... в каждую дыру" == "... избыточно много".
>>13196
>омнилайтов на экране под 30 набиралось
Думаю, что лампочки вдалеке от игрока заменялись обычным спрайтом с градиентом, т.к. вроде бы было хардварное ограничение на 8 источников света.
Погугли, как GTA 5 рендерит фары в ночном городе.
>>13196
Ну да, скорее всего разница в том что там просто сам свет был дешевле - менее детальный, меньше спецэффектов, скорее всего нет теней.
Кроме того, емнип в OpenGL лимит был 8 источников света. Делаешь пул омнилайтов, никто не будет считать сколько реально ракет в пачке выдает свет. (А если будет, была какая то техника из гта для рисования фар, когда вообще не освещение рисуется, а просто полупрозрачный размытый блоб)
Ну да, скорее всего разница в том что там просто сам свет был дешевле - менее детальный, меньше спецэффектов, скорее всего нет теней.
Кроме того, емнип в OpenGL лимит был 8 источников света. Делаешь пул омнилайтов, никто не будет считать сколько реально ракет в пачке выдает свет. (А если будет, была какая то техника из гта для рисования фар, когда вообще не освещение рисуется, а просто полупрозрачный размытый блоб)
>>13199
Оно так на пк и на нормальном железе. На мобилках, по крайней мере на моих, один омнилайт без теней сразу откусывает 20% фпсю
>без каких-либо либо проблем в плане производительности.
Оно так на пк и на нормальном железе. На мобилках, по крайней мере на моих, один омнилайт без теней сразу откусывает 20% фпсю
>>13200
В OpenGL вообще отсутствует реализация теней, т.е. источники света - это просто градиент на мешах. А реализовывать тени ты должен своим велосипедом. Просто Godot включает свои тени по умолчанию.
Он вроде не размытый, но да, базовая техника.
Она даже в GTA 5 используется в окнах домов.
>>13204
У них там специальные хардварные трюки, которые отличаются от того, что когда-либо имелось на ПК. Мобильные видеокарты делают из рассчёта энергоэффективности, а не эффектности.
>скорее всего нет теней
>в OpenGL... источников света
В OpenGL вообще отсутствует реализация теней, т.е. источники света - это просто градиент на мешах. А реализовывать тени ты должен своим велосипедом. Просто Godot включает свои тени по умолчанию.
>техника из гта для рисования фар
>просто полупрозрачный размытый блоб
Он вроде не размытый, но да, базовая техника.
Она даже в GTA 5 используется в окнах домов.
>>13204
>На мобилках
У них там специальные хардварные трюки, которые отличаются от того, что когда-либо имелось на ПК. Мобильные видеокарты делают из рассчёта энергоэффективности, а не эффектности.
Понял, спасибо. Значит базовые омнилайты и полупрозрачные меши для пк. А на ебучие мобилки - только полупрозрачные меши.
>>13209
Как жить-то вообще нахуй, а. Мобилоделы каждый год не знают чем изъебнуться, по 10 камер добавляют, а графика работает как жопа.
Как жить-то вообще нахуй, а. Мобилоделы каждый год не знают чем изъебнуться, по 10 камер добавляют, а графика работает как жопа.
>>13209
Она была быстрой раньше... Было оптимальнее использовать полупрозрачную текстуру-рисунок решётки, вместо 3D моделирования решётки из треугольников. Сейчас, кажется, всё наоборот.
>>13207
Ты не понял, на мобилках нужно очень сильно всё оптимизировать по определённым правилам, если планируешь игру для широкой аудитории. И как раз полупрозрачность на мобилках использовать плохо (исходя из того, что я читал про эти оптимизации), потому что мобильные GPU сортируют треугольники прежде, чем начать их рендерить, а твоя частичная прозрачность нарушает этот механизм, заставляя рендерить больше минимально необходимого.
GPU на ПК - это как роторный экскаватор.
GPU на мобилках - археолог с кисточкой...
Она была быстрой раньше... Было оптимальнее использовать полупрозрачную текстуру-рисунок решётки, вместо 3D моделирования решётки из треугольников. Сейчас, кажется, всё наоборот.
>>13207
>мобилки - только полупрозрачные меши
Ты не понял, на мобилках нужно очень сильно всё оптимизировать по определённым правилам, если планируешь игру для широкой аудитории. И как раз полупрозрачность на мобилках использовать плохо (исходя из того, что я читал про эти оптимизации), потому что мобильные GPU сортируют треугольники прежде, чем начать их рендерить, а твоя частичная прозрачность нарушает этот механизм, заставляя рендерить больше минимально необходимого.
GPU на ПК - это как роторный экскаватор.
GPU на мобилках - археолог с кисточкой...
>>13218
Полупрозрачность всегда на сколько-то медленнее непрозрачности - потому что недостаточно просто записать новый цвет, надо прочитать старый цвет, произвести какое-то умножение на альфу.
Полупрозрачность всегда на сколько-то медленнее непрозрачности - потому что недостаточно просто записать новый цвет, надо прочитать старый цвет, произвести какое-то умножение на альфу.
>>13222
Ну, смотри, на пк:
1. Закрасил один пиксель 99 раз разными цветами.
2. Прочитал цвет пикселя, умножил, закрасил 100-й.
На мобилках:
1. Нашёл правильный цвет, закрасил пиксель 1-й раз.
2. Прочитал цвет пикселя, умножил, закрасил 2-й раз.
Т.е. на ПК ~1% времени, на мобилке ~50% времени.
Добавим несколько полупрозрачных слоёв, на пк:
1. Закрасил один пиксель 50 раз разными цветами.
2. Прочитал цвет пикселя, умножил, закрасил +50 раз.
На мобилках:
1. Нашёл правильный цвет, закрасил пиксель 1-й раз.
2. Прочитал цвет пикселя, умножил, закрасил +50 раз.
Т.е. на ПК разница мала, на мобилке - в 50 раз дольше.
На практике будет не совсем так, конечно, но всё же...
Ну, смотри, на пк:
1. Закрасил один пиксель 99 раз разными цветами.
2. Прочитал цвет пикселя, умножил, закрасил 100-й.
На мобилках:
1. Нашёл правильный цвет, закрасил пиксель 1-й раз.
2. Прочитал цвет пикселя, умножил, закрасил 2-й раз.
Т.е. на ПК ~1% времени, на мобилке ~50% времени.
Добавим несколько полупрозрачных слоёв, на пк:
1. Закрасил один пиксель 50 раз разными цветами.
2. Прочитал цвет пикселя, умножил, закрасил +50 раз.
На мобилках:
1. Нашёл правильный цвет, закрасил пиксель 1-й раз.
2. Прочитал цвет пикселя, умножил, закрасил +50 раз.
Т.е. на ПК разница мала, на мобилке - в 50 раз дольше.
На практике будет не совсем так, конечно, но всё же...
Давайте просто воткнем RTX 5090 в каждый телефон.
4,9 Мб, mp4,480x360, 1:47
Я вспомнил, как раньше планировал реализовать раздробленные на части острова, которые можно разрушать по кусочкам - но без вокселей, просто произвольной формы блоки. Суть в том, что таким островам не нужно наклоняться - физика не нужна.
Заодно набросал отбойный молоток... Правда, я совершенно без понятия, что им добывать, т.к. не планировал никаких ископаемых материалов, лол. Механика получилась забойной, но не могу никак разобраться, почему она доставляет такой кайф.
По видео непонятно, но удары молотка происходят автоматически, пока он находится в руках, а левой кнопкой мыши можно зарядить усиленный удар. Наносимый урон умножается на максимальную вертикальную скорость при падении, т.е. в теории возможно наносить огромный урон, если сможешь достаточно высоко подняться и спрыгнуть на цель.
Заодно набросал отбойный молоток... Правда, я совершенно без понятия, что им добывать, т.к. не планировал никаких ископаемых материалов, лол. Механика получилась забойной, но не могу никак разобраться, почему она доставляет такой кайф.
По видео непонятно, но удары молотка происходят автоматически, пока он находится в руках, а левой кнопкой мыши можно зарядить усиленный удар. Наносимый урон умножается на максимальную вертикальную скорость при падении, т.е. в теории возможно наносить огромный урон, если сможешь достаточно высоко подняться и спрыгнуть на цель.
>>13259
Ты всё-таки сделал этого призрака через этот всратый прозрачный материал?
У тебя есть возможность заюзать стенсил и постпроцесс? Сделай норм постпроцесс материал через них.
В крайнем случае можно рендертексчур приделать к камере, отрендерить персонажа отдельно и наложить его на видимую область с прозрачностью. Через карту глубины, чтобы не просвечивало сквозь окружение.
Ты всё-таки сделал этого призрака через этот всратый прозрачный материал?
У тебя есть возможность заюзать стенсил и постпроцесс? Сделай норм постпроцесс материал через них.
В крайнем случае можно рендертексчур приделать к камере, отрендерить персонажа отдельно и наложить его на видимую область с прозрачностью. Через карту глубины, чтобы не просвечивало сквозь окружение.
>>13270
Делай свою игру.
Делай свою игру.
давно в тредик не заглядывал
ребята, кто-нибудь переехал уже на 4.4? как оно, нет багов или регрессий перфоманса? можно переезжать с 4.1?
ребята, кто-нибудь переехал уже на 4.4? как оно, нет багов или регрессий перфоманса? можно переезжать с 4.1?
судя по тому, как быстро выкатили 4.4.1 rc1, переезжать пока не стоит...
https://godotengine.org/article/release-candidate-godot-4-4-1-rc-1/
у них было 34 release blocker'a на гитхабе, но они решили просто перенести их на 4.5
https://godotengine.org/article/release-candidate-godot-4-4-1-rc-1/
у них было 34 release blocker'a на гитхабе, но они решили просто перенести их на 4.5
>>13380
не жалуюсь, мне все нравится. но я не сидел на тройке, я перекатыш с UE
так что не могу ответить, сори. как новый опыт, без сравнения с предыдущими версиями - супер движок, очень нравится отсутствие блоата, здоровый минимализм
не жалуюсь, мне все нравится. но я не сидел на тройке, я перекатыш с UE
так что не могу ответить, сори. как новый опыт, без сравнения с предыдущими версиями - супер движок, очень нравится отсутствие блоата, здоровый минимализм
45 Кб, 758x204https://www.reddit.com/r/gamedev/comments/1jargbs/were_two_indie_devs_our_first_steam_game_made_21m/
Ваше мнение по раннему релизу пре-демки, и допиливанию на ходу, основываясь на фидбеке?
Ваше мнение по раннему релизу пре-демки, и допиливанию на ходу, основываясь на фидбеке?
>>13374
Учи
Учи
>>13390
Полная безоговорочная база. Двачую каждое слово.
Полная безоговорочная база. Двачую каждое слово.
>>13390
Чем больше людей увидит твою игру - тем лучше
Чем больше людей увидит твою игру - тем лучше
Показывать можно только когда у тебя уже игра почти готова и на финальной прямой к релизу. если ты/твоя команда готовы ебашить нон стоп. Потому что иначе чем больше людей увидит, тем больше среди них окажется команд мидлов, которые тупо скопируют твою игру и выпустят раньше тебя.
>>13407
Да, целая очередь выстроится, чтобы спиздить твою игру, настолько она хороша. Так и будет.
Да, целая очередь выстроится, чтобы спиздить твою игру, настолько она хороша. Так и будет.
>>13390
Лариан с БГ3 кстати так и делали, пилили игру в прямом эфире на основе фидбека. До сих пор мегапатчи выкатывают.
Лариан с БГ3 кстати так и делали, пилили игру в прямом эфире на основе фидбека. До сих пор мегапатчи выкатывают.
>>13214
Десять камер на топовых лопатах. Проц уровня первого пентиума - на бомжезвонилках. А гамать хотят в одно и то же. И им, в отличие от пкбояр, системные требования не выкатишь. Тормозит у равшана на нокии - равшан поставит одну звезду.
>>13218
Ух бля охуенный эпик.
Я думал, их стационарно монтируют, а транспортируют по частям.
Десять камер на топовых лопатах. Проц уровня первого пентиума - на бомжезвонилках. А гамать хотят в одно и то же. И им, в отличие от пкбояр, системные требования не выкатишь. Тормозит у равшана на нокии - равшан поставит одну звезду.
>>13218
>пик1
Ух бля охуенный эпик.
Я думал, их стационарно монтируют, а транспортируют по частям.
>>13390
Мой опыт мне говорит, что это хуйня. Выкатили демку на итч, вышло 0 комментариев и 2 рейтинга.
Мой опыт мне говорит, что это хуйня. Выкатили демку на итч, вышло 0 комментариев и 2 рейтинга.
>>13260
Много моих идей игр связаны с или вдохновлены майнкрафтом, но эта игра по геймплею должна существенно отличаться от него. Как минимум, в майнкрафте строишь неподвижную базу, а я хочу сфокусироваться на необходимости двигаться. Выживание - в плане поддержания корабля, а не персонажа, который фактически бессмертный. Задерживаться на одном месте долго нельзя, но направление и порядок действий выбирает игрок.
>>13267
Без понятия, у меня же почти ничего нет. Чтобы был основной геймплей, нужно как минимум доделать строительство управляемых кораблей, без которых передвижение между островами невозможно...
>>13268
С чего взял, что там призрак? В этой игре не будет призраков, но мне очень хотелось бы иметь такие прозрачные материалы в т.ч. для кожи персонажа, элементов одежды и т.д. Это сложно, но возможно.
Ты никогда в реальности не видел полупрозрачные предметы? Открою секрет: если ты в реальности посмотришь на полупрозрачную модель человека - увидишь, как сквозь тело видно, где соединяются конечности, блики на внутренней (т.е. обратной) стороне, внутренние перегородки и тому подобное. Рендерить это всё в реальном времени дорого и достаточно сложно, Godot по умолчанию такое не поддерживает, но всё же это можно реализовать. Приблизительно повторить у меня получилось, но некоторые артефакты иногда бывают заметны...
Ничего из этого делать не нужно. Во-первых, будет некрасивая ошибочная недопрозрачность, т.к. ты предлагаешь скрыть то, что должно быть видно в реалистичном полупрозрачном объекте. Во-вторых, желаемого тобой можно добиться за один проход обычного шейдера, просто скопировав фон, но мне подобный спецэффект не нравится и не нужен.
К сожалению, слишком часто вижу точно такую же ошибку у художников в 2D иллюстрациях: вместо физически аккуратной симуляции света они тупо закрашивают объект одним сплошным цветом. Это неправильно и так рисовать нельзя, если от тебя по заданию требуется изобразить реальный объект; в данном случае я сам себе такое задание придумал.
В общем, я хотел именно это - это и сделал (хотя бы частично, т.к. от всех артефактов избавиться можно только специальным сложным алгоритмом). Зачем навязывать что-то полностью противоположное?
>майнкрафт
Много моих идей игр связаны с или вдохновлены майнкрафтом, но эта игра по геймплею должна существенно отличаться от него. Как минимум, в майнкрафте строишь неподвижную базу, а я хочу сфокусироваться на необходимости двигаться. Выживание - в плане поддержания корабля, а не персонажа, который фактически бессмертный. Задерживаться на одном месте долго нельзя, но направление и порядок действий выбирает игрок.
>>13267
>Когда билд?
Без понятия, у меня же почти ничего нет. Чтобы был основной геймплей, нужно как минимум доделать строительство управляемых кораблей, без которых передвижение между островами невозможно...
>>13268
>этого призрака
С чего взял, что там призрак? В этой игре не будет призраков, но мне очень хотелось бы иметь такие прозрачные материалы в т.ч. для кожи персонажа, элементов одежды и т.д. Это сложно, но возможно.
>всратый прозрачный материал
Ты никогда в реальности не видел полупрозрачные предметы? Открою секрет: если ты в реальности посмотришь на полупрозрачную модель человека - увидишь, как сквозь тело видно, где соединяются конечности, блики на внутренней (т.е. обратной) стороне, внутренние перегородки и тому подобное. Рендерить это всё в реальном времени дорого и достаточно сложно, Godot по умолчанию такое не поддерживает, но всё же это можно реализовать. Приблизительно повторить у меня получилось, но некоторые артефакты иногда бывают заметны...
>постпроцесс материал
>рендертексчур приделать
Ничего из этого делать не нужно. Во-первых, будет некрасивая ошибочная недопрозрачность, т.к. ты предлагаешь скрыть то, что должно быть видно в реалистичном полупрозрачном объекте. Во-вторых, желаемого тобой можно добиться за один проход обычного шейдера, просто скопировав фон, но мне подобный спецэффект не нравится и не нужен.
К сожалению, слишком часто вижу точно такую же ошибку у художников в 2D иллюстрациях: вместо физически аккуратной симуляции света они тупо закрашивают объект одним сплошным цветом. Это неправильно и так рисовать нельзя, если от тебя по заданию требуется изобразить реальный объект; в данном случае я сам себе такое задание придумал.
В общем, я хотел именно это - это и сделал (хотя бы частично, т.к. от всех артефактов избавиться можно только специальным сложным алгоритмом). Зачем навязывать что-то полностью противоположное?
>>13260
Много моих идей игр связаны с или вдохновлены майнкрафтом, но эта игра по геймплею должна существенно отличаться от него. Как минимум, в майнкрафте строишь неподвижную базу, а я хочу сфокусироваться на необходимости двигаться. Выживание - в плане поддержания корабля, а не персонажа, который фактически бессмертный. Задерживаться на одном месте долго нельзя, но направление и порядок действий выбирает игрок.
>>13267
Без понятия, у меня же почти ничего нет. Чтобы был основной геймплей, нужно как минимум доделать строительство управляемых кораблей, без которых передвижение между островами невозможно...
>>13268
С чего взял, что там призрак? В этой игре не будет призраков, но мне очень хотелось бы иметь такие прозрачные материалы в т.ч. для кожи персонажа, элементов одежды и т.д. Это сложно, но возможно.
Ты никогда в реальности не видел полупрозрачные предметы? Открою секрет: если ты в реальности посмотришь на полупрозрачную модель человека - увидишь, как сквозь тело видно, где соединяются конечности, блики на внутренней (т.е. обратной) стороне, внутренние перегородки и тому подобное. Рендерить это всё в реальном времени дорого и достаточно сложно, Godot по умолчанию такое не поддерживает, но всё же это можно реализовать. Приблизительно повторить у меня получилось, но некоторые артефакты иногда бывают заметны...
Ничего из этого делать не нужно. Во-первых, будет некрасивая ошибочная недопрозрачность, т.к. ты предлагаешь скрыть то, что должно быть видно в реалистичном полупрозрачном объекте. Во-вторых, желаемого тобой можно добиться за один проход обычного шейдера, просто скопировав фон, но мне подобный спецэффект не нравится и не нужен.
К сожалению, слишком часто вижу точно такую же ошибку у художников в 2D иллюстрациях: вместо физически аккуратной симуляции света они тупо закрашивают объект одним сплошным цветом. Это неправильно и так рисовать нельзя, если от тебя по заданию требуется изобразить реальный объект; в данном случае я сам себе такое задание придумал.
В общем, я хотел именно это - это и сделал (хотя бы частично, т.к. от всех артефактов избавиться можно только специальным сложным алгоритмом). Зачем навязывать что-то полностью противоположное?
>майнкрафт
Много моих идей игр связаны с или вдохновлены майнкрафтом, но эта игра по геймплею должна существенно отличаться от него. Как минимум, в майнкрафте строишь неподвижную базу, а я хочу сфокусироваться на необходимости двигаться. Выживание - в плане поддержания корабля, а не персонажа, который фактически бессмертный. Задерживаться на одном месте долго нельзя, но направление и порядок действий выбирает игрок.
>>13267
>Когда билд?
Без понятия, у меня же почти ничего нет. Чтобы был основной геймплей, нужно как минимум доделать строительство управляемых кораблей, без которых передвижение между островами невозможно...
>>13268
>этого призрака
С чего взял, что там призрак? В этой игре не будет призраков, но мне очень хотелось бы иметь такие прозрачные материалы в т.ч. для кожи персонажа, элементов одежды и т.д. Это сложно, но возможно.
>всратый прозрачный материал
Ты никогда в реальности не видел полупрозрачные предметы? Открою секрет: если ты в реальности посмотришь на полупрозрачную модель человека - увидишь, как сквозь тело видно, где соединяются конечности, блики на внутренней (т.е. обратной) стороне, внутренние перегородки и тому подобное. Рендерить это всё в реальном времени дорого и достаточно сложно, Godot по умолчанию такое не поддерживает, но всё же это можно реализовать. Приблизительно повторить у меня получилось, но некоторые артефакты иногда бывают заметны...
>постпроцесс материал
>рендертексчур приделать
Ничего из этого делать не нужно. Во-первых, будет некрасивая ошибочная недопрозрачность, т.к. ты предлагаешь скрыть то, что должно быть видно в реалистичном полупрозрачном объекте. Во-вторых, желаемого тобой можно добиться за один проход обычного шейдера, просто скопировав фон, но мне подобный спецэффект не нравится и не нужен.
К сожалению, слишком часто вижу точно такую же ошибку у художников в 2D иллюстрациях: вместо физически аккуратной симуляции света они тупо закрашивают объект одним сплошным цветом. Это неправильно и так рисовать нельзя, если от тебя по заданию требуется изобразить реальный объект; в данном случае я сам себе такое задание придумал.
В общем, я хотел именно это - это и сделал (хотя бы частично, т.к. от всех артефактов избавиться можно только специальным сложным алгоритмом). Зачем навязывать что-то полностью противоположное?
>>13432
Ну, того что я увидел мне уже достаточно, чтобы поаутировать джва часа.
В смысле управляемые корабли есть? И их можно спавнить готовые? Но ты еще не доделал строительство их и поэтому на кораблях пока что летать нельзя?
> у меня же почти ничего нет
Ну, того что я увидел мне уже достаточно, чтобы поаутировать джва часа.
> доделать строительство управляемых кораблей
В смысле управляемые корабли есть? И их можно спавнить готовые? Но ты еще не доделал строительство их и поэтому на кораблях пока что летать нельзя?
>>13474
За это и любим.
За это и любим.
ПротонСкаттер, годаны: https://www.youtube.com/watch?v=OoVAtGHEgjA
>>13430
На двачах и в тематических сообществах постил. Собрал оттуда 3 отзыва.
На двачах и в тематических сообществах постил. Собрал оттуда 3 отзыва.
>>13503
Замечание: когда работаешь на дядю. Будешь работать как скажут и сколько скажут. А когда отпустили домой на три часа раньше, и думаю - вот я бы работал еще три часа, могу ли я взять эти три часа и поработать на себя? Нет, не получается так-же как на дядю. Выходит, я дядю уважаю, и его зароботок тоже, а себя и свои идеи нихуя не уважаю? Почему я не могу использовать свой человеческий ресурс, так-жк эфективно в своих интересах? Обидно.
Замечание: когда работаешь на дядю. Будешь работать как скажут и сколько скажут. А когда отпустили домой на три часа раньше, и думаю - вот я бы работал еще три часа, могу ли я взять эти три часа и поработать на себя? Нет, не получается так-же как на дядю. Выходит, я дядю уважаю, и его зароботок тоже, а себя и свои идеи нихуя не уважаю? Почему я не могу использовать свой человеческий ресурс, так-жк эфективно в своих интересах? Обидно.
>>13512
Тебя не научили этому в твои 3-7 лет. В этом возрасте формируются подобные скиллы.
Пустили твоё воспитание на самотек.
Испортили ребенка.
Избаловали.
> Почему я не могу использовать свой человеческий ресурс, так-жк эфективно в своих интересах?
Тебя не научили этому в твои 3-7 лет. В этом возрасте формируются подобные скиллы.
Пустили твоё воспитание на самотек.
Испортили ребенка.
Избаловали.
>>13512
Теперь я твой дядя. Слышь работать.
Теперь я твой дядя. Слышь работать.
12 Кб, 1154x832>>13503
Я нашёл способ не делать игры:
Запускает редактор без текста.
>Делайте игры
Я нашёл способ не делать игры:
>godot --text-driver Dummy
Запускает редактор без текста.
>>13535
Получается, туда можно вставить отдельный драйвер текста? Тут выше один жаловался на размытый текст, если вернётся, будем знать, что отвечать: пусть пишет свой драйвер.
Получается, туда можно вставить отдельный драйвер текста? Тут выше один жаловался на размытый текст, если вернётся, будем знать, что отвечать: пусть пишет свой драйвер.
>>13544 >>13545
Да, можно хоть на GDScript написать, как я понял:
https://docs.godotengine.org/en/stable/classes/class_textserverextension.html
Но будет, наверное, медленно. Вот стандартные:
Сервер 4.x по умолчанию, поддерживает всё, что необходимо для всех языков мира (очень сложно).
Сервер 3.x (в 4.x по умолчанию отсутствует, нужно компилировать собственный билд движка), не имеет некоторых функций, но существенно быстрее нового.
Заглушка на случай, когда текста в игре нет. Можно активировать непосредственно в игровом процессе, выгрузив из оперативной памяти активный сервер.
>>13547
Только если с внешним редактором скриптов...
Да, можно хоть на GDScript написать, как я понял:
https://docs.godotengine.org/en/stable/classes/class_textserverextension.html
Но будет, наверное, медленно. Вот стандартные:
>TextServerAdvanced
Сервер 4.x по умолчанию, поддерживает всё, что необходимо для всех языков мира (очень сложно).
>TextServerFallback
Сервер 3.x (в 4.x по умолчанию отсутствует, нужно компилировать собственный билд движка), не имеет некоторых функций, но существенно быстрее нового.
>TextServerDummy
Заглушка на случай, когда текста в игре нет. Можно активировать непосредственно в игровом процессе, выгрузив из оперативной памяти активный сервер.
>>13547
Только если с внешним редактором скриптов...
>>13558
ВРоде бы воскресили визуал скриптинг через аддон
ВРоде бы воскресили визуал скриптинг через аддон
Есть ли вообще смысл локализировать игоря, если он уже на английском? При несложном тексте и новых крутых нейропереводчиках я не вижу проблемы перевести, вопрос - стоит ли.
>>13597
Зависит от целевой аудитории. Китайцы плохо знают английский, поэтому на китайский лучше перевести.
Достаточно знаю английский, чтоб иногда замечать серьёзные косяки LLM-перевода, несмотря на то, что русский не настолько радикально отличается от английского, по сравнению с китайским. Т.е. для адекватного перевода пока нужен носитель языка, нейронки слишком часто молча ошибаются, но при этом внушают тебе уверенность в качестве работы.
Но если у тебя просто маленькая игрушка по типу геймджемовских, локализовать не обязательно. Задумывайся об этом, когда проект серьёзный.
>>13607
Тебя устроят такие отзывы?
Играет игрок в игру, видит надписи:
Перевод 10 из 10, да?
Вот поэтому я играю в игры на английском, если разработчик очевидно не русскоговорящий. А то большинство переводов лишь вредят пониманию. Ломаешь голову над очень необычной фразой, переключаешь игру на английский для проверки - легко понимаешь её смысл, хотя в школе за него получал двойки, ничего не понимая на уроках...
Конечно, люди-переводчики тоже халтурят. Но их по крайней мере можно привлечь к ответственности за небрежное выполнение заказа; с нейронкой ты сам садишься в лужу - сам виноват, что не уследил.
>смысл локализировать
Зависит от целевой аудитории. Китайцы плохо знают английский, поэтому на китайский лучше перевести.
>новых крутых нейропереводчиках
Достаточно знаю английский, чтоб иногда замечать серьёзные косяки LLM-перевода, несмотря на то, что русский не настолько радикально отличается от английского, по сравнению с китайским. Т.е. для адекватного перевода пока нужен носитель языка, нейронки слишком часто молча ошибаются, но при этом внушают тебе уверенность в качестве работы.
Но если у тебя просто маленькая игрушка по типу геймджемовских, локализовать не обязательно. Задумывайся об этом, когда проект серьёзный.
>>13607
>почему бы и нет?
Тебя устроят такие отзывы?
>Chest for storage -> 胸部 (chest/breast of human body)
Играет игрок в игру, видит надписи:
>Сделать сиську
>Поставить сиську
>Открыть сиську
Перевод 10 из 10, да?
Вот поэтому я играю в игры на английском, если разработчик очевидно не русскоговорящий. А то большинство переводов лишь вредят пониманию. Ломаешь голову над очень необычной фразой, переключаешь игру на английский для проверки - легко понимаешь её смысл, хотя в школе за него получал двойки, ничего не понимая на уроках...
Конечно, люди-переводчики тоже халтурят. Но их по крайней мере можно привлечь к ответственности за небрежное выполнение заказа; с нейронкой ты сам садишься в лужу - сам виноват, что не уследил.
>>13627
Китай это отдельный рынок куда без китайского паблишера лучше не соваться.
>Зависит от целевой аудитории. Китайцы плохо знают английский
Китай это отдельный рынок куда без китайского паблишера лучше не соваться.
>>13628
Китайцев много в Steam. Регулярно вижу отзывы на китайском, инди-игры переводят на китайский. Очевидно, для релиза на китайские площадки тебе потребуется кто-то из Китая, т.к. там всё строго...
Китайцев много в Steam. Регулярно вижу отзывы на китайском, инди-игры переводят на китайский. Очевидно, для релиза на китайские площадки тебе потребуется кто-то из Китая, т.к. там всё строго...
Я уверен что нейронки уже добротно переводят на китайский. Особенно китайские нейронки.
Нужно искать китайские сервисы перевода, они на свой язык будут добротно переводить безо всяких этих мемных "ебал твой сестра" вместо "привет, как дела".
Если беспокоишься за качество, то просто делай обратный перевод для контроля.
Нужно искать китайские сервисы перевода, они на свой язык будут добротно переводить безо всяких этих мемных "ебал твой сестра" вместо "привет, как дела".
Если беспокоишься за качество, то просто делай обратный перевод для контроля.
>>13627
Если тебе дали инструмент, учись им пользоваться. Что мешало перевести обратно? Или погуглить иероглифы?
Если тебе дали инструмент, учись им пользоваться. Что мешало перевести обратно? Или погуглить иероглифы?
>>13652
Именно.
Именно.
https://www.reddit.com/r/godot/comments/1jf3t63/im_giving_away_my_project_link_in_the_comments/
Хватайте проект на миллион.
Хватайте проект на миллион.
>>13853
Да я не боюсь что украдут (для этого надо приложить усилия, не каждый ещё сможет, лол).
Я боюсь что безыгорные тролли-хейтеры начнут мне статистику портить и распространять дезинфу - мы ж на дваче.
Да я не боюсь что украдут (для этого надо приложить усилия, не каждый ещё сможет, лол).
Я боюсь что безыгорные тролли-хейтеры начнут мне статистику портить и распространять дезинфу - мы ж на дваче.
>>13873
Подводный только один. Твоя мотивация исчезнет пока открывается годот. А годот очень быстро открывается.
Подводный только один. Твоя мотивация исчезнет пока открывается годот. А годот очень быстро открывается.
>>13878
интересно, как у вкатунов не пропадает мотивация год ходить по собесам и терпеть унижения кабанов. Если можно год клепать говняк и ожидать выстрела
интересно, как у вкатунов не пропадает мотивация год ходить по собесам и терпеть унижения кабанов. Если можно год клепать говняк и ожидать выстрела
Накидал процедурную генерацию дерева. Внезапно, понравилось, особенно то, как крона из простейших зелёных шаров сливается в "биоморфную" массу. Единственное, что хочется - добавить анимацию при столкновении движущихся предметов с шарами. Но сэкономить, чтобы не съело все ресурсы компа...
>>13452
Первые управляемые в воздухе конструкции для конкретно этой игры у меня были в конце 2021. Но управление ограничивалось банальным вектором плавучести и вектором тяги. Нужен полноценный контроллер как в аркадных авиасимуляторах, ну, например, как в GTA, понимаешь, о чём я? Только проблема в том, что все элементы можно ставить в разных местах и их состояние должно учитываться непосредственно в полёте, динамически реагируя на повреждения, пока игрок эти повреждения фиксит.
У меня есть сцена, где я накидал в общих чертах управление дирижаблем: плавучесть (вроде бы правдоподобно), тяга, рысканье и тангаж. И что-то подобное я уже пытался сделать, но сейчас это не связано с системой строительства, которую я уже несколько раз переделывал почти с нуля.
Почему переделывал? Сначала я хотел сделать максимально свободное размещение всего, но на практике это неудобно ни игроку, ни игре. Поэтому неоднократно пытался упростить систему, а в итоге переусложнял код, запутывался в нём, забрасывал. Наверное, нужно было довести хоть какой-то из предыдущих вариантов до управляемой стадии, а переделывать (рефакторить) уже после этого...
Не думай, мол, "хочу сделать реалистичную игру". Наоборот, реалистичные дирижабли очень унылые, поскольку их буквально сносит ветром и скорость чрезвычайно низкая, а шары просто громадные. Я пытаюсь сделать фановое управление, например, хотелось бы иметь возможность дрифтить, лол. Но примитивные контроллеры во множестве игр, что я пробовал, унылые из-за того, что... наверное, мне кажется, они "слишком послушные", т.е. слишком подчиняются желанию игрока "лететь прямо". Если добавить немного "реализма", то будет веселее, т.к. потребуется учитывать дополнительные правила (расположение шаров и двигателей, их состояние).
В общем, прокрастинирую систему строительства и управления из-за её концептуальной сложности: код написать и добавить новую графику не так сложно, как разобраться, что мне вообще нужно сделать.
>>13452
>В смысле управляемые корабли есть?
Первые управляемые в воздухе конструкции для конкретно этой игры у меня были в конце 2021. Но управление ограничивалось банальным вектором плавучести и вектором тяги. Нужен полноценный контроллер как в аркадных авиасимуляторах, ну, например, как в GTA, понимаешь, о чём я? Только проблема в том, что все элементы можно ставить в разных местах и их состояние должно учитываться непосредственно в полёте, динамически реагируя на повреждения, пока игрок эти повреждения фиксит.
У меня есть сцена, где я накидал в общих чертах управление дирижаблем: плавучесть (вроде бы правдоподобно), тяга, рысканье и тангаж. И что-то подобное я уже пытался сделать, но сейчас это не связано с системой строительства, которую я уже несколько раз переделывал почти с нуля.
Почему переделывал? Сначала я хотел сделать максимально свободное размещение всего, но на практике это неудобно ни игроку, ни игре. Поэтому неоднократно пытался упростить систему, а в итоге переусложнял код, запутывался в нём, забрасывал. Наверное, нужно было довести хоть какой-то из предыдущих вариантов до управляемой стадии, а переделывать (рефакторить) уже после этого...
Не думай, мол, "хочу сделать реалистичную игру". Наоборот, реалистичные дирижабли очень унылые, поскольку их буквально сносит ветром и скорость чрезвычайно низкая, а шары просто громадные. Я пытаюсь сделать фановое управление, например, хотелось бы иметь возможность дрифтить, лол. Но примитивные контроллеры во множестве игр, что я пробовал, унылые из-за того, что... наверное, мне кажется, они "слишком послушные", т.е. слишком подчиняются желанию игрока "лететь прямо". Если добавить немного "реализма", то будет веселее, т.к. потребуется учитывать дополнительные правила (расположение шаров и двигателей, их состояние).
В общем, прокрастинирую систему строительства и управления из-за её концептуальной сложности: код написать и добавить новую графику не так сложно, как разобраться, что мне вообще нужно сделать.
Накидал процедурную генерацию дерева. Внезапно, понравилось, особенно то, как крона из простейших зелёных шаров сливается в "биоморфную" массу. Единственное, что хочется - добавить анимацию при столкновении движущихся предметов с шарами. Но сэкономить, чтобы не съело все ресурсы компа...
>>13452
Первые управляемые в воздухе конструкции для конкретно этой игры у меня были в конце 2021. Но управление ограничивалось банальным вектором плавучести и вектором тяги. Нужен полноценный контроллер как в аркадных авиасимуляторах, ну, например, как в GTA, понимаешь, о чём я? Только проблема в том, что все элементы можно ставить в разных местах и их состояние должно учитываться непосредственно в полёте, динамически реагируя на повреждения, пока игрок эти повреждения фиксит.
У меня есть сцена, где я накидал в общих чертах управление дирижаблем: плавучесть (вроде бы правдоподобно), тяга, рысканье и тангаж. И что-то подобное я уже пытался сделать, но сейчас это не связано с системой строительства, которую я уже несколько раз переделывал почти с нуля.
Почему переделывал? Сначала я хотел сделать максимально свободное размещение всего, но на практике это неудобно ни игроку, ни игре. Поэтому неоднократно пытался упростить систему, а в итоге переусложнял код, запутывался в нём, забрасывал. Наверное, нужно было довести хоть какой-то из предыдущих вариантов до управляемой стадии, а переделывать (рефакторить) уже после этого...
Не думай, мол, "хочу сделать реалистичную игру". Наоборот, реалистичные дирижабли очень унылые, поскольку их буквально сносит ветром и скорость чрезвычайно низкая, а шары просто громадные. Я пытаюсь сделать фановое управление, например, хотелось бы иметь возможность дрифтить, лол. Но примитивные контроллеры во множестве игр, что я пробовал, унылые из-за того, что... наверное, мне кажется, они "слишком послушные", т.е. слишком подчиняются желанию игрока "лететь прямо". Если добавить немного "реализма", то будет веселее, т.к. потребуется учитывать дополнительные правила (расположение шаров и двигателей, их состояние).
В общем, прокрастинирую систему строительства и управления из-за её концептуальной сложности: код написать и добавить новую графику не так сложно, как разобраться, что мне вообще нужно сделать.
>>13452
>В смысле управляемые корабли есть?
Первые управляемые в воздухе конструкции для конкретно этой игры у меня были в конце 2021. Но управление ограничивалось банальным вектором плавучести и вектором тяги. Нужен полноценный контроллер как в аркадных авиасимуляторах, ну, например, как в GTA, понимаешь, о чём я? Только проблема в том, что все элементы можно ставить в разных местах и их состояние должно учитываться непосредственно в полёте, динамически реагируя на повреждения, пока игрок эти повреждения фиксит.
У меня есть сцена, где я накидал в общих чертах управление дирижаблем: плавучесть (вроде бы правдоподобно), тяга, рысканье и тангаж. И что-то подобное я уже пытался сделать, но сейчас это не связано с системой строительства, которую я уже несколько раз переделывал почти с нуля.
Почему переделывал? Сначала я хотел сделать максимально свободное размещение всего, но на практике это неудобно ни игроку, ни игре. Поэтому неоднократно пытался упростить систему, а в итоге переусложнял код, запутывался в нём, забрасывал. Наверное, нужно было довести хоть какой-то из предыдущих вариантов до управляемой стадии, а переделывать (рефакторить) уже после этого...
Не думай, мол, "хочу сделать реалистичную игру". Наоборот, реалистичные дирижабли очень унылые, поскольку их буквально сносит ветром и скорость чрезвычайно низкая, а шары просто громадные. Я пытаюсь сделать фановое управление, например, хотелось бы иметь возможность дрифтить, лол. Но примитивные контроллеры во множестве игр, что я пробовал, унылые из-за того, что... наверное, мне кажется, они "слишком послушные", т.е. слишком подчиняются желанию игрока "лететь прямо". Если добавить немного "реализма", то будет веселее, т.к. потребуется учитывать дополнительные правила (расположение шаров и двигателей, их состояние).
В общем, прокрастинирую систему строительства и управления из-за её концептуальной сложности: код написать и добавить новую графику не так сложно, как разобраться, что мне вообще нужно сделать.
>>13890
Ну я уже говорил, повторюсь, из того что я вижу в видосах - я бы уже поиграл. Так что выкладывай ссылку на билд в тред, если нужны тестеры.
> разобраться, что мне вообще нужно сделать
Ну я уже говорил, повторюсь, из того что я вижу в видосах - я бы уже поиграл. Так что выкладывай ссылку на билд в тред, если нужны тестеры.
>>13897
Неиронично на сотни постов фидбэка и предложений
Неиронично на сотни постов фидбэка и предложений
43 Кб, 170x153>>13993
Ну и что? Ты игры сделал? На 4.3 вполне ничего не мешало тебе сделать хотя бы одну в прошлом году.
Ну и что? Ты игры сделал? На 4.3 вполне ничего не мешало тебе сделать хотя бы одну в прошлом году.
740 Кб, 2448x2448Охуеть, в Годо есть встроенное решение для undo/redo! А я городил велосипед (плохой).
Что здесь еще есть из такого, неочевидного?
Что здесь еще есть из такого, неочевидного?
>>14000
Можно запаковать состояние игры в рантайме в пакдсцену и работать с ней дальше как с обычной сценой в редакторе.
Можно запаковать состояние игры в рантайме в пакдсцену и работать с ней дальше как с обычной сценой в редакторе.
>>14000
какое?
какое?
Обновить тред
