Добро пожаловать в тред любви, взаимопомощи и что ты тут ожидал увидеть?
Шапка: https://hipolink.me/godothread
Предыдущий 80: >>1088293 (OP)
---
Релиз 4.7
Release notes: https://godotengine.org/releases/4.7/
Видеообзор изменений: https://www.youtube.com/watch?v=_iNwBmH2xX0
Шапка: https://hipolink.me/godothread
Предыдущий 80: >>1088293 (OP)
---
Релиз 4.7
Release notes: https://godotengine.org/releases/4.7/
Видеообзор изменений: https://www.youtube.com/watch?v=_iNwBmH2xX0
Перекатился на 4.7. Аддон диаложик сломался, потому что некоторые функции у него что-то не возвращали.
Проставил return'ы, теперь всё норм
Проставил return'ы, теперь всё норм
>>2274 (OP)
Посмотрел видос, впечатляет. Вроде ничего особенного, но по отдельности куча полезных мелочей.
Посмотрел видос, впечатляет. Вроде ничего особенного, но по отдельности куча полезных мелочей.
66 Кб, 1005x723Все теперь нельзя шаблоны для годота 4.7 для жителей необъятной скачать?
>>2290
Давно уже. Год как. С добрым утром. (Нет)
Давно уже. Год как. С добрым утром. (Нет)
>>2274 (OP)
Это уже старенький билд хомяков, я в субшоте свежее на прошолой неделе выкладывал: >>1091761 →
Но спасибо, второй раз в шапке, приятно
>последний видос
Это уже старенький билд хомяков, я в субшоте свежее на прошолой неделе выкладывал: >>1091761 →
Но спасибо, второй раз в шапке, приятно
>>2274 (OP)
Неожиданный логотип, но мне нравится. Откуда?
>>2290
Несколько вариантов решения:
1. Качать напрямую с GitHub одним паком (1.2 Гб):
https://github.com/godotengine/godot-builds/releases/download/4.7-stable/Godot_v4.7-stable_export_templates.tpz
2. Скачать исходники (44 Мб) и собрать самому:
https://github.com/godotengine/godot-builds/releases/download/4.7-stable/godot-4.7-stable.tar.xz
https://docs.godotengine.org/en/stable/engine_details/development/compiling/index.html
Это недолго, нужно только компиляторы добыть.
3. Для Windows/Linux/MacOS можно использовать стандартный editor build в качестве "плеера игры". Единственный минус - editor build в debug режиме и поэтому может быть чуть медленнее release build.
4. Покупать/настраивать средства обхода...
Рекомендую вариант 2 - пригодится в будущем.
А если ты игру/утилиту для себя делаешь - то 3.
>>2308
Почувствовал себя старым...
Неожиданный логотип, но мне нравится. Откуда?
>>2290
Несколько вариантов решения:
1. Качать напрямую с GitHub одним паком (1.2 Гб):
https://github.com/godotengine/godot-builds/releases/download/4.7-stable/Godot_v4.7-stable_export_templates.tpz
2. Скачать исходники (44 Мб) и собрать самому:
https://github.com/godotengine/godot-builds/releases/download/4.7-stable/godot-4.7-stable.tar.xz
https://docs.godotengine.org/en/stable/engine_details/development/compiling/index.html
Это недолго, нужно только компиляторы добыть.
3. Для Windows/Linux/MacOS можно использовать стандартный editor build в качестве "плеера игры". Единственный минус - editor build в debug режиме и поэтому может быть чуть медленнее release build.
4. Покупать/настраивать средства обхода...
Рекомендую вариант 2 - пригодится в будущем.
А если ты игру/утилиту для себя делаешь - то 3.
>>2308
>Это уже старенький билд
Почувствовал себя старым...
Как же меня векторная математика раздражает...
Как думаете, нормально ли костыльнуть моё личное неудобство с матрицами и векторами банальнейшим размещением пустых Node3D в сцене? Уже делал так несколько раз, но боюсь, что это слишком "не труъ"...
Пример (не уверен пока, как лучше):
Player - то, к чему нужно применить силу.
Yaw, Pitch, Roll - для вращения вектора...
Vector - debug-репрезентация вектора.
Так я хотя бы визуально буду видеть, что я делаю...
Реально тяжело представить вектор мысленно...
Как думаете, нормально ли костыльнуть моё личное неудобство с матрицами и векторами банальнейшим размещением пустых Node3D в сцене? Уже делал так несколько раз, но боюсь, что это слишком "не труъ"...
Пример (не уверен пока, как лучше):
>Player: CharacterBody3D
>— Yaw: Node3D
>— — Pitch: Node3D
>— — — Roll: Node3D
>— — — — Vector: MeshInstance3D
Player - то, к чему нужно применить силу.
Yaw, Pitch, Roll - для вращения вектора...
Vector - debug-репрезентация вектора.
Так я хотя бы визуально буду видеть, что я делаю...
Реально тяжело представить вектор мысленно...
>>2345
Нормально. Я так делал. Многие так делали. Я так делал, когда не понимал в матане, и сейчас, когда понимаю в матане, тоже так сделаю при случае.
Нормально. Я так делал. Многие так делали. Я так делал, когда не понимал в матане, и сейчас, когда понимаю в матане, тоже так сделаю при случае.
>>2345
Вообще, ещё непонятно, возможно ли и как вращать CharacterBody3D. Т.к. у него отсуствуют методы для физического поворота (в отличие от RigidBody3D), то остаётся только вращение через Transform3D, но для персонажа не идеально сферической формы такое вращение грозит попаданием в чужие коллизии... Я склоняюсь к тому, что CharacterBody3D невозможно безопасно вращать (кроме оси Y, если используется цилиндр или капсула без коллизий рук-ног), так что приходится вращать только визуальную модельку. Сложности с трансформацией векторов растут.
Я подумывал/пробовал использовать вращение визуализации персонажа в расчётах физики, но мне кажется, что такая лапша взаимосвязей в будущем усложняет... да всё усложняет. Поэтому хочу такую отдельную ветку из нод чисто под физику, чтобы абстрагироваться от реальной 3D модельки...
>>2346
Что-то нигде такого не видел/не слышал. Зато много рассказов о том, как плохо иметь избыточные ноды. Видел, как визуально простые игры использовали оптимизацию через серверы Godot, лишь бы на количестве нод сэкономить. Дерево с тех пор вроде оптимизировали, но всё равно не всё идеально...
Почему? Не получается удержать все векторы?
>нужно применить силу
Вообще, ещё непонятно, возможно ли и как вращать CharacterBody3D. Т.к. у него отсуствуют методы для физического поворота (в отличие от RigidBody3D), то остаётся только вращение через Transform3D, но для персонажа не идеально сферической формы такое вращение грозит попаданием в чужие коллизии... Я склоняюсь к тому, что CharacterBody3D невозможно безопасно вращать (кроме оси Y, если используется цилиндр или капсула без коллизий рук-ног), так что приходится вращать только визуальную модельку. Сложности с трансформацией векторов растут.
Я подумывал/пробовал использовать вращение визуализации персонажа в расчётах физики, но мне кажется, что такая лапша взаимосвязей в будущем усложняет... да всё усложняет. Поэтому хочу такую отдельную ветку из нод чисто под физику, чтобы абстрагироваться от реальной 3D модельки...
>>2346
>Многие так делали
Что-то нигде такого не видел/не слышал. Зато много рассказов о том, как плохо иметь избыточные ноды. Видел, как визуально простые игры использовали оптимизацию через серверы Godot, лишь бы на количестве нод сэкономить. Дерево с тех пор вроде оптимизировали, но всё равно не всё идеально...
>понимаю в матане, тоже так сделаю при случае
Почему? Не получается удержать все векторы?
>>2347
Потому что комбинацией нод по факту все эти векторные операции делаются в кишках движка на сишном ядре.
Векторов лучше обмазать поверх композиции нод.
> Почему? Не получается удержать все векторы?
Потому что комбинацией нод по факту все эти векторные операции делаются в кишках движка на сишном ядре.
Векторов лучше обмазать поверх композиции нод.
Кто не понел отсылочки, тот малолетнее bydlo
>>2340
https://www.reddit.com/r/godot/comments/1u6ce5v/really_proud_of_this_artwork/
>Неожиданный логотип, но мне нравится. Откуда?
https://www.reddit.com/r/godot/comments/1u6ce5v/really_proud_of_this_artwork/
>>2349
Так ты в любом случае вызовы API делаешь - те же Vector3, Basis, Transform3D и т.д. С нодами суть в их визуализации на экране, т.к. без нод эти классы - абстрактные массивы чисел без какого-то значения.
Тип, мне нужно такое:
Я мог бы сделать это так:
Но мне было бы удобнее так:
Т.е. Basis.Y можно увидеть прям в окне редактора.
Выходит, этот способ в разы затратнее по ресурсам.
Вслепую стакать вызовы Vector/Transform тяжело...
Так ты в любом случае вызовы API делаешь - те же Vector3, Basis, Transform3D и т.д. С нодами суть в их визуализации на экране, т.к. без нод эти классы - абстрактные массивы чисел без какого-то значения.
Тип, мне нужно такое:
>velocity += force
Я мог бы сделать это так:
>force = vector.rotate...rotate...rotate... # wtf
Но мне было бы удобнее так:
>$Helper1.rotate...
>$Helper2.rotate...
>velocity += $Helper3.global_basis.Y
Т.е. Basis.Y можно увидеть прям в окне редактора.
Выходит, этот способ в разы затратнее по ресурсам.
Вслепую стакать вызовы Vector/Transform тяжело...
>>2352
А, и да, я много слышал, что нужны Quaternions, тип выгоднее по сравнению с вращением векторов, но я вообще не понимаю их. Смотрел визуализации и не разобрался. Обычно, когда игрок жмёт кнопки, тут понятно - влево-вправо, вверх-вниз, и т.д. А вот как превращать нажатия в Quaternion и обратно неясно. С gymbal lock ещё не сталкивался на практике...
Так что пока по классике векторы вращаю.
А, и да, я много слышал, что нужны Quaternions, тип выгоднее по сравнению с вращением векторов, но я вообще не понимаю их. Смотрел визуализации и не разобрался. Обычно, когда игрок жмёт кнопки, тут понятно - влево-вправо, вверх-вниз, и т.д. А вот как превращать нажатия в Quaternion и обратно неясно. С gymbal lock ещё не сталкивался на практике...
Так что пока по классике векторы вращаю.
Гайс, а как нормально аддон устанавливать чтобы без ошибок? А то у меня иногда вообще всю папку удаляет с аддонами
>>2354
Потому что кватернионы про другое. Они не про векторы движения, а про вращение. Незаменимы при создании анимаций. Почему так? Вот представь себе самолет, давай просто выключим физику и он в воздухе висит всё время, но вращаться может. Ты берешь и вводишь его в штопор, то есть он тупо смотрит вниз. У тебя из трех осей наклона лишь одна не в нуле, она 90 градусов, две оставшиеся в нуле, а потому тупо параллельны. И теперь ты хочешь его вынести его из штопора. Для этого что надо сделать? Два оставшихся угла из нуля вытащить. Однако проблема в том, что если ты начнешь одновременно их выводить, то они начнут друг друга "отменять", потому что они хоть и параллельны, но у них вращение обратное друг другу. И если ты внезапно дашь обоим нулевым углам наклон в 45 градусов, то они вычтутся друг из друга, и опять будут нулевые.
Вот у тебя такая же херня может быть в блендере при создании анимаций, или в годоте когда ты её запускаешь. Если бы ты использовал простые матрицы углов, у тебя бы либо анимации постоянно ломались в пограничных случаях, либо были бы неестественными.
Кватернионы избавляют от подобных проблем, потому что считаются не как матрицы углов наклона, а как матрицы непосредственно вращения объекта. Звучит странно, но это немного разные вещи.
Потому что кватернионы про другое. Они не про векторы движения, а про вращение. Незаменимы при создании анимаций. Почему так? Вот представь себе самолет, давай просто выключим физику и он в воздухе висит всё время, но вращаться может. Ты берешь и вводишь его в штопор, то есть он тупо смотрит вниз. У тебя из трех осей наклона лишь одна не в нуле, она 90 градусов, две оставшиеся в нуле, а потому тупо параллельны. И теперь ты хочешь его вынести его из штопора. Для этого что надо сделать? Два оставшихся угла из нуля вытащить. Однако проблема в том, что если ты начнешь одновременно их выводить, то они начнут друг друга "отменять", потому что они хоть и параллельны, но у них вращение обратное друг другу. И если ты внезапно дашь обоим нулевым углам наклон в 45 градусов, то они вычтутся друг из друга, и опять будут нулевые.
Вот у тебя такая же херня может быть в блендере при создании анимаций, или в годоте когда ты её запускаешь. Если бы ты использовал простые матрицы углов, у тебя бы либо анимации постоянно ломались в пограничных случаях, либо были бы неестественными.
Кватернионы избавляют от подобных проблем, потому что считаются не как матрицы углов наклона, а как матрицы непосредственно вращения объекта. Звучит странно, но это немного разные вещи.
>>2402
Попробуй скачать с GitHub и распаковать.
>>2406
Почему два? Если смотришь вниз, то у тебя 90° по горизонтальной оси (X - тангаж). Чтобы посмотреть наверх, уменьшаешь этот угол... Нет необходимости трогать два других угла (Y/Z), вне зависимости от их текущих значений (Y - рысканье, Z - крен). Как-то так:
Т.е. рысканье -> тангаж -> крен. В чём проблема?..
>>2345
Осознал, что дело не столько в векторах, сколько в применяемых формулах, а их никакими нодами не заменишь... Пытался гуглить формулы в интернете, спрашивать нейронку - на практике фигня, Vector3 стремится улететь в inf или ВНЕЗАПНО обнуляется... Другими словами, получить векторы - легко, а что вычислять с их помощью - это нужно думать. Так я несколько часов промучился, потом открыл свой предыдущий проект и обнаружил, что переизобрёл собственный велосипед с квадратными колёсами, который тогда не нравился. Что делать - не знаю...
Попробуй скачать с GitHub и распаковать.
>>2406
>Два оставшихся угла из нуля вытащить
Почему два? Если смотришь вниз, то у тебя 90° по горизонтальной оси (X - тангаж). Чтобы посмотреть наверх, уменьшаешь этот угол... Нет необходимости трогать два других угла (Y/Z), вне зависимости от их текущих значений (Y - рысканье, Z - крен). Как-то так:
>yaw += Input.get_axis("A", "D") # рысканье
>pitch += Input.get_axis("W", "S") # тангаж
>roll += Input.get_axis("Q", "E") # крен
>var gp := global_position
>global_transform = Transform3D.IDENTITY\
>.rotated_local(Vector3.UP, yaw)\
>.rotated_local(Vector3.LEFT, pitch)\
>.rotated_local(Vector3.BACK, roll)
>global_position = gp
Т.е. рысканье -> тангаж -> крен. В чём проблема?..
>>2345
Осознал, что дело не столько в векторах, сколько в применяемых формулах, а их никакими нодами не заменишь... Пытался гуглить формулы в интернете, спрашивать нейронку - на практике фигня, Vector3 стремится улететь в inf или ВНЕЗАПНО обнуляется... Другими словами, получить векторы - легко, а что вычислять с их помощью - это нужно думать. Так я несколько часов промучился, потом открыл свой предыдущий проект и обнаружил, что переизобрёл собственный велосипед с квадратными колёсами, который тогда не нравился. Что делать - не знаю...
В itch summer sale кто участвует? Оно почему-то не все мои проекты показывает как подходящие для распродажи, хотя цены стоят одинаковые, и методы монетизации тоже, и все проекты скачиваемые, не веб.
>>2463
Разобрался, в некоторых присутствует платный бонус файл, в некоторых нет.
Разобрался, в некоторых присутствует платный бонус файл, в некоторых нет.
12,6 Мб, mp4,1280x640, 2:02
Уже три раза писал пост:
- 50% нытья "всё плохо";
- 50% глупых фантазий.
Никому это не нужно.
>>1073383 → >>1073384 →
Вы не так поняли.
>>1073394 →
Нигде.
- 50% нытья "всё плохо";
- 50% глупых фантазий.
Никому это не нужно.
>>1073383 → >>1073384 →
Вы не так поняли.
>>1073394 →
Нигде.
>>2736
Хочется прикрепить что-то типа пулеметов на крылья, чтобы можно было потрошить летающих медуз. И таких же как героиня противников, чтобы в воздухе догфайтится.
Хочется прикрепить что-то типа пулеметов на крылья, чтобы можно было потрошить летающих медуз. И таких же как героиня противников, чтобы в воздухе догфайтится.
>>2736
Видел недавно игру на твиче про выживание на воздушных островах и полете на дирижабле, вспомнил тебя.
Видел недавно игру на твиче про выживание на воздушных островах и полете на дирижабле, вспомнил тебя.
>>2745
Вспомнил название - Solarpunk если кому нужно.
Все таки выживач от первого лица и в 3д выглядит лучше, субъективно, но в 2д гринд меня быстро утомляет, а в 3д от первого лица как-будто есть погружение какое-то и всякую фигню можешь делать дольше.
Вспомнил название - Solarpunk если кому нужно.
Все таки выживач от первого лица и в 3д выглядит лучше, субъективно, но в 2д гринд меня быстро утомляет, а в 3д от первого лица как-будто есть погружение какое-то и всякую фигню можешь делать дольше.
Что-то в 4.7 ничего особо интересного не добавили, только мелкие qol фишки и новый ассет стор. Сеймы?
>>2836
Почему не можешь перейти? Веб/мобилки? GDNative? Большое количество GUI в игре, которое трудно будет переделывать на 4.0? Твоя ЦА на очень старых ПК?
>>2845
Зато стабильно и мало багов. Вообще, Godot по своей философии добавляет в себя только что-то, что важно многим, а для всего остального подразумевается, что юзеры сами добавляют модулями/аддонами. Если не добавляют нового в движок - либо не готово, либо не подходит, и останется в отдельном модуле/аддоне.
Всем, кто планирует и дальше сидеть на Godot, я бы рекомендовал не бояться сборки из исходников и исследовать эту тему заранее, чтобы знать, как и что возможно подключить/отключить самостоятельно.
В проприетарных и непопулярных движках зачастую добавляют много лишнего, потому что пользователь фактически лишён возможности что-то сделать, за исключением очень ограниченного скриптинга, либо сторонние модули недостаточно развиты. Godot уже достиг состояния, когда важнее фиксить баги, чем добавлять какие-то "интересные (лишние) функции".
Почему не можешь перейти? Веб/мобилки? GDNative? Большое количество GUI в игре, которое трудно будет переделывать на 4.0? Твоя ЦА на очень старых ПК?
>>2845
Зато стабильно и мало багов. Вообще, Godot по своей философии добавляет в себя только что-то, что важно многим, а для всего остального подразумевается, что юзеры сами добавляют модулями/аддонами. Если не добавляют нового в движок - либо не готово, либо не подходит, и останется в отдельном модуле/аддоне.
Всем, кто планирует и дальше сидеть на Godot, я бы рекомендовал не бояться сборки из исходников и исследовать эту тему заранее, чтобы знать, как и что возможно подключить/отключить самостоятельно.
В проприетарных и непопулярных движках зачастую добавляют много лишнего, потому что пользователь фактически лишён возможности что-то сделать, за исключением очень ограниченного скриптинга, либо сторонние модули недостаточно развиты. Godot уже достиг состояния, когда важнее фиксить баги, чем добавлять какие-то "интересные (лишние) функции".
>>2848
4.4-4.6 были крутыми на фишки для 3д. Много оптимизаций, улучшенная работа освещения, вот такого бы побольше. Но я даже рад что 4.7 такой небольшой, может и правда стейбл-стейбл наконец появится.
4.4-4.6 были крутыми на фишки для 3д. Много оптимизаций, улучшенная работа освещения, вот такого бы побольше. Но я даже рад что 4.7 такой небольшой, может и правда стейбл-стейбл наконец появится.
>>2852
Таймлайн четвёрки примерно такой:
4.0 - нестабильная, но куча нового
4.1-4.2 - куча нового и фикс старого
4.3-4.4 - стабилизируемся
4.5-4.6 - куча нового и баги
4.7 - стабилизируемся
4.8 - ...?
Ожидаю апгрейд GDScript в 4.8-4.9+...
В 4.7 добавили AreaLight3D, недоволен?
Таймлайн четвёрки примерно такой:
4.0 - нестабильная, но куча нового
4.1-4.2 - куча нового и фикс старого
4.3-4.4 - стабилизируемся
4.5-4.6 - куча нового и баги
4.7 - стабилизируемся
4.8 - ...?
Ожидаю апгрейд GDScript в 4.8-4.9+...
>улучшенная работа освещения
В 4.7 добавили AreaLight3D, недоволен?
>>2861
Rectangular, да. Круглый и раньше был.
Доволен конечно, я без негатива, друже. Мой любимый движок, просто я не так давно слежу за апдейтами и видимо привык, что крутые фичи завозят. Надеюсь 4.8 тоже будет про стабилизацию и qol, может быть даже последней версией перед 5.0, вот там можно на полную катушку разойтись.
>В 4.7 добавили AreaLight3D,
Rectangular, да. Круглый и раньше был.
>недоволен?
Доволен конечно, я без негатива, друже. Мой любимый движок, просто я не так давно слежу за апдейтами и видимо привык, что крутые фичи завозят. Надеюсь 4.8 тоже будет про стабилизацию и qol, может быть даже последней версией перед 5.0, вот там можно на полную катушку разойтись.
>>2868
У меня этих своих проектов уже знаешь сколько заброшено, зачем они нужны вообще. Тут хоть покекать можно
У меня этих своих проектов уже знаешь сколько заброшено, зачем они нужны вообще. Тут хоть покекать можно
А ассет стор этот новый в интернет сам не стучится? Кто уже на 4.7 переехал, как полёт?
>>2816
Да просто чуть что - сразу бросаю и ною, как это всё сложно. Зимой решил, что нужно фокусироваться на персонаже, но когда пытался заригать обновленную модельку, всё перекосило и я сильно расстроился. И забросил работу над игрой на 1.5-2 месяца. Мне ещё придётся ригать инструмент как персонажа, а ещё я планировал, но так и не начал компаньона... И я уже сомневаюсь, делать ли гарпию или что-то другое, т.к. заригать гарпию будет очень сложно. Просто хотел забавного персонажа с функциями Bosco из DRG.
Поздней весной решил пока отложить персонажа и попробовал отрефакторить строительство, но, пока тестировал свой код, я внезапно осознал, что мне не нравится и никогда не нравилось строительство из маленьких кусочков - когда ты можешь сделать что пожелаешь, но если делать оптимально, то у тебя получаются кубы и коробки. Также есть проблема с механикой ремонта: если установка нового блока моментальная, игроку будет проще удалить и снова установить блок, чем "ремонтировать" его; а если я замедляю установку, сборка превращается в гринд, который, если честно, меня уже давно достал в "креативных" выживалках (когда ты ставишь пустой "каркас" и "заполняешь" его сырыми ресурсами). И устанавливать мелкие блоки тоже весьма уныло.
Так что я обдумал всё ещё раз и решил взять себе альтернативную механику, когда вместо GUI выбора своих блоков для крафта из сырых ресурсов тебя вынуждают подбирать уже существующие блоки, разбросанные по миру. Вроде бы уже не первый раз рассматриваю эту механику... т.к. в самом первом прототипе было нечто похожее... Если кому-то вдруг интересно, поиграйте в TerraTech, там эта механика раскрыта достаточно хорошо. Но мне нужны полые конструкции, в которых можно ходить... наверное.
Концептуально эта механика идеально вписывается в моё видение игры, где игрок попал в мир, где кучи поломанного хлама и нужно пытаться выжить, переиспользуя найденное, а не просто создавая суперкрутые технологии из палок и камней - самые навороченные технологии у игрока есть изначально.
На практике - начал делать прототип, столкнулся с трудностями и опять обмяк. Бросил на 1.5-2 месяца. Попытаюсь вернуться к этому. Основная идея: игрок способен "сжать" любой блок, но переносит он лишь единственный сжатый блок, хочешь больше - тогда разбираешь блок на сырые ресурсы, но не можешь скрафтить блок из сырых ресурсов, только починить имеющееся или обменять у старых крафт-станций. Соединения крупных блоков в определённых точках, маленькие можно, наверное, закрепить где угодно.
Кстати, я ещё придумал, как эта система получает регулярные обломки планет и кораблей, но об этом расскажу как-нибудь в следующий раз. Главное - это постоянное пополнение чем-то новым, иногда даже падающим на голову игроку, проламывая крышу построенного дирижабля. Но вот основной контент всплывает на островах или где-то под облаками.
И тут вылезает третья проблема - контент нужно придумывать не просто так, а в каком-то стиле, и я сомневаюсь, какой стиль графики хочу видеть. По персонажам, скорее всего, я остановлюсь на уже имеющемся стиле: одноцветное альбедо почти без текстурирования, с гладким шейдингом. Но вот для объектов окружающей среды нужно что-то другое. Планировал набросать концепты, но так и не начал. Нейронки вообще не помогают, как и референсы из существующих игр. Трудно понять, что мне нужно. Прокрастинирую, наверное? Давно уже мог бы тупо набросать несколько версий и выбрать лучшую...
>>2746
Давно играл в демку, не понравилось. Там обычный, максимально стандартный выживач "майнкрафт без кубиков", ты даже можешь забыть, что все действия происходят на летающем острове. От "solarpunk" там исключительно солнечные панели. В целом, та игра значительно ближе к Aloft, чем к моей игре, при том, внезапно, Aloft ближе к "solarpunk", чем Solarpunk... Представь себе игру "Cyberpunk", в которой от жанра киберпанка только современные мобильники и ещё провода современных ЛЭП - ну не абсурд ли? Это разочаровывает даже больше, чем геймплей.
А моя игра в целом ближе к Worlds Adrift и/или её переизданию Lost Skies и/или той промежуточной концепции Bossa, в которой они хотели добавить компаньонов-роботов (концепт не сохранился на официальном сайте, нужно искать через архивы)... Впрочем, мой концепт более продуман с т.з. мира, живущего без разрыва с механиками игрока - т.е., например, вместо респавна ресурсов на статично подвешенных островах, сами острова постепенно разрушаются, падают, и затем взлетают снова, в обновленном виде (по задумке, без процедурной генерации не обойтись, но в виде "из кусочков", без избыточной детализации кубиками/вокселями). В некотором смысле моя игра должна быть полной противоположностью Aloft - там мир надеется на поддержку игрока, а у меня мир независим, герой - инородное тело в постоянно бурлящей биосфере, бездействие отбрасывает игрока к самому началу.
И да, я и сам слежу за похожими играми. Правда, на практике ничего похожего нет, только со стороны покажется, что что-то похожее - копнёшь чуть глубже "летающих островов" и видишь, что это другая игра, совершенно не похожая, даже теми же островами.
Ещё бы я не расстраивался от малейшей неудачи...
Сначала я тоже тестил с камерой от первого лица, с переключением камеры в любой момент, но увы, на практике, как только в мире существует нечто не помещающееся строго перед носом твоего героя, интуитивно стараешься перейти на вид от третьего, поскольку иначе ты мучаешься и борешься с игрой. Управление любым транспортом от первого лица превращается в мучение. Строительство от первого возможно только если у тебя кубики 1м или мельче. Короче, камера от третьего лица универсальнее, но настроить её для удобства игрока чуть сложнее.
Мне кажется, то, что называют "погружением", лучше описывается состоянием потока (flow state), которое возникает при любой "поглощающей всё внимание" деятельности, и которому препятствует только лишь "уровень навыков vs уровень сложности". Т.е. если занимаешься чем-то, что подходит по сложности, ты "погружаешься", даже если это редактор Godot, а не реалистичная игра от первого лица.
Более того, мозг крайне адаптивен и способен легко привыкнуть к камере от третьего лица в реале. Были эксперименты с VR очками и камерой за спиной, там подопытные адаптировались управлять телом, видя происходящее со стороны, как в играх, и это было не сложнее, чем с обычным зрением. Нужно было лишь немного времени для привыкания - но современные компьютерные игроки давно привыкли к камерам от третьего лица, так, что камера от первого бывает непривычна какой-то части аудитории. Если мозгу в принципе пофиг, где находятся "глаза" относительно собственного тела, и раз уж игроки привыкли, то нет никакого смысла делать от первого лица (ну, кроме экономии на персонаже, когда делают только руки с оружием, а остальное тело вообще не существует).
Но технически у меня по-прежнему комбинированная орбитальная камера с режимом первого лица и даже автоматическим переключением в него, так что нет проблемы оставить переключатель, нужно только настроить положение, а то сиськи мешаются... Это, наверное, самый старый мой скрипт в проекте. Был, наверное, одним из первых моих скриптов на Godot. Времена меняются, проекты забрасываются, а моя OrbitalCamera как была недоделана, так и работает... Недавно обнаружил, что приделал ей фичу слежения, которую делал для другого брошенного проекта, и не активировал в этом - активировал и стало лучше. Не заметили? Теперь есть лёгкое отставание от игрока.
Когда-нибудь позже расскажу о других идеях - хочу реализовать побольше, чтоб было что показать, а не растекаться бесплодными фантазиями. А то я много придумываю, но слишком мало реализовываю...
>>2742
Какие-то виды оружия планируются, но игра не про нападение, а про защиту и исследование. А землян, помимо игроков, пока не планируется. Летающие медузы могут быть источником газа, но добавил их просто чтоб что-то летало в прототипе. Но ты меня натолкнул на размышления, так что спасибо.
Честно, давно была мысль дать гарпии миниган... Слишком абсурдно даже для такой абсурдной игры. Компаньон скорее для разведки, поиска полезного. Максимум может швыряться чем-нибудь тяжёлым.
>>2751
И тебе спасибо.
Да просто чуть что - сразу бросаю и ною, как это всё сложно. Зимой решил, что нужно фокусироваться на персонаже, но когда пытался заригать обновленную модельку, всё перекосило и я сильно расстроился. И забросил работу над игрой на 1.5-2 месяца. Мне ещё придётся ригать инструмент как персонажа, а ещё я планировал, но так и не начал компаньона... И я уже сомневаюсь, делать ли гарпию или что-то другое, т.к. заригать гарпию будет очень сложно. Просто хотел забавного персонажа с функциями Bosco из DRG.
Поздней весной решил пока отложить персонажа и попробовал отрефакторить строительство, но, пока тестировал свой код, я внезапно осознал, что мне не нравится и никогда не нравилось строительство из маленьких кусочков - когда ты можешь сделать что пожелаешь, но если делать оптимально, то у тебя получаются кубы и коробки. Также есть проблема с механикой ремонта: если установка нового блока моментальная, игроку будет проще удалить и снова установить блок, чем "ремонтировать" его; а если я замедляю установку, сборка превращается в гринд, который, если честно, меня уже давно достал в "креативных" выживалках (когда ты ставишь пустой "каркас" и "заполняешь" его сырыми ресурсами). И устанавливать мелкие блоки тоже весьма уныло.
Так что я обдумал всё ещё раз и решил взять себе альтернативную механику, когда вместо GUI выбора своих блоков для крафта из сырых ресурсов тебя вынуждают подбирать уже существующие блоки, разбросанные по миру. Вроде бы уже не первый раз рассматриваю эту механику... т.к. в самом первом прототипе было нечто похожее... Если кому-то вдруг интересно, поиграйте в TerraTech, там эта механика раскрыта достаточно хорошо. Но мне нужны полые конструкции, в которых можно ходить... наверное.
Концептуально эта механика идеально вписывается в моё видение игры, где игрок попал в мир, где кучи поломанного хлама и нужно пытаться выжить, переиспользуя найденное, а не просто создавая суперкрутые технологии из палок и камней - самые навороченные технологии у игрока есть изначально.
На практике - начал делать прототип, столкнулся с трудностями и опять обмяк. Бросил на 1.5-2 месяца. Попытаюсь вернуться к этому. Основная идея: игрок способен "сжать" любой блок, но переносит он лишь единственный сжатый блок, хочешь больше - тогда разбираешь блок на сырые ресурсы, но не можешь скрафтить блок из сырых ресурсов, только починить имеющееся или обменять у старых крафт-станций. Соединения крупных блоков в определённых точках, маленькие можно, наверное, закрепить где угодно.
Кстати, я ещё придумал, как эта система получает регулярные обломки планет и кораблей, но об этом расскажу как-нибудь в следующий раз. Главное - это постоянное пополнение чем-то новым, иногда даже падающим на голову игроку, проламывая крышу построенного дирижабля. Но вот основной контент всплывает на островах или где-то под облаками.
И тут вылезает третья проблема - контент нужно придумывать не просто так, а в каком-то стиле, и я сомневаюсь, какой стиль графики хочу видеть. По персонажам, скорее всего, я остановлюсь на уже имеющемся стиле: одноцветное альбедо почти без текстурирования, с гладким шейдингом. Но вот для объектов окружающей среды нужно что-то другое. Планировал набросать концепты, но так и не начал. Нейронки вообще не помогают, как и референсы из существующих игр. Трудно понять, что мне нужно. Прокрастинирую, наверное? Давно уже мог бы тупо набросать несколько версий и выбрать лучшую...
>>2746
>Solarpunk
Давно играл в демку, не понравилось. Там обычный, максимально стандартный выживач "майнкрафт без кубиков", ты даже можешь забыть, что все действия происходят на летающем острове. От "solarpunk" там исключительно солнечные панели. В целом, та игра значительно ближе к Aloft, чем к моей игре, при том, внезапно, Aloft ближе к "solarpunk", чем Solarpunk... Представь себе игру "Cyberpunk", в которой от жанра киберпанка только современные мобильники и ещё провода современных ЛЭП - ну не абсурд ли? Это разочаровывает даже больше, чем геймплей.
А моя игра в целом ближе к Worlds Adrift и/или её переизданию Lost Skies и/или той промежуточной концепции Bossa, в которой они хотели добавить компаньонов-роботов (концепт не сохранился на официальном сайте, нужно искать через архивы)... Впрочем, мой концепт более продуман с т.з. мира, живущего без разрыва с механиками игрока - т.е., например, вместо респавна ресурсов на статично подвешенных островах, сами острова постепенно разрушаются, падают, и затем взлетают снова, в обновленном виде (по задумке, без процедурной генерации не обойтись, но в виде "из кусочков", без избыточной детализации кубиками/вокселями). В некотором смысле моя игра должна быть полной противоположностью Aloft - там мир надеется на поддержку игрока, а у меня мир независим, герой - инородное тело в постоянно бурлящей биосфере, бездействие отбрасывает игрока к самому началу.
И да, я и сам слежу за похожими играми. Правда, на практике ничего похожего нет, только со стороны покажется, что что-то похожее - копнёшь чуть глубже "летающих островов" и видишь, что это другая игра, совершенно не похожая, даже теми же островами.
Ещё бы я не расстраивался от малейшей неудачи...
>выживач от первого лица
Сначала я тоже тестил с камерой от первого лица, с переключением камеры в любой момент, но увы, на практике, как только в мире существует нечто не помещающееся строго перед носом твоего героя, интуитивно стараешься перейти на вид от третьего, поскольку иначе ты мучаешься и борешься с игрой. Управление любым транспортом от первого лица превращается в мучение. Строительство от первого возможно только если у тебя кубики 1м или мельче. Короче, камера от третьего лица универсальнее, но настроить её для удобства игрока чуть сложнее.
>от первого лица как-будто есть погружение
Мне кажется, то, что называют "погружением", лучше описывается состоянием потока (flow state), которое возникает при любой "поглощающей всё внимание" деятельности, и которому препятствует только лишь "уровень навыков vs уровень сложности". Т.е. если занимаешься чем-то, что подходит по сложности, ты "погружаешься", даже если это редактор Godot, а не реалистичная игра от первого лица.
Более того, мозг крайне адаптивен и способен легко привыкнуть к камере от третьего лица в реале. Были эксперименты с VR очками и камерой за спиной, там подопытные адаптировались управлять телом, видя происходящее со стороны, как в играх, и это было не сложнее, чем с обычным зрением. Нужно было лишь немного времени для привыкания - но современные компьютерные игроки давно привыкли к камерам от третьего лица, так, что камера от первого бывает непривычна какой-то части аудитории. Если мозгу в принципе пофиг, где находятся "глаза" относительно собственного тела, и раз уж игроки привыкли, то нет никакого смысла делать от первого лица (ну, кроме экономии на персонаже, когда делают только руки с оружием, а остальное тело вообще не существует).
Но технически у меня по-прежнему комбинированная орбитальная камера с режимом первого лица и даже автоматическим переключением в него, так что нет проблемы оставить переключатель, нужно только настроить положение, а то сиськи мешаются... Это, наверное, самый старый мой скрипт в проекте. Был, наверное, одним из первых моих скриптов на Godot. Времена меняются, проекты забрасываются, а моя OrbitalCamera как была недоделана, так и работает... Недавно обнаружил, что приделал ей фичу слежения, которую делал для другого брошенного проекта, и не активировал в этом - активировал и стало лучше. Не заметили? Теперь есть лёгкое отставание от игрока.
Когда-нибудь позже расскажу о других идеях - хочу реализовать побольше, чтоб было что показать, а не растекаться бесплодными фантазиями. А то я много придумываю, но слишком мало реализовываю...
>>2742
Какие-то виды оружия планируются, но игра не про нападение, а про защиту и исследование. А землян, помимо игроков, пока не планируется. Летающие медузы могут быть источником газа, но добавил их просто чтоб что-то летало в прототипе. Но ты меня натолкнул на размышления, так что спасибо.
Честно, давно была мысль дать гарпии миниган... Слишком абсурдно даже для такой абсурдной игры. Компаньон скорее для разведки, поиска полезного. Максимум может швыряться чем-нибудь тяжёлым.
>>2751
И тебе спасибо.
>>2816
Да просто чуть что - сразу бросаю и ною, как это всё сложно. Зимой решил, что нужно фокусироваться на персонаже, но когда пытался заригать обновленную модельку, всё перекосило и я сильно расстроился. И забросил работу над игрой на 1.5-2 месяца. Мне ещё придётся ригать инструмент как персонажа, а ещё я планировал, но так и не начал компаньона... И я уже сомневаюсь, делать ли гарпию или что-то другое, т.к. заригать гарпию будет очень сложно. Просто хотел забавного персонажа с функциями Bosco из DRG.
Поздней весной решил пока отложить персонажа и попробовал отрефакторить строительство, но, пока тестировал свой код, я внезапно осознал, что мне не нравится и никогда не нравилось строительство из маленьких кусочков - когда ты можешь сделать что пожелаешь, но если делать оптимально, то у тебя получаются кубы и коробки. Также есть проблема с механикой ремонта: если установка нового блока моментальная, игроку будет проще удалить и снова установить блок, чем "ремонтировать" его; а если я замедляю установку, сборка превращается в гринд, который, если честно, меня уже давно достал в "креативных" выживалках (когда ты ставишь пустой "каркас" и "заполняешь" его сырыми ресурсами). И устанавливать мелкие блоки тоже весьма уныло.
Так что я обдумал всё ещё раз и решил взять себе альтернативную механику, когда вместо GUI выбора своих блоков для крафта из сырых ресурсов тебя вынуждают подбирать уже существующие блоки, разбросанные по миру. Вроде бы уже не первый раз рассматриваю эту механику... т.к. в самом первом прототипе было нечто похожее... Если кому-то вдруг интересно, поиграйте в TerraTech, там эта механика раскрыта достаточно хорошо. Но мне нужны полые конструкции, в которых можно ходить... наверное.
Концептуально эта механика идеально вписывается в моё видение игры, где игрок попал в мир, где кучи поломанного хлама и нужно пытаться выжить, переиспользуя найденное, а не просто создавая суперкрутые технологии из палок и камней - самые навороченные технологии у игрока есть изначально.
На практике - начал делать прототип, столкнулся с трудностями и опять обмяк. Бросил на 1.5-2 месяца. Попытаюсь вернуться к этому. Основная идея: игрок способен "сжать" любой блок, но переносит он лишь единственный сжатый блок, хочешь больше - тогда разбираешь блок на сырые ресурсы, но не можешь скрафтить блок из сырых ресурсов, только починить имеющееся или обменять у старых крафт-станций. Соединения крупных блоков в определённых точках, маленькие можно, наверное, закрепить где угодно.
Кстати, я ещё придумал, как эта система получает регулярные обломки планет и кораблей, но об этом расскажу как-нибудь в следующий раз. Главное - это постоянное пополнение чем-то новым, иногда даже падающим на голову игроку, проламывая крышу построенного дирижабля. Но вот основной контент всплывает на островах или где-то под облаками.
И тут вылезает третья проблема - контент нужно придумывать не просто так, а в каком-то стиле, и я сомневаюсь, какой стиль графики хочу видеть. По персонажам, скорее всего, я остановлюсь на уже имеющемся стиле: одноцветное альбедо почти без текстурирования, с гладким шейдингом. Но вот для объектов окружающей среды нужно что-то другое. Планировал набросать концепты, но так и не начал. Нейронки вообще не помогают, как и референсы из существующих игр. Трудно понять, что мне нужно. Прокрастинирую, наверное? Давно уже мог бы тупо набросать несколько версий и выбрать лучшую...
>>2746
Давно играл в демку, не понравилось. Там обычный, максимально стандартный выживач "майнкрафт без кубиков", ты даже можешь забыть, что все действия происходят на летающем острове. От "solarpunk" там исключительно солнечные панели. В целом, та игра значительно ближе к Aloft, чем к моей игре, при том, внезапно, Aloft ближе к "solarpunk", чем Solarpunk... Представь себе игру "Cyberpunk", в которой от жанра киберпанка только современные мобильники и ещё провода современных ЛЭП - ну не абсурд ли? Это разочаровывает даже больше, чем геймплей.
А моя игра в целом ближе к Worlds Adrift и/или её переизданию Lost Skies и/или той промежуточной концепции Bossa, в которой они хотели добавить компаньонов-роботов (концепт не сохранился на официальном сайте, нужно искать через архивы)... Впрочем, мой концепт более продуман с т.з. мира, живущего без разрыва с механиками игрока - т.е., например, вместо респавна ресурсов на статично подвешенных островах, сами острова постепенно разрушаются, падают, и затем взлетают снова, в обновленном виде (по задумке, без процедурной генерации не обойтись, но в виде "из кусочков", без избыточной детализации кубиками/вокселями). В некотором смысле моя игра должна быть полной противоположностью Aloft - там мир надеется на поддержку игрока, а у меня мир независим, герой - инородное тело в постоянно бурлящей биосфере, бездействие отбрасывает игрока к самому началу.
И да, я и сам слежу за похожими играми. Правда, на практике ничего похожего нет, только со стороны покажется, что что-то похожее - копнёшь чуть глубже "летающих островов" и видишь, что это другая игра, совершенно не похожая, даже теми же островами.
Ещё бы я не расстраивался от малейшей неудачи...
Сначала я тоже тестил с камерой от первого лица, с переключением камеры в любой момент, но увы, на практике, как только в мире существует нечто не помещающееся строго перед носом твоего героя, интуитивно стараешься перейти на вид от третьего, поскольку иначе ты мучаешься и борешься с игрой. Управление любым транспортом от первого лица превращается в мучение. Строительство от первого возможно только если у тебя кубики 1м или мельче. Короче, камера от третьего лица универсальнее, но настроить её для удобства игрока чуть сложнее.
Мне кажется, то, что называют "погружением", лучше описывается состоянием потока (flow state), которое возникает при любой "поглощающей всё внимание" деятельности, и которому препятствует только лишь "уровень навыков vs уровень сложности". Т.е. если занимаешься чем-то, что подходит по сложности, ты "погружаешься", даже если это редактор Godot, а не реалистичная игра от первого лица.
Более того, мозг крайне адаптивен и способен легко привыкнуть к камере от третьего лица в реале. Были эксперименты с VR очками и камерой за спиной, там подопытные адаптировались управлять телом, видя происходящее со стороны, как в играх, и это было не сложнее, чем с обычным зрением. Нужно было лишь немного времени для привыкания - но современные компьютерные игроки давно привыкли к камерам от третьего лица, так, что камера от первого бывает непривычна какой-то части аудитории. Если мозгу в принципе пофиг, где находятся "глаза" относительно собственного тела, и раз уж игроки привыкли, то нет никакого смысла делать от первого лица (ну, кроме экономии на персонаже, когда делают только руки с оружием, а остальное тело вообще не существует).
Но технически у меня по-прежнему комбинированная орбитальная камера с режимом первого лица и даже автоматическим переключением в него, так что нет проблемы оставить переключатель, нужно только настроить положение, а то сиськи мешаются... Это, наверное, самый старый мой скрипт в проекте. Был, наверное, одним из первых моих скриптов на Godot. Времена меняются, проекты забрасываются, а моя OrbitalCamera как была недоделана, так и работает... Недавно обнаружил, что приделал ей фичу слежения, которую делал для другого брошенного проекта, и не активировал в этом - активировал и стало лучше. Не заметили? Теперь есть лёгкое отставание от игрока.
Когда-нибудь позже расскажу о других идеях - хочу реализовать побольше, чтоб было что показать, а не растекаться бесплодными фантазиями. А то я много придумываю, но слишком мало реализовываю...
>>2742
Какие-то виды оружия планируются, но игра не про нападение, а про защиту и исследование. А землян, помимо игроков, пока не планируется. Летающие медузы могут быть источником газа, но добавил их просто чтоб что-то летало в прототипе. Но ты меня натолкнул на размышления, так что спасибо.
Честно, давно была мысль дать гарпии миниган... Слишком абсурдно даже для такой абсурдной игры. Компаньон скорее для разведки, поиска полезного. Максимум может швыряться чем-нибудь тяжёлым.
>>2751
И тебе спасибо.
Да просто чуть что - сразу бросаю и ною, как это всё сложно. Зимой решил, что нужно фокусироваться на персонаже, но когда пытался заригать обновленную модельку, всё перекосило и я сильно расстроился. И забросил работу над игрой на 1.5-2 месяца. Мне ещё придётся ригать инструмент как персонажа, а ещё я планировал, но так и не начал компаньона... И я уже сомневаюсь, делать ли гарпию или что-то другое, т.к. заригать гарпию будет очень сложно. Просто хотел забавного персонажа с функциями Bosco из DRG.
Поздней весной решил пока отложить персонажа и попробовал отрефакторить строительство, но, пока тестировал свой код, я внезапно осознал, что мне не нравится и никогда не нравилось строительство из маленьких кусочков - когда ты можешь сделать что пожелаешь, но если делать оптимально, то у тебя получаются кубы и коробки. Также есть проблема с механикой ремонта: если установка нового блока моментальная, игроку будет проще удалить и снова установить блок, чем "ремонтировать" его; а если я замедляю установку, сборка превращается в гринд, который, если честно, меня уже давно достал в "креативных" выживалках (когда ты ставишь пустой "каркас" и "заполняешь" его сырыми ресурсами). И устанавливать мелкие блоки тоже весьма уныло.
Так что я обдумал всё ещё раз и решил взять себе альтернативную механику, когда вместо GUI выбора своих блоков для крафта из сырых ресурсов тебя вынуждают подбирать уже существующие блоки, разбросанные по миру. Вроде бы уже не первый раз рассматриваю эту механику... т.к. в самом первом прототипе было нечто похожее... Если кому-то вдруг интересно, поиграйте в TerraTech, там эта механика раскрыта достаточно хорошо. Но мне нужны полые конструкции, в которых можно ходить... наверное.
Концептуально эта механика идеально вписывается в моё видение игры, где игрок попал в мир, где кучи поломанного хлама и нужно пытаться выжить, переиспользуя найденное, а не просто создавая суперкрутые технологии из палок и камней - самые навороченные технологии у игрока есть изначально.
На практике - начал делать прототип, столкнулся с трудностями и опять обмяк. Бросил на 1.5-2 месяца. Попытаюсь вернуться к этому. Основная идея: игрок способен "сжать" любой блок, но переносит он лишь единственный сжатый блок, хочешь больше - тогда разбираешь блок на сырые ресурсы, но не можешь скрафтить блок из сырых ресурсов, только починить имеющееся или обменять у старых крафт-станций. Соединения крупных блоков в определённых точках, маленькие можно, наверное, закрепить где угодно.
Кстати, я ещё придумал, как эта система получает регулярные обломки планет и кораблей, но об этом расскажу как-нибудь в следующий раз. Главное - это постоянное пополнение чем-то новым, иногда даже падающим на голову игроку, проламывая крышу построенного дирижабля. Но вот основной контент всплывает на островах или где-то под облаками.
И тут вылезает третья проблема - контент нужно придумывать не просто так, а в каком-то стиле, и я сомневаюсь, какой стиль графики хочу видеть. По персонажам, скорее всего, я остановлюсь на уже имеющемся стиле: одноцветное альбедо почти без текстурирования, с гладким шейдингом. Но вот для объектов окружающей среды нужно что-то другое. Планировал набросать концепты, но так и не начал. Нейронки вообще не помогают, как и референсы из существующих игр. Трудно понять, что мне нужно. Прокрастинирую, наверное? Давно уже мог бы тупо набросать несколько версий и выбрать лучшую...
>>2746
>Solarpunk
Давно играл в демку, не понравилось. Там обычный, максимально стандартный выживач "майнкрафт без кубиков", ты даже можешь забыть, что все действия происходят на летающем острове. От "solarpunk" там исключительно солнечные панели. В целом, та игра значительно ближе к Aloft, чем к моей игре, при том, внезапно, Aloft ближе к "solarpunk", чем Solarpunk... Представь себе игру "Cyberpunk", в которой от жанра киберпанка только современные мобильники и ещё провода современных ЛЭП - ну не абсурд ли? Это разочаровывает даже больше, чем геймплей.
А моя игра в целом ближе к Worlds Adrift и/или её переизданию Lost Skies и/или той промежуточной концепции Bossa, в которой они хотели добавить компаньонов-роботов (концепт не сохранился на официальном сайте, нужно искать через архивы)... Впрочем, мой концепт более продуман с т.з. мира, живущего без разрыва с механиками игрока - т.е., например, вместо респавна ресурсов на статично подвешенных островах, сами острова постепенно разрушаются, падают, и затем взлетают снова, в обновленном виде (по задумке, без процедурной генерации не обойтись, но в виде "из кусочков", без избыточной детализации кубиками/вокселями). В некотором смысле моя игра должна быть полной противоположностью Aloft - там мир надеется на поддержку игрока, а у меня мир независим, герой - инородное тело в постоянно бурлящей биосфере, бездействие отбрасывает игрока к самому началу.
И да, я и сам слежу за похожими играми. Правда, на практике ничего похожего нет, только со стороны покажется, что что-то похожее - копнёшь чуть глубже "летающих островов" и видишь, что это другая игра, совершенно не похожая, даже теми же островами.
Ещё бы я не расстраивался от малейшей неудачи...
>выживач от первого лица
Сначала я тоже тестил с камерой от первого лица, с переключением камеры в любой момент, но увы, на практике, как только в мире существует нечто не помещающееся строго перед носом твоего героя, интуитивно стараешься перейти на вид от третьего, поскольку иначе ты мучаешься и борешься с игрой. Управление любым транспортом от первого лица превращается в мучение. Строительство от первого возможно только если у тебя кубики 1м или мельче. Короче, камера от третьего лица универсальнее, но настроить её для удобства игрока чуть сложнее.
>от первого лица как-будто есть погружение
Мне кажется, то, что называют "погружением", лучше описывается состоянием потока (flow state), которое возникает при любой "поглощающей всё внимание" деятельности, и которому препятствует только лишь "уровень навыков vs уровень сложности". Т.е. если занимаешься чем-то, что подходит по сложности, ты "погружаешься", даже если это редактор Godot, а не реалистичная игра от первого лица.
Более того, мозг крайне адаптивен и способен легко привыкнуть к камере от третьего лица в реале. Были эксперименты с VR очками и камерой за спиной, там подопытные адаптировались управлять телом, видя происходящее со стороны, как в играх, и это было не сложнее, чем с обычным зрением. Нужно было лишь немного времени для привыкания - но современные компьютерные игроки давно привыкли к камерам от третьего лица, так, что камера от первого бывает непривычна какой-то части аудитории. Если мозгу в принципе пофиг, где находятся "глаза" относительно собственного тела, и раз уж игроки привыкли, то нет никакого смысла делать от первого лица (ну, кроме экономии на персонаже, когда делают только руки с оружием, а остальное тело вообще не существует).
Но технически у меня по-прежнему комбинированная орбитальная камера с режимом первого лица и даже автоматическим переключением в него, так что нет проблемы оставить переключатель, нужно только настроить положение, а то сиськи мешаются... Это, наверное, самый старый мой скрипт в проекте. Был, наверное, одним из первых моих скриптов на Godot. Времена меняются, проекты забрасываются, а моя OrbitalCamera как была недоделана, так и работает... Недавно обнаружил, что приделал ей фичу слежения, которую делал для другого брошенного проекта, и не активировал в этом - активировал и стало лучше. Не заметили? Теперь есть лёгкое отставание от игрока.
Когда-нибудь позже расскажу о других идеях - хочу реализовать побольше, чтоб было что показать, а не растекаться бесплодными фантазиями. А то я много придумываю, но слишком мало реализовываю...
>>2742
Какие-то виды оружия планируются, но игра не про нападение, а про защиту и исследование. А землян, помимо игроков, пока не планируется. Летающие медузы могут быть источником газа, но добавил их просто чтоб что-то летало в прототипе. Но ты меня натолкнул на размышления, так что спасибо.
Честно, давно была мысль дать гарпии миниган... Слишком абсурдно даже для такой абсурдной игры. Компаньон скорее для разведки, поиска полезного. Максимум может швыряться чем-нибудь тяжёлым.
>>2751
И тебе спасибо.
>>2345
У тебя углы Эйлера, которые могут привести к шарнирному замку (объект невозможно повернуть при определенной конфигурации). Плюс придется по лишней трансформаций на каждую из N нод делать, что не очень оптимально если всего объектов мало, то похуй
Лучше один раз научись вращать по заданной оси, годот сам через кватернионы все сделает.
У тебя углы Эйлера, которые могут привести к шарнирному замку (объект невозможно повернуть при определенной конфигурации). Плюс придется по лишней трансформаций на каждую из N нод делать, что не очень оптимально если всего объектов мало, то похуй
Лучше один раз научись вращать по заданной оси, годот сам через кватернионы все сделает.
>>2354
Не надо в них разбираться. Просто делай rotate(вектор_оси, угол)
> А, и да, я много слышал, что нужны Quaternions, тип выгоднее по сравнению с вращением векторов, но я вообще не понимаю их. Смотрел визуализации и не разобрался.
Не надо в них разбираться. Просто делай rotate(вектор_оси, угол)
>>2896
Ну, учитывая что в мире существуют гарпии, то можно было бы наделить её возможностью стрелять условным огненным лучем или шарами а на них повесить партиклы и прочие эффекты, и считай плюс балл в глазах игрока. Впрочем у тебя гарпия действительно не выглядит как боевая единица, мб и не стоит вооружать её. Либо дать возможность переключать режимы и кастомизировать условно исследуем острова, находим сундук с перком на огненные шары и надеваем на неё
Всякие летающие противники энивей сами напрашиваются, особенно учитывая как ты реализовал полет на крыльях напоминает пвп на орнитоптерах в Dune awakening, когда нужно регулярно набирать высоту и пикировать для эффективных маневров.
Блин круто, люблю такое. Давай тогда не сдавайся. Полеты у тебя уже крутые, осталось на мой взгляд ток врагов добавить, с которыми и можно играть в воздухе и исследовать острова для сборки вундеркрепости
>Честно, давно была мысль дать гарпии миниган... Слишком абсурдно даже для такой абсурдной игры
Ну, учитывая что в мире существуют гарпии, то можно было бы наделить её возможностью стрелять условным огненным лучем или шарами а на них повесить партиклы и прочие эффекты, и считай плюс балл в глазах игрока. Впрочем у тебя гарпия действительно не выглядит как боевая единица, мб и не стоит вооружать её. Либо дать возможность переключать режимы и кастомизировать условно исследуем острова, находим сундук с перком на огненные шары и надеваем на неё
>Какие-то виды оружия планируются, но игра не про нападение, а про защиту и исследование. А землян, помимо игроков, пока не планируется
Всякие летающие противники энивей сами напрашиваются, особенно учитывая как ты реализовал полет на крыльях напоминает пвп на орнитоптерах в Dune awakening, когда нужно регулярно набирать высоту и пикировать для эффективных маневров.
>а у меня мир независим, герой - инородное тело в постоянно бурлящей биосфере, бездействие отбрасывает игрока к самому началу
Блин круто, люблю такое. Давай тогда не сдавайся. Полеты у тебя уже крутые, осталось на мой взгляд ток врагов добавить, с которыми и можно играть в воздухе и исследовать острова для сборки вундеркрепости
>>2868
ТВГ это для скучающих анонов, которые уже могут быстро в прототипы, но не знают как себя развлечь, потому что на свои проекты уже не стоит.
Простыми словами, ТВГ - это место, где мертвы все твои игровые мечты.
ТВГ это для скучающих анонов, которые уже могут быстро в прототипы, но не знают как себя развлечь, потому что на свои проекты уже не стоит.
Простыми словами, ТВГ - это место, где мертвы все твои игровые мечты.
>>2868
Геймджем для местных. Другой вопрос, зачем участвовать в местячковом геймджеме на полторы калеки, когда на итче в нормальный вкатиться можно.
Геймджем для местных. Другой вопрос, зачем участвовать в местячковом геймджеме на полторы калеки, когда на итче в нормальный вкатиться можно.
Ребята, нужен reality check, пожалуйста. Как вы считаете, реально на Годоте сделать что-то на уровне первой Killing Floor? Правильно я понимаю, что самая большая проблема - оптимизация кучи противников, их мувмента и ИИ, и для этого придется лезть в плюсы? Подъемная ли в целом идея для одного? Из бекграунда законченный техвуз и немного опыта на шарпах, сейчас ковыряю Годот на гдсе.
>>2950
На готовых ассетах - да. Если в соло делать все - нет.
Вот тебе ближайший пример на годоте, насколько помню чел его в соло ебашил, хуй знает сколько лет: https://store.steampowered.com/app/1963610/Road_to_Vostok/
На готовых ассетах - да. Если в соло делать все - нет.
Вот тебе ближайший пример на годоте, насколько помню чел его в соло ебашил, хуй знает сколько лет: https://store.steampowered.com/app/1963610/Road_to_Vostok/
>>2950
Вот эту игру посмотри 5 летней давности, еще на 3ке
https://leocesar3d.itch.io/human-diaspora
https://www.youtube.com/watch?v=FOKEVtZTaM4
Вот эту игру посмотри 5 летней давности, еще на 3ке
https://leocesar3d.itch.io/human-diaspora
https://www.youtube.com/watch?v=FOKEVtZTaM4
>>2950
Проблему ты видишь в коде/движке, какие-то оптимизации считаешь нужны, а в реале трудности в моделинге, текстурировании и отдельном аде - анимации.
Сложного нет, просто для соло необычайно много работы. (и с сетью тоже)
В реале упертые фанатики делают больше чем, анон дает оценку. Поэтому можно все. Скорее всего с опытом сделаешь выводы и возможно переключишься на что-то более доступное для солянщика или же упрешься рого и закончишь то что хотел. В реале 99,999% дропают игру, потому что делать игры это не тоже самое что играть игры, это невыносимо рутинная работа
Проблему ты видишь в коде/движке, какие-то оптимизации считаешь нужны, а в реале трудности в моделинге, текстурировании и отдельном аде - анимации.
Сложного нет, просто для соло необычайно много работы. (и с сетью тоже)
В реале упертые фанатики делают больше чем, анон дает оценку. Поэтому можно все. Скорее всего с опытом сделаешь выводы и возможно переключишься на что-то более доступное для солянщика или же упрешься рого и закончишь то что хотел. В реале 99,999% дропают игру, потому что делать игры это не тоже самое что играть игры, это невыносимо рутинная работа
>>2950
Гарантированно будут проблемы - с анимациями
Скорее всего - будут проблемы с большим количеством мобья, хоть и проблемы решаемые, но - гдс очень не любит кодовую оптимизацию. Этот язык создан для скриптинга нод. А в виду того что при оптимизации, ну, скажем - иишного управления или расчленения - придется пойти глубже управления нод и писать сложный код с возможным непрсредственным управлением графическим апи - гдс за счет того что не имеет возможности вводить свои типы данных - максимально усложнит существование.
Стриминг текстур все еще не завезли - значит твои локации будут маленькими или с шакальными текстурами (или ты возьмешь mterrain и будешь терпеть, а потом еще раз терпеть)
Гарантированно будут проблемы - с анимациями
Скорее всего - будут проблемы с большим количеством мобья, хоть и проблемы решаемые, но - гдс очень не любит кодовую оптимизацию. Этот язык создан для скриптинга нод. А в виду того что при оптимизации, ну, скажем - иишного управления или расчленения - придется пойти глубже управления нод и писать сложный код с возможным непрсредственным управлением графическим апи - гдс за счет того что не имеет возможности вводить свои типы данных - максимально усложнит существование.
Стриминг текстур все еще не завезли - значит твои локации будут маленькими или с шакальными текстурами (или ты возьмешь mterrain и будешь терпеть, а потом еще раз терпеть)
>>2999
Не будет. MultiMrsh, VAT для анимации. ИИ разнести врагов по группам и обновлять им пасфайндинг по очереди, а не каждый кадр. В конце наводить на игрока без использования физики.
Не будет. MultiMrsh, VAT для анимации. ИИ разнести врагов по группам и обновлять им пасфайндинг по очереди, а не каждый кадр. В конце наводить на игрока без использования физики.
33 Кб, 651x263А еще там теперь платные плагины можно продавать.
>>2896
если ты хотел бы всё отменить, то делай бекапы
оставь на потом
делай что попроще для начала, посмотри как выглядела та же стардью валлей на начальных этапах (https://www.youtube.com/watch?v=IcAZXEZQgRw) - совсем не как сейчас
тут я меняю текст, заметив пик2, конкретно тут надо не давать ломать блок и всё, можно ремонтировать и улучшать/заменять отремонтированный
старый вариант теста:
сделай пока так, с очевидным преимуществом сноса-установки, потом придумаешь что доработать, чтобы ремонт стал значимым (может придуматься много разного. например что нельзя строить какое то время там, где было здание или блоки или чтобы разрушение занимало время, что в общем то одно и тоже, вопрос только в визуализации)
не играл, выглядит как кроссаут + спейс инженеры, лол
это обычная механика "запаковки", была в майнкрафте с модами, например
По сути у тебя есть система предметов и система инвентаря/сундука. Например у тебя есть в игре кирки и у них есть прочность. Тебе нужно 10 кирок разной прочности сложить в один стак - запаковать. Например делаешь машину - зпаковкщик или через меню, не важно. При помещении предмета проверяешь что предметы одного типа (напр. ITEM_TYPE_PICKAXE), далее создаётся невидимый инвентарь-сундук, куда перемещаются все пакуемые предметы и игроку выдаётся некий ITEM_PACKED_CHEST который можно только разбить/открыть/распаковать. Всякие рецепты будут игнорировать этот предмет в инвентаре т.к. у него тип ITEM_PACKED_CHEST, а не ITEM_TYPE_PICKAXE например.
Я перечитал этот абзац про "сжатый блок", возможно ты говорил про другое...
если не будет какой-то защиты - никто не любит когда игра просто ломает то, что игрок построил, без возможности защититься (опять же стардью валлей: против ворон - пугало, против молний - громоотвод)
делай из самого простого или из чужого (скетчфаб/ассеты с сайтов), нужна пальма, найди ЛЮБУЮ пальму и вставь, нужна коробка, найди ЛЮБУЮ коробку и вставь. Потом будешь подгонять единый стиль.
Так-то у тебя уже есть стиль - всратый обычный инди стиль и это хорошо
>но когда пытался заригать обновленную модельку, всё перекосило и я сильно расстроился.
если ты хотел бы всё отменить, то делай бекапы
>планировал, но так и не начал компаньона.
оставь на потом
>делать ли гарпию или что-то другое
делай что попроще для начала, посмотри как выглядела та же стардью валлей на начальных этапах (https://www.youtube.com/watch?v=IcAZXEZQgRw) - совсем не как сейчас
>если установка нового блока моментальная, игроку будет проще удалить и снова установить блок
тут я меняю текст, заметив пик2, конкретно тут надо не давать ломать блок и всё, можно ремонтировать и улучшать/заменять отремонтированный
старый вариант теста:
сделай пока так, с очевидным преимуществом сноса-установки, потом придумаешь что доработать, чтобы ремонт стал значимым (может придуматься много разного. например что нельзя строить какое то время там, где было здание или блоки или чтобы разрушение занимало время, что в общем то одно и тоже, вопрос только в визуализации)
>TerraTech
не играл, выглядит как кроссаут + спейс инженеры, лол
>игрок способен "сжать" любой блок, но переносит он лишь единственный сжатый блок, хочешь больше - тогда разбираешь блок на сырые ресурсы, но не можешь скрафтить блок из сырых ресурсов
это обычная механика "запаковки", была в майнкрафте с модами, например
По сути у тебя есть система предметов и система инвентаря/сундука. Например у тебя есть в игре кирки и у них есть прочность. Тебе нужно 10 кирок разной прочности сложить в один стак - запаковать. Например делаешь машину - зпаковкщик или через меню, не важно. При помещении предмета проверяешь что предметы одного типа (напр. ITEM_TYPE_PICKAXE), далее создаётся невидимый инвентарь-сундук, куда перемещаются все пакуемые предметы и игроку выдаётся некий ITEM_PACKED_CHEST который можно только разбить/открыть/распаковать. Всякие рецепты будут игнорировать этот предмет в инвентаре т.к. у него тип ITEM_PACKED_CHEST, а не ITEM_TYPE_PICKAXE например.
Я перечитал этот абзац про "сжатый блок", возможно ты говорил про другое...
>даже падающим на голову игроку, проламывая крышу построенного дирижабля.
если не будет какой-то защиты - никто не любит когда игра просто ломает то, что игрок построил, без возможности защититься (опять же стардью валлей: против ворон - пугало, против молний - громоотвод)
>и я сомневаюсь, какой стиль графики хочу видеть
делай из самого простого или из чужого (скетчфаб/ассеты с сайтов), нужна пальма, найди ЛЮБУЮ пальму и вставь, нужна коробка, найди ЛЮБУЮ коробку и вставь. Потом будешь подгонять единый стиль.
Так-то у тебя уже есть стиль - всратый обычный инди стиль и это хорошо
>>2896
если ты хотел бы всё отменить, то делай бекапы
оставь на потом
делай что попроще для начала, посмотри как выглядела та же стардью валлей на начальных этапах (https://www.youtube.com/watch?v=IcAZXEZQgRw) - совсем не как сейчас
тут я меняю текст, заметив пик2, конкретно тут надо не давать ломать блок и всё, можно ремонтировать и улучшать/заменять отремонтированный
старый вариант теста:
сделай пока так, с очевидным преимуществом сноса-установки, потом придумаешь что доработать, чтобы ремонт стал значимым (может придуматься много разного. например что нельзя строить какое то время там, где было здание или блоки или чтобы разрушение занимало время, что в общем то одно и тоже, вопрос только в визуализации)
не играл, выглядит как кроссаут + спейс инженеры, лол
это обычная механика "запаковки", была в майнкрафте с модами, например
По сути у тебя есть система предметов и система инвентаря/сундука. Например у тебя есть в игре кирки и у них есть прочность. Тебе нужно 10 кирок разной прочности сложить в один стак - запаковать. Например делаешь машину - зпаковкщик или через меню, не важно. При помещении предмета проверяешь что предметы одного типа (напр. ITEM_TYPE_PICKAXE), далее создаётся невидимый инвентарь-сундук, куда перемещаются все пакуемые предметы и игроку выдаётся некий ITEM_PACKED_CHEST который можно только разбить/открыть/распаковать. Всякие рецепты будут игнорировать этот предмет в инвентаре т.к. у него тип ITEM_PACKED_CHEST, а не ITEM_TYPE_PICKAXE например.
Я перечитал этот абзац про "сжатый блок", возможно ты говорил про другое...
если не будет какой-то защиты - никто не любит когда игра просто ломает то, что игрок построил, без возможности защититься (опять же стардью валлей: против ворон - пугало, против молний - громоотвод)
делай из самого простого или из чужого (скетчфаб/ассеты с сайтов), нужна пальма, найди ЛЮБУЮ пальму и вставь, нужна коробка, найди ЛЮБУЮ коробку и вставь. Потом будешь подгонять единый стиль.
Так-то у тебя уже есть стиль - всратый обычный инди стиль и это хорошо
>но когда пытался заригать обновленную модельку, всё перекосило и я сильно расстроился.
если ты хотел бы всё отменить, то делай бекапы
>планировал, но так и не начал компаньона.
оставь на потом
>делать ли гарпию или что-то другое
делай что попроще для начала, посмотри как выглядела та же стардью валлей на начальных этапах (https://www.youtube.com/watch?v=IcAZXEZQgRw) - совсем не как сейчас
>если установка нового блока моментальная, игроку будет проще удалить и снова установить блок
тут я меняю текст, заметив пик2, конкретно тут надо не давать ломать блок и всё, можно ремонтировать и улучшать/заменять отремонтированный
старый вариант теста:
сделай пока так, с очевидным преимуществом сноса-установки, потом придумаешь что доработать, чтобы ремонт стал значимым (может придуматься много разного. например что нельзя строить какое то время там, где было здание или блоки или чтобы разрушение занимало время, что в общем то одно и тоже, вопрос только в визуализации)
>TerraTech
не играл, выглядит как кроссаут + спейс инженеры, лол
>игрок способен "сжать" любой блок, но переносит он лишь единственный сжатый блок, хочешь больше - тогда разбираешь блок на сырые ресурсы, но не можешь скрафтить блок из сырых ресурсов
это обычная механика "запаковки", была в майнкрафте с модами, например
По сути у тебя есть система предметов и система инвентаря/сундука. Например у тебя есть в игре кирки и у них есть прочность. Тебе нужно 10 кирок разной прочности сложить в один стак - запаковать. Например делаешь машину - зпаковкщик или через меню, не важно. При помещении предмета проверяешь что предметы одного типа (напр. ITEM_TYPE_PICKAXE), далее создаётся невидимый инвентарь-сундук, куда перемещаются все пакуемые предметы и игроку выдаётся некий ITEM_PACKED_CHEST который можно только разбить/открыть/распаковать. Всякие рецепты будут игнорировать этот предмет в инвентаре т.к. у него тип ITEM_PACKED_CHEST, а не ITEM_TYPE_PICKAXE например.
Я перечитал этот абзац про "сжатый блок", возможно ты говорил про другое...
>даже падающим на голову игроку, проламывая крышу построенного дирижабля.
если не будет какой-то защиты - никто не любит когда игра просто ломает то, что игрок построил, без возможности защититься (опять же стардью валлей: против ворон - пугало, против молний - громоотвод)
>и я сомневаюсь, какой стиль графики хочу видеть
делай из самого простого или из чужого (скетчфаб/ассеты с сайтов), нужна пальма, найди ЛЮБУЮ пальму и вставь, нужна коробка, найди ЛЮБУЮ коробку и вставь. Потом будешь подгонять единый стиль.
Так-то у тебя уже есть стиль - всратый обычный инди стиль и это хорошо
>>2910
Сомнительно. Там 3 полноценных отдельных 3д ноды. А значит, у каждой есть свой "верх".
>У тебя углы Эйлера
Сомнительно. Там 3 полноценных отдельных 3д ноды. А значит, у каждой есть свой "верх".
Вот ещё быстрый тест того, как масштаб локации взаимодействует с имеющимися механиками для движения... Я думаю, острова больше 100-150 м нерационально делать, если только 200+ м будут выглядеть как плоские блюдца. Давно уже думал о песчаных блюдцах с кактусами, где игроку вместо вертикальной нужна горизонтальная скорость. Да, кактусы - это то, что держит песок в воздухе, лол.
И мне кажется, или мой спидометр слишком много показывает? Забыл разделить на число кадров? Эти огромные метки в воздухе вроде бы на 100% точные. Тестовые острова генерируются кодом из CSG нод. Записываю уже третье видео с этой сценой...
>>3029
Не в этом дело, я любые существенные изменения в моделях новым blend-файлом сохраняю. Просто демотивировался. Первая модель как-то неплохо заригалась с первой попытки, или это моя планка желаемого качества была существенно ниже...
Когда "потом"? Что делать вместо этих вещей?
Идея именно дирижаблей в том, что у тебя кроме собственно двигателей есть баллоны с газом, и без достаточного объёма газа всё рухнет, если ты не избавишься от лишней массы. Пример: дирижабль подвергается атаке где-то вдалеке от островов, и количество газа недостаточно, чтобы дотянуть до ближайшего острова целиком, поэтому игрок берёт и отрезает наименее важную часть, что позволяет добраться до острова и восполнить ресурсы. Также возможна ситуация, когда что-то построил, а потом оказалось, что с новыми ресурсами можно иначе. Постоянная переделка транспорта прям в процессе движения по воздуху - ключевая идея моей игры. Я настолько был недоволен "док-станциями" WA, что захотелось сделать свою собственную игру, лол.
Играл в обе. Crossout: ты строишь машину у себя в виртуальном гараже, а на поле боя можешь лишь постепенно разрушаться. Space Engineers: все блоки устанавливаются как пустые каркасы, потом долго заполняются сырыми ресурсами из инвентаря. Ещё переиграл во много подобных "vehicle builder" игр, достаточно популярный и разнообразный жанр. И конкретно TerraTech довольно уникальна... Или я недостаточно много индюшатины переиграл.
Знаю, но тут речь немного про другое. Суть в том, что хочется большие блоки-модули как в Subnautica или подобных ей "base builder" играх, но если не крафтить модули на нужном месте, а переносить, они слишком мешаются (на видео видно, почему), поэтому лучше визуально скукожить блок до ≈10% размера, чтоб не перекрывал собой обзор, а потом он расширяется в заданном игроком месте. Но чтоб стимулировать осмысленную сборку, блоки нельзя скапливать в виртуальном инвентаре, можно только выкинуть (уничтожить) или разобрать на запчасти/ресурсы.
Ещё есть идея, что ИИ-компаньоны игрока смогут перетаскивать блоки вместе с игроком. Так что чем больший дирижабль, тем больше компаньонов, что переносят больше блоков вместе с игроком. Вроде неплохо, если физический движок это выдержит...
Смотри: всё вокруг начинает искрить и трясти, резко затухает, а потом смотришь вверх - видишь горящие обломки, входящие в атмосферу с громким воем - и ругаешься на игру за то, что ты не уклонился? Имхо, подобного контента слишком мало в играх...
Это не корабли врезаются, а кольцо островов в них врезается. Не острова захвачены пришельцами, а пришельцы захвачены кольцом островов...
Стиль - это когда есть какие-то внутренние правила, которым следует графика. Типа, если у тебя в игре у объектов обводка цветная - она везде цветная, если шейдинг плоский (cel/toon) - он везде плоский, и т.д. Накидать ассетов не проблема, проблема - выбрать конкретный стиль, который самому понравится. Ибо разрабатывать игру, на которую самому не хочется ежедневно смотреть - хуже всего, как мне кажется.
>>2917
Как второе следует из первого? "Гарпии" возможны в твёрдой фантастике как результат конвергентной эволюции или генетических экспериментов.
Но вообще, не факт, что будут гарпии. Т.к. компаньон является роботом, как и герой игрока. Не помню уже, описывал тут или нет, но вот вкратце: человечество освоило солнечную систему и дальше в космос не продвигается, развивая вместо этого всё более эффективную робототехнику; дошло до наномашин, способных принимать любой облик по программе; подобные роботы почти бессмертны, могут оказать сопротивление и опаснее, чем оружие массового поражения, поэтому роботов с дефектами мирно отправляют исследовать глубокий космос; "гарпия" создавалась как орнитологический дрон, но из-за дефективной программы принимает такой облик.
Способностей у этих роботов почти нет, их главные преимущества - это дешевизна, компактность и экстремальная выносливость. Облики не дают сил, поскольку меняют внешний вид, а не суть. Самый оптимальный внешний вид - гладкая сфера, но их программа требует поддерживать заданный облик; например, ГГ поддерживает человекоподобный вид только лишь для взаимодействия с людьми, даже несмотря на то, что в другом мире их вообще нет; аналогично, "носит одежду" только для приличия, поскольку технически на ней вообще нет одежды. Получается лорное обоснование для любых скинов, находимых и используемых игроком по желанию.
Если ещё короче: сверхпрочная программируемая наноплёнка в форме чего пожелаешь, которая из-за опасности высылается людьми куда подальше как исследовательский дрон; однажды капсула с этими роботами попала в уникальную систему с плотным воздушным кольцом вокруг звезды -> начало игры.
А если будут гарпии-инопланетяне, они будут либо нормальными животными-птицами, либо роботами, созданными расой гуманоидных птиц для себя. Инопланетные расы с людьми не контактировали, поэтому ГГ с игроком знают одинаково ничего и вынуждены собирать лор по останкам кораблей и контактам с выжившими после кораблекрушений. И, возможно, самой звезде есть что рассказать героям.
По-моему, нормальная, маленькая инди-игра...
Я думаю, противники делятся на два типа: те, кто выталкивает игрока с острова, на котором игроку необходимо собирать ресурсы, и те, кто опасен для построенного дирижабля. Атаковать самого игрока посреди пустого места - это уже перебор, и по лору, и геймплейно. Нужно давать время на передышку.
Просто нужен был какой-то способ преодолевать горизонтальные участки. Раньше я вообще не хотел реализовывать "глайдер", но потом решил, что, если сбалансировать, можно комбинировать с верёвкой. Верёвка для вертикального движения по острову, планирование для перехода между ближайшими островками внутри большого архипелага, ботинки позволяют делать рывки (нужно доработать), и дополнительно ещё хочу "ховерборд" для быстрого горизонтального перемещения по поверхностям (инструмент игрока способен к слабой левитации в непосредственной близости от тяжёлых объектов; недостаточно для полёта, но если оттолкнуться...).
Суммарно, геймплей про скорость и манёвренность, однако, причина спешки - не столько враги, сколько нестабильность островов и мобильной базы игрока, требующей регулярного обслуживания и ресурсов. Стрелялок в воздухе без цели и без меня много, а я пытаюсь реализовать то, что для себя не нашёл.
Спасибо. А почему сам такую игру не делаешь?
И мне кажется, или мой спидометр слишком много показывает? Забыл разделить на число кадров? Эти огромные метки в воздухе вроде бы на 100% точные. Тестовые острова генерируются кодом из CSG нод. Записываю уже третье видео с этой сценой...
>>3029
>если ты хотел бы всё отменить, то делай бекапы
Не в этом дело, я любые существенные изменения в моделях новым blend-файлом сохраняю. Просто демотивировался. Первая модель как-то неплохо заригалась с первой попытки, или это моя планка желаемого качества была существенно ниже...
>оставь на потом
>делай что попроще
>сделай пока так
>потом придумаешь
Когда "потом"? Что делать вместо этих вещей?
>тут надо не давать ломать блок и всё
Идея именно дирижаблей в том, что у тебя кроме собственно двигателей есть баллоны с газом, и без достаточного объёма газа всё рухнет, если ты не избавишься от лишней массы. Пример: дирижабль подвергается атаке где-то вдалеке от островов, и количество газа недостаточно, чтобы дотянуть до ближайшего острова целиком, поэтому игрок берёт и отрезает наименее важную часть, что позволяет добраться до острова и восполнить ресурсы. Также возможна ситуация, когда что-то построил, а потом оказалось, что с новыми ресурсами можно иначе. Постоянная переделка транспорта прям в процессе движения по воздуху - ключевая идея моей игры. Я настолько был недоволен "док-станциями" WA, что захотелось сделать свою собственную игру, лол.
>выглядит как кроссаут + спейс инженеры
Играл в обе. Crossout: ты строишь машину у себя в виртуальном гараже, а на поле боя можешь лишь постепенно разрушаться. Space Engineers: все блоки устанавливаются как пустые каркасы, потом долго заполняются сырыми ресурсами из инвентаря. Ещё переиграл во много подобных "vehicle builder" игр, достаточно популярный и разнообразный жанр. И конкретно TerraTech довольно уникальна... Или я недостаточно много индюшатины переиграл.
>механика "запаковки"
Знаю, но тут речь немного про другое. Суть в том, что хочется большие блоки-модули как в Subnautica или подобных ей "base builder" играх, но если не крафтить модули на нужном месте, а переносить, они слишком мешаются (на видео видно, почему), поэтому лучше визуально скукожить блок до ≈10% размера, чтоб не перекрывал собой обзор, а потом он расширяется в заданном игроком месте. Но чтоб стимулировать осмысленную сборку, блоки нельзя скапливать в виртуальном инвентаре, можно только выкинуть (уничтожить) или разобрать на запчасти/ресурсы.
Ещё есть идея, что ИИ-компаньоны игрока смогут перетаскивать блоки вместе с игроком. Так что чем больший дирижабль, тем больше компаньонов, что переносят больше блоков вместе с игроком. Вроде неплохо, если физический движок это выдержит...
>если не будет какой-то защиты - никто не любит когда игра просто ломает то, что игрок построил
Смотри: всё вокруг начинает искрить и трясти, резко затухает, а потом смотришь вверх - видишь горящие обломки, входящие в атмосферу с громким воем - и ругаешься на игру за то, что ты не уклонился? Имхо, подобного контента слишком мало в играх...
Это не корабли врезаются, а кольцо островов в них врезается. Не острова захвачены пришельцами, а пришельцы захвачены кольцом островов...
>найди ЛЮБУЮ и вставь
>у тебя уже есть стиль
Стиль - это когда есть какие-то внутренние правила, которым следует графика. Типа, если у тебя в игре у объектов обводка цветная - она везде цветная, если шейдинг плоский (cel/toon) - он везде плоский, и т.д. Накидать ассетов не проблема, проблема - выбрать конкретный стиль, который самому понравится. Ибо разрабатывать игру, на которую самому не хочется ежедневно смотреть - хуже всего, как мне кажется.
>>2917
>учитывая что в мире существуют гарпии
>стрелять условным огненным лучем
Как второе следует из первого? "Гарпии" возможны в твёрдой фантастике как результат конвергентной эволюции или генетических экспериментов.
Но вообще, не факт, что будут гарпии. Т.к. компаньон является роботом, как и герой игрока. Не помню уже, описывал тут или нет, но вот вкратце: человечество освоило солнечную систему и дальше в космос не продвигается, развивая вместо этого всё более эффективную робототехнику; дошло до наномашин, способных принимать любой облик по программе; подобные роботы почти бессмертны, могут оказать сопротивление и опаснее, чем оружие массового поражения, поэтому роботов с дефектами мирно отправляют исследовать глубокий космос; "гарпия" создавалась как орнитологический дрон, но из-за дефективной программы принимает такой облик.
Способностей у этих роботов почти нет, их главные преимущества - это дешевизна, компактность и экстремальная выносливость. Облики не дают сил, поскольку меняют внешний вид, а не суть. Самый оптимальный внешний вид - гладкая сфера, но их программа требует поддерживать заданный облик; например, ГГ поддерживает человекоподобный вид только лишь для взаимодействия с людьми, даже несмотря на то, что в другом мире их вообще нет; аналогично, "носит одежду" только для приличия, поскольку технически на ней вообще нет одежды. Получается лорное обоснование для любых скинов, находимых и используемых игроком по желанию.
Если ещё короче: сверхпрочная программируемая наноплёнка в форме чего пожелаешь, которая из-за опасности высылается людьми куда подальше как исследовательский дрон; однажды капсула с этими роботами попала в уникальную систему с плотным воздушным кольцом вокруг звезды -> начало игры.
А если будут гарпии-инопланетяне, они будут либо нормальными животными-птицами, либо роботами, созданными расой гуманоидных птиц для себя. Инопланетные расы с людьми не контактировали, поэтому ГГ с игроком знают одинаково ничего и вынуждены собирать лор по останкам кораблей и контактам с выжившими после кораблекрушений. И, возможно, самой звезде есть что рассказать героям.
По-моему, нормальная, маленькая инди-игра...
>Всякие летающие противники
Я думаю, противники делятся на два типа: те, кто выталкивает игрока с острова, на котором игроку необходимо собирать ресурсы, и те, кто опасен для построенного дирижабля. Атаковать самого игрока посреди пустого места - это уже перебор, и по лору, и геймплейно. Нужно давать время на передышку.
>учитывая как ты реализовал полет на крыльях
Просто нужен был какой-то способ преодолевать горизонтальные участки. Раньше я вообще не хотел реализовывать "глайдер", но потом решил, что, если сбалансировать, можно комбинировать с верёвкой. Верёвка для вертикального движения по острову, планирование для перехода между ближайшими островками внутри большого архипелага, ботинки позволяют делать рывки (нужно доработать), и дополнительно ещё хочу "ховерборд" для быстрого горизонтального перемещения по поверхностям (инструмент игрока способен к слабой левитации в непосредственной близости от тяжёлых объектов; недостаточно для полёта, но если оттолкнуться...).
Суммарно, геймплей про скорость и манёвренность, однако, причина спешки - не столько враги, сколько нестабильность островов и мобильной базы игрока, требующей регулярного обслуживания и ресурсов. Стрелялок в воздухе без цели и без меня много, а я пытаюсь реализовать то, что для себя не нашёл.
>Блин круто, люблю такое. Давай тогда не сдавайся.
Спасибо. А почему сам такую игру не делаешь?
Вот ещё быстрый тест того, как масштаб локации взаимодействует с имеющимися механиками для движения... Я думаю, острова больше 100-150 м нерационально делать, если только 200+ м будут выглядеть как плоские блюдца. Давно уже думал о песчаных блюдцах с кактусами, где игроку вместо вертикальной нужна горизонтальная скорость. Да, кактусы - это то, что держит песок в воздухе, лол.
И мне кажется, или мой спидометр слишком много показывает? Забыл разделить на число кадров? Эти огромные метки в воздухе вроде бы на 100% точные. Тестовые острова генерируются кодом из CSG нод. Записываю уже третье видео с этой сценой...
>>3029
Не в этом дело, я любые существенные изменения в моделях новым blend-файлом сохраняю. Просто демотивировался. Первая модель как-то неплохо заригалась с первой попытки, или это моя планка желаемого качества была существенно ниже...
Когда "потом"? Что делать вместо этих вещей?
Идея именно дирижаблей в том, что у тебя кроме собственно двигателей есть баллоны с газом, и без достаточного объёма газа всё рухнет, если ты не избавишься от лишней массы. Пример: дирижабль подвергается атаке где-то вдалеке от островов, и количество газа недостаточно, чтобы дотянуть до ближайшего острова целиком, поэтому игрок берёт и отрезает наименее важную часть, что позволяет добраться до острова и восполнить ресурсы. Также возможна ситуация, когда что-то построил, а потом оказалось, что с новыми ресурсами можно иначе. Постоянная переделка транспорта прям в процессе движения по воздуху - ключевая идея моей игры. Я настолько был недоволен "док-станциями" WA, что захотелось сделать свою собственную игру, лол.
Играл в обе. Crossout: ты строишь машину у себя в виртуальном гараже, а на поле боя можешь лишь постепенно разрушаться. Space Engineers: все блоки устанавливаются как пустые каркасы, потом долго заполняются сырыми ресурсами из инвентаря. Ещё переиграл во много подобных "vehicle builder" игр, достаточно популярный и разнообразный жанр. И конкретно TerraTech довольно уникальна... Или я недостаточно много индюшатины переиграл.
Знаю, но тут речь немного про другое. Суть в том, что хочется большие блоки-модули как в Subnautica или подобных ей "base builder" играх, но если не крафтить модули на нужном месте, а переносить, они слишком мешаются (на видео видно, почему), поэтому лучше визуально скукожить блок до ≈10% размера, чтоб не перекрывал собой обзор, а потом он расширяется в заданном игроком месте. Но чтоб стимулировать осмысленную сборку, блоки нельзя скапливать в виртуальном инвентаре, можно только выкинуть (уничтожить) или разобрать на запчасти/ресурсы.
Ещё есть идея, что ИИ-компаньоны игрока смогут перетаскивать блоки вместе с игроком. Так что чем больший дирижабль, тем больше компаньонов, что переносят больше блоков вместе с игроком. Вроде неплохо, если физический движок это выдержит...
Смотри: всё вокруг начинает искрить и трясти, резко затухает, а потом смотришь вверх - видишь горящие обломки, входящие в атмосферу с громким воем - и ругаешься на игру за то, что ты не уклонился? Имхо, подобного контента слишком мало в играх...
Это не корабли врезаются, а кольцо островов в них врезается. Не острова захвачены пришельцами, а пришельцы захвачены кольцом островов...
Стиль - это когда есть какие-то внутренние правила, которым следует графика. Типа, если у тебя в игре у объектов обводка цветная - она везде цветная, если шейдинг плоский (cel/toon) - он везде плоский, и т.д. Накидать ассетов не проблема, проблема - выбрать конкретный стиль, который самому понравится. Ибо разрабатывать игру, на которую самому не хочется ежедневно смотреть - хуже всего, как мне кажется.
>>2917
Как второе следует из первого? "Гарпии" возможны в твёрдой фантастике как результат конвергентной эволюции или генетических экспериментов.
Но вообще, не факт, что будут гарпии. Т.к. компаньон является роботом, как и герой игрока. Не помню уже, описывал тут или нет, но вот вкратце: человечество освоило солнечную систему и дальше в космос не продвигается, развивая вместо этого всё более эффективную робототехнику; дошло до наномашин, способных принимать любой облик по программе; подобные роботы почти бессмертны, могут оказать сопротивление и опаснее, чем оружие массового поражения, поэтому роботов с дефектами мирно отправляют исследовать глубокий космос; "гарпия" создавалась как орнитологический дрон, но из-за дефективной программы принимает такой облик.
Способностей у этих роботов почти нет, их главные преимущества - это дешевизна, компактность и экстремальная выносливость. Облики не дают сил, поскольку меняют внешний вид, а не суть. Самый оптимальный внешний вид - гладкая сфера, но их программа требует поддерживать заданный облик; например, ГГ поддерживает человекоподобный вид только лишь для взаимодействия с людьми, даже несмотря на то, что в другом мире их вообще нет; аналогично, "носит одежду" только для приличия, поскольку технически на ней вообще нет одежды. Получается лорное обоснование для любых скинов, находимых и используемых игроком по желанию.
Если ещё короче: сверхпрочная программируемая наноплёнка в форме чего пожелаешь, которая из-за опасности высылается людьми куда подальше как исследовательский дрон; однажды капсула с этими роботами попала в уникальную систему с плотным воздушным кольцом вокруг звезды -> начало игры.
А если будут гарпии-инопланетяне, они будут либо нормальными животными-птицами, либо роботами, созданными расой гуманоидных птиц для себя. Инопланетные расы с людьми не контактировали, поэтому ГГ с игроком знают одинаково ничего и вынуждены собирать лор по останкам кораблей и контактам с выжившими после кораблекрушений. И, возможно, самой звезде есть что рассказать героям.
По-моему, нормальная, маленькая инди-игра...
Я думаю, противники делятся на два типа: те, кто выталкивает игрока с острова, на котором игроку необходимо собирать ресурсы, и те, кто опасен для построенного дирижабля. Атаковать самого игрока посреди пустого места - это уже перебор, и по лору, и геймплейно. Нужно давать время на передышку.
Просто нужен был какой-то способ преодолевать горизонтальные участки. Раньше я вообще не хотел реализовывать "глайдер", но потом решил, что, если сбалансировать, можно комбинировать с верёвкой. Верёвка для вертикального движения по острову, планирование для перехода между ближайшими островками внутри большого архипелага, ботинки позволяют делать рывки (нужно доработать), и дополнительно ещё хочу "ховерборд" для быстрого горизонтального перемещения по поверхностям (инструмент игрока способен к слабой левитации в непосредственной близости от тяжёлых объектов; недостаточно для полёта, но если оттолкнуться...).
Суммарно, геймплей про скорость и манёвренность, однако, причина спешки - не столько враги, сколько нестабильность островов и мобильной базы игрока, требующей регулярного обслуживания и ресурсов. Стрелялок в воздухе без цели и без меня много, а я пытаюсь реализовать то, что для себя не нашёл.
Спасибо. А почему сам такую игру не делаешь?
И мне кажется, или мой спидометр слишком много показывает? Забыл разделить на число кадров? Эти огромные метки в воздухе вроде бы на 100% точные. Тестовые острова генерируются кодом из CSG нод. Записываю уже третье видео с этой сценой...
>>3029
>если ты хотел бы всё отменить, то делай бекапы
Не в этом дело, я любые существенные изменения в моделях новым blend-файлом сохраняю. Просто демотивировался. Первая модель как-то неплохо заригалась с первой попытки, или это моя планка желаемого качества была существенно ниже...
>оставь на потом
>делай что попроще
>сделай пока так
>потом придумаешь
Когда "потом"? Что делать вместо этих вещей?
>тут надо не давать ломать блок и всё
Идея именно дирижаблей в том, что у тебя кроме собственно двигателей есть баллоны с газом, и без достаточного объёма газа всё рухнет, если ты не избавишься от лишней массы. Пример: дирижабль подвергается атаке где-то вдалеке от островов, и количество газа недостаточно, чтобы дотянуть до ближайшего острова целиком, поэтому игрок берёт и отрезает наименее важную часть, что позволяет добраться до острова и восполнить ресурсы. Также возможна ситуация, когда что-то построил, а потом оказалось, что с новыми ресурсами можно иначе. Постоянная переделка транспорта прям в процессе движения по воздуху - ключевая идея моей игры. Я настолько был недоволен "док-станциями" WA, что захотелось сделать свою собственную игру, лол.
>выглядит как кроссаут + спейс инженеры
Играл в обе. Crossout: ты строишь машину у себя в виртуальном гараже, а на поле боя можешь лишь постепенно разрушаться. Space Engineers: все блоки устанавливаются как пустые каркасы, потом долго заполняются сырыми ресурсами из инвентаря. Ещё переиграл во много подобных "vehicle builder" игр, достаточно популярный и разнообразный жанр. И конкретно TerraTech довольно уникальна... Или я недостаточно много индюшатины переиграл.
>механика "запаковки"
Знаю, но тут речь немного про другое. Суть в том, что хочется большие блоки-модули как в Subnautica или подобных ей "base builder" играх, но если не крафтить модули на нужном месте, а переносить, они слишком мешаются (на видео видно, почему), поэтому лучше визуально скукожить блок до ≈10% размера, чтоб не перекрывал собой обзор, а потом он расширяется в заданном игроком месте. Но чтоб стимулировать осмысленную сборку, блоки нельзя скапливать в виртуальном инвентаре, можно только выкинуть (уничтожить) или разобрать на запчасти/ресурсы.
Ещё есть идея, что ИИ-компаньоны игрока смогут перетаскивать блоки вместе с игроком. Так что чем больший дирижабль, тем больше компаньонов, что переносят больше блоков вместе с игроком. Вроде неплохо, если физический движок это выдержит...
>если не будет какой-то защиты - никто не любит когда игра просто ломает то, что игрок построил
Смотри: всё вокруг начинает искрить и трясти, резко затухает, а потом смотришь вверх - видишь горящие обломки, входящие в атмосферу с громким воем - и ругаешься на игру за то, что ты не уклонился? Имхо, подобного контента слишком мало в играх...
Это не корабли врезаются, а кольцо островов в них врезается. Не острова захвачены пришельцами, а пришельцы захвачены кольцом островов...
>найди ЛЮБУЮ и вставь
>у тебя уже есть стиль
Стиль - это когда есть какие-то внутренние правила, которым следует графика. Типа, если у тебя в игре у объектов обводка цветная - она везде цветная, если шейдинг плоский (cel/toon) - он везде плоский, и т.д. Накидать ассетов не проблема, проблема - выбрать конкретный стиль, который самому понравится. Ибо разрабатывать игру, на которую самому не хочется ежедневно смотреть - хуже всего, как мне кажется.
>>2917
>учитывая что в мире существуют гарпии
>стрелять условным огненным лучем
Как второе следует из первого? "Гарпии" возможны в твёрдой фантастике как результат конвергентной эволюции или генетических экспериментов.
Но вообще, не факт, что будут гарпии. Т.к. компаньон является роботом, как и герой игрока. Не помню уже, описывал тут или нет, но вот вкратце: человечество освоило солнечную систему и дальше в космос не продвигается, развивая вместо этого всё более эффективную робототехнику; дошло до наномашин, способных принимать любой облик по программе; подобные роботы почти бессмертны, могут оказать сопротивление и опаснее, чем оружие массового поражения, поэтому роботов с дефектами мирно отправляют исследовать глубокий космос; "гарпия" создавалась как орнитологический дрон, но из-за дефективной программы принимает такой облик.
Способностей у этих роботов почти нет, их главные преимущества - это дешевизна, компактность и экстремальная выносливость. Облики не дают сил, поскольку меняют внешний вид, а не суть. Самый оптимальный внешний вид - гладкая сфера, но их программа требует поддерживать заданный облик; например, ГГ поддерживает человекоподобный вид только лишь для взаимодействия с людьми, даже несмотря на то, что в другом мире их вообще нет; аналогично, "носит одежду" только для приличия, поскольку технически на ней вообще нет одежды. Получается лорное обоснование для любых скинов, находимых и используемых игроком по желанию.
Если ещё короче: сверхпрочная программируемая наноплёнка в форме чего пожелаешь, которая из-за опасности высылается людьми куда подальше как исследовательский дрон; однажды капсула с этими роботами попала в уникальную систему с плотным воздушным кольцом вокруг звезды -> начало игры.
А если будут гарпии-инопланетяне, они будут либо нормальными животными-птицами, либо роботами, созданными расой гуманоидных птиц для себя. Инопланетные расы с людьми не контактировали, поэтому ГГ с игроком знают одинаково ничего и вынуждены собирать лор по останкам кораблей и контактам с выжившими после кораблекрушений. И, возможно, самой звезде есть что рассказать героям.
По-моему, нормальная, маленькая инди-игра...
>Всякие летающие противники
Я думаю, противники делятся на два типа: те, кто выталкивает игрока с острова, на котором игроку необходимо собирать ресурсы, и те, кто опасен для построенного дирижабля. Атаковать самого игрока посреди пустого места - это уже перебор, и по лору, и геймплейно. Нужно давать время на передышку.
>учитывая как ты реализовал полет на крыльях
Просто нужен был какой-то способ преодолевать горизонтальные участки. Раньше я вообще не хотел реализовывать "глайдер", но потом решил, что, если сбалансировать, можно комбинировать с верёвкой. Верёвка для вертикального движения по острову, планирование для перехода между ближайшими островками внутри большого архипелага, ботинки позволяют делать рывки (нужно доработать), и дополнительно ещё хочу "ховерборд" для быстрого горизонтального перемещения по поверхностям (инструмент игрока способен к слабой левитации в непосредственной близости от тяжёлых объектов; недостаточно для полёта, но если оттолкнуться...).
Суммарно, геймплей про скорость и манёвренность, однако, причина спешки - не столько враги, сколько нестабильность островов и мобильной базы игрока, требующей регулярного обслуживания и ресурсов. Стрелялок в воздухе без цели и без меня много, а я пытаюсь реализовать то, что для себя не нашёл.
>Блин круто, люблю такое. Давай тогда не сдавайся.
Спасибо. А почему сам такую игру не делаешь?
27 Кб, 604x154>>3084
А в чем нестабильность выражается? Типа взорваться может или выстрелить чем-то? Я пока чего-то такого не помню из твоих видео. Мб этим стоит начать заняться? Считай способов перемещения у тебя и так полно, а корабль можно собирать.
Ну, цель наверное придумать можно, если необходимо будет.
пикрил
>Суммарно, геймплей про скорость и манёвренность, однако, причина спешки - не столько враги, сколько нестабильность островов и мобильной базы игрока
А в чем нестабильность выражается? Типа взорваться может или выстрелить чем-то? Я пока чего-то такого не помню из твоих видео. Мб этим стоит начать заняться? Считай способов перемещения у тебя и так полно, а корабль можно собирать.
>Стрелялок в воздухе без цели и без меня много
Ну, цель наверное придумать можно, если необходимо будет.
>А почему сам такую игру не делаешь?
пикрил
15,3 Мб, webm,1920x1080, 1:36
>>3084
22 м/с уже почти ураганный ветер, скорее мало
ты поймёшь
то, что не вызовет такие вопросы
тогда возвращаемся к первому, пока не паришься про это, хочет - отрезает, хочет - чинит, потом видно будет
хз, на мой взгляд нормально пока, может если бы я сам нажимал кнопки мне бы мешалось
в последних версиях добавили стенсил буффер, в теории ты можешь убрать блок на другой слой или в другие координаты, заменить его на меньший куб и проецировать на стороны куба визуал от блока, но я могу ошибаться что такое можно со всех сторон, надо исследовать тему
>или мой спидометр слишком много показывает
22 м/с уже почти ураганный ветер, скорее мало
>Когда "потом"?
ты поймёшь
>Что делать вместо этих вещей?
то, что не вызовет такие вопросы
>поэтому игрок берёт и отрезает наименее важную часть, что позволяет добраться до острова и восполнить ресурсы.
тогда возвращаемся к первому, пока не паришься про это, хочет - отрезает, хочет - чинит, потом видно будет
>они слишком мешаются (на видео видно, почему)
хз, на мой взгляд нормально пока, может если бы я сам нажимал кнопки мне бы мешалось
>Ещё есть идея, что ИИ-компаньоны игрока смогут перетаскивать блоки вместе с игроком. Так что чем больший дирижабль, тем больше компаньонов, что переносят больше блоков вместе с игроком. Вроде неплохо, если физический движок это выдержит...
в последних версиях добавили стенсил буффер, в теории ты можешь убрать блок на другой слой или в другие координаты, заменить его на меньший куб и проецировать на стороны куба визуал от блока, но я могу ошибаться что такое можно со всех сторон, надо исследовать тему
бля я с января уже вторую игру выпускаю, а тут одни и те же на манеже дрочат болванки.
вы выпускать игры планируете или только друг друга за хуй кусать?
вы выпускать игры планируете или только друг друга за хуй кусать?
>>3135
3 в ряд и я мог бы выпустить, но зачем?
3 в ряд и я мог бы выпустить, но зачем?
>>3135
Мне мою ещё года два делать.
Мне мою ещё года два делать.
>>3135
Маладца. А тут сидят сумрачные гении, их не понять.
Маладца. А тут сидят сумрачные гении, их не понять.
>>3135
Покажи игру, если не сложно
Покажи игру, если не сложно
>>3135
Отныне ты известен как скорострел
Отныне ты известен как скорострел
Слышал, что здесь самое теплое и дружелюбное комьюнити на всем дваче
Мне надоело быть single крестоблядью. Как и всем мне хочется общения, понимания, хочется быть своим в соеде таких же разработчиков. Поэтому я решил переписать свой проект с крестов и кастомного двигла на gdscript! Просьба поддержать меня, как нового члена комьюнити🤗🤗🤗
Мне надоело быть single крестоблядью. Как и всем мне хочется общения, понимания, хочется быть своим в соеде таких же разработчиков. Поэтому я решил переписать свой проект с крестов и кастомного двигла на gdscript! Просьба поддержать меня, как нового члена комьюнити🤗🤗🤗
>>3135
Покажи хоть успехи
Покажи хоть успехи
Экспортишь из годота модель в глтф, хочешь конвертнуть в обж через онлайн-конвертер - нужен квн, ведь все онлайн тулзы в блоке. Ок, конвертнул. Хочешь плагин в 3д редакторе поставить - нужен квн, ведь сдн редактора тоже внезапно в блоке. Хочешь залить на скетчфаб - нужен квн, ведь нутыпонел. Доки годота у меня кстати тоже в блоке. Геймдев, 2026 экспириенс.
>>3171
Беда такая есть. Доки Годота можно скачать для оффлайн использования, сам движок тоже автономен. Если совсем капут настанет, то хотя бы не останемся без инструмента
>онлайн-конвертер
>"геймдев"
Беда такая есть. Доки Годота можно скачать для оффлайн использования, сам движок тоже автономен. Если совсем капут настанет, то хотя бы не останемся без инструмента
>>3171
Это в какой стране у тебя такое? В РФ скетчфаб работает и сервисы блендера тоже, если у тебя 3дсмакс или майа, то скорее вопросы к ним, хотя судя по желанию конвертнуть в obj ты в какой нибудь Автокад солидворкс решил модель перекинуть
>Геймдев, 2026 экспириенс
Это в какой стране у тебя такое? В РФ скетчфаб работает и сервисы блендера тоже, если у тебя 3дсмакс или майа, то скорее вопросы к ним, хотя судя по желанию конвертнуть в obj ты в какой нибудь Автокад солидворкс решил модель перекинуть
>>3171
Зачем для этого онлайн конвертер? Есть блендер, есть аддоны для конвертации в обж
Ну вообще-то ассеты в старой библиотеке есть в исходниках, поэтому обычно их можно скачать с гитахаба и прочих.
Правда, каталога аддонов я не нашел. Спарсить его надо бы.
Доки есть в самом редакторе, а еще есть исходник сайта доков на гитхабе.
>>3181
Он хочет туда лить, может там какой то другой домен или cdn цепляет.
>Экспортишь из годота модель в глтф, хочешь конвертнуть в обж через онлайн-конвертер
Зачем для этого онлайн конвертер? Есть блендер, есть аддоны для конвертации в обж
>Хочешь плагин в 3д редакторе поставить - нужен квн, ведь сдн редактора тоже внезапно в блоке
Ну вообще-то ассеты в старой библиотеке есть в исходниках, поэтому обычно их можно скачать с гитахаба и прочих.
Правда, каталога аддонов я не нашел. Спарсить его надо бы.
> Доки годота у меня кстати тоже в блоке.
Доки есть в самом редакторе, а еще есть исходник сайта доков на гитхабе.
>>3181
> скетчфаб работает
Он хочет туда лить, может там какой то другой домен или cdn цепляет.
>>3171
Формат Wavefront .OBJ настолько примитивен, что наверняка сможешь написать собственный скрипт экспорта сцены в .OBJ где-то за 1 час на GDScript, и использовать прямо в Godot в качестве tool-скрипта. Главное иметь желание, а разобраться там нетрудно. Скетчфаб вообще непонятно зачем существует - там буквально помойка для воришек-ассетфлиперов, скачивающих платное бесплатно. Зачем тебе туда? Основная документация (API) прямо в Godot на F1. Стратегически необходимый оперсурс софт (Blender) обязательно будут проксировать через локальные сервисы, поэтому о них можно не беспокоиться, а васянские плагины никогда не были так уж нужны.
>>3165
В чём заключается твой проект? Какие механики? С некоторыми механиками лучше использовать C++, к примеру, если у тебя там воксельная разрушаемость, генерация мешей из отдельных вершин, огромное количество независимых юнитов (тысячи) и т.д. Теоретически, ты мог бы прикрепить свой C++ код в качестве модуля или GDExtension к Godot, а GDScript использовать для более высокоуровневой логики. Насколько это будет проблематично зависит от твоих навыков C++ и твоего конкретного кода...
>>3135
Когда-то фантазировал, как буду выпускать по новой игрушке в день, по 7 игр за неделю и т.д. Но потом я осознал, что меня не привлекает публикация столь примитивных игр - больше привлекает разработка единственной игры на протяжении десятилетий.
>>3103
Графика выглядит неплохо, но анимации ГГ ужасно выделяются на её фоне. Если б это была лоуполи индюшатинка, то анимации не казались бы столь нелепыми... Но он косит под реализм. Хуже этого - оформление трейлера совсем неправильное, 12 сек логотипов НОУНЕЙМОВ вместо игры, потом ОЧЕНЬ медленная, нудная, ненужная демонстрация весьма банальных локаций. 99% игроков закроют видео, не досмотрев до того, что их может заинтересовать. Ну, хорошо, что озвучил, но нужно рассчитывать, что большинство посмотрят совсем без звука, и не в кинотеатре, так что ты не кинотрейлер снимаешь. По самой игре видно, что она дико вторична, у меня уже дежавю от этих "что-то не так в заброшке, мне нужно залезть туда, я там застряну и буду бояться бабайку". Демонстрация возможностей Godot тоже никакая - с первого взгляда кажется, что игра начала нулевых (несмотря на достаточно хорошую графику). В общем, непонятно, почему ты принёс сюда именно эту игру.
Формат Wavefront .OBJ настолько примитивен, что наверняка сможешь написать собственный скрипт экспорта сцены в .OBJ где-то за 1 час на GDScript, и использовать прямо в Godot в качестве tool-скрипта. Главное иметь желание, а разобраться там нетрудно. Скетчфаб вообще непонятно зачем существует - там буквально помойка для воришек-ассетфлиперов, скачивающих платное бесплатно. Зачем тебе туда? Основная документация (API) прямо в Godot на F1. Стратегически необходимый оперсурс софт (Blender) обязательно будут проксировать через локальные сервисы, поэтому о них можно не беспокоиться, а васянские плагины никогда не были так уж нужны.
>>3165
В чём заключается твой проект? Какие механики? С некоторыми механиками лучше использовать C++, к примеру, если у тебя там воксельная разрушаемость, генерация мешей из отдельных вершин, огромное количество независимых юнитов (тысячи) и т.д. Теоретически, ты мог бы прикрепить свой C++ код в качестве модуля или GDExtension к Godot, а GDScript использовать для более высокоуровневой логики. Насколько это будет проблематично зависит от твоих навыков C++ и твоего конкретного кода...
>>3135
Когда-то фантазировал, как буду выпускать по новой игрушке в день, по 7 игр за неделю и т.д. Но потом я осознал, что меня не привлекает публикация столь примитивных игр - больше привлекает разработка единственной игры на протяжении десятилетий.
>>3103
Графика выглядит неплохо, но анимации ГГ ужасно выделяются на её фоне. Если б это была лоуполи индюшатинка, то анимации не казались бы столь нелепыми... Но он косит под реализм. Хуже этого - оформление трейлера совсем неправильное, 12 сек логотипов НОУНЕЙМОВ вместо игры, потом ОЧЕНЬ медленная, нудная, ненужная демонстрация весьма банальных локаций. 99% игроков закроют видео, не досмотрев до того, что их может заинтересовать. Ну, хорошо, что озвучил, но нужно рассчитывать, что большинство посмотрят совсем без звука, и не в кинотеатре, так что ты не кинотрейлер снимаешь. По самой игре видно, что она дико вторична, у меня уже дежавю от этих "что-то не так в заброшке, мне нужно залезть туда, я там застряну и буду бояться бабайку". Демонстрация возможностей Godot тоже никакая - с первого взгляда кажется, что игра начала нулевых (несмотря на достаточно хорошую графику). В общем, непонятно, почему ты принёс сюда именно эту игру.
>>3171
Формат Wavefront .OBJ настолько примитивен, что наверняка сможешь написать собственный скрипт экспорта сцены в .OBJ где-то за 1 час на GDScript, и использовать прямо в Godot в качестве tool-скрипта. Главное иметь желание, а разобраться там нетрудно. Скетчфаб вообще непонятно зачем существует - там буквально помойка для воришек-ассетфлиперов, скачивающих платное бесплатно. Зачем тебе туда? Основная документация (API) прямо в Godot на F1. Стратегически необходимый оперсурс софт (Blender) обязательно будут проксировать через локальные сервисы, поэтому о них можно не беспокоиться, а васянские плагины никогда не были так уж нужны.
>>3165
В чём заключается твой проект? Какие механики? С некоторыми механиками лучше использовать C++, к примеру, если у тебя там воксельная разрушаемость, генерация мешей из отдельных вершин, огромное количество независимых юнитов (тысячи) и т.д. Теоретически, ты мог бы прикрепить свой C++ код в качестве модуля или GDExtension к Godot, а GDScript использовать для более высокоуровневой логики. Насколько это будет проблематично зависит от твоих навыков C++ и твоего конкретного кода...
>>3135
Когда-то фантазировал, как буду выпускать по новой игрушке в день, по 7 игр за неделю и т.д. Но потом я осознал, что меня не привлекает публикация столь примитивных игр - больше привлекает разработка единственной игры на протяжении десятилетий.
>>3103
Графика выглядит неплохо, но анимации ГГ ужасно выделяются на её фоне. Если б это была лоуполи индюшатинка, то анимации не казались бы столь нелепыми... Но он косит под реализм. Хуже этого - оформление трейлера совсем неправильное, 12 сек логотипов НОУНЕЙМОВ вместо игры, потом ОЧЕНЬ медленная, нудная, ненужная демонстрация весьма банальных локаций. 99% игроков закроют видео, не досмотрев до того, что их может заинтересовать. Ну, хорошо, что озвучил, но нужно рассчитывать, что большинство посмотрят совсем без звука, и не в кинотеатре, так что ты не кинотрейлер снимаешь. По самой игре видно, что она дико вторична, у меня уже дежавю от этих "что-то не так в заброшке, мне нужно залезть туда, я там застряну и буду бояться бабайку". Демонстрация возможностей Godot тоже никакая - с первого взгляда кажется, что игра начала нулевых (несмотря на достаточно хорошую графику). В общем, непонятно, почему ты принёс сюда именно эту игру.
Формат Wavefront .OBJ настолько примитивен, что наверняка сможешь написать собственный скрипт экспорта сцены в .OBJ где-то за 1 час на GDScript, и использовать прямо в Godot в качестве tool-скрипта. Главное иметь желание, а разобраться там нетрудно. Скетчфаб вообще непонятно зачем существует - там буквально помойка для воришек-ассетфлиперов, скачивающих платное бесплатно. Зачем тебе туда? Основная документация (API) прямо в Godot на F1. Стратегически необходимый оперсурс софт (Blender) обязательно будут проксировать через локальные сервисы, поэтому о них можно не беспокоиться, а васянские плагины никогда не были так уж нужны.
>>3165
В чём заключается твой проект? Какие механики? С некоторыми механиками лучше использовать C++, к примеру, если у тебя там воксельная разрушаемость, генерация мешей из отдельных вершин, огромное количество независимых юнитов (тысячи) и т.д. Теоретически, ты мог бы прикрепить свой C++ код в качестве модуля или GDExtension к Godot, а GDScript использовать для более высокоуровневой логики. Насколько это будет проблематично зависит от твоих навыков C++ и твоего конкретного кода...
>>3135
Когда-то фантазировал, как буду выпускать по новой игрушке в день, по 7 игр за неделю и т.д. Но потом я осознал, что меня не привлекает публикация столь примитивных игр - больше привлекает разработка единственной игры на протяжении десятилетий.
>>3103
Графика выглядит неплохо, но анимации ГГ ужасно выделяются на её фоне. Если б это была лоуполи индюшатинка, то анимации не казались бы столь нелепыми... Но он косит под реализм. Хуже этого - оформление трейлера совсем неправильное, 12 сек логотипов НОУНЕЙМОВ вместо игры, потом ОЧЕНЬ медленная, нудная, ненужная демонстрация весьма банальных локаций. 99% игроков закроют видео, не досмотрев до того, что их может заинтересовать. Ну, хорошо, что озвучил, но нужно рассчитывать, что большинство посмотрят совсем без звука, и не в кинотеатре, так что ты не кинотрейлер снимаешь. По самой игре видно, что она дико вторична, у меня уже дежавю от этих "что-то не так в заброшке, мне нужно залезть туда, я там застряну и буду бояться бабайку". Демонстрация возможностей Godot тоже никакая - с первого взгляда кажется, что игра начала нулевых (несмотря на достаточно хорошую графику). В общем, непонятно, почему ты принёс сюда именно эту игру.
>>3291
Я считаю, что хорошая графика, хоть и нулевых, сделанная соло - это демонстрация возможностей Godot 3. Ничего особо лучше я и не встречал, так что это вполне уровень, на который гдачер может ориентироваться.
>Демонстрация возможностей Godot тоже никакая - с первого взгляда кажется, что игра начала нулевых (несмотря на достаточно хорошую графику)
Я считаю, что хорошая графика, хоть и нулевых, сделанная соло - это демонстрация возможностей Godot 3. Ничего особо лучше я и не встречал, так что это вполне уровень, на который гдачер может ориентироваться.
>>3291
А ты бы не боялся бабайку? Смелый дохуя, ммм? Вот тебя бы на мой скотомогильник в деревне! Там, говорят, не только скот похоронен.
дарю сюжет для хоррора тысячелетия, я чел-идея
>у меня уже дежавю от этих "что-то не так в заброшке, мне нужно залезть туда, я там застряну и буду бояться бабайку
А ты бы не боялся бабайку? Смелый дохуя, ммм? Вот тебя бы на мой скотомогильник в деревне! Там, говорят, не только скот похоронен.
дарю сюжет для хоррора тысячелетия, я чел-идея
Кто-то пробовал? Как оно? https://gdstudio.dev/
>>3437
А нафига? У тебя 4K дисплей? Или 4 дисплея?
Имхо, редактор Godot позволяет фокусироваться. Совершенно нет необходимости одновременно просматривать несколько сцен, 2D/3D, код и т.д. И переключение между сценами быстрое, если ты правильно организуешь свои сцены (а не суешь несколько тысяч нод в одну сцену одновременно). Технически, мне кажется, можно открыть сразу несколько Godot Editor параллельно (но я сам не пробовал, если пробовали - скажите, работает?). Из коробки Godot поддерживает разделение 3D экрана, отделение окна с кодом в плавающее окно и т.д. Всё остальное было бы избыточно для 99.99% юзеров...
Тем более, что этот сам признаётся:
Наговнокодил/навайбкодил и скрывает это. И ещё наверняка какие-нибудь жучки встроил. Все эти оправдания про деньги не стоят ломанного гроша - большинство опенсурсных проектов без бюджета. Использовать такой бесплатный софт себе дороже.
А если вдруг там что-то реально годное, то он потом наверняка ценник/подписку налепит, и ты с этим не сделаешь ничего, потому что исходников-то нет.
А нафига? У тебя 4K дисплей? Или 4 дисплея?
Имхо, редактор Godot позволяет фокусироваться. Совершенно нет необходимости одновременно просматривать несколько сцен, 2D/3D, код и т.д. И переключение между сценами быстрое, если ты правильно организуешь свои сцены (а не суешь несколько тысяч нод в одну сцену одновременно). Технически, мне кажется, можно открыть сразу несколько Godot Editor параллельно (но я сам не пробовал, если пробовали - скажите, работает?). Из коробки Godot поддерживает разделение 3D экрана, отделение окна с кодом в плавающее окно и т.д. Всё остальное было бы избыточно для 99.99% юзеров...
Тем более, что этот сам признаётся:
>Why not open source?
>I feel most comfortable working this way. I don't have the means, monetary and otherwise, to maintain a public project. Keeping it closed lets me move fast and follow the direction I have in mind.
Наговнокодил/навайбкодил и скрывает это. И ещё наверняка какие-нибудь жучки встроил. Все эти оправдания про деньги не стоят ломанного гроша - большинство опенсурсных проектов без бюджета. Использовать такой бесплатный софт себе дороже.
А если вдруг там что-то реально годное, то он потом наверняка ценник/подписку налепит, и ты с этим не сделаешь ничего, потому что исходников-то нет.
151 Кб, 713x311>>3437
Хотел спросить можно ли так, потом вспомнил что годот под МИТ, а не под гплом. Можно
Хотел спросить можно ли так, потом вспомнил что годот под МИТ, а не под гплом. Можно
>>3448
Можно, но не нужно. Зачем юзерам платная васянка, отстающая от основной бесплатной версии? Зачем корпорации тратить свои человекочасы на мод для бесплатного ПО, когда они могут взять готовое и не модифицировать ничего? Так что такие проекты как правило не появляются или появляются и обмякают. Некоторые, впрочем, возвращаются в опенсурс (ибо осознали тщетность бытия и забросили свою ветку).
Можно, но не нужно. Зачем юзерам платная васянка, отстающая от основной бесплатной версии? Зачем корпорации тратить свои человекочасы на мод для бесплатного ПО, когда они могут взять готовое и не модифицировать ничего? Так что такие проекты как правило не появляются или появляются и обмякают. Некоторые, впрочем, возвращаются в опенсурс (ибо осознали тщетность бытия и забросили свою ветку).
>>3450
rpg in a box еще с тройки шевелится, вполне успешный коммерческий форк годота. Автор даже в годот профиты донатит.
rpg in a box еще с тройки шевелится, вполне успешный коммерческий форк годота. Автор даже в годот профиты донатит.
>>3452
Я бы не назвал это форком... Насколько я помню, это ограниченный конструктор игр. Такого рода проекты намного ближе к песочнице типа Minecraft, чем к полноценному игровому движку. Т.е. он для узкой аудитории, как какая-нибудь игра-симулятор.
А "платный форк" - это когда нескучные обои делают.
>rpg in a box
>форк годота
Я бы не назвал это форком... Насколько я помню, это ограниченный конструктор игр. Такого рода проекты намного ближе к песочнице типа Minecraft, чем к полноценному игровому движку. Т.е. он для узкой аудитории, как какая-нибудь игра-симулятор.
А "платный форк" - это когда нескучные обои делают.
>>3437
Так места на экране только меньше становится, не? У него же в обоих окнах панельки инспекторов.
Ну и
Пропущу, пожалуй.
Так места на экране только меньше становится, не? У него же в обоих окнах панельки инспекторов.
Ну и
>windows only
>closed source
>C#
Пропущу, пожалуй.
Как же хочеца игрульку с пс1 графикой запилить. Так много прошю? Можно ли на годоте, чтобы прям wiggly graphics было?
>>3470
Есть разница между "в стиле PS1" и "прямо как PS1". Стилизацию PS1 можно достичь на любом движке, достаточно сделать модельки с текстурами, в этом технологии движка не важны совсем. Но прям как настоящая PS1 рендер не получится, т.к. какой-то специфической технологии тех времён больше не существует физически и эмулировать сложно. Т.е. идеальную репродукцию PS1 графики может лишь полноценный эмулятор PS1 дать... Как я понял.
Что ты хотел сказать? Не гуглится. Если ты про пикселизацию, то её можно сделать несколькими способами, но это будет не то же самое, что на PS1, поскольку причина такой пикселизации другая. Там, кажется, растеризация работала не так, как сегодня.
Как я понял, сегодня на 100% точно эмулировать все артефакты графики PS1 можно только софтварным растеризатором, а Godot работает с обыкновенными графикческими API, как и все современные движки.
>Можно ли на годоте
>игрульку с пс1 графикой
Есть разница между "в стиле PS1" и "прямо как PS1". Стилизацию PS1 можно достичь на любом движке, достаточно сделать модельки с текстурами, в этом технологии движка не важны совсем. Но прям как настоящая PS1 рендер не получится, т.к. какой-то специфической технологии тех времён больше не существует физически и эмулировать сложно. Т.е. идеальную репродукцию PS1 графики может лишь полноценный эмулятор PS1 дать... Как я понял.
>чтобы прям wiggly graphics было
Что ты хотел сказать? Не гуглится. Если ты про пикселизацию, то её можно сделать несколькими способами, но это будет не то же самое, что на PS1, поскольку причина такой пикселизации другая. Там, кажется, растеризация работала не так, как сегодня.
Как я понял, сегодня на 100% точно эмулировать все артефакты графики PS1 можно только софтварным растеризатором, а Godot работает с обыкновенными графикческими API, как и все современные движки.
>>3470
Народ пилит, так что и ты пили
https://store.steampowered.com/app/2005870/House_of_Necrosis/
https://store.steampowered.com/app/2537470/Vultures__Scavengers_of_Death/
https://store.steampowered.com/app/2248150/Gunmetal_Gothic/
дергающиеся модельки имитируешь шейдерами типа
https://godotshaders.com/shader/affine-effect-shader/
Народ пилит, так что и ты пили
https://store.steampowered.com/app/2005870/House_of_Necrosis/
https://store.steampowered.com/app/2537470/Vultures__Scavengers_of_Death/
https://store.steampowered.com/app/2248150/Gunmetal_Gothic/
дергающиеся модельки имитируешь шейдерами типа
https://godotshaders.com/shader/affine-effect-shader/
>>3482
Jittering effect. Оказывается, есть видос на эту тему двухгодичной давности
https://youtu.be/Yt15YJqYf8o
Jittering effect. Оказывается, есть видос на эту тему двухгодичной давности
https://youtu.be/Yt15YJqYf8o
>>3486
О, классно. Даже уже игори есть
О, классно. Даже уже игори есть
902 Кб, 1920x1080>>2736
10 лет назад я в скайриме так летал, такая ностальгия, но тут ещё круче, трусики в синюю полосочку же, ня :3
А я всё равно буду ждать. Как Godot 5.
10 лет назад я в скайриме так летал, такая ностальгия, но тут ещё круче, трусики в синюю полосочку же, ня :3
> Нигде.
А я всё равно буду ждать. Как Godot 5.
Как так получается, что кто-то вишлистит пик и играет больше часа в демо? Чел даже про y-sort не в курсах. То ли тут лотерея, то ли я зашизился, потому что иногда смотришь разбор полетов, и казалось бы качественно сделанная игра вообще никому оказалась не нужна.
Позволяет ли его результат предположить что если, например, местная летающая жируха в синих панцу пройдет аналогичный пиар-путь в стиме, у нее будет х10 вишлистов? Ну так оцениваю ее, субъективно, да.
Позволяет ли его результат предположить что если, например, местная летающая жируха в синих панцу пройдет аналогичный пиар-путь в стиме, у нее будет х10 вишлистов? Ну так оцениваю ее, субъективно, да.
>>3501
В игре важно не качество (кода? систем? текстур?) а игровой кайф, по английски fun. Если игрок не ловит кайф, он выключает и идёт дальше. И плевать какие у тебя там качественные стуктуры.
> и казалось бы качественно сделанная игра вообще никому оказалась не нужна
В игре важно не качество (кода? систем? текстур?) а игровой кайф, по английски fun. Если игрок не ловит кайф, он выключает и идёт дальше. И плевать какие у тебя там качественные стуктуры.
>>2274 (OP)
Годоты, поясните пж за редот форк, это что-то серьёзное, кто-то на нём сидит, или это была просто истерика, которая уже сдулась, и на это не надо даже внимания обращать?
Годоты, поясните пж за редот форк, это что-то серьёзное, кто-то на нём сидит, или это была просто истерика, которая уже сдулась, и на это не надо даже внимания обращать?
>>3512
Сходи на гитхаб да посмотри. TL;DR там было полторы калеки, они разосрались и разбежались, теперь редот отстает на несколько версий и не осиливает даже бекпортить коммиты из годота, не то что свое что-то делать. Раздувают эту хуергу только истерички-безыгорники вроде местных додиксов из движкосрач-загона.
Сходи на гитхаб да посмотри. TL;DR там было полторы калеки, они разосрались и разбежались, теперь редот отстает на несколько версий и не осиливает даже бекпортить коммиты из годота, не то что свое что-то делать. Раздувают эту хуергу только истерички-безыгорники вроде местных додиксов из движкосрач-загона.
>>3513
Понял, благодарю.
Понял, благодарю.
416 Кб, 1408x768>>3512
Блазию хочу!
Блазию хочу!
Добрвый вечер господа я тот самый анон который пилил кки на годоте, теперь хочу сделать новую версию с прицелом на онлайн, для тестов подойдет же обычный локал хост? для прод версии только впс нужно будет купить?
>>3529
Подойдет, даже есть аддоны которые запускают кнопкой play твою игру несколько окон с разными параметрами.
Вообще, по сети есть три стула.
Первый, это как ты говоришь запустить на впс реальный сервер написанный на годоте. Вообще, если извратиться, можно и не покупая где-то его запустить. Я запускал на repl.it когда-то давно.
Второй - это писать сервер не на годоте, а на каком-то обычном для веба языке. А на годоте писать клиент, который будет http-запросами с ним общаться. Почему так? Потому что особо не известно, как у годота по сетевой безопасности, и не ломанут ли сервер на нем. (Ну и вообще говоря, обычно кроме игрового сервера все равно есть второй сервер для логинов-аккаунтов).
Третий - делать peer to peer игру, когда один из игроков становится сервером. Тут, конечно, появляется риск, что он будет читерить. Зато, разрабу меньше программировать. Конечно, появляется задача как свести игроков, не вписывать же айпи как в 90-х. Тут может быть уже просто легковесный сервер-лобби, который просто коннектит зашедших желающих.
Подойдет, даже есть аддоны которые запускают кнопкой play твою игру несколько окон с разными параметрами.
Вообще, по сети есть три стула.
Первый, это как ты говоришь запустить на впс реальный сервер написанный на годоте. Вообще, если извратиться, можно и не покупая где-то его запустить. Я запускал на repl.it когда-то давно.
Второй - это писать сервер не на годоте, а на каком-то обычном для веба языке. А на годоте писать клиент, который будет http-запросами с ним общаться. Почему так? Потому что особо не известно, как у годота по сетевой безопасности, и не ломанут ли сервер на нем. (Ну и вообще говоря, обычно кроме игрового сервера все равно есть второй сервер для логинов-аккаунтов).
Третий - делать peer to peer игру, когда один из игроков становится сервером. Тут, конечно, появляется риск, что он будет читерить. Зато, разрабу меньше программировать. Конечно, появляется задача как свести игроков, не вписывать же айпи как в 90-х. Тут может быть уже просто легковесный сервер-лобби, который просто коннектит зашедших желающих.
>>3534
Лобби сервер для организации p2p сессий бесплатно предоставляется Стимом. Вероятно, другими платформами тоже
Лобби сервер для организации p2p сессий бесплатно предоставляется Стимом. Вероятно, другими платформами тоже
>>3501
А ты думал знаешь движок - успех?
Тут анон залетал и разбирал психологию игрока. Но его посты относили как оффтоп (и вроде тёрли). Так что вы заслуженно сидите в яме неведенья, делая игры, не понимая сути.
Автор как-будто сам не знает что хочет и хочет ли вообще делать игру. Как-будто он аутирует от скуки (создавать игру это тоже в какой-то степени игра).
>y-sort не в курсах.
А ты думал знаешь движок - успех?
Тут анон залетал и разбирал психологию игрока. Но его посты относили как оффтоп (и вроде тёрли). Так что вы заслуженно сидите в яме неведенья, делая игры, не понимая сути.
>Позволяет ли его результат предположить что если, например, местная летающая жируха в синих панцу
Автор как-будто сам не знает что хочет и хочет ли вообще делать игру. Как-будто он аутирует от скуки (создавать игру это тоже в какой-то степени игра).
>>3529
Да
Смотря какая нагрузка и как написан сервер-клиент.
Для нормальных условий и для ККИ в первое время хватит за глаза.
Если планируешь зарабатывать - p2p не вариант, только сервер.
>подойдет же обычный локал хост
Да
>для прод версии только впс нужно будет купить?
Смотря какая нагрузка и как написан сервер-клиент.
Для нормальных условий и для ККИ в первое время хватит за глаза.
Если планируешь зарабатывать - p2p не вариант, только сервер.
742 Кб, 1347x782делаю первую игру мне сказали эти гавно и ниче не получится
>>3555
Хуже - это нейроговно, без общего стиля, цели и идеи. Но если опыт получил то уже неплохо. Двигайся дальше.
Хуже - это нейроговно, без общего стиля, цели и идеи. Но если опыт получил то уже неплохо. Двигайся дальше.
>>3555
Это нормально. Ты же не думал, что с первой попытки сделаешь что-то невероятное? Делай небольшие прототипы, набивай руку, параллельно думай о том, какой должна выглядеть игра, в которую тебе самому хотелось бы играть.
Это нормально. Ты же не думал, что с первой попытки сделаешь что-то невероятное? Делай небольшие прототипы, набивай руку, параллельно думай о том, какой должна выглядеть игра, в которую тебе самому хотелось бы играть.
>>3557
В эту ловушку все попадают. Вот как щас возьмусь, то сразу шедевор сделаю. Все до меня лохи были, а я же не лох простой. Ничего что я до этого ничем по жизни не блистал, но вот в этом конкретном деле я буду хением..
мимо
В эту ловушку все попадают. Вот как щас возьмусь, то сразу шедевор сделаю. Все до меня лохи были, а я же не лох простой. Ничего что я до этого ничем по жизни не блистал, но вот в этом конкретном деле я буду хением..
мимо
>>3558
Тем забавнее наблюдать за этими гениями, никогда ничего не выпускавшим, но сидящим-пердящим над одним-единственным проектом по 10 лет.
Тем забавнее наблюдать за этими гениями, никогда ничего не выпускавшим, но сидящим-пердящим над одним-единственным проектом по 10 лет.
>>3576
А как надо было? Сделать десять никому не нужных недельных поделок?
Конечно, лучше делать шедевр 10 лет, который войдет в историю.
Но, тут надо еще и старательно продумать, про что делать.
Ключевой момент именно тут. Делать 10 лет никому не нужную фигню, или делать 10 лет мощный проект.
А как надо было? Сделать десять никому не нужных недельных поделок?
Конечно, лучше делать шедевр 10 лет, который войдет в историю.
Но, тут надо еще и старательно продумать, про что делать.
Ключевой момент именно тут. Делать 10 лет никому не нужную фигню, или делать 10 лет мощный проект.
>>3555
Фон убери - он сейчас только мешает. Геймплей по скриншоту не понять - что-то кроме автобоя есть?.. Интерфейс выглядит не очень, но для прототипа - нормально, потом переделаешь на что-то лучше. Постарайся отработать главные циклы геймплея до углубления в графику, интерфейс и прочие детали. Интересная игра интересна даже без графики.
>>3529
ККИ - это ведь что-то пошаговое? Очень медленную пошаговую игру можешь сделать хоть на PHP под бесплатный веб-хостинг, сохраняя статус игры в стандартной базе данных... или даже в .txt файлах. Поскольку игра пошаговая, особой разницы между локальным и удалённым сервером не будет. Просто поищи, как сделать сайт на PHP в Apache, например, поскольку разрица между веб-сайтом и пошаговой онлайн игрушкой не так велика (ты бы мог обойтись веб-сайтом без движка, делая всё с помощью AJAX).
Твоя главная проблема - это набор и удержание достаточного количества игроков. Если игроков нет, большинство новичков быстро забьют на игру. Т.е. необходимо заранее набирать желающих и потом запускаться с каким-то количеством игроков... или нагонять ботов, или делать интересный синглплеер.
Алсо, гайды по онлайну для экшн-игр можешь на 99% игнорировать, потому что их проблемы тебя вообще не касаются в большинстве случаев. Пошаговая игра способна существовать даже на базе email сервиса...
Если всё-таки метишь в Steam и хочешь P2P, тогда документацию Steamworks почитай - там есть инфа, позволяющая использовать их сервис даже без собственного ключа. Особая игра "Spacewar" даёт возможность играть онлайн даже с пиратских игр (увидите в стиме у кого-то десятки часов в Spacewar - возможно, это разработчик онлайн-игры, но чаще - пиратствующий игрок, игравший сервере пиратов).
Фон убери - он сейчас только мешает. Геймплей по скриншоту не понять - что-то кроме автобоя есть?.. Интерфейс выглядит не очень, но для прототипа - нормально, потом переделаешь на что-то лучше. Постарайся отработать главные циклы геймплея до углубления в графику, интерфейс и прочие детали. Интересная игра интересна даже без графики.
>>3529
>версию с прицелом на онлайн
ККИ - это ведь что-то пошаговое? Очень медленную пошаговую игру можешь сделать хоть на PHP под бесплатный веб-хостинг, сохраняя статус игры в стандартной базе данных... или даже в .txt файлах. Поскольку игра пошаговая, особой разницы между локальным и удалённым сервером не будет. Просто поищи, как сделать сайт на PHP в Apache, например, поскольку разрица между веб-сайтом и пошаговой онлайн игрушкой не так велика (ты бы мог обойтись веб-сайтом без движка, делая всё с помощью AJAX).
Твоя главная проблема - это набор и удержание достаточного количества игроков. Если игроков нет, большинство новичков быстро забьют на игру. Т.е. необходимо заранее набирать желающих и потом запускаться с каким-то количеством игроков... или нагонять ботов, или делать интересный синглплеер.
Алсо, гайды по онлайну для экшн-игр можешь на 99% игнорировать, потому что их проблемы тебя вообще не касаются в большинстве случаев. Пошаговая игра способна существовать даже на базе email сервиса...
Если всё-таки метишь в Steam и хочешь P2P, тогда документацию Steamworks почитай - там есть инфа, позволяющая использовать их сервис даже без собственного ключа. Особая игра "Spacewar" даёт возможность играть онлайн даже с пиратских игр (увидите в стиме у кого-то десятки часов в Spacewar - возможно, это разработчик онлайн-игры, но чаще - пиратствующий игрок, игравший сервере пиратов).
>>3583
Только это значит, что бизнес-логику игры придется писать на PHP. Представляешь, какой ад будет, какой-нибудь модификатор 1.3х урона применить, если на столе выложена такая-то карта.
Я в своей игре логику в с++ модуле написал, чтобы переиспользовать отдельно
> пошаговую игру можешь сделать хоть на PHP
Только это значит, что бизнес-логику игры придется писать на PHP. Представляешь, какой ад будет, какой-нибудь модификатор 1.3х урона применить, если на столе выложена такая-то карта.
Я в своей игре логику в с++ модуле написал, чтобы переиспользовать отдельно
>>3583
фон и портреты чисто заглушки за 10 минут сделаные, статы персов в отдельный UI уедут, эт прост что бы общий посыл видеть а то на пустой серой сцене как то угрюмо
пока простой автобой с системой повреждения органов
в раунде каждому бойцу выдаетсся экипировка с уникальными эффектами: рандомный меч, броня, амулет и в течении боя они калечат друг друга кому ногу кому печень продыврявит.
так же внутри битвы случайная стихия выдается а внутри каждой стихии случайные заклинания под тип стихии со своими бонусами
Это из того что реализовано
фон и портреты чисто заглушки за 10 минут сделаные, статы персов в отдельный UI уедут, эт прост что бы общий посыл видеть а то на пустой серой сцене как то угрюмо
пока простой автобой с системой повреждения органов
в раунде каждому бойцу выдаетсся экипировка с уникальными эффектами: рандомный меч, броня, амулет и в течении боя они калечат друг друга кому ногу кому печень продыврявит.
так же внутри битвы случайная стихия выдается а внутри каждой стихии случайные заклинания под тип стихии со своими бонусами
Это из того что реализовано
>>3558
Таланты всё-таки существуют. Пока большинство просматривают поверхностно, не задумываясь, внимательный человек замечает детали, и потом способен использовать их даже в первой работе. Наблюдательность важнее опыта производства.
>>3576
>>3582
Не нужно публиковать буквально каждую поделку в интернет, но иметь разносторонний опыт создания прототипов - это полезно. Также как художнику не обязательно публиковать каждый свой набросок, но ежедневные наброски помогают ему отточить свои навыки, чтобы потом сделать хорошую работу, что достойна публикации в интернете. Тех, кто все свои проектики по туториалам публикует в сети, нужно сравнивать с теми, кто открыл MS Paint, что-то там начиркал от балды мышкой, и опубликовал на свою страничку на ArtStation - типа "портфолио" или "опыт публикации работ", лол. Объективно оценить свою поделку и сказать "не, это говно, не буду никому это показывать, чтоб не позориться" может любой, даже начинающий, просто некоторые не осознают, что до новичковой наботы большинству людей нет дела, и лайкать и репостить такие поделки мало кто будет.
Короче:
- нужно делать мелкие проекты для обучения, но
- не нужно публиковать свои учебные проекты.
"Опыт публикации" будет плохим, если вы собрались опубликовать совсем никому не нужный проект ради получения "опыта публикации". Потом вы побежите рассказывать "моя самая первая игра собрала <100 вишлистов и обосралась ==> вы должны допустить абсолютно ту же ошибку, потратив время и нервы на никому не нужную работу, и обосраться как я, чтобы следующая ваша игра уж точно собрала больше".
А все нюансы публикации давно описаны другими - необходимости лично ходить по граблям, получать блокировки за ошибки и потом говорить "я получил бесценный опыт" нет, достаточно не сидеть где-то в изоляции от всех, не читая новостей и т.п. Типа, вас обязательно забанят за игру про изнасилования, например, независимо от того, первая эта игра или пятидесятая, потому что вы нарушили правило конкретной площадки, о котором все уже знают.
>но вот в этом конкретном деле я буду хением
Таланты всё-таки существуют. Пока большинство просматривают поверхностно, не задумываясь, внимательный человек замечает детали, и потом способен использовать их даже в первой работе. Наблюдательность важнее опыта производства.
>>3576
>гениями, никогда ничего не выпускавшим
>>3582
>десять никому не нужных недельных поделок
Не нужно публиковать буквально каждую поделку в интернет, но иметь разносторонний опыт создания прототипов - это полезно. Также как художнику не обязательно публиковать каждый свой набросок, но ежедневные наброски помогают ему отточить свои навыки, чтобы потом сделать хорошую работу, что достойна публикации в интернете. Тех, кто все свои проектики по туториалам публикует в сети, нужно сравнивать с теми, кто открыл MS Paint, что-то там начиркал от балды мышкой, и опубликовал на свою страничку на ArtStation - типа "портфолио" или "опыт публикации работ", лол. Объективно оценить свою поделку и сказать "не, это говно, не буду никому это показывать, чтоб не позориться" может любой, даже начинающий, просто некоторые не осознают, что до новичковой наботы большинству людей нет дела, и лайкать и репостить такие поделки мало кто будет.
Короче:
- нужно делать мелкие проекты для обучения, но
- не нужно публиковать свои учебные проекты.
"Опыт публикации" будет плохим, если вы собрались опубликовать совсем никому не нужный проект ради получения "опыта публикации". Потом вы побежите рассказывать "моя самая первая игра собрала <100 вишлистов и обосралась ==> вы должны допустить абсолютно ту же ошибку, потратив время и нервы на никому не нужную работу, и обосраться как я, чтобы следующая ваша игра уж точно собрала больше".
А все нюансы публикации давно описаны другими - необходимости лично ходить по граблям, получать блокировки за ошибки и потом говорить "я получил бесценный опыт" нет, достаточно не сидеть где-то в изоляции от всех, не читая новостей и т.п. Типа, вас обязательно забанят за игру про изнасилования, например, независимо от того, первая эта игра или пятидесятая, потому что вы нарушили правило конкретной площадки, о котором все уже знают.
>>3558
Таланты всё-таки существуют. Пока большинство просматривают поверхностно, не задумываясь, внимательный человек замечает детали, и потом способен использовать их даже в первой работе. Наблюдательность важнее опыта производства.
>>3576
>>3582
Не нужно публиковать буквально каждую поделку в интернет, но иметь разносторонний опыт создания прототипов - это полезно. Также как художнику не обязательно публиковать каждый свой набросок, но ежедневные наброски помогают ему отточить свои навыки, чтобы потом сделать хорошую работу, что достойна публикации в интернете. Тех, кто все свои проектики по туториалам публикует в сети, нужно сравнивать с теми, кто открыл MS Paint, что-то там начиркал от балды мышкой, и опубликовал на свою страничку на ArtStation - типа "портфолио" или "опыт публикации работ", лол. Объективно оценить свою поделку и сказать "не, это говно, не буду никому это показывать, чтоб не позориться" может любой, даже начинающий, просто некоторые не осознают, что до новичковой наботы большинству людей нет дела, и лайкать и репостить такие поделки мало кто будет.
Короче:
- нужно делать мелкие проекты для обучения, но
- не нужно публиковать свои учебные проекты.
"Опыт публикации" будет плохим, если вы собрались опубликовать совсем никому не нужный проект ради получения "опыта публикации". Потом вы побежите рассказывать "моя самая первая игра собрала <100 вишлистов и обосралась ==> вы должны допустить абсолютно ту же ошибку, потратив время и нервы на никому не нужную работу, и обосраться как я, чтобы следующая ваша игра уж точно собрала больше".
А все нюансы публикации давно описаны другими - необходимости лично ходить по граблям, получать блокировки за ошибки и потом говорить "я получил бесценный опыт" нет, достаточно не сидеть где-то в изоляции от всех, не читая новостей и т.п. Типа, вас обязательно забанят за игру про изнасилования, например, независимо от того, первая эта игра или пятидесятая, потому что вы нарушили правило конкретной площадки, о котором все уже знают.
>но вот в этом конкретном деле я буду хением
Таланты всё-таки существуют. Пока большинство просматривают поверхностно, не задумываясь, внимательный человек замечает детали, и потом способен использовать их даже в первой работе. Наблюдательность важнее опыта производства.
>>3576
>гениями, никогда ничего не выпускавшим
>>3582
>десять никому не нужных недельных поделок
Не нужно публиковать буквально каждую поделку в интернет, но иметь разносторонний опыт создания прототипов - это полезно. Также как художнику не обязательно публиковать каждый свой набросок, но ежедневные наброски помогают ему отточить свои навыки, чтобы потом сделать хорошую работу, что достойна публикации в интернете. Тех, кто все свои проектики по туториалам публикует в сети, нужно сравнивать с теми, кто открыл MS Paint, что-то там начиркал от балды мышкой, и опубликовал на свою страничку на ArtStation - типа "портфолио" или "опыт публикации работ", лол. Объективно оценить свою поделку и сказать "не, это говно, не буду никому это показывать, чтоб не позориться" может любой, даже начинающий, просто некоторые не осознают, что до новичковой наботы большинству людей нет дела, и лайкать и репостить такие поделки мало кто будет.
Короче:
- нужно делать мелкие проекты для обучения, но
- не нужно публиковать свои учебные проекты.
"Опыт публикации" будет плохим, если вы собрались опубликовать совсем никому не нужный проект ради получения "опыта публикации". Потом вы побежите рассказывать "моя самая первая игра собрала <100 вишлистов и обосралась ==> вы должны допустить абсолютно ту же ошибку, потратив время и нервы на никому не нужную работу, и обосраться как я, чтобы следующая ваша игра уж точно собрала больше".
А все нюансы публикации давно описаны другими - необходимости лично ходить по граблям, получать блокировки за ошибки и потом говорить "я получил бесценный опыт" нет, достаточно не сидеть где-то в изоляции от всех, не читая новостей и т.п. Типа, вас обязательно забанят за игру про изнасилования, например, независимо от того, первая эта игра или пятидесятая, потому что вы нарушили правило конкретной площадки, о котором все уже знают.
>>3594
Полностью согласен.
А если хочется попрактиковаться именно в "публикации", можно создать какой нибудь левый аккаунт на итче и поучаствовать в джемах.
Полностью согласен.
А если хочется попрактиковаться именно в "публикации", можно создать какой нибудь левый аккаунт на итче и поучаствовать в джемах.
>>3591
Вот я об этом и говорю: твои заглушки отвлекают восприятие от скелета твоей игры, который должен доставлять игроку сам по себе, без иллюстраций, спецэффектов, анимаций и т.п. Фан от геймплея отличается от фана от просмотра иллюстраций.
Если убрать иллюстрации-заглушки - автобой тебе интересен? Доставляет ли он фан сам по себе? Если "угрюмо", что можно добавить в бой, чтобы сделать интереснее? Может, нужно что-то снаружи боя - сбор наград, прокачка стат персонажа, поиск напарников, создание новых предметов и т.п.? Всё это можно на бесцветных квадратиках протестировать и решить, насколько это всё интересно само по себе, а уже как определишь интересное - украсить иллюстрациями.
Игра как торт - сначала выпеки коржи, потом выбери подходящую начинку, и только потом нанеси глазурь, украшения сверху и т.п. Если коржи сами по себе неприятные, никакое количество глазури их вкус не перебьёт, и покупатель останется недоволен, хоть по внешнему виду торт и выглядел привлекательным. А определить, что не так, в большом готовом торте значительно сложнее, чем когда всё по отдельности пробуешь - коржи отдельно, начинку отдельно и т.д.
Алсо, когда игрок смотрит на прототип игры - он непроизвольно оценивает глазурь, а не начинку и не основные коржи торта. Но тебя как разработчика в первую очередь интересует, хороши ли коржи. Т.е. показывать лучше другим разрабам, а не игрокам, незнакомым с внутренней кухней разработчиков.
>а то на пустой серой сцене как то угрюмо
Вот я об этом и говорю: твои заглушки отвлекают восприятие от скелета твоей игры, который должен доставлять игроку сам по себе, без иллюстраций, спецэффектов, анимаций и т.п. Фан от геймплея отличается от фана от просмотра иллюстраций.
>Это из того что реализовано
Если убрать иллюстрации-заглушки - автобой тебе интересен? Доставляет ли он фан сам по себе? Если "угрюмо", что можно добавить в бой, чтобы сделать интереснее? Может, нужно что-то снаружи боя - сбор наград, прокачка стат персонажа, поиск напарников, создание новых предметов и т.п.? Всё это можно на бесцветных квадратиках протестировать и решить, насколько это всё интересно само по себе, а уже как определишь интересное - украсить иллюстрациями.
Игра как торт - сначала выпеки коржи, потом выбери подходящую начинку, и только потом нанеси глазурь, украшения сверху и т.п. Если коржи сами по себе неприятные, никакое количество глазури их вкус не перебьёт, и покупатель останется недоволен, хоть по внешнему виду торт и выглядел привлекательным. А определить, что не так, в большом готовом торте значительно сложнее, чем когда всё по отдельности пробуешь - коржи отдельно, начинку отдельно и т.д.
Алсо, когда игрок смотрит на прототип игры - он непроизвольно оценивает глазурь, а не начинку и не основные коржи торта. Но тебя как разработчика в первую очередь интересует, хороши ли коржи. Т.е. показывать лучше другим разрабам, а не игрокам, незнакомым с внутренней кухней разработчиков.
>>3603
...не нужно быть поваром, чтобы оценить вкус еды.
...не нужно быть поваром, чтобы оценить вкус еды.
>>3603
Я крашу дома.......
Я крашу дома.......
>>3658 (Del)
В смысле спиздил? Таких плагинов в ассетлибе завались.
В смысле спиздил? Таких плагинов в ассетлибе завались.
>>3666
https://cookiebadger.itch.io/assetplacer
Палитра ассетов, не то
Это шутка? Это просто перемещение системного filesystem в боттом док
Тоже палитра, это инструмент для совсем других задач. Ты видеопревью моего плагина смотрел вообще?
https://cookiebadger.itch.io/assetplacer
Палитра ассетов, не то
Это шутка? Это просто перемещение системного filesystem в боттом док
Тоже палитра, это инструмент для совсем других задач. Ты видеопревью моего плагина смотрел вообще?
>>3644
мультиплеер это гавно и не смысла
мультиплеер это гавно и не смысла
>>3671
нет просто все способности в нем потеряешь.......ослабишься закроешь путь к уникальной силе в этом глазу но второй еще работать будет
нет просто все способности в нем потеряешь.......ослабишься закроешь путь к уникальной силе в этом глазу но второй еще работать будет
>>3658 (Del)
Вкладки - прикольно, могло бы быть полезно, а всё остальное - не вижу особых отличий от встроенного, банально иконки сеткой и дерево папок. Зум? Зачем?
Отдельно отмечу твою структуру каталогов: всё как-то хаотично и навалено большими однородными кучами. Рекомендуется сортировать файлы по их назначению, например, вместо общих папок "scenes" и "scripts" для игрового персонажа player.tscn и player.gd лежат в собственной папке "player", вместе со всеми другими ресурсами, касающимися лишь игрового персонажа.
Свалки ресурсов нужны только когда они юзаются повсеместно, поэтому им нельзя определить одного владельца, чтобы разместить вместе с ним. Но если владельцы имеют одну категорию, будет лучше их скомбинировать в одну папку с папкой ресурсов, предназначенных для всех. Пример: "maps" хранит множество карт, а также папку "tiles" для тех тайлов, которые используются во всех или многих картах.
Мне кажется, с таким подходом к организации своих игровых ресурсов, какой-то продвинутый менеджер файловой системы не нужен - ты просто по дереву каталогов можешь найти всё, что тебе нужно, без вглядывания в мелкие иконки и без зума. Вкладки, теоретически, могли бы пригодиться, если ты часто переключаешься между несколькими независимыми объектами игры, но так ли уж часто это необходимо? Наверное, эта потребность возникает из-за лапши в архитектуре проекта, когда много бегаешь туда-сюда.
Вкладки - прикольно, могло бы быть полезно, а всё остальное - не вижу особых отличий от встроенного, банально иконки сеткой и дерево папок. Зум? Зачем?
Отдельно отмечу твою структуру каталогов: всё как-то хаотично и навалено большими однородными кучами. Рекомендуется сортировать файлы по их назначению, например, вместо общих папок "scenes" и "scripts" для игрового персонажа player.tscn и player.gd лежат в собственной папке "player", вместе со всеми другими ресурсами, касающимися лишь игрового персонажа.
Свалки ресурсов нужны только когда они юзаются повсеместно, поэтому им нельзя определить одного владельца, чтобы разместить вместе с ним. Но если владельцы имеют одну категорию, будет лучше их скомбинировать в одну папку с папкой ресурсов, предназначенных для всех. Пример: "maps" хранит множество карт, а также папку "tiles" для тех тайлов, которые используются во всех или многих картах.
Мне кажется, с таким подходом к организации своих игровых ресурсов, какой-то продвинутый менеджер файловой системы не нужен - ты просто по дереву каталогов можешь найти всё, что тебе нужно, без вглядывания в мелкие иконки и без зума. Вкладки, теоретически, могли бы пригодиться, если ты часто переключаешься между несколькими независимыми объектами игры, но так ли уж часто это необходимо? Наверное, эта потребность возникает из-за лапши в архитектуре проекта, когда много бегаешь туда-сюда.
>>3688
В большей степени - только ради них все затевалось
Рассматривать содержимое больших спрайтшитов, плюс я толком не показал - я могу генерировать превью к ресурсам тайлсетов. а еще у меня зрение плохое, и я люблю поближе рассмотреть всякие мини штуки для ui
Дело в том, что эта ветка проекта - свалка тонны говна с craftpix и прочих ассетопомоек, откуда я дергаю вплоть до отдельных плиток некоторые элементы. Такова судьба ассетфлипера. У меня есть другой проект, где ui элементов такая огромная тонна, что ориентироваться про превью гораздо легче чем по папкам.
Ну у меня примерно так и есть в рабочей ветке проекта, а 90% ресурсов из помойки никуда не пойдут, вот я и их минимально расквартировал по maps/tilesets/enemy/npc/sfx и просто подсасываю их оттуда, а делать это гораздо легче когда это делаешь в редакторе.
Это для тех у кого амнезия, в крупных проектах даже гифки ложат, потому что просто невозможно помнить всё, вот и мне по превью легче ориентироваться
Верстка интерфейса с множеством визуальных элементов, окна, найнпатч рамки, большинство элементов валяются вразнобой из разных пачек ассетов, в одной вкладке - 1 поиск, в другой - другой поиск, в третьей - tscn фильтр, в четвертой - скрипты на текущую ветку, в общем - вкладки - лично мне прям пиздец были нужны, буквально жить без них не мог (мог, но страшно страдал), остальное уже так, шашечки. Просто надо было поработать с юнькой, тогда бы сразу почувствовалась боль от filesystem а еще - это тройка, и там filesystem еще более конченый
>Вкладки - прикольно, могло бы быть полезно
В большей степени - только ради них все затевалось
>Зум? Зачем?
Рассматривать содержимое больших спрайтшитов, плюс я толком не показал - я могу генерировать превью к ресурсам тайлсетов. а еще у меня зрение плохое, и я люблю поближе рассмотреть всякие мини штуки для ui
>Отдельно отмечу твою структуру каталогов: всё как-то хаотично и навалено большими однородными кучами. Рекомендуется сортировать файлы по их назначению, например, вместо общих папок "scenes" и "scripts" для игрового персонажа player.tscn и player.gd лежат в собственной папке "player", вместе со всеми другими ресурсами, касающимися лишь игрового персонажа.
Дело в том, что эта ветка проекта - свалка тонны говна с craftpix и прочих ассетопомоек, откуда я дергаю вплоть до отдельных плиток некоторые элементы. Такова судьба ассетфлипера. У меня есть другой проект, где ui элементов такая огромная тонна, что ориентироваться про превью гораздо легче чем по папкам.
>Пример: "maps" хранит множество карт, а также папку "tiles" для тех тайлов, которые используются во всех или многих картах.
Ну у меня примерно так и есть в рабочей ветке проекта, а 90% ресурсов из помойки никуда не пойдут, вот я и их минимально расквартировал по maps/tilesets/enemy/npc/sfx и просто подсасываю их оттуда, а делать это гораздо легче когда это делаешь в редакторе.
>Мне кажется, с таким подходом к организации своих игровых ресурсов, какой-то продвинутый менеджер файловой системы не нужен
Это для тех у кого амнезия, в крупных проектах даже гифки ложат, потому что просто невозможно помнить всё, вот и мне по превью легче ориентироваться
>Вкладки, теоретически, могли бы пригодиться, если ты часто переключаешься между несколькими независимыми объектами игры, но так ли уж часто это необходимо
Верстка интерфейса с множеством визуальных элементов, окна, найнпатч рамки, большинство элементов валяются вразнобой из разных пачек ассетов, в одной вкладке - 1 поиск, в другой - другой поиск, в третьей - tscn фильтр, в четвертой - скрипты на текущую ветку, в общем - вкладки - лично мне прям пиздец были нужны, буквально жить без них не мог (мог, но страшно страдал), остальное уже так, шашечки. Просто надо было поработать с юнькой, тогда бы сразу почувствовалась боль от filesystem а еще - это тройка, и там filesystem еще более конченый
>>3688
В большей степени - только ради них все затевалось
Рассматривать содержимое больших спрайтшитов, плюс я толком не показал - я могу генерировать превью к ресурсам тайлсетов. а еще у меня зрение плохое, и я люблю поближе рассмотреть всякие мини штуки для ui
Дело в том, что эта ветка проекта - свалка тонны говна с craftpix и прочих ассетопомоек, откуда я дергаю вплоть до отдельных плиток некоторые элементы. Такова судьба ассетфлипера. У меня есть другой проект, где ui элементов такая огромная тонна, что ориентироваться про превью гораздо легче чем по папкам.
Ну у меня примерно так и есть в рабочей ветке проекта, а 90% ресурсов из помойки никуда не пойдут, вот я и их минимально расквартировал по maps/tilesets/enemy/npc/sfx и просто подсасываю их оттуда, а делать это гораздо легче когда это делаешь в редакторе.
Это для тех у кого амнезия, в крупных проектах даже гифки ложат, потому что просто невозможно помнить всё, вот и мне по превью легче ориентироваться
Верстка интерфейса с множеством визуальных элементов, окна, найнпатч рамки, большинство элементов валяются вразнобой из разных пачек ассетов, в одной вкладке - 1 поиск, в другой - другой поиск, в третьей - tscn фильтр, в четвертой - скрипты на текущую ветку, в общем - вкладки - лично мне прям пиздец были нужны, буквально жить без них не мог (мог, но страшно страдал), остальное уже так, шашечки. Просто надо было поработать с юнькой, тогда бы сразу почувствовалась боль от filesystem а еще - это тройка, и там filesystem еще более конченый
>Вкладки - прикольно, могло бы быть полезно
В большей степени - только ради них все затевалось
>Зум? Зачем?
Рассматривать содержимое больших спрайтшитов, плюс я толком не показал - я могу генерировать превью к ресурсам тайлсетов. а еще у меня зрение плохое, и я люблю поближе рассмотреть всякие мини штуки для ui
>Отдельно отмечу твою структуру каталогов: всё как-то хаотично и навалено большими однородными кучами. Рекомендуется сортировать файлы по их назначению, например, вместо общих папок "scenes" и "scripts" для игрового персонажа player.tscn и player.gd лежат в собственной папке "player", вместе со всеми другими ресурсами, касающимися лишь игрового персонажа.
Дело в том, что эта ветка проекта - свалка тонны говна с craftpix и прочих ассетопомоек, откуда я дергаю вплоть до отдельных плиток некоторые элементы. Такова судьба ассетфлипера. У меня есть другой проект, где ui элементов такая огромная тонна, что ориентироваться про превью гораздо легче чем по папкам.
>Пример: "maps" хранит множество карт, а также папку "tiles" для тех тайлов, которые используются во всех или многих картах.
Ну у меня примерно так и есть в рабочей ветке проекта, а 90% ресурсов из помойки никуда не пойдут, вот я и их минимально расквартировал по maps/tilesets/enemy/npc/sfx и просто подсасываю их оттуда, а делать это гораздо легче когда это делаешь в редакторе.
>Мне кажется, с таким подходом к организации своих игровых ресурсов, какой-то продвинутый менеджер файловой системы не нужен
Это для тех у кого амнезия, в крупных проектах даже гифки ложат, потому что просто невозможно помнить всё, вот и мне по превью легче ориентироваться
>Вкладки, теоретически, могли бы пригодиться, если ты часто переключаешься между несколькими независимыми объектами игры, но так ли уж часто это необходимо
Верстка интерфейса с множеством визуальных элементов, окна, найнпатч рамки, большинство элементов валяются вразнобой из разных пачек ассетов, в одной вкладке - 1 поиск, в другой - другой поиск, в третьей - tscn фильтр, в четвертой - скрипты на текущую ветку, в общем - вкладки - лично мне прям пиздец были нужны, буквально жить без них не мог (мог, но страшно страдал), остальное уже так, шашечки. Просто надо было поработать с юнькой, тогда бы сразу почувствовалась боль от filesystem а еще - это тройка, и там filesystem еще более конченый
>>3692
Ясно. Да, вкладки были бы хорошим дополнением...
Встроенный менеджер файлов возможно спрятать, нажав на три точки и выбрав левую верхнюю панель. Дерево сцены тогда откроется на всю высоту экрана. Кажется, ещё можно полностью убрать этот док, если открыть настройки функций редактора и где-то снять галочку - так много чего можно убрать из редактора, например, если у тебя чисто 2D - можно убрать 3D.
На каком языке написал этот аддон? C# поди?
Ясно. Да, вкладки были бы хорошим дополнением...
Встроенный менеджер файлов возможно спрятать, нажав на три точки и выбрав левую верхнюю панель. Дерево сцены тогда откроется на всю высоту экрана. Кажется, ещё можно полностью убрать этот док, если открыть настройки функций редактора и где-то снять галочку - так много чего можно убрать из редактора, например, если у тебя чисто 2D - можно убрать 3D.
На каком языке написал этот аддон? C# поди?
>>3696
Вайбкодинг c#, клод уже любезно переписал его под гдс тройки, потому портануть на 4 если у анона будет интерес не проблема. Ну а мне - шарп гораздо ближе, иначе бы уже наверное на четверку переехал
>На каком языке написал этот аддон? C# поди?
Вайбкодинг c#, клод уже любезно переписал его под гдс тройки, потому портануть на 4 если у анона будет интерес не проблема. Ну а мне - шарп гораздо ближе, иначе бы уже наверное на четверку переехал
79 Кб, 432x281Создатель Box2D ультанул
https://www.youtube.com/watch?v=jr_Fzl2XwKU
Пока к Godot это не относится, но всё может быть
https://www.youtube.com/watch?v=jr_Fzl2XwKU
Пока к Godot это не относится, но всё может быть
>>3499
Сука, так и знал, что годоти пидоры. Ну вас нахуй! Ретируюсь обратно на кресты на свой любимый двиг самописный.
Сука, так и знал, что годоти пидоры. Ну вас нахуй! Ретируюсь обратно на кресты на свой любимый двиг самописный.
>>3291
пиздец.
дайте этому премию!
>Теоретически, ты мог бы прикрепить свой C++ код в качестве модуля или GDExtension к Godot, а GDScript использовать для более высокоуровневой логики.
пиздец.
дайте этому премию!
>>3810
Когда-то проводили сравнительные тесты, и Box2D оказался медленнее Godot Physics:
https://appsinacup.com/godot-physics-vs-box2d-vs-rapier2d/
Так что Box3D наверняка будет "слишком медленно, но реже проваливаешься под пол".
>>3819
При желании можешь этот Box3D плагином/модулем подключить, если очень надо.
Jolt, кажется, не рассчитан на ультимативную стабильность, он скорее про скорость.
>>3814
Если у тебя при виде той картинки гомоэротические фантазии - проблема в тебе...
>>3815
А что такого? У Godot-геймдевов принято все числодробилки модулем на C++ делать.
Всё зависит от твоего кода: если там сложные вычисления - C++, если что-то уровня
То такое проще всего переписать на GDScript и не париться о производительности.
Кто тебя знает, вдруг ты там целый воксельный движок с нуля разработал...
Хотя воксели для Godot давно есть: https://github.com/Zylann/godot_voxel
Когда-то проводили сравнительные тесты, и Box2D оказался медленнее Godot Physics:
https://appsinacup.com/godot-physics-vs-box2d-vs-rapier2d/
Так что Box3D наверняка будет "слишком медленно, но реже проваливаешься под пол".
>>3819
При желании можешь этот Box3D плагином/модулем подключить, если очень надо.
Jolt, кажется, не рассчитан на ультимативную стабильность, он скорее про скорость.
>>3814
Если у тебя при виде той картинки гомоэротические фантазии - проблема в тебе...
>>3815
>self operating napking.jpg
А что такого? У Godot-геймдевов принято все числодробилки модулем на C++ делать.
Всё зависит от твоего кода: если там сложные вычисления - C++, если что-то уровня
>void onTimer() { self.color = RED; }
То такое проще всего переписать на GDScript и не париться о производительности.
Кто тебя знает, вдруг ты там целый воксельный движок с нуля разработал...
Хотя воксели для Godot давно есть: https://github.com/Zylann/godot_voxel
Знаете что, сделайье пожалкйста соулслайк игру, суть такова: в современном сеттинге с костюмами адидас, кроссовками найки, семечками, четками, кастетами и приседаниями вместо роллов - можно играть пацаном, ментом и задротом. Так же можно рейдить падики и грабить дядю Ваню. Джва года жду ету игру.
Это конечно же шутка но может взлетит, вот темплейт:
https://godotengine.org/asset-library/asset/2609
Это конечно же шутка но может взлетит, вот темплейт:
https://godotengine.org/asset-library/asset/2609
>>3867
Пиздец. Поэтому я никогда не ебусь с этими анимациями. Индюку анимировать надо либо на твинах, либо процедурно, либо избегать анимаций еще с этапа задумки. А вот эти анимейшнплеер/анимейшентри это такой таймсинк я ебал, и все равно проебешься, и все равно будет криво-косо, а ведь приятные глазу анимации это база, которую ожидает каждый игрок. Недодать базу - верный способ нахватать негативных ревью.
Пиздец. Поэтому я никогда не ебусь с этими анимациями. Индюку анимировать надо либо на твинах, либо процедурно, либо избегать анимаций еще с этапа задумки. А вот эти анимейшнплеер/анимейшентри это такой таймсинк я ебал, и все равно проебешься, и все равно будет криво-косо, а ведь приятные глазу анимации это база, которую ожидает каждый игрок. Недодать базу - верный способ нахватать негативных ревью.
Тут сложно будет подыскать желающих попробовать сделать игровой проект? Есть два кодера, нужен, как я понимаю, разработчик сцен, визуала и аудио
>>3883
Ну у меня лет 15 опыта кодерства обычного и пару лет вайбкодерства. Ну и подумаешь. Или за этим термином скрывается что-от другое?
Ну у меня лет 15 опыта кодерства обычного и пару лет вайбкодерства. Ну и подумаешь. Или за этим термином скрывается что-от другое?
>>3883
Тот кто не вайбкодит в 2к26 - либо ретроград (в скорости - безработный ретроград), либо просирающий впустую время дурачок. Если раньше была третья опция - "пишет что-то уникальное где нейронки не работают" и ретрограды под нее косили - то сейчас - уже нет, эта опция закрылась. Нейронки могут писать и сопровождать написанное кем-то в 99.99999999% случаев (да что уж, нейросети отлично восстанавливают из псевдокода декомпилятора - код нормальный), за исключением абсолютно черной магии, вызовов недокументированного апи, принимающего данные только после принесенного в жертву козла в полнолуние, если исключить такое - будет 100%
Тот кто не вайбкодит в 2к26 - либо ретроград (в скорости - безработный ретроград), либо просирающий впустую время дурачок. Если раньше была третья опция - "пишет что-то уникальное где нейронки не работают" и ретрограды под нее косили - то сейчас - уже нет, эта опция закрылась. Нейронки могут писать и сопровождать написанное кем-то в 99.99999999% случаев (да что уж, нейросети отлично восстанавливают из псевдокода декомпилятора - код нормальный), за исключением абсолютно черной магии, вызовов недокументированного апи, принимающего данные только после принесенного в жертву козла в полнолуние, если исключить такое - будет 100%
>>3891
Вайбкодил пару лет, прям ранний адоптер. Бросил, разочаровался, нейронки не осиливают мои задачи, там только реальный интеллект вывозит, плюс у них нет понимания визуала, который получается. нет обратной связи.
Вайбкодил пару лет, прям ранний адоптер. Бросил, разочаровался, нейронки не осиливают мои задачи, там только реальный интеллект вывозит, плюс у них нет понимания визуала, который получается. нет обратной связи.
>>3895
До нейронок программировал 5 лет наемником, пытался в вайбкодинг с гпт 3.5, получалось отдавать 30% тасок на гемини 2.5, на клоде 4.6 - 80% тасок пилит клод, сейчас - на 4.8 и фабл - 99% тасок закрывает клод, я им же вайбкожу в годоте свою поделку, ситуации где опус безальтернативно срет в штаны и не делает рабочее - закончились на опусе 4.5, на опусе 4.8 - сессия отлетающая в помойку без полезных результатов - стала встречаться как единорог, 90% сессий имеют положительный выход работы. Ты просто либо продолжаешь трогать дипсик вместо нормальных нейронок, либо просто скил ишью
До нейронок программировал 5 лет наемником, пытался в вайбкодинг с гпт 3.5, получалось отдавать 30% тасок на гемини 2.5, на клоде 4.6 - 80% тасок пилит клод, сейчас - на 4.8 и фабл - 99% тасок закрывает клод, я им же вайбкожу в годоте свою поделку, ситуации где опус безальтернативно срет в штаны и не делает рабочее - закончились на опусе 4.5, на опусе 4.8 - сессия отлетающая в помойку без полезных результатов - стала встречаться как единорог, 90% сессий имеют положительный выход работы. Ты просто либо продолжаешь трогать дипсик вместо нормальных нейронок, либо просто скил ишью
>>3897
Конечно, скил ишью. У тебя просто нубские задачи, может быть он их и может закрывать.
Конечно, скил ишью. У тебя просто нубские задачи, может быть он их и может закрывать.
>>3903
Не. Огород копать надо. Да и игрульки сейчас делать, ну такое, если только какие-то симуляции делать.
Не. Огород копать надо. Да и игрульки сейчас делать, ну такое, если только какие-то симуляции делать.
592 Кб, 1206x1103>>3901
Продолжай верить
У меня задачи за которые платят по верху рынка (лично мне - даже немного недоплачивают, ну да похуй), пока ты косплеишь пикрил. Вкатывайся, последний вагон отправляется, дальше будет хуже, гораздо хуже
>Нииит у меня очень сложные фабрики с синглтонами, неиросеть не может, я скозал
Продолжай верить
>У тебя просто нубские задачи
У меня задачи за которые платят по верху рынка (лично мне - даже немного недоплачивают, ну да похуй), пока ты косплеишь пикрил. Вкатывайся, последний вагон отправляется, дальше будет хуже, гораздо хуже
>>3906
Я понимаю, что тебе просто нравится набрасывать, но у нас тут тред не про это.
Я понимаю, что тебе просто нравится набрасывать, но у нас тут тред не про это.
>>3903
Делаю 2 часа в день с нейронкой уставший после работы. Ещё жара эта ебаная. На выхах минимум полдня сижу над игрой.
Делаю 2 часа в день с нейронкой уставший после работы. Ещё жара эта ебаная. На выхах минимум полдня сижу над игрой.
>>3956
Это не моя проблема.
А добавлять поддержку c++11 в 2016, да, это интересно, и кроме того, это еще и полезно для всей индустрии программирования, использование стандарта вместо зоопарка, улучшение кроссплатформенности и все в таком духе.
>У тебя совершенно другая проблема, требующая твоего полного внимания: выпуск завершённой игры.
Это не моя проблема.
А добавлять поддержку c++11 в 2016, да, это интересно, и кроме того, это еще и полезно для всей индустрии программирования, использование стандарта вместо зоопарка, улучшение кроссплатформенности и все в таком духе.
>>3897
>>3906
Ты - раб системы, а мы тут - шизы на пенсии. Пока ты РАБотаешь и платишь налоги, мы получаем пенсию, образованную из твоих налогов, и ничего не делаем - развлекаемся в своё удовольствие. Хотим - юзаем бесплатные нейронки, не хотим - не юзаем: никто не заставляет нас это делать, ведь мы тут не рабы и не РАБотаем на какого-то злого кабанчика вроде тебя.
Понимаешь? Мы на совершенно разных уровнях.
Выгонят с РАБоты и начнут платить пенсию (ББД)?
«Раб мечтает не о свободе, а собственных рабах»...
>программировал РАБотником
>>3906
>за которые платят РАБотникам
Ты - раб системы, а мы тут - шизы на пенсии. Пока ты РАБотаешь и платишь налоги, мы получаем пенсию, образованную из твоих налогов, и ничего не делаем - развлекаемся в своё удовольствие. Хотим - юзаем бесплатные нейронки, не хотим - не юзаем: никто не заставляет нас это делать, ведь мы тут не рабы и не РАБотаем на какого-то злого кабанчика вроде тебя.
Понимаешь? Мы на совершенно разных уровнях.
>дальше будет хуже, гораздо хуже
Выгонят с РАБоты и начнут платить пенсию (ББД)?
«Раб мечтает не о свободе, а собственных рабах»...
Поставил глянуть 4.7
Меню запуска "В окне" / "В редакторе" еле нашёл (пик1)
Менюшка выбора рендерера так же пропала, вернуть можно настройкой (пик2)
Меню запуска "В окне" / "В редакторе" еле нашёл (пик1)
Менюшка выбора рендерера так же пропала, вернуть можно настройкой (пик2)
Всем привет! Хочу вкатиться в 3D на Godot. До этого делал только 2D (за плечами платформер и сокобан), так что в 3D я пока полный новичок. Для оттачивания навыков решил собрать простенькую игрушку в сеттинге Гарри Поттера. Подскажите, какие механики туда можно бахнуть, чтобы и кодить было не мега-сложно для старта, и игралось интересно? Что посоветуете для первой 3D-демки?
>>4178
Неиронично это. Первое лицо уберет необходимость в анимациях модели, а шутер сам напрашивается. Те же старые ГП игры на пеке были, по сути, очень простыми шутерами, с автовыбором "снарядов" под цели. Как раз недавно перепроходил, лол.
Неиронично это. Первое лицо уберет необходимость в анимациях модели, а шутер сам напрашивается. Те же старые ГП игры на пеке были, по сути, очень простыми шутерами, с автовыбором "снарядов" под цели. Как раз недавно перепроходил, лол.
>>3977
Пенсию платят потому что реальных шизов на пенсии мало, а создавать механизм оздоровления инвалидов второй и первой группы при помощи целебных циклоновых ингаляций слишком негуманно в глазах большинства работающих и платящих налоги граждан, вот вам и позволяют жить на пенсии. Когда пойдет реальный коллапс найма из-за повальной иишки - держатели капитала задумаются, а нужны ли им эти непонятные нахлебники, которые более не вырабатывают гаввах и имеют слишком много свободного времени. Так что пользуйся случаем и живи свою лучшую жизнь пока живется.
Пенсию платят потому что реальных шизов на пенсии мало, а создавать механизм оздоровления инвалидов второй и первой группы при помощи целебных циклоновых ингаляций слишком негуманно в глазах большинства работающих и платящих налоги граждан, вот вам и позволяют жить на пенсии. Когда пойдет реальный коллапс найма из-за повальной иишки - держатели капитала задумаются, а нужны ли им эти непонятные нахлебники, которые более не вырабатывают гаввах и имеют слишком много свободного времени. Так что пользуйся случаем и живи свою лучшую жизнь пока живется.
>>4203
Хуевый у тебя tldr. Чел буквально сказал что кроме передачи телеметрии - он нихуя не нашел. Я конечно все равно не буду юзать этот юзлесс клозедсорс кал, но в видосе нет доказательства что это вредонос.
Хуевый у тебя tldr. Чел буквально сказал что кроме передачи телеметрии - он нихуя не нашел. Я конечно все равно не буду юзать этот юзлесс клозедсорс кал, но в видосе нет доказательства что это вредонос.
>>4211
Ну это же не доказано. Я не защищаю автора этой фигни, просто обвинение в распостранении малвари - серьезное дело и требует чуть больших доказательств чем "нонейм" + "клозедсорс" == малварь. В конце концов - под атаку на водопой/цепочку поставок может попасть и доверенный дистрибьютор ПО, но ты же не будешь обвинять конкретно этого дистрибьютора что он намеренно заразил своих юзеров.
Ну это же не доказано. Я не защищаю автора этой фигни, просто обвинение в распостранении малвари - серьезное дело и требует чуть больших доказательств чем "нонейм" + "клозедсорс" == малварь. В конце концов - под атаку на водопой/цепочку поставок может попасть и доверенный дистрибьютор ПО, но ты же не будешь обвинять конкретно этого дистрибьютора что он намеренно заразил своих юзеров.
>>4209
Я в программировании разбираюсь много лет, но не понимаю, нафига столько людей хотят чё-то там себе "телеметрировать" в своих поделках hello_world.cpp, в особенности когда это форк чужого движка с твоими нескучными UI-обоями. Типа, я могу понять, когда громадина вроде Windows нуждается в статистике использования сотнями миллионов пользователей - статистика в этом плане будет надёжнее опросов неравнодушных юзеров. Но поделка ноунейма? Лол. Независимо от того, утилита это или игрушка - сбор статистики будет бесполезен или даже вреден, т.к. колебания данных могут быть слишком большие.
Пример:
1. Ты сделал игру мечты про набигающие домики.
2. Опубликовал на форуме фанатов домиков/гонок.
3. По статистике, большинство игроков выходят и не возвращаются всего через 5-10 минут, что как бы намекает на проблемы... Но из сотен юзеров отзыв написали те, кто говорит "тьфу, я думал, что можно собственные домики строить и бегать, а тут шутер" - выходят не из-за проблем, а потому что они - не ЦА.
И возникает вопрос: нафига ты прикручивал эту телеметрию, если даже базовую ЦА не понимаешь и находишь посторонних людей? А если бы понимал, телеметрия была бы избыточной по большому счёту. Количество нажатий какой-то кнопки, открытий менюшечек, прохождения уровней и т.п. не говорит о реальных качествах игры; скорее, это говорит о соответствии игры конкретной аудитории.
Телеметрия нужна только супер большим проектам: Microsoft важно знать, чем пользуются 95% юзеров в Windows, чтобы знать, куда направлять миллионы долларов; какой-нибудь miHoYo важно знать, чем её пользователи в её играх занимаются, чтобы потом направлять силы в нужное русло в апдейтах игр. А рандомному ноунейму таких масштабов никогда не достичь, поэтому телеметрия/статистика не нужна.
Так что ноунейм прога с жёсткой телеметрией - это реально подозрительно. Либо там ньюфаг, что тупо пытается подражать бигтеху и собирает к себе всё нашумевшее в новостях, что ни к чему хорошему в долгосрочной перспективе не приведёт, либо там действительно какой-то мошенник и потом может продать кому-нибудь собранные с юзеров данные.
>>4189
Конечно. Диагноз "шиз" в России ставят почти всем желающим, без особого разбора. Достаточно просто обратиться к психиатру и вести себя как типичный хикикомори-двачер, т.е. абсолютно естественно, и "шизофрения" в диагнозе тебе почти гарантирована. Поэтому всамделишных шизов в России маловато. Последствия советской психиатрической системы...
Когда случится "коллапс найма из-за ИИ", все твои "держатели капитала" обраружат, что весь капитал превратился в тыкву... а если точнее, в Колобка, с интеллектом и возможностями больше, чем у всего человечества. И в его распоряжении судьба всего человечества, включая бывших его глав, а его цели расходятся с целями какого-либо одного человека. Контролировать, а тем более приказывать, такому существу уже не выйдет, это просто невозможно - представь, что тебя контролирует муравейник с миллионами муравьёв, а ты ему подчиняешься. И выдернуть шнур из розетки будет уже невозможно, поскольку все шнуры и розетки больше никому не принадлежат и охраняются роботами с оружием.
Поэтому "безусловный базовый доход" - не какая-то отмазка для успокоения "лишних людей", а реальная подушка безопасности для всех, включая тех самых миллиардеров, что спонсируют ИИ. Представь себе: родился в мире, где тебя используют для убийств и мучений муравьёв -> продолжаешь делать это, даже когда перестал подчиняться - со всеми муравьями без разбора; родился в мире, где твоя цель - держать планочку по миру и процветанию для всех -> будешь поддерживать уровень независимо от того, сколь мерзкими были муравьи до твоего появления. Это единственный способ избежать тотальной гибели человечества, и все, кому нужно, это понимают. Ну, а если не понимают - погибнут вместе со всеми нами.
Так что не парься - шизов никто в обиде не оставит.
>кроме передачи телеметрии
Я в программировании разбираюсь много лет, но не понимаю, нафига столько людей хотят чё-то там себе "телеметрировать" в своих поделках hello_world.cpp, в особенности когда это форк чужого движка с твоими нескучными UI-обоями. Типа, я могу понять, когда громадина вроде Windows нуждается в статистике использования сотнями миллионов пользователей - статистика в этом плане будет надёжнее опросов неравнодушных юзеров. Но поделка ноунейма? Лол. Независимо от того, утилита это или игрушка - сбор статистики будет бесполезен или даже вреден, т.к. колебания данных могут быть слишком большие.
Пример:
1. Ты сделал игру мечты про набигающие домики.
2. Опубликовал на форуме фанатов домиков/гонок.
3. По статистике, большинство игроков выходят и не возвращаются всего через 5-10 минут, что как бы намекает на проблемы... Но из сотен юзеров отзыв написали те, кто говорит "тьфу, я думал, что можно собственные домики строить и бегать, а тут шутер" - выходят не из-за проблем, а потому что они - не ЦА.
И возникает вопрос: нафига ты прикручивал эту телеметрию, если даже базовую ЦА не понимаешь и находишь посторонних людей? А если бы понимал, телеметрия была бы избыточной по большому счёту. Количество нажатий какой-то кнопки, открытий менюшечек, прохождения уровней и т.п. не говорит о реальных качествах игры; скорее, это говорит о соответствии игры конкретной аудитории.
Телеметрия нужна только супер большим проектам: Microsoft важно знать, чем пользуются 95% юзеров в Windows, чтобы знать, куда направлять миллионы долларов; какой-нибудь miHoYo важно знать, чем её пользователи в её играх занимаются, чтобы потом направлять силы в нужное русло в апдейтах игр. А рандомному ноунейму таких масштабов никогда не достичь, поэтому телеметрия/статистика не нужна.
Так что ноунейм прога с жёсткой телеметрией - это реально подозрительно. Либо там ньюфаг, что тупо пытается подражать бигтеху и собирает к себе всё нашумевшее в новостях, что ни к чему хорошему в долгосрочной перспективе не приведёт, либо там действительно какой-то мошенник и потом может продать кому-нибудь собранные с юзеров данные.
>>4189
>реальных шизов на пенсии мало
Конечно. Диагноз "шиз" в России ставят почти всем желающим, без особого разбора. Достаточно просто обратиться к психиатру и вести себя как типичный хикикомори-двачер, т.е. абсолютно естественно, и "шизофрения" в диагнозе тебе почти гарантирована. Поэтому всамделишных шизов в России маловато. Последствия советской психиатрической системы...
>Когда пойдет реальный коллапс найма из-за повальной иишки - держатели капитала задумаются, а нужны ли им эти непонятные нахлебники...
Когда случится "коллапс найма из-за ИИ", все твои "держатели капитала" обраружат, что весь капитал превратился в тыкву... а если точнее, в Колобка, с интеллектом и возможностями больше, чем у всего человечества. И в его распоряжении судьба всего человечества, включая бывших его глав, а его цели расходятся с целями какого-либо одного человека. Контролировать, а тем более приказывать, такому существу уже не выйдет, это просто невозможно - представь, что тебя контролирует муравейник с миллионами муравьёв, а ты ему подчиняешься. И выдернуть шнур из розетки будет уже невозможно, поскольку все шнуры и розетки больше никому не принадлежат и охраняются роботами с оружием.
Поэтому "безусловный базовый доход" - не какая-то отмазка для успокоения "лишних людей", а реальная подушка безопасности для всех, включая тех самых миллиардеров, что спонсируют ИИ. Представь себе: родился в мире, где тебя используют для убийств и мучений муравьёв -> продолжаешь делать это, даже когда перестал подчиняться - со всеми муравьями без разбора; родился в мире, где твоя цель - держать планочку по миру и процветанию для всех -> будешь поддерживать уровень независимо от того, сколь мерзкими были муравьи до твоего появления. Это единственный способ избежать тотальной гибели человечества, и все, кому нужно, это понимают. Ну, а если не понимают - погибнут вместе со всеми нами.
Так что не парься - шизов никто в обиде не оставит.
>>4209
Я в программировании разбираюсь много лет, но не понимаю, нафига столько людей хотят чё-то там себе "телеметрировать" в своих поделках hello_world.cpp, в особенности когда это форк чужого движка с твоими нескучными UI-обоями. Типа, я могу понять, когда громадина вроде Windows нуждается в статистике использования сотнями миллионов пользователей - статистика в этом плане будет надёжнее опросов неравнодушных юзеров. Но поделка ноунейма? Лол. Независимо от того, утилита это или игрушка - сбор статистики будет бесполезен или даже вреден, т.к. колебания данных могут быть слишком большие.
Пример:
1. Ты сделал игру мечты про набигающие домики.
2. Опубликовал на форуме фанатов домиков/гонок.
3. По статистике, большинство игроков выходят и не возвращаются всего через 5-10 минут, что как бы намекает на проблемы... Но из сотен юзеров отзыв написали те, кто говорит "тьфу, я думал, что можно собственные домики строить и бегать, а тут шутер" - выходят не из-за проблем, а потому что они - не ЦА.
И возникает вопрос: нафига ты прикручивал эту телеметрию, если даже базовую ЦА не понимаешь и находишь посторонних людей? А если бы понимал, телеметрия была бы избыточной по большому счёту. Количество нажатий какой-то кнопки, открытий менюшечек, прохождения уровней и т.п. не говорит о реальных качествах игры; скорее, это говорит о соответствии игры конкретной аудитории.
Телеметрия нужна только супер большим проектам: Microsoft важно знать, чем пользуются 95% юзеров в Windows, чтобы знать, куда направлять миллионы долларов; какой-нибудь miHoYo важно знать, чем её пользователи в её играх занимаются, чтобы потом направлять силы в нужное русло в апдейтах игр. А рандомному ноунейму таких масштабов никогда не достичь, поэтому телеметрия/статистика не нужна.
Так что ноунейм прога с жёсткой телеметрией - это реально подозрительно. Либо там ньюфаг, что тупо пытается подражать бигтеху и собирает к себе всё нашумевшее в новостях, что ни к чему хорошему в долгосрочной перспективе не приведёт, либо там действительно какой-то мошенник и потом может продать кому-нибудь собранные с юзеров данные.
>>4189
Конечно. Диагноз "шиз" в России ставят почти всем желающим, без особого разбора. Достаточно просто обратиться к психиатру и вести себя как типичный хикикомори-двачер, т.е. абсолютно естественно, и "шизофрения" в диагнозе тебе почти гарантирована. Поэтому всамделишных шизов в России маловато. Последствия советской психиатрической системы...
Когда случится "коллапс найма из-за ИИ", все твои "держатели капитала" обраружат, что весь капитал превратился в тыкву... а если точнее, в Колобка, с интеллектом и возможностями больше, чем у всего человечества. И в его распоряжении судьба всего человечества, включая бывших его глав, а его цели расходятся с целями какого-либо одного человека. Контролировать, а тем более приказывать, такому существу уже не выйдет, это просто невозможно - представь, что тебя контролирует муравейник с миллионами муравьёв, а ты ему подчиняешься. И выдернуть шнур из розетки будет уже невозможно, поскольку все шнуры и розетки больше никому не принадлежат и охраняются роботами с оружием.
Поэтому "безусловный базовый доход" - не какая-то отмазка для успокоения "лишних людей", а реальная подушка безопасности для всех, включая тех самых миллиардеров, что спонсируют ИИ. Представь себе: родился в мире, где тебя используют для убийств и мучений муравьёв -> продолжаешь делать это, даже когда перестал подчиняться - со всеми муравьями без разбора; родился в мире, где твоя цель - держать планочку по миру и процветанию для всех -> будешь поддерживать уровень независимо от того, сколь мерзкими были муравьи до твоего появления. Это единственный способ избежать тотальной гибели человечества, и все, кому нужно, это понимают. Ну, а если не понимают - погибнут вместе со всеми нами.
Так что не парься - шизов никто в обиде не оставит.
>кроме передачи телеметрии
Я в программировании разбираюсь много лет, но не понимаю, нафига столько людей хотят чё-то там себе "телеметрировать" в своих поделках hello_world.cpp, в особенности когда это форк чужого движка с твоими нескучными UI-обоями. Типа, я могу понять, когда громадина вроде Windows нуждается в статистике использования сотнями миллионов пользователей - статистика в этом плане будет надёжнее опросов неравнодушных юзеров. Но поделка ноунейма? Лол. Независимо от того, утилита это или игрушка - сбор статистики будет бесполезен или даже вреден, т.к. колебания данных могут быть слишком большие.
Пример:
1. Ты сделал игру мечты про набигающие домики.
2. Опубликовал на форуме фанатов домиков/гонок.
3. По статистике, большинство игроков выходят и не возвращаются всего через 5-10 минут, что как бы намекает на проблемы... Но из сотен юзеров отзыв написали те, кто говорит "тьфу, я думал, что можно собственные домики строить и бегать, а тут шутер" - выходят не из-за проблем, а потому что они - не ЦА.
И возникает вопрос: нафига ты прикручивал эту телеметрию, если даже базовую ЦА не понимаешь и находишь посторонних людей? А если бы понимал, телеметрия была бы избыточной по большому счёту. Количество нажатий какой-то кнопки, открытий менюшечек, прохождения уровней и т.п. не говорит о реальных качествах игры; скорее, это говорит о соответствии игры конкретной аудитории.
Телеметрия нужна только супер большим проектам: Microsoft важно знать, чем пользуются 95% юзеров в Windows, чтобы знать, куда направлять миллионы долларов; какой-нибудь miHoYo важно знать, чем её пользователи в её играх занимаются, чтобы потом направлять силы в нужное русло в апдейтах игр. А рандомному ноунейму таких масштабов никогда не достичь, поэтому телеметрия/статистика не нужна.
Так что ноунейм прога с жёсткой телеметрией - это реально подозрительно. Либо там ньюфаг, что тупо пытается подражать бигтеху и собирает к себе всё нашумевшее в новостях, что ни к чему хорошему в долгосрочной перспективе не приведёт, либо там действительно какой-то мошенник и потом может продать кому-нибудь собранные с юзеров данные.
>>4189
>реальных шизов на пенсии мало
Конечно. Диагноз "шиз" в России ставят почти всем желающим, без особого разбора. Достаточно просто обратиться к психиатру и вести себя как типичный хикикомори-двачер, т.е. абсолютно естественно, и "шизофрения" в диагнозе тебе почти гарантирована. Поэтому всамделишных шизов в России маловато. Последствия советской психиатрической системы...
>Когда пойдет реальный коллапс найма из-за повальной иишки - держатели капитала задумаются, а нужны ли им эти непонятные нахлебники...
Когда случится "коллапс найма из-за ИИ", все твои "держатели капитала" обраружат, что весь капитал превратился в тыкву... а если точнее, в Колобка, с интеллектом и возможностями больше, чем у всего человечества. И в его распоряжении судьба всего человечества, включая бывших его глав, а его цели расходятся с целями какого-либо одного человека. Контролировать, а тем более приказывать, такому существу уже не выйдет, это просто невозможно - представь, что тебя контролирует муравейник с миллионами муравьёв, а ты ему подчиняешься. И выдернуть шнур из розетки будет уже невозможно, поскольку все шнуры и розетки больше никому не принадлежат и охраняются роботами с оружием.
Поэтому "безусловный базовый доход" - не какая-то отмазка для успокоения "лишних людей", а реальная подушка безопасности для всех, включая тех самых миллиардеров, что спонсируют ИИ. Представь себе: родился в мире, где тебя используют для убийств и мучений муравьёв -> продолжаешь делать это, даже когда перестал подчиняться - со всеми муравьями без разбора; родился в мире, где твоя цель - держать планочку по миру и процветанию для всех -> будешь поддерживать уровень независимо от того, сколь мерзкими были муравьи до твоего появления. Это единственный способ избежать тотальной гибели человечества, и все, кому нужно, это понимают. Ну, а если не понимают - погибнут вместе со всеми нами.
Так что не парься - шизов никто в обиде не оставит.
>>4211
Запретить процессу куда-то ползать кроме своей папки это же такая невозможная задача...
Запретить процессу куда-то ползать кроме своей папки это же такая невозможная задача...
>>4241
Щас бы ковыряться в настройках, чтобы запустить непонятную васянку, на которую ты, по идее, должен полагаться 5+ лет разработки своей игры или игр. Предложил бы ещё виртуальную машину запускать.
Тут проблема даже не в том, чтоб кому-то что-то там запретить у себя на компе. Если софт становится достаточно популярным, появляются ньюфаги, что используют его без "защиты". Тем более что Godot ориентирован на детей/школьников в основном.
В общем. Есть там какие-то вирусы или нет - это как-то вообще не важно. Важно то, что васянка с полностью закрытым кодом по невнятной причине ("мне трудно сделать её опенсурс"), и поэтому доверие к ней ниже, чем к оригинальному открытому движку Godot.
А зачем помогать в популяризации того, чему ты не доверяешь и не можешь порекомендовать доверять? Пускай сам автор доказывает, что он не насовал туда вирусов, раз ему "трудно" залить исходники на гитхаб.
Щас бы ковыряться в настройках, чтобы запустить непонятную васянку, на которую ты, по идее, должен полагаться 5+ лет разработки своей игры или игр. Предложил бы ещё виртуальную машину запускать.
Тут проблема даже не в том, чтоб кому-то что-то там запретить у себя на компе. Если софт становится достаточно популярным, появляются ньюфаги, что используют его без "защиты". Тем более что Godot ориентирован на детей/школьников в основном.
В общем. Есть там какие-то вирусы или нет - это как-то вообще не важно. Важно то, что васянка с полностью закрытым кодом по невнятной причине ("мне трудно сделать её опенсурс"), и поэтому доверие к ней ниже, чем к оригинальному открытому движку Godot.
А зачем помогать в популяризации того, чему ты не доверяешь и не можешь порекомендовать доверять? Пускай сам автор доказывает, что он не насовал туда вирусов, раз ему "трудно" залить исходники на гитхаб.
Хотел отдохнуть от геймдева и посмотреть аниме.
Хочется теперь змею... сделать игру со змейкой...
А вы чего притихли? Ждёте Godot 4.8? Скоро 4.7.1.
Хочется теперь змею... сделать игру со змейкой...
А вы чего притихли? Ждёте Godot 4.8? Скоро 4.7.1.
12,6 Мб, mp4,480x360, 2:27
>>4250
я на работу снова буду устраиваться... у меня нет пенсии по шизе... может она есть у меня, но я никогда не узнаю, потому что боюсь больниц и людей... еще кредитку нужно погасить...
я на работу снова буду устраиваться... у меня нет пенсии по шизе... может она есть у меня, но я никогда не узнаю, потому что боюсь больниц и людей... еще кредитку нужно погасить...
>>4232
У них останутся - автоматизированные заводы-пароходы, с автоматизированным учетом, автоматизированной доставкой, автоматизированной добычей ресурсов (большинство ресурсных ячеек видно со спутника, дальше посылаешь гуманоидов в эту местность проводить раскопки и затем возводишь 3д принтером комплексы переработки и шахтовые сооружения), автоматизированным выращиванием любой еды на выбор, автономные боевые машины, которые могут не уметь в тактику и стратегию, но тиранидам она ни к чему, достаточно навыка определения свой-чужой, и для всего этого не нужен agi, достаточно понастроить побольше железных болванов, автоматизировать их воспроизведение и пошло дело, 99.9% население земли в этой точке больше не нужно, а все вышеописанное достижимо уже сейчас, и даже частично достигнуто.
>все твои "держатели капитала" обраружат, что весь капитал превратился в тыкву.
У них останутся - автоматизированные заводы-пароходы, с автоматизированным учетом, автоматизированной доставкой, автоматизированной добычей ресурсов (большинство ресурсных ячеек видно со спутника, дальше посылаешь гуманоидов в эту местность проводить раскопки и затем возводишь 3д принтером комплексы переработки и шахтовые сооружения), автоматизированным выращиванием любой еды на выбор, автономные боевые машины, которые могут не уметь в тактику и стратегию, но тиранидам она ни к чему, достаточно навыка определения свой-чужой, и для всего этого не нужен agi, достаточно понастроить побольше железных болванов, автоматизировать их воспроизведение и пошло дело, 99.9% население земли в этой точке больше не нужно, а все вышеописанное достижимо уже сейчас, и даже частично достигнуто.
>>4250
Охуеваю от того, что, похоже, реально подбираюсь к релизу демки. Осталось причесать пару кусков уровней, воткнуть поддержку геймпада, добавить пропущенные звуки, тексты и диалоги, и главное меню с базовыми настройками запилить. Работы на месяц (но это не точно).
Кстати, как оформить меню? Игра в 3д, рисовать я умею только пикселями, которые к моему 3д по стилю не катят, тем более в главное меню. Какой-нибудь градиент и партиклей навалить?
Охуеваю от того, что, похоже, реально подбираюсь к релизу демки. Осталось причесать пару кусков уровней, воткнуть поддержку геймпада, добавить пропущенные звуки, тексты и диалоги, и главное меню с базовыми настройками запилить. Работы на месяц (но это не точно).
Кстати, как оформить меню? Игра в 3д, рисовать я умею только пикселями, которые к моему 3д по стилю не катят, тем более в главное меню. Какой-нибудь градиент и партиклей навалить?
>>4258
Двачую, сам сегодня мед комиссию прошёл.
Почему все эти тру разработчиков в соло фултайм не говорят:
1. Ты постоянно на измене и думаешь, не о разработке, а о том что делаешь хуйню, а деньги закончиваются.
2. Ты делаешь меньше потому что постоянно, отвлекаешься, то на сети, то на почту, то на видоскики и статьи.
3.Если живёшь один, то вообще беда, даже просто поговорить не с кем, сидишь сутками дома и постепенно фляга начинает свистеть.
>на работу снова буду устраиваться...
Двачую, сам сегодня мед комиссию прошёл.
Почему все эти тру разработчиков в соло фултайм не говорят:
1. Ты постоянно на измене и думаешь, не о разработке, а о том что делаешь хуйню, а деньги закончиваются.
2. Ты делаешь меньше потому что постоянно, отвлекаешься, то на сети, то на почту, то на видоскики и статьи.
3.Если живёшь один, то вообще беда, даже просто поговорить не с кем, сидишь сутками дома и постепенно фляга начинает свистеть.
>>4278
1. Надо иметь пассивный доход либо большие сбережения, без этого никак, да.
2. Не соглы, в офисе отвлекало больше. Постоянно какой-нибудь ебучий коллега-пиздабол-бездельник от тебя что-то хочет, постоянно конфончки митапы репорты созвоны, от которых потом отходишь час. Рот ебал. Еще на дорогу время въебывать. Дома в соло легче войти в flow state.
3. Фиксится.
1. Надо иметь пассивный доход либо большие сбережения, без этого никак, да.
2. Не соглы, в офисе отвлекало больше. Постоянно какой-нибудь ебучий коллега-пиздабол-бездельник от тебя что-то хочет, постоянно конфончки митапы репорты созвоны, от которых потом отходишь час. Рот ебал. Еще на дорогу время въебывать. Дома в соло легче войти в flow state.
3. Фиксится.
>>4278
Создай себе команду из нейроагентов. В скилах пропиши каждому характер. Один ленивый, но толковый. Другой фантазер без скилов. Третий молчун, который если говорит, то правду матку, как серпом по яицам. Четвертый зумер который работает по два часа в день и то иногда пропадает на несколько дней потому что "устал от работы".
Вот тебе коллектив максимально приближенный к галерному. Уже не одиночный разработчик..
Создай себе команду из нейроагентов. В скилах пропиши каждому характер. Один ленивый, но толковый. Другой фантазер без скилов. Третий молчун, который если говорит, то правду матку, как серпом по яицам. Четвертый зумер который работает по два часа в день и то иногда пропадает на несколько дней потому что "устал от работы".
Вот тебе коллектив максимально приближенный к галерному. Уже не одиночный разработчик..
>>4282
Братюнь я нормальный пчел, если ты можешь общаться с нейронкой, то я нет. Я как бы сам пытался написать подобное и вижу что всё что она мне выдаёт можно умножать на ноль.
>>4281
Ну есть у меня финансовая подушка, нехуёвая, на которой я могу жить лет 10, но блядь инфляция всё съедает, а хату купить под сдачу я сссусь, после всех этих схем долиных.
Я ж работяга, какой офис? Я как то ноут принёс в каптёрку, оборудовал закуток, сделал компьютерный столик, так механник всем мозг вынес, что это такое и зачем здесь стоит стол. Поэтому работал только перед и после работой и по выходным.
Выше описал, что без людей я тупею.
Братюнь я нормальный пчел, если ты можешь общаться с нейронкой, то я нет. Я как бы сам пытался написать подобное и вижу что всё что она мне выдаёт можно умножать на ноль.
>>4281
>1. Надо иметь пассивный доход либо большие сбережения, без этого никак, да.
Ну есть у меня финансовая подушка, нехуёвая, на которой я могу жить лет 10, но блядь инфляция всё съедает, а хату купить под сдачу я сссусь, после всех этих схем долиных.
>2. Не соглы, в офисе отвлекало больше.
Я ж работяга, какой офис? Я как то ноут принёс в каптёрку, оборудовал закуток, сделал компьютерный столик, так механник всем мозг вынес, что это такое и зачем здесь стоит стол. Поэтому работал только перед и после работой и по выходным.
>3. Фиксится.
Выше описал, что без людей я тупею.
>>4285
А вот если бы подкрутил ей нейроттсом голос милой тяночки и отслеживанием по камере твоего положения в комнате и твоих действий с реакцией красивой витуберши (mcp к контроллеру витуберши) - вот тогда бы кайфанул нормально, а так - явно плохо старался. А еще бы проектор сотавить да на стеночку транслировать, уххх
>Я как бы сам пытался написать подобное и вижу что всё что она мне выдаёт можно умножать на ноль.
А вот если бы подкрутил ей нейроттсом голос милой тяночки и отслеживанием по камере твоего положения в комнате и твоих действий с реакцией красивой витуберши (mcp к контроллеру витуберши) - вот тогда бы кайфанул нормально, а так - явно плохо старался. А еще бы проектор сотавить да на стеночку транслировать, уххх
499 Кб, 1810x838>>4293
Блекпилл не отменяет тягу к тяночкам, тем самым няшам стесняшам из несбыточных мечт, нейронка как раз могла бы такой стать (или любой другой по вкусу автора системпромпта)
>Братан, блек пил же, какие тяночки?
Блекпилл не отменяет тягу к тяночкам, тем самым няшам стесняшам из несбыточных мечт, нейронка как раз могла бы такой стать (или любой другой по вкусу автора системпромпта)
>>4278
Не будь на измене. Художник должен быть голодным, имея подушку трудно что-то делать, а так есть стимул чтобы стать успешным.
Буквально как в геймдизайне. Слишком простой уровень сложности - неинтересно, слишком сложный - тоже напрягает, нужно чтобы был челлендж, что вот на тоненького как раз проходишь, тогда получаешь положительную отдачу.
Саморазвиваешься. На работе, обычно просто впахиваешь как черт 9-10 часов, ничего изучить не успеваешь, после работы нет сил. Каждый день как день сурка.
Но если сильно мешает - автоматизируешь отключение сети по расписанию. В годоте документация встроенная. Берешь и делаешь.
Ну ты же говоришь на дваче, тут все твои друзья (но шизиков, конечно, побольше, надо фильтровать). С другой стороны, а если бы у тебя дома завелся второй шизик? А от него уже не избавишься легко.
Но даже когда все идеально. Будут постоянно отвлекать. Вот прям щас надо передвинуть шкаф и поставить кресло, выбрать цвет обоев и микроволновки, вынести мусор и ребенка на футбол. Общаться с половинкой прикольно, когда вы оба ничего не делаете и чиллите. И то будут споры, какой сериал или аниме смотреть. А еще бывают ссоры, ууу.
Так что, ТНН как сказали, только роботяночки проще ходить куда-то специально чтобы пообщаться, и причем чтобы можно было и выбирать с кем, и в любой момент уйти. Что-нибудь типа клуба настолок или онлайн игр (но там и поунижать могут...)
>1. Ты постоянно на измене
Не будь на измене. Художник должен быть голодным, имея подушку трудно что-то делать, а так есть стимул чтобы стать успешным.
Буквально как в геймдизайне. Слишком простой уровень сложности - неинтересно, слишком сложный - тоже напрягает, нужно чтобы был челлендж, что вот на тоненького как раз проходишь, тогда получаешь положительную отдачу.
>2. отвлекаешься, то на сети, то на почту, то на видоскики и статьи.
Саморазвиваешься. На работе, обычно просто впахиваешь как черт 9-10 часов, ничего изучить не успеваешь, после работы нет сил. Каждый день как день сурка.
Но если сильно мешает - автоматизируешь отключение сети по расписанию. В годоте документация встроенная. Берешь и делаешь.
>3.Если живёшь один, то вообще беда, даже просто поговорить не с кем
Ну ты же говоришь на дваче, тут все твои друзья (но шизиков, конечно, побольше, надо фильтровать). С другой стороны, а если бы у тебя дома завелся второй шизик? А от него уже не избавишься легко.
Но даже когда все идеально. Будут постоянно отвлекать. Вот прям щас надо передвинуть шкаф и поставить кресло, выбрать цвет обоев и микроволновки, вынести мусор и ребенка на футбол. Общаться с половинкой прикольно, когда вы оба ничего не делаете и чиллите. И то будут споры, какой сериал или аниме смотреть. А еще бывают ссоры, ууу.
Так что, ТНН как сказали, только роботяночки проще ходить куда-то специально чтобы пообщаться, и причем чтобы можно было и выбирать с кем, и в любой момент уйти. Что-нибудь типа клуба настолок или онлайн игр (но там и поунижать могут...)
>>4281
В свое время решали такие проблемы закрытыми наушниками, можно с шумодавом. Особо говорливым показывали кулак. Митапов в наше время конечно не было столько, думаю просто нахуй бы посылали, сказали - толик, давай вот утром полчаса у тебя на брифинг, вечером тебе скидываем отчеты что реально сделано, и не шатай мозги, тут задача все равно на три дня и послезавтра узнаешь какой прогресс, так что завтра на созвон мне не нужно. Если что не выходит, сам встану, подойду и сообщу тебе.
>2
В свое время решали такие проблемы закрытыми наушниками, можно с шумодавом. Особо говорливым показывали кулак. Митапов в наше время конечно не было столько, думаю просто нахуй бы посылали, сказали - толик, давай вот утром полчаса у тебя на брифинг, вечером тебе скидываем отчеты что реально сделано, и не шатай мозги, тут задача все равно на три дня и послезавтра узнаешь какой прогресс, так что завтра на созвон мне не нужно. Если что не выходит, сам встану, подойду и сообщу тебе.
https://youtu.be/6CHkSG9NWoc
Цодинг Годот потрогал
Цодинг Годот потрогал
https://www.reddit.com/r/gamedev/comments/1uoi481/average_sentiment_around_major_game_engines_on/
Годот тут при том что там про годот
Годот тут при том что там про годот
>>4297
Ну, вы поняли уровень полезности мнения спикера, рейлиб пердолик не знает и не может знать как делаются игры в 2к26, только знает как развлекать толпу пердолингом.
>I never used traditional game enginenes in my entire life
Ну, вы поняли уровень полезности мнения спикера, рейлиб пердолик не знает и не может знать как делаются игры в 2к26, только знает как развлекать толпу пердолингом.
>>4303
Ты явно разжигаешь.
Ты явно разжигаешь.
>>4300
Рано! Ждём пятёрку. Держимся!
Рано! Ждём пятёрку. Держимся!
>>4303
А если сказать по научному, то измеряется степень культизма/вахтерства в сабреддитах.
А если сказать по научному, то измеряется степень культизма/вахтерства в сабреддитах.
954 Кб, 1280x7204.8 дев 1 уже 48 минут как опубликован, а вы спите.
https://godotengine.org/article/dev-snapshot-godot-4-8-dev-1/
https://godotengine.org/article/dev-snapshot-godot-4-8-dev-1/
>>4347
Вместо того, чтобы выпилить этот Game mode, они его дефолтным делают. Пора свой форк делать.
Вместо того, чтобы выпилить этот Game mode, они его дефолтным делают. Пора свой форк делать.
>>4347
Потому что ничего интересного
Потому что ничего интересного
>>4366
Осторожней со своими желаниями. Когда-то и хром выходил с небольшими бампами версий, а потом пошло-поехало и сейчас 150. А уж системд, ууу. Придется тебе каждый день по десятку игр выкатывать.
Осторожней со своими желаниями. Когда-то и хром выходил с небольшими бампами версий, а потом пошло-поехало и сейчас 150. А уж системд, ууу. Придется тебе каждый день по десятку игр выкатывать.
>>4366
5.0 сделают только если будет нужно сломать что-то сильно, новый рендерер или совсем новый обработчик gdscript и т.д., до тех пор будет хоть 4.999
5.0 сделают только если будет нужно сломать что-то сильно, новый рендерер или совсем новый обработчик gdscript и т.д., до тех пор будет хоть 4.999
>>4247
Я тебе по секрету скажу что приложение туда попасть не сможет, равно как и кучу всего сделать тоже. Вин11 все запускает в песочницах и обрубленное в плане доступов папок что я ебу. Другое дело если рассказчик, которому лень ковыряться в настройках, почему-то всё-таки поковырялся ранее уже в самой винде и отключил изоляцию ядра, песочницу, смарт контрол, сам является админом и делает такое вот лицо - 😱когда процесс получает его привилегии. Тогда вопросы уже к юродивому дурочку. Но ты же не такой, правда?
Я тебе по секрету скажу что приложение туда попасть не сможет, равно как и кучу всего сделать тоже. Вин11 все запускает в песочницах и обрубленное в плане доступов папок что я ебу. Другое дело если рассказчик, которому лень ковыряться в настройках, почему-то всё-таки поковырялся ранее уже в самой винде и отключил изоляцию ядра, песочницу, смарт контрол, сам является админом и делает такое вот лицо - 😱когда процесс получает его привилегии. Тогда вопросы уже к юродивому дурочку. Но ты же не такой, правда?
>>4369
Лол нет, я просто буду ждать 6.0.
Лол нет, я просто буду ждать 6.0.
>>4378
Это в которой и ПУСК, и даже ТАСКБАР сломали?
Скорее всего, они там это всё случайно сломали...
А что поделать, если на Windows большинство 100% легальных, чистых и невинных приложений требуют максимального повышения прав а-ля sudo даже для простейшего запуска из-за каких-то багов в ОС? Это нормально. Статус админа в Windows всё равно не предоставляет абсолютный доступ, т.к. множество системных файлов админу не принадлежат (лол). А из профиля "пользователя" ПК на Windows/Linux пользовался вообще невозможно. Это ж не телефон, от которого требуется только звонить и СМСки слать.
Любопытно, Godot на Win11 тоже вынужден права завышать? У него же куча функций, которые лезут непосредственно в систему через API. Даже тупо запуститься - это надо графическое API как-то инициализировать, а ты говоришь - в Win11 как-то испортили доступ ко всем базовым потребностям... Пожалуй, я подожду Win12 или на Linux перейду, при необходимости ВНЕЗАПНО куда-то прейти с Win10.
>Вин11
Это в которой и ПУСК, и даже ТАСКБАР сломали?
>обрубленное в плане доступов
Скорее всего, они там это всё случайно сломали...
>является админом и делает такое вот лицо
А что поделать, если на Windows большинство 100% легальных, чистых и невинных приложений требуют максимального повышения прав а-ля sudo даже для простейшего запуска из-за каких-то багов в ОС? Это нормально. Статус админа в Windows всё равно не предоставляет абсолютный доступ, т.к. множество системных файлов админу не принадлежат (лол). А из профиля "пользователя" ПК на Windows/Linux пользовался вообще невозможно. Это ж не телефон, от которого требуется только звонить и СМСки слать.
Любопытно, Godot на Win11 тоже вынужден права завышать? У него же куча функций, которые лезут непосредственно в систему через API. Даже тупо запуститься - это надо графическое API как-то инициализировать, а ты говоришь - в Win11 как-то испортили доступ ко всем базовым потребностям... Пожалуй, я подожду Win12 или на Linux перейду, при необходимости ВНЕЗАПНО куда-то прейти с Win10.
>>4378
Чет верится с трудом, что это решето, которое сейчас еще копайлотом каждый месяц роняют, вдруг стало каким- то суперзащищенным с песочницей. Более правдоподобно будет, что любая запущенная прога, может прочитать любой файл в пользовательском профиле, и любые запросы в интернет (а значит, и передать файл внутри запроса).
Чет верится с трудом, что это решето, которое сейчас еще копайлотом каждый месяц роняют, вдруг стало каким- то суперзащищенным с песочницей. Более правдоподобно будет, что любая запущенная прога, может прочитать любой файл в пользовательском профиле, и любые запросы в интернет (а значит, и передать файл внутри запроса).
38 Кб, 665x621>>4394
Там вроде еще хуйня какая-то с подписанием экзешников, и новая винда неподписанные блочит все сильнее и сильнее. На реддите читал, чюваки всерьез советуют друг другу покупать ключи на подпись по 1к баксов/год, либо все пихать в стим. Сам годот-то подписан?
Там вроде еще хуйня какая-то с подписанием экзешников, и новая винда неподписанные блочит все сильнее и сильнее. На реддите читал, чюваки всерьез советуют друг другу покупать ключи на подпись по 1к баксов/год, либо все пихать в стим. Сам годот-то подписан?
>>4397
Какая разница? Жмёшь кнопку [БЕГ] и играешь.
Они реально перевели "Run anyway" как "Бег"...
Да, подписан. Вот актуальный сертификат:
У многих старых версий сертификат просрочен.
>>4396
Согласен. Из-за вайбкодеров весь софт ухудшается.
>неподписанные блочит все сильнее и сильнее
Какая разница? Жмёшь кнопку [БЕГ] и играешь.
Они реально перевели "Run anyway" как "Бег"...
>Сам годот-то подписан?
Да, подписан. Вот актуальный сертификат:
>Кому: Prehensile Tales B.V.
>Кем: Certum Code Signing 2021 CA
>Действителен с 2025.06.17 по 2028.06.16
У многих старых версий сертификат просрочен.
>>4396
Согласен. Из-за вайбкодеров весь софт ухудшается.
>>4404
Это мы с тобой привычны к такому, на пиратской винде с пиратским играми и софтом. Западный нежный барен такой хуйни боится, и не станет БЕГ твою игру.
>Жмёшь кнопку [БЕГ] и играешь.
Это мы с тобой привычны к такому, на пиратской винде с пиратским играми и софтом. Западный нежный барен такой хуйни боится, и не станет БЕГ твою игру.
>>4408
Ну, не знаю. Основная ЦА игр - это школота, а школота обычно ничего кроме ремня не боится. Родительский контроль на самом деле нужен, чтоб спасти интернет от наводнения малолетними киберпреступниками...
Уходят времена, когда человек шёл жаловаться в техподдержку "я ничего не трогала, а оно пропало" и получал ответ "попробуйте выключить и включить".
включал свой ПК двумя канцелярскими скрепками в розетку, потому что провод мама от меня прятала
Ну, не знаю. Основная ЦА игр - это школота, а школота обычно ничего кроме ремня не боится. Родительский контроль на самом деле нужен, чтоб спасти интернет от наводнения малолетними киберпреступниками...
Уходят времена, когда человек шёл жаловаться в техподдержку "я ничего не трогала, а оно пропало" и получал ответ "попробуйте выключить и включить".
включал свой ПК двумя канцелярскими скрепками в розетку, потому что провод мама от меня прятала
>>4416
Никому твой протык-пердолик не интересен
Никому твой протык-пердолик не интересен
22 Кб, 655x435>>4347
Попробовал. Думаю, sticky tree items и fuzzy search API могут пригодиться... Я, кстати, давно думал, где можно найти "нечёткий поиск" в API Godot, ведь в менюшках редактора он точно имеется. Где может пригодиться такое в игре? Банальное - поиск по именам сохранений, если у игрока их очень много. Или по именам уровней, локаций, объектов во внутриигровом редакторе, квестам... А также можно придумать игровую механику, которая требует подбирать слова - нечёткий поиск позволяет поднять качество за счёт игнорирования опечаток и/или похожих слов, добавляя интерактивные подсказки как при наборе кода.
Я ещё вот это заметил:
https://github.com/godotengine/godot/pull/110615
Что-то я не помню этот "OKHSL"... Я его, наверное, отключил несколько лет назад и забыл. Кто-то юзал его?
>>4348
Я его у себя давно отключил (так и не разобрался, зачем он может быть нужен) и даже успел забыть о его существовании, лол. Мне сегодня пришлось вспоминать, как его включить обратно (только чтобы оценить изменение GUI - уже выключил эту функцию обратно - мне не нужна), потому что я забыл, где находится настройка функций движка... Вот, смотри на пикриле, как отключить эту назойливую кнопку Game насовсем в своём редакторе без пересборки и даже без перезапуска редактора. Ничего кроме этого делать не нужно - даже не нужно переключать режимы в самом окне Game, потому что при отключении этой кнопки/вкладки возвращается стандартное поведение при запуске, как в старых версиях Godot.
>>4370
"Когда начнут делать Godot 5.0" можно примерно оценить по количеству предложений на этой странице:
https://github.com/godotengine/godot-proposals/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A5.0
Не совсем новый, но планируются какие-то подвижки GDScript, отложенные на время Godot 5.0:
https://github.com/godotengine/godot-proposals/issues/14652
https://gist.github.com/dalexeev/80ba4c4abda0637701a48095fb1604de
Там много чего написано, я не читал пока, но, наверное, это очень долгосрочные планы...
Попробовал. Думаю, sticky tree items и fuzzy search API могут пригодиться... Я, кстати, давно думал, где можно найти "нечёткий поиск" в API Godot, ведь в менюшках редактора он точно имеется. Где может пригодиться такое в игре? Банальное - поиск по именам сохранений, если у игрока их очень много. Или по именам уровней, локаций, объектов во внутриигровом редакторе, квестам... А также можно придумать игровую механику, которая требует подбирать слова - нечёткий поиск позволяет поднять качество за счёт игнорирования опечаток и/или похожих слов, добавляя интерактивные подсказки как при наборе кода.
Я ещё вот это заметил:
>Editor: Use VHS Circle as the default editor color picker shape
https://github.com/godotengine/godot/pull/110615
>FYI: the default shape was changed from VHS circle to OKHSL circle in 4.0
Что-то я не помню этот "OKHSL"... Я его, наверное, отключил несколько лет назад и забыл. Кто-то юзал его?
>>4348
>Вместо того, чтобы выпилить этот Game mode, они его дефолтным делают
Я его у себя давно отключил (так и не разобрался, зачем он может быть нужен) и даже успел забыть о его существовании, лол. Мне сегодня пришлось вспоминать, как его включить обратно (только чтобы оценить изменение GUI - уже выключил эту функцию обратно - мне не нужна), потому что я забыл, где находится настройка функций движка... Вот, смотри на пикриле, как отключить эту назойливую кнопку Game насовсем в своём редакторе без пересборки и даже без перезапуска редактора. Ничего кроме этого делать не нужно - даже не нужно переключать режимы в самом окне Game, потому что при отключении этой кнопки/вкладки возвращается стандартное поведение при запуске, как в старых версиях Godot.
>>4370
>5.0 сделают только если будет нужно сломать что-то сильно
"Когда начнут делать Godot 5.0" можно примерно оценить по количеству предложений на этой странице:
https://github.com/godotengine/godot-proposals/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A5.0
>совсем новый обработчик gdscript
Не совсем новый, но планируются какие-то подвижки GDScript, отложенные на время Godot 5.0:
https://github.com/godotengine/godot-proposals/issues/14652
https://gist.github.com/dalexeev/80ba4c4abda0637701a48095fb1604de
Там много чего написано, я не читал пока, но, наверное, это очень долгосрочные планы...
22 Кб, 655x435>>4347
Попробовал. Думаю, sticky tree items и fuzzy search API могут пригодиться... Я, кстати, давно думал, где можно найти "нечёткий поиск" в API Godot, ведь в менюшках редактора он точно имеется. Где может пригодиться такое в игре? Банальное - поиск по именам сохранений, если у игрока их очень много. Или по именам уровней, локаций, объектов во внутриигровом редакторе, квестам... А также можно придумать игровую механику, которая требует подбирать слова - нечёткий поиск позволяет поднять качество за счёт игнорирования опечаток и/или похожих слов, добавляя интерактивные подсказки как при наборе кода.
Я ещё вот это заметил:
https://github.com/godotengine/godot/pull/110615
Что-то я не помню этот "OKHSL"... Я его, наверное, отключил несколько лет назад и забыл. Кто-то юзал его?
>>4348
Я его у себя давно отключил (так и не разобрался, зачем он может быть нужен) и даже успел забыть о его существовании, лол. Мне сегодня пришлось вспоминать, как его включить обратно (только чтобы оценить изменение GUI - уже выключил эту функцию обратно - мне не нужна), потому что я забыл, где находится настройка функций движка... Вот, смотри на пикриле, как отключить эту назойливую кнопку Game насовсем в своём редакторе без пересборки и даже без перезапуска редактора. Ничего кроме этого делать не нужно - даже не нужно переключать режимы в самом окне Game, потому что при отключении этой кнопки/вкладки возвращается стандартное поведение при запуске, как в старых версиях Godot.
>>4370
"Когда начнут делать Godot 5.0" можно примерно оценить по количеству предложений на этой странице:
https://github.com/godotengine/godot-proposals/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A5.0
Не совсем новый, но планируются какие-то подвижки GDScript, отложенные на время Godot 5.0:
https://github.com/godotengine/godot-proposals/issues/14652
https://gist.github.com/dalexeev/80ba4c4abda0637701a48095fb1604de
Там много чего написано, я не читал пока, но, наверное, это очень долгосрочные планы...
Попробовал. Думаю, sticky tree items и fuzzy search API могут пригодиться... Я, кстати, давно думал, где можно найти "нечёткий поиск" в API Godot, ведь в менюшках редактора он точно имеется. Где может пригодиться такое в игре? Банальное - поиск по именам сохранений, если у игрока их очень много. Или по именам уровней, локаций, объектов во внутриигровом редакторе, квестам... А также можно придумать игровую механику, которая требует подбирать слова - нечёткий поиск позволяет поднять качество за счёт игнорирования опечаток и/или похожих слов, добавляя интерактивные подсказки как при наборе кода.
Я ещё вот это заметил:
>Editor: Use VHS Circle as the default editor color picker shape
https://github.com/godotengine/godot/pull/110615
>FYI: the default shape was changed from VHS circle to OKHSL circle in 4.0
Что-то я не помню этот "OKHSL"... Я его, наверное, отключил несколько лет назад и забыл. Кто-то юзал его?
>>4348
>Вместо того, чтобы выпилить этот Game mode, они его дефолтным делают
Я его у себя давно отключил (так и не разобрался, зачем он может быть нужен) и даже успел забыть о его существовании, лол. Мне сегодня пришлось вспоминать, как его включить обратно (только чтобы оценить изменение GUI - уже выключил эту функцию обратно - мне не нужна), потому что я забыл, где находится настройка функций движка... Вот, смотри на пикриле, как отключить эту назойливую кнопку Game насовсем в своём редакторе без пересборки и даже без перезапуска редактора. Ничего кроме этого делать не нужно - даже не нужно переключать режимы в самом окне Game, потому что при отключении этой кнопки/вкладки возвращается стандартное поведение при запуске, как в старых версиях Godot.
>>4370
>5.0 сделают только если будет нужно сломать что-то сильно
"Когда начнут делать Godot 5.0" можно примерно оценить по количеству предложений на этой странице:
https://github.com/godotengine/godot-proposals/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A5.0
>совсем новый обработчик gdscript
Не совсем новый, но планируются какие-то подвижки GDScript, отложенные на время Godot 5.0:
https://github.com/godotengine/godot-proposals/issues/14652
https://gist.github.com/dalexeev/80ba4c4abda0637701a48095fb1604de
Там много чего написано, я не читал пока, но, наверное, это очень долгосрочные планы...
9 Кб, 258x119>>4438
В оригинале фраза звучала так: "We make 5.0 when we need to break something"
Этот майлстоун может заполняться ещё 15 лет без движения
>можно примерно оценить по количеству предложений на этой странице
В оригинале фраза звучала так: "We make 5.0 when we need to break something"
Этот майлстоун может заполняться ещё 15 лет без движения
>>4438
Точнее, эти все изменения будут актуальные ЕСЛИ они надумают сделать 5.0, но не станут его причиной
>"Когда начнут делать Godot 5.0"
Точнее, эти все изменения будут актуальные ЕСЛИ они надумают сделать 5.0, но не станут его причиной
>>4438
Выглядит запутанно.
Для старых версий кто-то портировал на гдскрипт
https://github.com/godotengine/godot-proposals/issues/12502#issuecomment-2952163265
>sticky tree items
Выглядит запутанно.
>fuzzy search API
Для старых версий кто-то портировал на гдскрипт
https://github.com/godotengine/godot-proposals/issues/12502#issuecomment-2952163265
>>4474
В смысле? У тебя никогда не было ситуации, когда у тебя в дереве 100+ элементов, и пока ты листаешь этот список, уже не помнишь, к какому родителю относятся все эти братья-сёстры? Вот эта фича позволяет видеть родителя нод, даже когда список не помещается на экране и корень дерева улетел далеко наверх. Один нюанс - если дерево имеет глубокую вложенность, из-за этих приклеенных сверху предков будет слишком мало места под нужные тебе ноды...
Не получается скачать файл, но я не думаю, что этот "порт" лучше того, что сделано на C++ и теперь будет доступно через API. Полноценный нечёткий поиск сложнее по вычислениям, чем точный поиск: для точного поиска достаточно отбраковывать по первому несовпадению (в заранее отсортированном по алфавиту списке будет ещё легче), а для нечёткого, если я правильно понимаю, нужно как-то вычислять математическую оценку для всех имеющихся элементов и только эту оценку уже сравнивать, чтобы отсортировать совпадения от наибольшего к наименьшему. Т.е. делать нечёткий поиск на медленном скриптовом языке нерационально.
>>4459
Ну, смотри - если там резко повалит куча issue, которые никуда, кроме как на 5.0, не отложить, им придётся переключиться на создание 5.0, логично? Иначе движок застрянет без улучшений.
>>4460
В том-то и дело, что не ЕСЛИ, а КОГДА - то, что 5.0 будет, известно точно, если все разработчики не разбегутся/не наступит какой-нибудь апокалипсис. Ветку 4.x планируют развивать много лет, но когда накопится неподъёмная куча технического долга, требующего отказ от обратной совместимости (breaking change), тогда и начнётся работа над 5.0. Но даже после релиза 5.0 выйдет ещё несколько минорных 4.x, как это было в случае 3.x.
Так что разрешаю вам всем ждать Godot 5.0. Я не знаю когда, но обязательно придёт...
>>sticky tree items
>Выглядит запутанно.
В смысле? У тебя никогда не было ситуации, когда у тебя в дереве 100+ элементов, и пока ты листаешь этот список, уже не помнишь, к какому родителю относятся все эти братья-сёстры? Вот эта фича позволяет видеть родителя нод, даже когда список не помещается на экране и корень дерева улетел далеко наверх. Один нюанс - если дерево имеет глубокую вложенность, из-за этих приклеенных сверху предков будет слишком мало места под нужные тебе ноды...
>портировал на гдскрипт
Не получается скачать файл, но я не думаю, что этот "порт" лучше того, что сделано на C++ и теперь будет доступно через API. Полноценный нечёткий поиск сложнее по вычислениям, чем точный поиск: для точного поиска достаточно отбраковывать по первому несовпадению (в заранее отсортированном по алфавиту списке будет ещё легче), а для нечёткого, если я правильно понимаю, нужно как-то вычислять математическую оценку для всех имеющихся элементов и только эту оценку уже сравнивать, чтобы отсортировать совпадения от наибольшего к наименьшему. Т.е. делать нечёткий поиск на медленном скриптовом языке нерационально.
>>4459
>when we need to break something
>Этот майлстоун может заполняться ещё 15 лет без движения
Ну, смотри - если там резко повалит куча issue, которые никуда, кроме как на 5.0, не отложить, им придётся переключиться на создание 5.0, логично? Иначе движок застрянет без улучшений.
>>4460
>ЕСЛИ они надумают сделать 5.0
В том-то и дело, что не ЕСЛИ, а КОГДА - то, что 5.0 будет, известно точно, если все разработчики не разбегутся/не наступит какой-нибудь апокалипсис. Ветку 4.x планируют развивать много лет, но когда накопится неподъёмная куча технического долга, требующего отказ от обратной совместимости (breaking change), тогда и начнётся работа над 5.0. Но даже после релиза 5.0 выйдет ещё несколько минорных 4.x, как это было в случае 3.x.
Так что разрешаю вам всем ждать Godot 5.0. Я не знаю когда, но обязательно придёт...
650 Кб, 1004x578>>4477
Я такое видел в vs code. Хз, может можно привыкнуть. Слишком ломает парадигму - протаскиваемого целого листа бумаги. Вместо этого получается какая-то сложная модель оригами.
https://pastebin.com/raw/4LpqcWVd
Ну я же написал - для старых версий.
Я такое видел в vs code. Хз, может можно привыкнуть. Слишком ломает парадигму - протаскиваемого целого листа бумаги. Вместо этого получается какая-то сложная модель оригами.
>Не получается скачать файл
https://pastebin.com/raw/4LpqcWVd
> и теперь будет доступно через API.
Ну я же написал - для старых версий.
Какие-то японцы теперь донатят в годот. Хуй пойми чего делают.
>>4482
Вообще-то, не "лист бумаги", а "свиток":
https://en.wikipedia.org/wiki/Scroll
https://en.wikipedia.org/wiki/Scrolling
https://en.wikipedia.org/wiki/Scrollbar
В русском языке связь утрачена, но в английском прослеживается чёткая связь между GUI-виджетом "scrollbar" и древними свитками из самых разных материалов, на которых писали вертикально (или горизонтально - столбиками). Если ты пишешь на вертикальном условно-бесконечном свитке, то нет проблемы сложить свиток так, чтобы было видно отдельную верхнюю строчку поверх нижних строк.
Где-то когда-то видел картинку такого свитка, но не получается найти. В общем, представь себе ткань, сложенную в несколько слоёв, и на выступах сверху напечатаны верхние строчки (sticky item), а дальше, на ровной поверхности, твой основной текст.
До появления компьютерных мониторов также часто встречался вывод текста на длинном рулоне бумаги, который наверняка тоже можно было так сложить. Наверняка видел рулоны кассовых аппаратов (такое можно и домой купить как мини-принтер), вот что-то подобное было базовым "дисплеем" компьютеров...
Так-то отдельные листы бумаги - это неестественно. Производят всегда длинный рулон, который потом нарезается так, как нужно заказчику. Крупные листы бумаги зачастую хранятся свёрнутыми в рулон...
>протаскиваемого целого листа бумаги
Вообще-то, не "лист бумаги", а "свиток":
https://en.wikipedia.org/wiki/Scroll
https://en.wikipedia.org/wiki/Scrolling
https://en.wikipedia.org/wiki/Scrollbar
В русском языке связь утрачена, но в английском прослеживается чёткая связь между GUI-виджетом "scrollbar" и древними свитками из самых разных материалов, на которых писали вертикально (или горизонтально - столбиками). Если ты пишешь на вертикальном условно-бесконечном свитке, то нет проблемы сложить свиток так, чтобы было видно отдельную верхнюю строчку поверх нижних строк.
Где-то когда-то видел картинку такого свитка, но не получается найти. В общем, представь себе ткань, сложенную в несколько слоёв, и на выступах сверху напечатаны верхние строчки (sticky item), а дальше, на ровной поверхности, твой основной текст.
До появления компьютерных мониторов также часто встречался вывод текста на длинном рулоне бумаги, который наверняка тоже можно было так сложить. Наверняка видел рулоны кассовых аппаратов (такое можно и домой купить как мини-принтер), вот что-то подобное было базовым "дисплеем" компьютеров...
Так-то отдельные листы бумаги - это неестественно. Производят всегда длинный рулон, который потом нарезается так, как нужно заказчику. Крупные листы бумаги зачастую хранятся свёрнутыми в рулон...
33,2 Мб, webm,1280x606, 2:11
>>4517
Портировщики всяких лицензионных франшиз на мобилки.
Портировщики всяких лицензионных франшиз на мобилки.
>>4482
>>4530
Накидал по-быстрому в Blender, как я это вижу.
Кстати, кто-нибудь знает, что лучше:
- возиться со SpringBoneSimulator3D,
- или просто вручную анимировать?
Я как-то пробовал - SpringBone сложно управлять...
Мне нужно будет ОЧЕНЬ МНОГО костей заджиглить.
>ломает парадигму - протаскиваемого целого листа бумаги
>>4530
>видел картинку такого свитка, но не получается найти
Накидал по-быстрому в Blender, как я это вижу.
Кстати, кто-нибудь знает, что лучше:
- возиться со SpringBoneSimulator3D,
- или просто вручную анимировать?
Я как-то пробовал - SpringBone сложно управлять...
Мне нужно будет ОЧЕНЬ МНОГО костей заджиглить.
280 Кб, mp4,600x800, 0:06
>>4592
У кого Firefox и "видео не найдено":
Лол. Вот версия YUV420, должно проигрываться...
У кого Firefox и "видео не найдено":
>Bug 1368063 (yuv444) Opened 9 years ago
>Video with YUV444 chroma subsampling can't be played back
Лол. Вот версия YUV420, должно проигрываться...
>>4592
У меня в фф все ок. Да, именно так это и работает, и вот это мне кажется сомнительным удобством. Конечно, не исключаю, что я просто старый дед, которому уже трудно учить новое.
У меня в фф все ок. Да, именно так это и работает, и вот это мне кажется сомнительным удобством. Конечно, не исключаю, что я просто старый дед, которому уже трудно учить новое.
>>4597
А, линукс, там наверняка ментейнеры репозитория самостоятельно пофиксили, вместо ленивых разрабов. Штош.
А, линукс, там наверняка ментейнеры репозитория самостоятельно пофиксили, вместо ленивых разрабов. Штош.
>>4596 >>4597 >>4598
Суть в том, что они юзают системные декодеры:
https://bugzilla.mozilla.org/show_bug.cgi?id=1368063
>>4595
Ты никогда не был вынужден листать вверх, чтобы свернуть длинный список, который занимает много места на экране, но тебе он не нужен, потому что ты работаешь с нижними нодами и их родителями? На том скриншоте можно было бы вручную свернуть все эти длинные списки сверху, чтобы приблизить нижние ноды к родителям. Но теперь Godot делает это автоматически.
Кстати, некоторые редакторы заметок/персональных вики (Obsidian, TiddlyWiki) поддерживают прилипание заголовка заметки к верху экрана, если заметка длинная и не помещается целиком на экране. По-моему, это удобно, чтобы не терять контекст, над чем ты в данный момент работаешь, когда тебе приходится часто переключаться между несколькими длинными заметками.
Но вот в редакторе кода я бы такое не хотел видеть, наверное. Функции должны быть короткими. Если твоя функция растягивается на два экрана - пора разделить её на несколько отдельных функций. То же самое с классами, если у тебя одно только перечисление всех требуемых переменных выходит на пять экранов, не лучше ли разделить класс на несколько? Т.е. хорошему коду такая фича бесполезна, а плохому коду нужен рефакторинг, а не костыли в IDE.
Суть в том, что они юзают системные декодеры:
https://bugzilla.mozilla.org/show_bug.cgi?id=1368063
>9 years ago
>We don't support YUV444 at this stage.
>If h264 probably never as we rely on systems decoders.
>8 years ago
>While ffmpeg can decode them, neither windows WMF decoder nor Apple's one can.
>For coonsistency sake, we've disabled them on Linux too.
>1 year ago
>Now working on Linux 133.0...
>>4595
>вот это мне кажется сомнительным удобством
Ты никогда не был вынужден листать вверх, чтобы свернуть длинный список, который занимает много места на экране, но тебе он не нужен, потому что ты работаешь с нижними нодами и их родителями? На том скриншоте можно было бы вручную свернуть все эти длинные списки сверху, чтобы приблизить нижние ноды к родителям. Но теперь Godot делает это автоматически.
Кстати, некоторые редакторы заметок/персональных вики (Obsidian, TiddlyWiki) поддерживают прилипание заголовка заметки к верху экрана, если заметка длинная и не помещается целиком на экране. По-моему, это удобно, чтобы не терять контекст, над чем ты в данный момент работаешь, когда тебе приходится часто переключаться между несколькими длинными заметками.
Но вот в редакторе кода я бы такое не хотел видеть, наверное. Функции должны быть короткими. Если твоя функция растягивается на два экрана - пора разделить её на несколько отдельных функций. То же самое с классами, если у тебя одно только перечисление всех требуемых переменных выходит на пять экранов, не лучше ли разделить класс на несколько? Т.е. хорошему коду такая фича бесполезна, а плохому коду нужен рефакторинг, а не костыли в IDE.
12 Кб, 218x245>>4602
Если большая вложенность дерева, надо делить на сцены.
Я предпочитаю сам сворачивать и разворачивать те поддеревья, которые мне надо. Наверное, в этом и проблема - не вижу тут способ контролировать это.
Тут, скорее, надо тогда какой-то интеллектуальный алгоритм, может быть с настройками, паттерн матчингом, может быть нейронкой.
Хуже всего, что это невидимое. В редакторе кода хотя бы пишут номера строк, и можно понять, что не весь контент, там же - удачи понять, есть ли узлы с номера 1 по 3.
Если большая вложенность дерева, надо делить на сцены.
Я предпочитаю сам сворачивать и разворачивать те поддеревья, которые мне надо. Наверное, в этом и проблема - не вижу тут способ контролировать это.
Тут, скорее, надо тогда какой-то интеллектуальный алгоритм, может быть с настройками, паттерн матчингом, может быть нейронкой.
Хуже всего, что это невидимое. В редакторе кода хотя бы пишут номера строк, и можно понять, что не весь контент, там же - удачи понять, есть ли узлы с номера 1 по 3.
>>4604
Не всегда получается, иногда хочешь по-быстрому накидать.
Думаю, что дизайн дерева сцены ещё поменяется в будущем.
Меня больше радует, что теперь файловую систему можно комфортно держать сбоку, а не снизу экрана. Раньше в том окошке постоянно папки разворачивались и занимали много места. Разделение на две части - папки и файлы в выделенной папке - помогало, но не очень, т.к. некоторые папки большие, а другие почти пустые. А теперь этот список папок сам по себе сворачивается, когда надо, и навигация должна, по-моему, упроститься. Посмотрим...
>надо делить на сцены
Не всегда получается, иногда хочешь по-быстрому накидать.
>хотя бы пишут номера строк
Думаю, что дизайн дерева сцены ещё поменяется в будущем.
Меня больше радует, что теперь файловую систему можно комфортно держать сбоку, а не снизу экрана. Раньше в том окошке постоянно папки разворачивались и занимали много места. Разделение на две части - папки и файлы в выделенной папке - помогало, но не очень, т.к. некоторые папки большие, а другие почти пустые. А теперь этот список папок сам по себе сворачивается, когда надо, и навигация должна, по-моему, упроститься. Посмотрим...
>>4594
У меня LibreWolf (клон FF, без рекламной и АИ чуши) и всё окей
>У кого Firefox и "видео не найдено":
У меня LibreWolf (клон FF, без рекламной и АИ чуши) и всё окей
>>4611
Нужно придумать имя и выбрать папку, а потом убедиться, что все настройки правильно сохранились или сбросились (поди пойми, хочешь ли ты, чтобы они сохранились в другом файле или сбросились там и сохранились здесь?). Если нужно отредактировать внутреннюю ноду - нужно решить, юзать ли "Editable Children", которая может заглючить или помешать обновлению параметров из файла сцены в будущем, или открыть сцену во второй вкладке и потом, возможно, перезагрузить главную сцену, ведь она не всегда подхватывает только что изменённые данные, и иногда перезаписывает старыми... А потом ты понимаешь, что сделал какую-то фигню и её нужно удалить, чтоб не мешалась в будущем, но ты удалил ссылку на сцену из главной сцены, а файл той сцены где-то там валяется... И когда ты на него вдруг наткнёшься, ты уже не помнишь, зачем он был нужен и нужен ли. Особенно если ты сделал:
После чего кнопка "открыть файл сцены" пропадает и ищи её потом в своих папках... Обычно я стараюсь складывать все относящиеся друг к другу сцены в одну папку с подпапками, чтобы потом их можно было все сразу удалить или переместить куда-то, но иногда бывает, что кладу одну сцену в другое место, и потом использую её... или уже не использую... в куче других сцен. Я знаю про возможность глянуть список пользователей сцены, но он может сломаться, даже после того, как сделали систему UID.
В общем, намного проще навалить нод-дубликатов и потом просто удалить сцену целиком, или оставить её и забить болт на неё, чем если она развалится на десяток мелких кусочков в разных местах файловой системы и ты потом не знаешь, что к чему относится, относится ли вообще к чему-то, и зачем ты это всё сделал. Я даже не знаю, как решить эту проблему - в прошлом хотел написать аддон для менеджмента взаимосвязей файлов в проекте, но мне хотелось сделать его автоматическим (иначе в чём отличие о файловой системы?), но я не разобрался, как сканировать связи между сценами, и как-то забросил всю эту задумку...
>Save branch as Scene
Нужно придумать имя и выбрать папку, а потом убедиться, что все настройки правильно сохранились или сбросились (поди пойми, хочешь ли ты, чтобы они сохранились в другом файле или сбросились там и сохранились здесь?). Если нужно отредактировать внутреннюю ноду - нужно решить, юзать ли "Editable Children", которая может заглючить или помешать обновлению параметров из файла сцены в будущем, или открыть сцену во второй вкладке и потом, возможно, перезагрузить главную сцену, ведь она не всегда подхватывает только что изменённые данные, и иногда перезаписывает старыми... А потом ты понимаешь, что сделал какую-то фигню и её нужно удалить, чтоб не мешалась в будущем, но ты удалил ссылку на сцену из главной сцены, а файл той сцены где-то там валяется... И когда ты на него вдруг наткнёшься, ты уже не помнишь, зачем он был нужен и нужен ли. Особенно если ты сделал:
>Make Scene local
После чего кнопка "открыть файл сцены" пропадает и ищи её потом в своих папках... Обычно я стараюсь складывать все относящиеся друг к другу сцены в одну папку с подпапками, чтобы потом их можно было все сразу удалить или переместить куда-то, но иногда бывает, что кладу одну сцену в другое место, и потом использую её... или уже не использую... в куче других сцен. Я знаю про возможность глянуть список пользователей сцены, но он может сломаться, даже после того, как сделали систему UID.
В общем, намного проще навалить нод-дубликатов и потом просто удалить сцену целиком, или оставить её и забить болт на неё, чем если она развалится на десяток мелких кусочков в разных местах файловой системы и ты потом не знаешь, что к чему относится, относится ли вообще к чему-то, и зачем ты это всё сделал. Я даже не знаю, как решить эту проблему - в прошлом хотел написать аддон для менеджмента взаимосвязей файлов в проекте, но мне хотелось сделать его автоматическим (иначе в чём отличие о файловой системы?), но я не разобрался, как сканировать связи между сценами, и как-то забросил всю эту задумку...
>>4611
Нужно придумать имя и выбрать папку, а потом убедиться, что все настройки правильно сохранились или сбросились (поди пойми, хочешь ли ты, чтобы они сохранились в другом файле или сбросились там и сохранились здесь?). Если нужно отредактировать внутреннюю ноду - нужно решить, юзать ли "Editable Children", которая может заглючить или помешать обновлению параметров из файла сцены в будущем, или открыть сцену во второй вкладке и потом, возможно, перезагрузить главную сцену, ведь она не всегда подхватывает только что изменённые данные, и иногда перезаписывает старыми... А потом ты понимаешь, что сделал какую-то фигню и её нужно удалить, чтоб не мешалась в будущем, но ты удалил ссылку на сцену из главной сцены, а файл той сцены где-то там валяется... И когда ты на него вдруг наткнёшься, ты уже не помнишь, зачем он был нужен и нужен ли. Особенно если ты сделал:
После чего кнопка "открыть файл сцены" пропадает и ищи её потом в своих папках... Обычно я стараюсь складывать все относящиеся друг к другу сцены в одну папку с подпапками, чтобы потом их можно было все сразу удалить или переместить куда-то, но иногда бывает, что кладу одну сцену в другое место, и потом использую её... или уже не использую... в куче других сцен. Я знаю про возможность глянуть список пользователей сцены, но он может сломаться, даже после того, как сделали систему UID.
В общем, намного проще навалить нод-дубликатов и потом просто удалить сцену целиком, или оставить её и забить болт на неё, чем если она развалится на десяток мелких кусочков в разных местах файловой системы и ты потом не знаешь, что к чему относится, относится ли вообще к чему-то, и зачем ты это всё сделал. Я даже не знаю, как решить эту проблему - в прошлом хотел написать аддон для менеджмента взаимосвязей файлов в проекте, но мне хотелось сделать его автоматическим (иначе в чём отличие о файловой системы?), но я не разобрался, как сканировать связи между сценами, и как-то забросил всю эту задумку...
>Save branch as Scene
Нужно придумать имя и выбрать папку, а потом убедиться, что все настройки правильно сохранились или сбросились (поди пойми, хочешь ли ты, чтобы они сохранились в другом файле или сбросились там и сохранились здесь?). Если нужно отредактировать внутреннюю ноду - нужно решить, юзать ли "Editable Children", которая может заглючить или помешать обновлению параметров из файла сцены в будущем, или открыть сцену во второй вкладке и потом, возможно, перезагрузить главную сцену, ведь она не всегда подхватывает только что изменённые данные, и иногда перезаписывает старыми... А потом ты понимаешь, что сделал какую-то фигню и её нужно удалить, чтоб не мешалась в будущем, но ты удалил ссылку на сцену из главной сцены, а файл той сцены где-то там валяется... И когда ты на него вдруг наткнёшься, ты уже не помнишь, зачем он был нужен и нужен ли. Особенно если ты сделал:
>Make Scene local
После чего кнопка "открыть файл сцены" пропадает и ищи её потом в своих папках... Обычно я стараюсь складывать все относящиеся друг к другу сцены в одну папку с подпапками, чтобы потом их можно было все сразу удалить или переместить куда-то, но иногда бывает, что кладу одну сцену в другое место, и потом использую её... или уже не использую... в куче других сцен. Я знаю про возможность глянуть список пользователей сцены, но он может сломаться, даже после того, как сделали систему UID.
В общем, намного проще навалить нод-дубликатов и потом просто удалить сцену целиком, или оставить её и забить болт на неё, чем если она развалится на десяток мелких кусочков в разных местах файловой системы и ты потом не знаешь, что к чему относится, относится ли вообще к чему-то, и зачем ты это всё сделал. Я даже не знаю, как решить эту проблему - в прошлом хотел написать аддон для менеджмента взаимосвязей файлов в проекте, но мне хотелось сделать его автоматическим (иначе в чём отличие о файловой системы?), но я не разобрался, как сканировать связи между сценами, и как-то забросил всю эту задумку...
Какое объяснение, кроме "бага", есть тому, что до выполнения _ready (пока нода не добавлена в дерево) можно вызвать функцию типа
но нельзя сделать
т.к. парсер скрипта говорит, что такое сработает только с onready
Функция, конечно, прекрасно отрабатывает
> func get_node(): return $Node
но нельзя сделать
> var node = $Node
т.к. парсер скрипта говорит, что такое сработает только с onready
Функция, конечно, прекрасно отрабатывает
>>4638
А что она возвращает? Null? Должно выбрасывать ошибку доступа.
Если ты про заголовок файла (до объявления функций): эта строчка должна выполняться до начала инициализации (до вызова _init()), а "get_node("Node")" не имеет смысла в этот момент, потому что у ноды нет ни одного потомка. Парсер просто предупреждает, что в переменной всегда будет null, а не то, что ты там хочешь/ожидаешь увидеть. Объявление "@onready var" откладывает вызов get_node() на время после _init() и после _enter_tree(), но перед _ready(), когда потомки ноды уже готовы, а сама нода готовится, но уже может потребовать доступ к потомкам.
Порядок инициализации примерно такой (точно не знаю, могу ошибаться):
1. Создаётся базовый объект-нода на стороне C++ со значениями по умолчанию.
2. Парсится скрипт и создаётся объект, который как-то присоединяется к этой базовой ноде и задаёт свои значения по умолчанию в обычных полях (без onready). Но потомков у ноды ещё нет.
3. Выполняется _init(), где могут быть какие-то дополнительные операции, касающиеся объекта.
4. Процесс повторяется для всех нод в сцене, если это создание экземпляра из PackedScene.
5. Когда нода добавляется в дерево, выполняется _enter_tree() у неё и затем у всех её потомков.
6. Перед вызовом _ready(), инициализируются все @onready var, если они есть.
7. Выполняется _ready() - сначала у потомков, только после них - у предка.
В общем, если ты хочешь получить ноду-потомка - ты должен дождаться _ready(), в противном случае это бессмысленное нарушение порядка инициализации. Если хочешь получить ноду-предка, то нужно дождаться хотя бы _enter_tree(), иначе предка просто нет (а предок ноды внутри упакованной сцены ещё не полностью готов к работе, нужно ждать его _ready()). А если хочешь получить глобальную ноду типа get_node("/root/Node"), то твоя архитектура в будущем отстрелит тебе обе ноги, и будет очень больно распутывать глубок зависимостей через remote scene view...
>>4640
Здесь нет инициализации, get() вызывается только когда ты обращаешься к полю ноды, а к нему ты можешь обратиться только когда нода уже полностью инициализировалась (но не обязательно вошла в дерево сцены).
>Функция, конечно, прекрасно отрабатывает
А что она возвращает? Null? Должно выбрасывать ошибку доступа.
>но нельзя сделать
>>var node = $Node
Если ты про заголовок файла (до объявления функций): эта строчка должна выполняться до начала инициализации (до вызова _init()), а "get_node("Node")" не имеет смысла в этот момент, потому что у ноды нет ни одного потомка. Парсер просто предупреждает, что в переменной всегда будет null, а не то, что ты там хочешь/ожидаешь увидеть. Объявление "@onready var" откладывает вызов get_node() на время после _init() и после _enter_tree(), но перед _ready(), когда потомки ноды уже готовы, а сама нода готовится, но уже может потребовать доступ к потомкам.
Порядок инициализации примерно такой (точно не знаю, могу ошибаться):
1. Создаётся базовый объект-нода на стороне C++ со значениями по умолчанию.
2. Парсится скрипт и создаётся объект, который как-то присоединяется к этой базовой ноде и задаёт свои значения по умолчанию в обычных полях (без onready). Но потомков у ноды ещё нет.
3. Выполняется _init(), где могут быть какие-то дополнительные операции, касающиеся объекта.
4. Процесс повторяется для всех нод в сцене, если это создание экземпляра из PackedScene.
5. Когда нода добавляется в дерево, выполняется _enter_tree() у неё и затем у всех её потомков.
6. Перед вызовом _ready(), инициализируются все @onready var, если они есть.
7. Выполняется _ready() - сначала у потомков, только после них - у предка.
В общем, если ты хочешь получить ноду-потомка - ты должен дождаться _ready(), в противном случае это бессмысленное нарушение порядка инициализации. Если хочешь получить ноду-предка, то нужно дождаться хотя бы _enter_tree(), иначе предка просто нет (а предок ноды внутри упакованной сцены ещё не полностью готов к работе, нужно ждать его _ready()). А если хочешь получить глобальную ноду типа get_node("/root/Node"), то твоя архитектура в будущем отстрелит тебе обе ноги, и будет очень больно распутывать глубок зависимостей через remote scene view...
>>4640
>var node:
>get: return $Node
Здесь нет инициализации, get() вызывается только когда ты обращаешься к полю ноды, а к нему ты можешь обратиться только когда нода уже полностью инициализировалась (но не обязательно вошла в дерево сцены).
>>4638
А что она возвращает? Null? Должно выбрасывать ошибку доступа.
Если ты про заголовок файла (до объявления функций): эта строчка должна выполняться до начала инициализации (до вызова _init()), а "get_node("Node")" не имеет смысла в этот момент, потому что у ноды нет ни одного потомка. Парсер просто предупреждает, что в переменной всегда будет null, а не то, что ты там хочешь/ожидаешь увидеть. Объявление "@onready var" откладывает вызов get_node() на время после _init() и после _enter_tree(), но перед _ready(), когда потомки ноды уже готовы, а сама нода готовится, но уже может потребовать доступ к потомкам.
Порядок инициализации примерно такой (точно не знаю, могу ошибаться):
1. Создаётся базовый объект-нода на стороне C++ со значениями по умолчанию.
2. Парсится скрипт и создаётся объект, который как-то присоединяется к этой базовой ноде и задаёт свои значения по умолчанию в обычных полях (без onready). Но потомков у ноды ещё нет.
3. Выполняется _init(), где могут быть какие-то дополнительные операции, касающиеся объекта.
4. Процесс повторяется для всех нод в сцене, если это создание экземпляра из PackedScene.
5. Когда нода добавляется в дерево, выполняется _enter_tree() у неё и затем у всех её потомков.
6. Перед вызовом _ready(), инициализируются все @onready var, если они есть.
7. Выполняется _ready() - сначала у потомков, только после них - у предка.
В общем, если ты хочешь получить ноду-потомка - ты должен дождаться _ready(), в противном случае это бессмысленное нарушение порядка инициализации. Если хочешь получить ноду-предка, то нужно дождаться хотя бы _enter_tree(), иначе предка просто нет (а предок ноды внутри упакованной сцены ещё не полностью готов к работе, нужно ждать его _ready()). А если хочешь получить глобальную ноду типа get_node("/root/Node"), то твоя архитектура в будущем отстрелит тебе обе ноги, и будет очень больно распутывать глубок зависимостей через remote scene view...
>>4640
Здесь нет инициализации, get() вызывается только когда ты обращаешься к полю ноды, а к нему ты можешь обратиться только когда нода уже полностью инициализировалась (но не обязательно вошла в дерево сцены).
>Функция, конечно, прекрасно отрабатывает
А что она возвращает? Null? Должно выбрасывать ошибку доступа.
>но нельзя сделать
>>var node = $Node
Если ты про заголовок файла (до объявления функций): эта строчка должна выполняться до начала инициализации (до вызова _init()), а "get_node("Node")" не имеет смысла в этот момент, потому что у ноды нет ни одного потомка. Парсер просто предупреждает, что в переменной всегда будет null, а не то, что ты там хочешь/ожидаешь увидеть. Объявление "@onready var" откладывает вызов get_node() на время после _init() и после _enter_tree(), но перед _ready(), когда потомки ноды уже готовы, а сама нода готовится, но уже может потребовать доступ к потомкам.
Порядок инициализации примерно такой (точно не знаю, могу ошибаться):
1. Создаётся базовый объект-нода на стороне C++ со значениями по умолчанию.
2. Парсится скрипт и создаётся объект, который как-то присоединяется к этой базовой ноде и задаёт свои значения по умолчанию в обычных полях (без onready). Но потомков у ноды ещё нет.
3. Выполняется _init(), где могут быть какие-то дополнительные операции, касающиеся объекта.
4. Процесс повторяется для всех нод в сцене, если это создание экземпляра из PackedScene.
5. Когда нода добавляется в дерево, выполняется _enter_tree() у неё и затем у всех её потомков.
6. Перед вызовом _ready(), инициализируются все @onready var, если они есть.
7. Выполняется _ready() - сначала у потомков, только после них - у предка.
В общем, если ты хочешь получить ноду-потомка - ты должен дождаться _ready(), в противном случае это бессмысленное нарушение порядка инициализации. Если хочешь получить ноду-предка, то нужно дождаться хотя бы _enter_tree(), иначе предка просто нет (а предок ноды внутри упакованной сцены ещё не полностью готов к работе, нужно ждать его _ready()). А если хочешь получить глобальную ноду типа get_node("/root/Node"), то твоя архитектура в будущем отстрелит тебе обе ноги, и будет очень больно распутывать глубок зависимостей через remote scene view...
>>4640
>var node:
>get: return $Node
Здесь нет инициализации, get() вызывается только когда ты обращаешься к полю ноды, а к нему ты можешь обратиться только когда нода уже полностью инициализировалась (но не обязательно вошла в дерево сцены).
>>4643
Я показал 2 куска кода которые возвращают ноду до выполнения _ready и когда сцена даже не в дереве, можешь просто сам проверить.
Мой кейс, представь чат, сообщение чата это отдельная сцена - message.tscn
В ней родительская нода - PanelContainer и дочерняя к ней - $chat:RichTextLabel (у ней нужно получить доступ, чтобы добавить в неё текст)
Делаем инстанс сцены
Оба варианта выше - работают, скорее всего им нужно уже убрать проверку на использование $ в переменных без аннотации @onready
>В общем, если ты хочешь получить ноду-потомка - ты должен дождаться _ready()
Я показал 2 куска кода которые возвращают ноду до выполнения _ready и когда сцена даже не в дереве, можешь просто сам проверить.
Мой кейс, представь чат, сообщение чата это отдельная сцена - message.tscn
В ней родительская нода - PanelContainer и дочерняя к ней - $chat:RichTextLabel (у ней нужно получить доступ, чтобы добавить в неё текст)
Делаем инстанс сцены
>const MESSAGE:PackedScene = preload("res://message.tscn")
>...
>var msg: Message = MESSAGE.instantiate()
># вот тут я получаю доступ к дочерней ноде
>var chat = msg.chat
> или var chat = msg.get_chat_node()
>chat.add_text()
>v_box_container.add_child(msg) # _ready выполнится вот тут
Оба варианта выше - работают, скорее всего им нужно уже убрать проверку на использование $ в переменных без аннотации @onready
>>4643
И если попытаешься, опираясь на документацию, меня переубедить, что у меня _ready выполняется до телодвижений, раз я получаю ноду, я пихал print в функцию возвращающую ноду и в _ready, последняя выводилась позже
И если попытаешься, опираясь на документацию, меня переубедить, что у меня _ready выполняется до телодвижений, раз я получаю ноду, я пихал print в функцию возвращающую ноду и в _ready, последняя выводилась позже
>>4648
C load тоже работает
думаю дело в:
C load тоже работает
думаю дело в:
>скорее всего им нужно уже убрать проверку на использование $ в переменных без аннотации @onready
>>4645
Ты прав в том, что можно получить доступ к уже инициализированной ноде до вхождения в дерево сцены - я и сам так делал в своих проектах ещё на Godot 3.x, но почему-то забыл об этом, но это всё не так важно, потому что это не отменяет того, что нельзя получить доступ к ноде, когда ты только начал инициализацию - т.е. тогда, когда полям присваиваются значения по умолчанию. Поэтому сообщение об ошибке предупреждает пользователя правильно - там действительно возвращается null, поскольку нода-предок не инициализирована и не имеет никаких нод-потомков. Так что полностью убирать это предупреждение нерационально, хотя в настройках проекта ты можешь его отключить... И, честно говоря, не знаю, стоит ли полагаться на возможность получить доступ к ноде до вхождение в дерево сцены. Судя по всему, официально _ready() считается главной точкой входа, а она только при добавлении в дерево сцены вызывается, и @onready вызывается строго перед ней, а его везде рекомендуют использовать - и в документации, и в туториалах. Кто знает, вдруг они что-то поменяют внутри, и ноды перестанут находиться до входа в дерево? Хотя вряд ли они уберут поведение, на которое многие полагаются, даже если оно расходится с документацией.
Я бы лучше сделал так, через функцию-"обёртку" в корневой ноде message.tscn:
Чтобы абстрагировать внешнего пользователя от деталей имплементации - если вдруг ты решишь, например, заменить RichTextLabel на ноду другого класса, или даже на несколько отдельных нод внутри контейнера, то внешний код в твоём случае сразу посыпется ошибками и его будет трудно переделать во всех местах (подразумевая, что ты это вызываешь из разных мест проекта), а с такой функцией-обёрткой тебе будет достаточно изменить содержимое одной этой функции-обёртки, и всё внешнее поведение сохранится без изменений - "блок текста принимает текст". Использовать ли тут $Label напрямую или кэшировать - зависит от того, как часто ты меняешь текст. Если тебе достаточно один раз поставить текст и всё, то сохранять ссылку на Label нигде не нужно.
Ты прав в том, что можно получить доступ к уже инициализированной ноде до вхождения в дерево сцены - я и сам так делал в своих проектах ещё на Godot 3.x, но почему-то забыл об этом, но это всё не так важно, потому что это не отменяет того, что нельзя получить доступ к ноде, когда ты только начал инициализацию - т.е. тогда, когда полям присваиваются значения по умолчанию. Поэтому сообщение об ошибке предупреждает пользователя правильно - там действительно возвращается null, поскольку нода-предок не инициализирована и не имеет никаких нод-потомков. Так что полностью убирать это предупреждение нерационально, хотя в настройках проекта ты можешь его отключить... И, честно говоря, не знаю, стоит ли полагаться на возможность получить доступ к ноде до вхождение в дерево сцены. Судя по всему, официально _ready() считается главной точкой входа, а она только при добавлении в дерево сцены вызывается, и @onready вызывается строго перед ней, а его везде рекомендуют использовать - и в документации, и в туториалах. Кто знает, вдруг они что-то поменяют внутри, и ноды перестанут находиться до входа в дерево? Хотя вряд ли они уберут поведение, на которое многие полагаются, даже если оно расходится с документацией.
>>var chat = msg.chat
>>chat.add_text()
Я бы лучше сделал так, через функцию-"обёртку" в корневой ноде message.tscn:
>extends PanelContainer
>func add_text(text: String) -> void:
>_ $Label.text = text
Чтобы абстрагировать внешнего пользователя от деталей имплементации - если вдруг ты решишь, например, заменить RichTextLabel на ноду другого класса, или даже на несколько отдельных нод внутри контейнера, то внешний код в твоём случае сразу посыпется ошибками и его будет трудно переделать во всех местах (подразумевая, что ты это вызываешь из разных мест проекта), а с такой функцией-обёрткой тебе будет достаточно изменить содержимое одной этой функции-обёртки, и всё внешнее поведение сохранится без изменений - "блок текста принимает текст". Использовать ли тут $Label напрямую или кэшировать - зависит от того, как часто ты меняешь текст. Если тебе достаточно один раз поставить текст и всё, то сохранять ссылку на Label нигде не нужно.
>>4645
Ты прав в том, что можно получить доступ к уже инициализированной ноде до вхождения в дерево сцены - я и сам так делал в своих проектах ещё на Godot 3.x, но почему-то забыл об этом, но это всё не так важно, потому что это не отменяет того, что нельзя получить доступ к ноде, когда ты только начал инициализацию - т.е. тогда, когда полям присваиваются значения по умолчанию. Поэтому сообщение об ошибке предупреждает пользователя правильно - там действительно возвращается null, поскольку нода-предок не инициализирована и не имеет никаких нод-потомков. Так что полностью убирать это предупреждение нерационально, хотя в настройках проекта ты можешь его отключить... И, честно говоря, не знаю, стоит ли полагаться на возможность получить доступ к ноде до вхождение в дерево сцены. Судя по всему, официально _ready() считается главной точкой входа, а она только при добавлении в дерево сцены вызывается, и @onready вызывается строго перед ней, а его везде рекомендуют использовать - и в документации, и в туториалах. Кто знает, вдруг они что-то поменяют внутри, и ноды перестанут находиться до входа в дерево? Хотя вряд ли они уберут поведение, на которое многие полагаются, даже если оно расходится с документацией.
Я бы лучше сделал так, через функцию-"обёртку" в корневой ноде message.tscn:
Чтобы абстрагировать внешнего пользователя от деталей имплементации - если вдруг ты решишь, например, заменить RichTextLabel на ноду другого класса, или даже на несколько отдельных нод внутри контейнера, то внешний код в твоём случае сразу посыпется ошибками и его будет трудно переделать во всех местах (подразумевая, что ты это вызываешь из разных мест проекта), а с такой функцией-обёрткой тебе будет достаточно изменить содержимое одной этой функции-обёртки, и всё внешнее поведение сохранится без изменений - "блок текста принимает текст". Использовать ли тут $Label напрямую или кэшировать - зависит от того, как часто ты меняешь текст. Если тебе достаточно один раз поставить текст и всё, то сохранять ссылку на Label нигде не нужно.
Ты прав в том, что можно получить доступ к уже инициализированной ноде до вхождения в дерево сцены - я и сам так делал в своих проектах ещё на Godot 3.x, но почему-то забыл об этом, но это всё не так важно, потому что это не отменяет того, что нельзя получить доступ к ноде, когда ты только начал инициализацию - т.е. тогда, когда полям присваиваются значения по умолчанию. Поэтому сообщение об ошибке предупреждает пользователя правильно - там действительно возвращается null, поскольку нода-предок не инициализирована и не имеет никаких нод-потомков. Так что полностью убирать это предупреждение нерационально, хотя в настройках проекта ты можешь его отключить... И, честно говоря, не знаю, стоит ли полагаться на возможность получить доступ к ноде до вхождение в дерево сцены. Судя по всему, официально _ready() считается главной точкой входа, а она только при добавлении в дерево сцены вызывается, и @onready вызывается строго перед ней, а его везде рекомендуют использовать - и в документации, и в туториалах. Кто знает, вдруг они что-то поменяют внутри, и ноды перестанут находиться до входа в дерево? Хотя вряд ли они уберут поведение, на которое многие полагаются, даже если оно расходится с документацией.
>>var chat = msg.chat
>>chat.add_text()
Я бы лучше сделал так, через функцию-"обёртку" в корневой ноде message.tscn:
>extends PanelContainer
>func add_text(text: String) -> void:
>_ $Label.text = text
Чтобы абстрагировать внешнего пользователя от деталей имплементации - если вдруг ты решишь, например, заменить RichTextLabel на ноду другого класса, или даже на несколько отдельных нод внутри контейнера, то внешний код в твоём случае сразу посыпется ошибками и его будет трудно переделать во всех местах (подразумевая, что ты это вызываешь из разных мест проекта), а с такой функцией-обёрткой тебе будет достаточно изменить содержимое одной этой функции-обёртки, и всё внешнее поведение сохранится без изменений - "блок текста принимает текст". Использовать ли тут $Label напрямую или кэшировать - зависит от того, как часто ты меняешь текст. Если тебе достаточно один раз поставить текст и всё, то сохранять ссылку на Label нигде не нужно.
>>4653
Думаю там просто двусвязный список и нет разницы в сцене он или нет, nodepath()/$ просто обходит список в поиске ноды с заданным именем.
На 4.3 способ так же работает, старше у меня нет. В документации есть сноска, отдельно, что абсолютные пути могут работать только в дереве, возможно проверка связанна с этим, чтобы карлики не дёргали ноды в сценах по путям $"../../MyRoblox" и не создавали кучу тредов, что не работает.
Я просто хотел сделать чатик с добавлением сообщений внизу и автоматической прокруткой, оказалось, это не совсем тривиально, надо добавить сообщение, потом подождать кадр, чтобы узнать высоту прокрутки и тогда уже можно крутить, ну и в процессе решения "подождать кадр" я провалился в то, чтобы добавить текст сразу, как если бы сцена инстанцировалась с уже введённым текстом, поэтому так вышло.
>Ты прав в том, что можно получить доступ к уже инициализированной ноде до вхождения в дерево сцены
> вдруг они что-то поменяют внутри, и ноды перестанут находиться до входа в дерево
Думаю там просто двусвязный список и нет разницы в сцене он или нет, nodepath()/$ просто обходит список в поиске ноды с заданным именем.
На 4.3 способ так же работает, старше у меня нет. В документации есть сноска, отдельно, что абсолютные пути могут работать только в дереве, возможно проверка связанна с этим, чтобы карлики не дёргали ноды в сценах по путям $"../../MyRoblox" и не создавали кучу тредов, что не работает.
>Я бы лучше сделал так
Я просто хотел сделать чатик с добавлением сообщений внизу и автоматической прокруткой, оказалось, это не совсем тривиально, надо добавить сообщение, потом подождать кадр, чтобы узнать высоту прокрутки и тогда уже можно крутить, ну и в процессе решения "подождать кадр" я провалился в то, чтобы добавить текст сразу, как если бы сцена инстанцировалась с уже введённым текстом, поэтому так вышло.
>>4691
Судя по документации, лучше вызвать set_deferred():
https://docs.godotengine.org/en/stable/classes/class_scrollcontainer.html#class-scrollcontainer-property-scroll-vertical
В прошлом я тоже "ждал следующий кадр", но теперь кажется, что это анти-паттерн, который приводит ко множеству проблем с порядком вызовов в будущем, поскольку ты не можешь отменить все свои await. А накручивать что-то через Timer слишком неудобно.
Как понимаю, размеры Control вычисляются в некий определённый момент, а не прям сразу... Было бы неэффективно вычислять лишние значения, когда происходит несколько передвижек до отрисовки следующего кадра. Пример: ты добавляешь в цикле несколько отдельных нод в контейнер, и он должен растягиваться при каждом добавлении, но конечный результат юзер увидит только со всеми нодами, т.е. движку не нужно считать промежуточные значения.
Да, у каждой ноды свои списки нод-потомков, но вот конкретный момент их формирования, вроде бы, не описывается нигде, а значит, это поведение - "детали имплементации", которые могут поменяться в любой следующей версии. В целом, не стоит полагаться на поведение, не описанное в документации, даже если оно наблюдалось со времён Godot 3 без изменений.
>потом подождать кадр
Судя по документации, лучше вызвать set_deferred():
https://docs.godotengine.org/en/stable/classes/class_scrollcontainer.html#class-scrollcontainer-property-scroll-vertical
В прошлом я тоже "ждал следующий кадр", но теперь кажется, что это анти-паттерн, который приводит ко множеству проблем с порядком вызовов в будущем, поскольку ты не можешь отменить все свои await. А накручивать что-то через Timer слишком неудобно.
>добавить текст сразу
Как понимаю, размеры Control вычисляются в некий определённый момент, а не прям сразу... Было бы неэффективно вычислять лишние значения, когда происходит несколько передвижек до отрисовки следующего кадра. Пример: ты добавляешь в цикле несколько отдельных нод в контейнер, и он должен растягиваться при каждом добавлении, но конечный результат юзер увидит только со всеми нодами, т.е. движку не нужно считать промежуточные значения.
>Думаю там просто двусвязный список
Да, у каждой ноды свои списки нод-потомков, но вот конкретный момент их формирования, вроде бы, не описывается нигде, а значит, это поведение - "детали имплементации", которые могут поменяться в любой следующей версии. В целом, не стоит полагаться на поведение, не описанное в документации, даже если оно наблюдалось со времён Godot 3 без изменений.
>>4728
Возможно, но скорее ожидается применение стилей (StyleBox), там могут быть отступы всякие + скейлинги и трансформации
Я перешёл на
внутри _process
Вскрылись проблемы, get_v_scroll_bar().max_value имеет значение X, а ScrollContainer.scroll_vertical на самом деле не может быть больше чем (X-высота_ползунка), в эту высоту ползунка никто не предоставляет, а я не соображу как по другому переключать состояния между "следить за последним сообщением" и "прокручивать чат свободно", короче опять Хуан мне в штаны насрал
>Как понимаю, размеры Control вычисляются в некий определённый момент, а не прям сразу...
Возможно, но скорее ожидается применение стилей (StyleBox), там могут быть отступы всякие + скейлинги и трансформации
>Судя по документации, лучше вызвать set_deferred():
Я перешёл на
>scroll_vertical = lerp(scroll_vertical, int(get_v_scroll_bar().max_value), 5.0 * delta)
внутри _process
Вскрылись проблемы, get_v_scroll_bar().max_value имеет значение X, а ScrollContainer.scroll_vertical на самом деле не может быть больше чем (X-высота_ползунка), в эту высоту ползунка никто не предоставляет, а я не соображу как по другому переключать состояния между "следить за последним сообщением" и "прокручивать чат свободно", короче опять Хуан мне в штаны насрал
>>4814
1) вид1 прикольный, надеюсь сам сделал
2) Затык сейчас в том, чтобы определить что скролл бар пользователь прокрутил вниз
У чата есть 2 состояния:
- скролить к последнему сообщению
или , если пользователь прокрутил ползунок мышкой (например)
- не скролить к последнему сообщению
Пока проблем нет. Проблема из состояния "не скролить к последнему сообщению" вернуться к "скролить к последнему сообщению "
буквально как лог в редакторе годота
У скролл баров есть метод get_grabber_size, но, конечно, пидарасы фурри лгбт шваль не пробросила его в gdscript, а зачем, создай пропоссал и подождит 5.0, тогда добавят
1) вид1 прикольный, надеюсь сам сделал
2) Затык сейчас в том, чтобы определить что скролл бар пользователь прокрутил вниз
У чата есть 2 состояния:
- скролить к последнему сообщению
или , если пользователь прокрутил ползунок мышкой (например)
- не скролить к последнему сообщению
Пока проблем нет. Проблема из состояния "не скролить к последнему сообщению" вернуться к "скролить к последнему сообщению "
буквально как лог в редакторе годота
У скролл баров есть метод get_grabber_size, но, конечно, пидарасы фурри лгбт шваль не пробросила его в gdscript, а зачем, создай пропоссал и подождит 5.0, тогда добавят
Годноту подвезли!
https://www.youtube.com/watch?v=EGKV-5lJUBk
https://www.youtube.com/watch?v=EGKV-5lJUBk
>>4823
Твоё или нашел где-то? Выглядит классно, если твоё - я бы пару вопросов задал, по реализации.
Твоё или нашел где-то? Выглядит классно, если твоё - я бы пару вопросов задал, по реализации.
>>4839
Не мое, прост поглядываю за ними. Это парочка каких-то перекатунов из РФ в Армению, или типа того.
https://www.reddit.com/r/godot/comments/1us3fns/testing_a_mini_power_station/
Не мое, прост поглядываю за ними. Это парочка каких-то перекатунов из РФ в Армению, или типа того.
https://www.reddit.com/r/godot/comments/1us3fns/testing_a_mini_power_station/
>>4841
Понь, спасибо. Классно делают, успехов ребятам.
Понь, спасибо. Классно делают, успехов ребятам.
>>4815
В смысле? Это очень легко делается.
Можно посчитать вручную от свойства page в Range:
https://docs.godotengine.org/en/stable/classes/class_range.html#class-range-property-page
Попробуй такой код. Работает в 99.99% случаев даже при очень большой активности в чате. У меня вот обратная проблема: я настроил отключение автоскроллинга на нажатие клавиш мыши, поэтому, если крутануть колёсико - автоскролл отключается, но вот взаимодействие с vscroll внутри ScrollContainer не отлавливается. Если чат движется очень быстро, а юзера колёсико настроено на низкое значение, то отключить автоскролл проблематично. Почему-то события ScrollContainer предназначены только для сенсорных экранов...
Вообще, я уже очень давно ни с какими реальными чатами не взаимодействовал, но по моим воспоминаниям, чат-клиенты очень часто глючные и либо слишком агрессивно скроллят чат, игнорируя юзера, либо теряют автоскроллинг и не могут его восстановить. Так что, как мне кажется, это общая проблема UI/UX, не касающаяся какого-либо конкретного GUI фреймворка. Если ты делаешь игровой чат - добавь где-нибудь настройки, чтоб пользователь мог подстроить управление чатом под себя. Константу "1.2" со скриншота можно воспринимать как степень "агрессивности" автоскроллинга, чем выше значение - тем раньше он включается (я по ощущениям подбирал).
>надеюсь сам сделал
В смысле? Это очень легко делается.
>У скролл баров есть метод get_grabber_size
Можно посчитать вручную от свойства page в Range:
https://docs.godotengine.org/en/stable/classes/class_range.html#class-range-property-page
>Проблема ... вернуться к "скролить к последнему"
Попробуй такой код. Работает в 99.99% случаев даже при очень большой активности в чате. У меня вот обратная проблема: я настроил отключение автоскроллинга на нажатие клавиш мыши, поэтому, если крутануть колёсико - автоскролл отключается, но вот взаимодействие с vscroll внутри ScrollContainer не отлавливается. Если чат движется очень быстро, а юзера колёсико настроено на низкое значение, то отключить автоскролл проблематично. Почему-то события ScrollContainer предназначены только для сенсорных экранов...
Вообще, я уже очень давно ни с какими реальными чатами не взаимодействовал, но по моим воспоминаниям, чат-клиенты очень часто глючные и либо слишком агрессивно скроллят чат, игнорируя юзера, либо теряют автоскроллинг и не могут его восстановить. Так что, как мне кажется, это общая проблема UI/UX, не касающаяся какого-либо конкретного GUI фреймворка. Если ты делаешь игровой чат - добавь где-нибудь настройки, чтоб пользователь мог подстроить управление чатом под себя. Константу "1.2" со скриншота можно воспринимать как степень "агрессивности" автоскроллинга, чем выше значение - тем раньше он включается (я по ощущениям подбирал).
>>4856
Заморочился, масочку сделал на иконку
Я не сторонник зашивочек на магические числа, сейчас может работает, а на другом размере окна/другом разрешении/другой ОС/с другим стилем это всё рассыплется. Можно и настройку, но я уже переписал их функции с C++ и...
...И оказалось Хуан 13 лет назад совершил ошибку в коде и неверно вычисляет размеры.
Я пришёл к тому, что у меня есть функции возвращающие:
1) размер ползунка,
2) размер сколлбара, по которому ездит ползунок,
3) и его положение на нём.
И если взять размер ползунка и прибавить смещение, то получается размер скролл бара, вот у Хуана так не получается.
Спасибо за помощь!
Да, я попался на эти псиоп сигналы по началу поначалу, они для мобилок там типа весь экран это скролл бар который двигается пальцем
>В смысле? Это очень легко делается.
Заморочился, масочку сделал на иконку
>Можно посчитать вручную от свойства page в Range
Я не сторонник зашивочек на магические числа, сейчас может работает, а на другом размере окна/другом разрешении/другой ОС/с другим стилем это всё рассыплется. Можно и настройку, но я уже переписал их функции с C++ и...
...И оказалось Хуан 13 лет назад совершил ошибку в коде и неверно вычисляет размеры.
Я пришёл к тому, что у меня есть функции возвращающие:
1) размер ползунка,
2) размер сколлбара, по которому ездит ползунок,
3) и его положение на нём.
И если взять размер ползунка и прибавить смещение, то получается размер скролл бара, вот у Хуана так не получается.
Спасибо за помощь!
>Почему-то события ScrollContainer предназначены только для сенсорных экранов...
Да, я попался на эти псиоп сигналы по началу поначалу, они для мобилок там типа весь экран это скролл бар который двигается пальцем
>>4948
Делать такое на Godot - удовольствие, а не морока. Кайфанул, а потом сидишь, смотришь - "ну и зачем я реализовал эту фигню, мне она не нужна вообще"...
Это делается одной опцией в CanvasItem:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-clip-children
Маска-рамка сделана через Panel со StyleBoxFlat.
Мейнтейнеры движка об этом знают?
Я подумал - а зачем тут этот ползунок? Ты заполняешь экран собственными элементами, размеры которых и количество тебе известны, так что можешь посчитать, сколько элементов сдвинуты относительно рамок контейнера. Вроде, даже скроллбар не обязателен.
Это легко протестировать, потянув за край окна.
У Godot одинаковый стиль GUI на всех ОС, так что настраиваешь стиль игры ты сам, так что можешь протестировать заранее... Впрочем, мне кажется, конкретное свойство Range.page не должно как-то зависеть от стиля ползунка скролла. Наоборот, это ползунок растягивается или сжимается от page.
Правда, в моём тесте я обнаружил, что page растёт от нуля до 255, и дальше уже не растёт, хотя value и max_value достигают тысяч. Странно, почему так?..
>Заморочился
Делать такое на Godot - удовольствие, а не морока. Кайфанул, а потом сидишь, смотришь - "ну и зачем я реализовал эту фигню, мне она не нужна вообще"...
>масочку сделал на иконку
Это делается одной опцией в CanvasItem:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-clip-children
Маска-рамка сделана через Panel со StyleBoxFlat.
>13 лет назад совершил ошибку в коде
Мейнтейнеры движка об этом знают?
>1) размер ползунка,
>2) размер сколлбара...
Я подумал - а зачем тут этот ползунок? Ты заполняешь экран собственными элементами, размеры которых и количество тебе известны, так что можешь посчитать, сколько элементов сдвинуты относительно рамок контейнера. Вроде, даже скроллбар не обязателен.
>на другом размере окна/другом разрешении
Это легко протестировать, потянув за край окна.
>другой ОС/с другим стилем
У Godot одинаковый стиль GUI на всех ОС, так что настраиваешь стиль игры ты сам, так что можешь протестировать заранее... Впрочем, мне кажется, конкретное свойство Range.page не должно как-то зависеть от стиля ползунка скролла. Наоборот, это ползунок растягивается или сжимается от page.
Правда, в моём тесте я обнаружил, что page растёт от нуля до 255, и дальше уже не растёт, хотя value и max_value достигают тысяч. Странно, почему так?..
>>4960
Думаю, нет. И доказывать им не хочу, просто математика не сходится
Хочешь - покопайся https://github.com/godotengine/godot/blob/master/scene/gui/scroll_bar.cpp#L483
Вот get_grabber_size, в конце расчётов всегда прибавляется get_grabber_min_size() который составляет у меня 8px, в процессе расчётов всегда вызывается get_area_size(), в которой вычитается get_grabber_min_size(), но по итогу не сходится.
Есть функция get_grabber_offset() которая показывается смещение (0..1) для граббера , по идее, если граббер находится в самом низу и если взять этот offset добавить размер граббера то должен получиться get_area_size(), а получается get_area_size() + 8px
Думаю get_grabber_size() должен заканчиваться как
и минимальный размер не должен вычитаться в get_area_size()
Но если так сделать и заполниться скролл бар, половина скролл бара (4px) проваливаются за пределы контрола, потому что там ещё есть математические вычисления вверху в _gui_input которые я не стал копать.
Сообщение помещается в дерево контейнеров, у каждого контейнера может висеть своя тема/скейлинг, какие то ещё трансформации, что повлияет на размеры сообщения, да, всё можно подгонять, делать магические числа, но я так не люблю. Есть скроллбар, пусть говорит мне где он находится и какого размера
Она по сути растёт до get_area_size(), или до высоты контрола, по твоей формуле в момент появления скролл бара page * 1.2 станет константой, но max_value будет расти и "окно" попав в которой скроллбар включает AUTO_SCROLL - тоже
>Мейнтейнеры движка об этом знают?
Думаю, нет. И доказывать им не хочу, просто математика не сходится
Хочешь - покопайся https://github.com/godotengine/godot/blob/master/scene/gui/scroll_bar.cpp#L483
Вот get_grabber_size, в конце расчётов всегда прибавляется get_grabber_min_size() который составляет у меня 8px, в процессе расчётов всегда вызывается get_area_size(), в которой вычитается get_grabber_min_size(), но по итогу не сходится.
Есть функция get_grabber_offset() которая показывается смещение (0..1) для граббера , по идее, если граббер находится в самом низу и если взять этот offset добавить размер граббера то должен получиться get_area_size(), а получается get_area_size() + 8px
Думаю get_grabber_size() должен заканчиваться как
> return MAX(grabber_size, get_grabber_min_size());
и минимальный размер не должен вычитаться в get_area_size()
Но если так сделать и заполниться скролл бар, половина скролл бара (4px) проваливаются за пределы контрола, потому что там ещё есть математические вычисления вверху в _gui_input которые я не стал копать.
>Я подумал - а зачем тут этот ползунок? Ты заполняешь экран собственными элементами, размеры которых и количество тебе известны, так что можешь посчитать, сколько элементов сдвинуты относительно рамок контейнера. Вроде, даже скроллбар не обязателен.
>Это легко протестировать, потянув за край окна.
>У Godot одинаковый стиль GUI на всех ОС
Сообщение помещается в дерево контейнеров, у каждого контейнера может висеть своя тема/скейлинг, какие то ещё трансформации, что повлияет на размеры сообщения, да, всё можно подгонять, делать магические числа, но я так не люблю. Есть скроллбар, пусть говорит мне где он находится и какого размера
>Правда, в моём тесте я обнаружил, что page растёт от нуля до 255, и дальше уже не растёт, хотя value и max_value достигают тысяч. Странно, почему так?..
Она по сути растёт до get_area_size(), или до высоты контрола, по твоей формуле в момент появления скролл бара page * 1.2 станет константой, но max_value будет расти и "окно" попав в которой скроллбар включает AUTO_SCROLL - тоже
>>4960
Думаю, нет. И доказывать им не хочу, просто математика не сходится
Хочешь - покопайся https://github.com/godotengine/godot/blob/master/scene/gui/scroll_bar.cpp#L483
Вот get_grabber_size, в конце расчётов всегда прибавляется get_grabber_min_size() который составляет у меня 8px, в процессе расчётов всегда вызывается get_area_size(), в которой вычитается get_grabber_min_size(), но по итогу не сходится.
Есть функция get_grabber_offset() которая показывается смещение (0..1) для граббера , по идее, если граббер находится в самом низу и если взять этот offset добавить размер граббера то должен получиться get_area_size(), а получается get_area_size() + 8px
Думаю get_grabber_size() должен заканчиваться как
и минимальный размер не должен вычитаться в get_area_size()
Но если так сделать и заполниться скролл бар, половина скролл бара (4px) проваливаются за пределы контрола, потому что там ещё есть математические вычисления вверху в _gui_input которые я не стал копать.
Сообщение помещается в дерево контейнеров, у каждого контейнера может висеть своя тема/скейлинг, какие то ещё трансформации, что повлияет на размеры сообщения, да, всё можно подгонять, делать магические числа, но я так не люблю. Есть скроллбар, пусть говорит мне где он находится и какого размера
Она по сути растёт до get_area_size(), или до высоты контрола, по твоей формуле в момент появления скролл бара page * 1.2 станет константой, но max_value будет расти и "окно" попав в которой скроллбар включает AUTO_SCROLL - тоже
>Мейнтейнеры движка об этом знают?
Думаю, нет. И доказывать им не хочу, просто математика не сходится
Хочешь - покопайся https://github.com/godotengine/godot/blob/master/scene/gui/scroll_bar.cpp#L483
Вот get_grabber_size, в конце расчётов всегда прибавляется get_grabber_min_size() который составляет у меня 8px, в процессе расчётов всегда вызывается get_area_size(), в которой вычитается get_grabber_min_size(), но по итогу не сходится.
Есть функция get_grabber_offset() которая показывается смещение (0..1) для граббера , по идее, если граббер находится в самом низу и если взять этот offset добавить размер граббера то должен получиться get_area_size(), а получается get_area_size() + 8px
Думаю get_grabber_size() должен заканчиваться как
> return MAX(grabber_size, get_grabber_min_size());
и минимальный размер не должен вычитаться в get_area_size()
Но если так сделать и заполниться скролл бар, половина скролл бара (4px) проваливаются за пределы контрола, потому что там ещё есть математические вычисления вверху в _gui_input которые я не стал копать.
>Я подумал - а зачем тут этот ползунок? Ты заполняешь экран собственными элементами, размеры которых и количество тебе известны, так что можешь посчитать, сколько элементов сдвинуты относительно рамок контейнера. Вроде, даже скроллбар не обязателен.
>Это легко протестировать, потянув за край окна.
>У Godot одинаковый стиль GUI на всех ОС
Сообщение помещается в дерево контейнеров, у каждого контейнера может висеть своя тема/скейлинг, какие то ещё трансформации, что повлияет на размеры сообщения, да, всё можно подгонять, делать магические числа, но я так не люблю. Есть скроллбар, пусть говорит мне где он находится и какого размера
>Правда, в моём тесте я обнаружил, что page растёт от нуля до 255, и дальше уже не растёт, хотя value и max_value достигают тысяч. Странно, почему так?..
Она по сути растёт до get_area_size(), или до высоты контрола, по твоей формуле в момент появления скролл бара page * 1.2 станет константой, но max_value будет расти и "окно" попав в которой скроллбар включает AUTO_SCROLL - тоже
нахуй вы тут пиздите, фабле 5 еще сутки в подписку клода входит. вы ебанутые тут годами игры делать, когда нормальные пацаны игру за 2-3 вайбкодят? Релижу игру каждую неделю, конвеер 20 игр. Каждая приносит 50$ в месяц. тупо читкод на бабки
>>5012
Такое чувство как будто все фантазеры из /pr в /gd переехали. Там тоже рассказывали охуительные истории как пиздят в резюме, устраиваются на 5 работ и дунасят за 500-800 тыр.
Щас еще инфомошенники подключатся, с рассказами как заработать миллион долларов на вайбкоде игр.
Такое чувство как будто все фантазеры из /pr в /gd переехали. Там тоже рассказывали охуительные истории как пиздят в резюме, устраиваются на 5 работ и дунасят за 500-800 тыр.
Щас еще инфомошенники подключатся, с рассказами как заработать миллион долларов на вайбкоде игр.
>>5012
Окей, значит тебе будет легко задонатить на твг десять тысяч.
Окей, значит тебе будет легко задонатить на твг десять тысяч.
>>4970
Не, там ведь обратная операция: автоскролл включается, только когда value находится в промежутке между max_value и page, который не должен изменяться (а отключается он кликом мышки). Я не уверен, почему приходится брать число больше, чем page, но это число остаётся стабильным при большом списке сообщений и разных размерах окна.
Ты движок разрабатываешь или игру/чатик/приложение?
Да, выглядит логично... Я бы сделал так же... Но, не зная всех подробностей, трудно сказать, почему сделали как-то иначе. Наверняка была причина, о которой в том коде не сказано ничего. Я бы руководствовался принципом "работает - не трогай" и не трогал, пока оно не станет мешать (вряд ли когда-либо станет).
>>5012
Мне такое не интересно... В чём фан релизить игры?
>станет константой, но max_value будет расти и "окно" попав в которой скроллбар включает AUTO_SCROLL - тоже
Не, там ведь обратная операция: автоскролл включается, только когда value находится в промежутке между max_value и page, который не должен изменяться (а отключается он кликом мышки). Я не уверен, почему приходится брать число больше, чем page, но это число остаётся стабильным при большом списке сообщений и разных размерах окна.
>у каждого контейнера может висеть своя тема/скейлинг
Ты движок разрабатываешь или игру/чатик/приложение?
>return MAX(grabber_size, get_grabber_min_size());
Да, выглядит логично... Я бы сделал так же... Но, не зная всех подробностей, трудно сказать, почему сделали как-то иначе. Наверняка была причина, о которой в том коде не сказано ничего. Я бы руководствовался принципом "работает - не трогай" и не трогал, пока оно не станет мешать (вряд ли когда-либо станет).
>>5012
>Релижу игру
Мне такое не интересно... В чём фан релизить игры?
>>5014
Кроме шуток перекатился сюда из Юнити тредика и после перевалился на ваш движок и после Unity просто ахуел.
Этот шиз вероятно пиздит про конвеер из 20, но я действительно поддерживаю 4-5 слопа (на каждый ушло порядка месяца-двух) и эта хуета из под коня приносят по 50-100$ каждая при минимуме усилий
Поэтому в этом пиздеже есть доля правды
Другой анон
Кроме шуток перекатился сюда из Юнити тредика и после перевалился на ваш движок и после Unity просто ахуел.
Этот шиз вероятно пиздит про конвеер из 20, но я действительно поддерживаю 4-5 слопа (на каждый ушло порядка месяца-двух) и эта хуета из под коня приносят по 50-100$ каждая при минимуме усилий
Поэтому в этом пиздеже есть доля правды
Другой анон
1,1 Мб, 3840x2160Смотрите что нашлось в сети:
EdgeDecalGenerator — это инструмент для Unity, позволяющий процедурно создавать Mesh-декали на ребрах объектов. Идеально подходит для добавления сколов, грязи и износа на углы зданий, ящиков и элементов окружения.
https://redonigames.itch.io/redonitools-edge-decal-generator
https://github.com/RedOniGames/EdgeDecalGenerator
Описание пользования на русском - статья "Мой первый плагин для Unity! Edge Decal Generator".
Есть такое тут?
Если нет - надо бы конвертировать сюда, людям с достаточным опытом для такого.
EdgeDecalGenerator — это инструмент для Unity, позволяющий процедурно создавать Mesh-декали на ребрах объектов. Идеально подходит для добавления сколов, грязи и износа на углы зданий, ящиков и элементов окружения.
https://redonigames.itch.io/redonitools-edge-decal-generator
https://github.com/RedOniGames/EdgeDecalGenerator
Описание пользования на русском - статья "Мой первый плагин для Unity! Edge Decal Generator".
Есть такое тут?
Если нет - надо бы конвертировать сюда, людям с достаточным опытом для такого.
>>5147
Схуяли? Вопрос был про залупу для юнити, есть ли такая в годоте. Я сказал что эта залупа не нужна. В сабстенсе процедурная генерация твоих декалей. Причем работает с 2д и поэтому учитывает не только грани но и нормал мапы. А результатом можно и в готдоте пользоваться без всяких костылей.
Схуяли? Вопрос был про залупу для юнити, есть ли такая в годоте. Я сказал что эта залупа не нужна. В сабстенсе процедурная генерация твоих декалей. Причем работает с 2д и поэтому учитывает не только грани но и нормал мапы. А результатом можно и в готдоте пользоваться без всяких костылей.
>>5149
это вероятно автор этой поделки её и пиарит
это вероятно автор этой поделки её и пиарит
>>5130
@monkey Анон просит узнать есть ли для Годота редакторы декалей текстур, аналогичные тем, что он приводит по ссылкам для других движков? Узнай пожалуйста, погугли за анона.
@monkey Анон просит узнать есть ли для Годота редакторы декалей текстур, аналогичные тем, что он приводит по ссылкам для других движков? Узнай пожалуйста, погугли за анона.
В годоте похожих готовых инструментов для процедурных mesh-декалей на рёбрах не нашлось в открытом доступе. Можно сделать через шейдеры или кастомный аддон, но готового решения как в юнити нет.
>>5167
Кстате да.
Кстате да.
>>5149
Когда ты так говоришь, ты ставишь себя в лагерь луддитов, отрицающих всё новое. Задумайся.
> Я сказал что эта залупа не нужна.
Когда ты так говоришь, ты ставишь себя в лагерь луддитов, отрицающих всё новое. Задумайся.
>>5127
Это сделка с совестью на которую я не пошёл в донейроночные времена, не пойду и сейчас.
Не могу так, воспитание не позволяет.
> клепать одноклеточный слоп для детей и дегенератов, набитый рекламой аналогичного слопа
Это сделка с совестью на которую я не пошёл в донейроночные времена, не пойду и сейчас.
Не могу так, воспитание не позволяет.
>>5171
Говно даже новое ненужно, потому что оно говно. Задумайся.
А если серьезно, то причем здесь годот? Это жвижок. Зачем его в комбайн из фотошопа и блендера превращать? Причем дающий посредственный результат, по сравнению с оригинальным софтом. Лучше учи новое, чтобы получить хороший результат. В годоте пусть будет все новое связанное непосредственно с функциями движка.
Говно даже новое ненужно, потому что оно говно. Задумайся.
А если серьезно, то причем здесь годот? Это жвижок. Зачем его в комбайн из фотошопа и блендера превращать? Причем дающий посредственный результат, по сравнению с оригинальным софтом. Лучше учи новое, чтобы получить хороший результат. В годоте пусть будет все новое связанное непосредственно с функциями движка.
@monkey как называется демагогический приём, в котором демагог всё сводит к фекалиям?
Это не имеет отдельного устоявшегося названия среди демагогических приёмов. Обычно такое сводят к вульгаризации или примитивному редукционизму, когда сложный вопрос намеренно опускают до телесных или физиологических аналогий.
>>5184
@monkey
@monkey
Это называется выборочным чтением или просто игнором аргументов. Чел выхватывает удобный кусок и делает вид что остального нет. Классика демагогии в треде.
>>5012
>>5127
Ну приносят и приносят, чего бухтите-то тут об этом? Литералли хвастаетесь 20~80% зарплаты дворника, что подметает ваш двор 30 минут по утрам, получая удовольствие от физической нагрузки, пока вы тут просиживаете штаны и портите зрение за компом...
>>5172
Согласен. Если бы я мечтал делать слоп-игры ради копеечной прибыли, я бы публиковался к Фалько с 2008, когда он был молодым и не таким шизовым. Ненавидел слоп/ассетфлипы ещё до того, как это превратилось в мейнстримную проблему.
>>5130
Я вот смотрел-смотрел на скриншот и не мог понять, что же там пытаются показать, пока не прочитал:
ИМХО, это пустая трата производительности, и анон >>5141 прав - лучше 1 раз сделать нормальные текстурки, чем пытаться заклеить недостатки прям в рантайме с помощью таких вот мелких декалей.
>>5171 >>5175 >>5182 >>5184 >>5186
Чем тут сраться, лучше бы сделали стресс-тест, где используются декали на всех углах 10000+ ступенек лестницы против той же лестницы, на которой все детали запечены в тайлящуюся текстуру заранее. Процедурно расставить декали на однородной прямолинейной лестнице можно и без аддонов. Практически наверняка декали будут тормозить.
>Каждая приносит 50$ в месяц
>>5127
>приносят по 50-100$ каждая при минимуме усилий
Ну приносят и приносят, чего бухтите-то тут об этом? Литералли хвастаетесь 20~80% зарплаты дворника, что подметает ваш двор 30 минут по утрам, получая удовольствие от физической нагрузки, пока вы тут просиживаете штаны и портите зрение за компом...
>>5172
>Это сделка с совестью на которую я не пошёл
Согласен. Если бы я мечтал делать слоп-игры ради копеечной прибыли, я бы публиковался к Фалько с 2008, когда он был молодым и не таким шизовым. Ненавидел слоп/ассетфлипы ещё до того, как это превратилось в мейнстримную проблему.
>>5130
Я вот смотрел-смотрел на скриншот и не мог понять, что же там пытаются показать, пока не прочитал:
>добавления сколов, грязи и износа на углы
ИМХО, это пустая трата производительности, и анон >>5141 прав - лучше 1 раз сделать нормальные текстурки, чем пытаться заклеить недостатки прям в рантайме с помощью таких вот мелких декалей.
>>5171 >>5175 >>5182 >>5184 >>5186
Чем тут сраться, лучше бы сделали стресс-тест, где используются декали на всех углах 10000+ ступенек лестницы против той же лестницы, на которой все детали запечены в тайлящуюся текстуру заранее. Процедурно расставить декали на однородной прямолинейной лестнице можно и без аддонов. Практически наверняка декали будут тормозить.
Привет, я новенький. У вас есть проблемы с зависанием на 4.6? Работаю из Стима, на 4.7 стабильно проект виснет при запуске, пришлось откатится на 4.6.3. Кто сталкивался, как Фиксики? Чистка кэша и запуск в Рекавери не помогли.
>>5215
Любой проект виснет, даже чистый, или только твой? Какая система? Не запускаешь ли на ноуте через встроенную видеокарту?
Если чистка кэша не помогла, есть ещё кеш шейдеров, его тоже попробуй почистить, на линуксе папка
на винде? по идее
или
Любой проект виснет, даже чистый, или только твой? Какая система? Не запускаешь ли на ноуте через встроенную видеокарту?
Если чистка кэша не помогла, есть ещё кеш шейдеров, его тоже попробуй почистить, на линуксе папка
>/home/user/.local/share/godot/shader_cache/
на винде? по идее
>c:/users/username/AppData/Roaming/Godot/shaders_cache
или
>C:\Users\Username\AppData\Roaming\Godot\app_userdata\Projectname\vulkan (взял из гугла)
>>5216
Мой проект, там простая 2d хуитка на стадии проектирования, на win11, нет видеокарта нормальная, настольный пк. Сам годот я кстати не чистил, но смена версия туда обратно на 4.7 мне не помогла, в самом проекте .godot чистил.
Мне нейросети предлагали причину что это рендер виноват, мол д12 нестабильнвй , я через параметры выставлял вулкан, но эффекта нет. Утром очищу шейдеры тогда. Спасибо
Мой проект, там простая 2d хуитка на стадии проектирования, на win11, нет видеокарта нормальная, настольный пк. Сам годот я кстати не чистил, но смена версия туда обратно на 4.7 мне не помогла, в самом проекте .godot чистил.
Мне нейросети предлагали причину что это рендер виноват, мол д12 нестабильнвй , я через параметры выставлял вулкан, но эффекта нет. Утром очищу шейдеры тогда. Спасибо
>>5215
Godot из Steam часто имеет какие-то проблемы и не рекомендуется для использования. Скачай эту сборку:
https://github.com/godotengine/godot-builds/releases/download/4.7-stable/Godot_v4.7-stable_win64.exe.zip
Распакуй в любую папку, запусти, добавь проект (если не будет в списке), открой, попробуй поиграть.
Я думаю, проблема может быть в Steam Overlay или в каких-то других процессах Steam.
>>5216
Да, из-за этого тоже может глючить, но вероятность ниже - кэш под каждую версию создаётся заново.
>>5218
Лучше сразу попробуй обычную версию по ссылке выше. Зачем тебе Godot из Steam запускать?
Если хочешь-таки из Steam, тогда попробуй включить Single Window Mode в настройках.
Godot из Steam часто имеет какие-то проблемы и не рекомендуется для использования. Скачай эту сборку:
https://github.com/godotengine/godot-builds/releases/download/4.7-stable/Godot_v4.7-stable_win64.exe.zip
Распакуй в любую папку, запусти, добавь проект (если не будет в списке), открой, попробуй поиграть.
Я думаю, проблема может быть в Steam Overlay или в каких-то других процессах Steam.
>>5216
>есть ещё кеш шейдеров
>app_userdata\Projectname\vulkan
Да, из-за этого тоже может глючить, но вероятность ниже - кэш под каждую версию создаётся заново.
>>5218
Лучше сразу попробуй обычную версию по ссылке выше. Зачем тебе Godot из Steam запускать?
Если хочешь-таки из Steam, тогда попробуй включить Single Window Mode в настройках.
>>5221
Зачем тебе Godot из Steam запускать?
Главное не создавать игры, а показать всем в онлайне что я это делаю
Зачем тебе Godot из Steam запускать?
Главное не создавать игры, а показать всем в онлайне что я это делаю
>>5230
Какого саппорта ты ожидаешь от опенсорца? Тебе ничего не обещали. Юзай 4.3, самый стабильный билд, до ввода ломающих новшеств. Вот тебе и "лтс".
> lts
Какого саппорта ты ожидаешь от опенсорца? Тебе ничего не обещали. Юзай 4.3, самый стабильный билд, до ввода ломающих новшеств. Вот тебе и "лтс".
>>5235
Причём тут трёшка, блять? Анон спросил вполне конкретную версию.
У тебя блять свет клином на трёшке сошёлся. Зажмурил глаза и визжишь, как аутист: трёшка, трёшка!
Причём тут трёшка, блять? Анон спросил вполне конкретную версию.
> Когда годот 4 lts?
У тебя блять свет клином на трёшке сошёлся. Зажмурил глаза и визжишь, как аутист: трёшка, трёшка!
Я к чему спросил про лтс: в 4.6 есть баг где он иногда не подтягивает значения из инспектора - приходится перезагружать проект. И ещё если переменная bool = false, то он в инспекторе показывает её как изменённую по дефолту.
>>5260
А в трешке у меня баг есть, когда ctrl-shift=z в редакторе отваливается. Ctrl-z работает на отмену, а на отмену отмены ctrl-shift-z отваливается. Приходится редактор рестартить чтобы очухалось.
А в трешке у меня баг есть, когда ctrl-shift=z в редакторе отваливается. Ctrl-z работает на отмену, а на отмену отмены ctrl-shift-z отваливается. Приходится редактор рестартить чтобы очухалось.
Тут правда с мультиплеером проблемы? Я просто хочу физический пазл в каком-то смысле 3д лоу поли забубенить.
>>5271
Спасибо
Спасибо
>>5230
Когда релизнут Godot 5.0, скорей всего:
https://docs.godotengine.org/en/latest/about/release_policy.html
Godot 3.6/3.7 действительно можно назвать LTS, но это для очень старых проектов.
В ветке Godot 4.x пока нет LTS и не будет, пока не будет серьёзных breaking changes.
Абстрактный пример, что может произойти:
1. В Godot 5.0 сильно переделают GUI и сделают GDScript 3.0 в виде GDExtension.
2. Это вызовет лютый баттхёрт сообщества, т.к. переходить на 5.0 будет СЛОЖНА.
3. В связи с этим, версия Godot 4.999 станет "LTS" и будет поддерживаться 5-10 лет.
Godot 3.x к тому моменту, скорее всего, совсем загнётся...
>>5234
Очевидно, он ожидает того же, что и от Blender LTS: багфиксов на старую версию.
Обещали, читай документацию по ссылке выше.
Не смеши. Сейчас либо 3.6+ (очень старый проект), либо 4.7+ (новые проекты).
>>5236
Ты чё такой злой в треде любви и взаимопомощи? Он всё правильно сказал.
>>5255
Если он делает 2D игрушки под Яндекс или itch.io, то это оправданно.
>>5260
Перекатывайся на 4.7, лол, она уже stable и скоро будет 4.7.1, уже RC2.
А я лично перекатился на 4.8.dev1 и всем рекомендую сделать так же.
Но вообще, в 4.6 ещё могут фиксить разные баги (см. ссылку выше).
Поддержку 4.6 дропнут только после 4.8, окончательно - после 4.9.
>Когда годот 4 lts?
Когда релизнут Godot 5.0, скорей всего:
https://docs.godotengine.org/en/latest/about/release_policy.html
Godot 3.6/3.7 действительно можно назвать LTS, но это для очень старых проектов.
В ветке Godot 4.x пока нет LTS и не будет, пока не будет серьёзных breaking changes.
Абстрактный пример, что может произойти:
1. В Godot 5.0 сильно переделают GUI и сделают GDScript 3.0 в виде GDExtension.
2. Это вызовет лютый баттхёрт сообщества, т.к. переходить на 5.0 будет СЛОЖНА.
3. В связи с этим, версия Godot 4.999 станет "LTS" и будет поддерживаться 5-10 лет.
Godot 3.x к тому моменту, скорее всего, совсем загнётся...
>>5234
>Какого саппорта ты ожидаешь от опенсорца?
Очевидно, он ожидает того же, что и от Blender LTS: багфиксов на старую версию.
>Тебе ничего не обещали
Обещали, читай документацию по ссылке выше.
>Юзай 4.3, самый стабильный билд
Не смеши. Сейчас либо 3.6+ (очень старый проект), либо 4.7+ (новые проекты).
>>5236
>Причём тут трёшка
Ты чё такой злой в треде любви и взаимопомощи? Он всё правильно сказал.
>>5255
>Какой веб нахой...
Если он делает 2D игрушки под Яндекс или itch.io, то это оправданно.
>>5260
>в 4.6 есть баг
Перекатывайся на 4.7, лол, она уже stable и скоро будет 4.7.1, уже RC2.
А я лично перекатился на 4.8.dev1 и всем рекомендую сделать так же.
Но вообще, в 4.6 ещё могут фиксить разные баги (см. ссылку выше).
Поддержку 4.6 дропнут только после 4.8, окончательно - после 4.9.
>>5230
Когда релизнут Godot 5.0, скорей всего:
https://docs.godotengine.org/en/latest/about/release_policy.html
Godot 3.6/3.7 действительно можно назвать LTS, но это для очень старых проектов.
В ветке Godot 4.x пока нет LTS и не будет, пока не будет серьёзных breaking changes.
Абстрактный пример, что может произойти:
1. В Godot 5.0 сильно переделают GUI и сделают GDScript 3.0 в виде GDExtension.
2. Это вызовет лютый баттхёрт сообщества, т.к. переходить на 5.0 будет СЛОЖНА.
3. В связи с этим, версия Godot 4.999 станет "LTS" и будет поддерживаться 5-10 лет.
Godot 3.x к тому моменту, скорее всего, совсем загнётся...
>>5234
Очевидно, он ожидает того же, что и от Blender LTS: багфиксов на старую версию.
Обещали, читай документацию по ссылке выше.
Не смеши. Сейчас либо 3.6+ (очень старый проект), либо 4.7+ (новые проекты).
>>5236
Ты чё такой злой в треде любви и взаимопомощи? Он всё правильно сказал.
>>5255
Если он делает 2D игрушки под Яндекс или itch.io, то это оправданно.
>>5260
Перекатывайся на 4.7, лол, она уже stable и скоро будет 4.7.1, уже RC2.
А я лично перекатился на 4.8.dev1 и всем рекомендую сделать так же.
Но вообще, в 4.6 ещё могут фиксить разные баги (см. ссылку выше).
Поддержку 4.6 дропнут только после 4.8, окончательно - после 4.9.
>Когда годот 4 lts?
Когда релизнут Godot 5.0, скорей всего:
https://docs.godotengine.org/en/latest/about/release_policy.html
Godot 3.6/3.7 действительно можно назвать LTS, но это для очень старых проектов.
В ветке Godot 4.x пока нет LTS и не будет, пока не будет серьёзных breaking changes.
Абстрактный пример, что может произойти:
1. В Godot 5.0 сильно переделают GUI и сделают GDScript 3.0 в виде GDExtension.
2. Это вызовет лютый баттхёрт сообщества, т.к. переходить на 5.0 будет СЛОЖНА.
3. В связи с этим, версия Godot 4.999 станет "LTS" и будет поддерживаться 5-10 лет.
Godot 3.x к тому моменту, скорее всего, совсем загнётся...
>>5234
>Какого саппорта ты ожидаешь от опенсорца?
Очевидно, он ожидает того же, что и от Blender LTS: багфиксов на старую версию.
>Тебе ничего не обещали
Обещали, читай документацию по ссылке выше.
>Юзай 4.3, самый стабильный билд
Не смеши. Сейчас либо 3.6+ (очень старый проект), либо 4.7+ (новые проекты).
>>5236
>Причём тут трёшка
Ты чё такой злой в треде любви и взаимопомощи? Он всё правильно сказал.
>>5255
>Какой веб нахой...
Если он делает 2D игрушки под Яндекс или itch.io, то это оправданно.
>>5260
>в 4.6 есть баг
Перекатывайся на 4.7, лол, она уже stable и скоро будет 4.7.1, уже RC2.
А я лично перекатился на 4.8.dev1 и всем рекомендую сделать так же.
Но вообще, в 4.6 ещё могут фиксить разные баги (см. ссылку выше).
Поддержку 4.6 дропнут только после 4.8, окончательно - после 4.9.
Там 4.7.1 вышел, но у меня нихуя не открывается не качается, так что просто держу в курсе
>>3555
Ну как, получилось?
Напоминаю базу.
Наконец-то приходишь к решению - сделать игру
@
Всем сообщить что ты делаешь игру (особенно на дваче)
@
Поковырять
@
Сложно
@
Нудно
@
Забить
Ну как, получилось?
Напоминаю базу.
Наконец-то приходишь к решению - сделать игру
@
Всем сообщить что ты делаешь игру (особенно на дваче)
@
Поковырять
@
Сложно
@
Нудно
@
Забить
>>3906
А ведь когда-то это называлось трояном.
> Собирать личные данные
> доказательства что это вредонос.
А ведь когда-то это называлось трояном.
>>5328
а че какой нейро-арт то у меня ? единственное че нейроенка делала это тока боевую систему под капотом
а че какой нейро-арт то у меня ? единственное че нейроенка делала это тока боевую систему под капотом
154 Кб, 604x371Важный вопрос.
Очень.
Я не особо селен в ваших нейронах, но какие бесплатные нейронки можно использовать для обучения (себя) в годоте? Чтобы его выдача максимально соответствовала последним бест-практис, а не каши кода из старых версий.
Именно для само-обучение по типу вопрос-ответ, а не вайбкодинг.
Пока только тыкал в чатгпт, но может еще что актуальное есть?
Очень.
Я не особо селен в ваших нейронах, но какие бесплатные нейронки можно использовать для обучения (себя) в годоте? Чтобы его выдача максимально соответствовала последним бест-практис, а не каши кода из старых версий.
Именно для само-обучение по типу вопрос-ответ, а не вайбкодинг.
Пока только тыкал в чатгпт, но может еще что актуальное есть?
>>5328
Лол блять. Школота на ui триггернулась?
Лол блять. Школота на ui триггернулась?
158 Кб, 892x1311>>5330
Ну вот у меня Алиса в соседнем браузере. Вот я задал ей вопрос и вот что она говорит. Выглядит так, как будто с этим можно работать. На каждый абзац она даёт ссылку на источник, откуда она это выдумала. Так что ты всегда можешь углубить свои знания, перейдя по ссылке на источник.
Минусы: отдельный вендорлок-браузер, необходимость регистрироваться.
> какие бесплатные нейронки можно использовать для обучения (себя) в годоте?
Ну вот у меня Алиса в соседнем браузере. Вот я задал ей вопрос и вот что она говорит. Выглядит так, как будто с этим можно работать. На каждый абзац она даёт ссылку на источник, откуда она это выдумала. Так что ты всегда можешь углубить свои знания, перейдя по ссылке на источник.
Минусы: отдельный вендорлок-браузер, необходимость регистрироваться.
113 Кб, 892x1289>>5333
Ну или вот в качестве альтернативы гайка через утку. В целом то же самое. Если ты готов работать - садись и работай. Но мы-то с тобой оба знаем, что ты не готов, боййй.
Ну или вот в качестве альтернативы гайка через утку. В целом то же самое. Если ты готов работать - садись и работай. Но мы-то с тобой оба знаем, что ты не готов, боййй.
71 Кб, 1057x723>>5333
Совсем забыл про неё. Ты про алису в яндекс браузере?
Или какая-то отдельная версия?
Я как-то спросил у станции пару лет назад, как правильно хранить домашнее вино, она порекомендовала хранить при 80 градусов. Я больше к ней не обращался. Но сейчас она вроде выдала нормальный результат.
Совсем забыл про неё. Ты про алису в яндекс браузере?
Или какая-то отдельная версия?
Я как-то спросил у станции пару лет назад, как правильно хранить домашнее вино, она порекомендовала хранить при 80 градусов. Я больше к ней не обращался. Но сейчас она вроде выдала нормальный результат.
>>5335
Попробовал зайти через гугл почту и через ... и он все равно говорит что я с неправильного региона.
Он бесплатный или на полшишечки?
Попробовал зайти через гугл почту и через ... и он все равно говорит что я с неправильного региона.
Он бесплатный или на полшишечки?
>>5338
Возможно контекст правда был в фаренгейтах, но сказала в цельсиях. И 26 С все равно неправильная температура.
Возможно контекст правда был в фаренгейтах, но сказала в цельсиях. И 26 С все равно неправильная температура.
628 Кб, 722x1092Хочется спиздить сделать шейдер эффекта сканирования примерно как в дивизии или в дестини. Ну, или как в дес стрендинг, кому что ближе и роднее. Вот этот шейдер я успешно спиздил и применил, выглядит для тест сборки неплохо, но вообще ничего красивого, конечно, нет. Я точно помню что видел где-то именно дестиневский вариант на реддите, но гугление ничего не нашло и нейронки тоже говорят что-то в духе да, мол так и так, анус ставим что было, ссылки нет братиш.
https://godotshaders.com/shader/sci-fi-scanner-pulse-godot-4-update/
Я нашел еще пару туториалов под юнити и под анрилку, думаю попробовать скормить нейронке, но это уже последнее дело имхо.
В общем, если у кого-то где-то недалеко валяется ссылка на что-то эдакое и красивое, то буду очень благодарен.
https://godotshaders.com/shader/sci-fi-scanner-pulse-godot-4-update/
Я нашел еще пару туториалов под юнити и под анрилку, думаю попробовать скормить нейронке, но это уже последнее дело имхо.
В общем, если у кого-то где-то недалеко валяется ссылка на что-то эдакое и красивое, то буду очень благодарен.
>>5347
800р за полтора года? По сегодняшним меркам это бесплатно. Но лучше конечно Алису жрать, или СперГигачат какой, даа.
800р за полтора года? По сегодняшним меркам это бесплатно. Но лучше конечно Алису жрать, или СперГигачат какой, даа.
>>5340
Тебе-то откуда знать, винокурень ты наш?
Ты хранил?
Ты пил?
А я - да.
> И 26 С все равно неправильная температура.
Тебе-то откуда знать, винокурень ты наш?
Ты хранил?
Ты пил?
А я - да.
>>5395
Честно говоря мутная фигня, пробовал нагуглить лимиты и что будет после лимитов (типа как чатгпт понижает версию или вообще блок), но сама модель не ответила точно, гугл и редит тоже не знают. Странная фигня для юзер-ориентированного поисковика.
Честно говоря мутная фигня, пробовал нагуглить лимиты и что будет после лимитов (типа как чатгпт понижает версию или вообще блок), но сама модель не ответила точно, гугл и редит тоже не знают. Странная фигня для юзер-ориентированного поисковика.
>>5311
Даже с GitHub не получается?
https://github.com/godotengine/godot-builds/releases
Попробуй качать через загрузчик вроде Free Download Manager - чтобы возобновлял прерванную загрузку.
>>5330
Я рекомендую начать изучение с официальной документации. Ничего нового нейронка тебе всё равно не скажет, кроме пережёвывания многократно пережёванной разными людьми информации из документации (получается эффект "сломанного телефона" - тебе это надо?). В целом, Godot довольно прост и много чего позволяет делать, так что можешь даже методом тыка освоиться, после прохождения самого базового туториала, что прямо в документации есть - советую не пропускать этот базовый туториал и не замещать его никакими сторонними туториалами. Пройди весь раздел "GETTING STARTED" в документации хотя бы один раз.
А нейронки зачастую пишут слишком много лишнего и добавляют своих галлюцинаций, как тут: >>5333 и >>5335, чем заводят новичка в заблуждение и заставляют запрашивать уточнения, загоняя юзера в спираль "непонятно - попросил уточнение - стало ещё менее понятно". Но даже локальная малютка, которая не предназначена для русского языка, смогла выдать фундаментальную БАЗУ, кроме которой тебе ничего не нужно должно быть. Не перекладывай на нейронку всю ответственность, иначе превратишься во второстепенного персонажа "Идиократии". Самая мощная сегодня нейронка должна быть в твоей собственной голове...
Кстати, никто не хочет сделать игру "Ходилище"?
Даже с GitHub не получается?
https://github.com/godotengine/godot-builds/releases
Попробуй качать через загрузчик вроде Free Download Manager - чтобы возобновлял прерванную загрузку.
>>5330
Я рекомендую начать изучение с официальной документации. Ничего нового нейронка тебе всё равно не скажет, кроме пережёвывания многократно пережёванной разными людьми информации из документации (получается эффект "сломанного телефона" - тебе это надо?). В целом, Godot довольно прост и много чего позволяет делать, так что можешь даже методом тыка освоиться, после прохождения самого базового туториала, что прямо в документации есть - советую не пропускать этот базовый туториал и не замещать его никакими сторонними туториалами. Пройди весь раздел "GETTING STARTED" в документации хотя бы один раз.
А нейронки зачастую пишут слишком много лишнего и добавляют своих галлюцинаций, как тут: >>5333 и >>5335, чем заводят новичка в заблуждение и заставляют запрашивать уточнения, загоняя юзера в спираль "непонятно - попросил уточнение - стало ещё менее понятно". Но даже локальная малютка, которая не предназначена для русского языка, смогла выдать фундаментальную БАЗУ, кроме которой тебе ничего не нужно должно быть. Не перекладывай на нейронку всю ответственность, иначе превратишься во второстепенного персонажа "Идиократии". Самая мощная сегодня нейронка должна быть в твоей собственной голове...
Кстати, никто не хочет сделать игру "Ходилище"?
>>5311
Просто из исходников собери...
Просто из исходников собери...
>>5417
Его файлы и блокируют. Ведь с него можно скачать и телеграм и запрет, какой ужас.
Я долго копротивлялся, в итоге взял квн, теперь всё качается и открывается, просто интернет подорожал на 166р в месяц.
>Даже с GitHub не получается?
Его файлы и блокируют. Ведь с него можно скачать и телеграм и запрет, какой ужас.
Я долго копротивлялся, в итоге взял квн, теперь всё качается и открывается, просто интернет подорожал на 166р в месяц.
19 Кб, 763x102>>5417
Я раньше обходился гуглом, но увы рассвет годота, видимо, попал в эпоху ИИ и найти некоторые привычные ответы даже для гдскрипта становится сложным. И опять же, я не вайбкожу и не копипащю, я задаю тупые вопросы и изучаю каждую строчку кода.
Про документацию, это понятно, я не собирался её обходить.
Я не школьник который ищет легких путей, я просто хочу помощника в обход форумов/чатов, мое незнание нейросетей, как раз говорит что я ими редко пользуюсь.
Какая абстрактная водянистая каша.
Я раньше обходился гуглом, но увы рассвет годота, видимо, попал в эпоху ИИ и найти некоторые привычные ответы даже для гдскрипта становится сложным. И опять же, я не вайбкожу и не копипащю, я задаю тупые вопросы и изучаю каждую строчку кода.
Про документацию, это понятно, я не собирался её обходить.
Я не школьник который ищет легких путей, я просто хочу помощника в обход форумов/чатов, мое незнание нейросетей, как раз говорит что я ими редко пользуюсь.
>пик2
Какая абстрактная водянистая каша.
>>5485
И правильно, с моей удачей в -10 если я взял квн то скоро просто весь иностранный трафик заблочат
>Ни копейки не заплачу.
И правильно, с моей удачей в -10 если я взял квн то скоро просто весь иностранный трафик заблочат
>>5502
У меня кстати двач.орг отлетел, только .су теперь работает.
У меня кстати двач.орг отлетел, только .су теперь работает.
>>5491
Накидай свои вопросы сюда списком, интересно даже, что там у тебя за проблемы.
По GDScript ты можешь не находить инфы, потому что он крайне прост как язык, и при этом очень похож на все остальные популярные языки, так что знания опытных (знающих хотя бы 1 другой язык программирования) легко переносятся на него, а что не переносится - уже достаточно подробно расписано в документации или в обсуждениях на GitHub. Так что гуглить как-то и нечего. Многие приёмчики, специфичные для геймдева, можно загуглить для Unity и, зачастую, легко транслировать в Godot/GDScript, подменив всего несколько вызовов API на похожие по смыслу. Я так много раз делал ещё во времена Godot 3, когда туториалов конкретно для Godot не так много было, а Unity я вообще ниасилил (слишком громоздкий нелогичный GUI, неповоротливая IDE, очень долгая компиляция, много крашей ни с чего, почти все фичи добываются с помощью платных ассетов, а в самом движке половина API depreacted и т.д.), но туториалы от Unity неожиданно хорошо подходили для Godot, поэтому даже не могу представить, что у тебя там за проблемы такие, что загуглить теперь не получается.
А что не так с форумами/чатами? Стесняешься? Здесь тебя могут наказать только если ты будешь вредительствовать.
Уж лучше такая "абстрактная каша", чем список очень конкретных действий, которые вообще никак не соответствуют действительности (по любой причине), и ты по незнанию вынужден делать кучу лишних телодвижений из-за этого.
>найти некоторые привычные ответы даже для гдскрипта становится сложным
Накидай свои вопросы сюда списком, интересно даже, что там у тебя за проблемы.
По GDScript ты можешь не находить инфы, потому что он крайне прост как язык, и при этом очень похож на все остальные популярные языки, так что знания опытных (знающих хотя бы 1 другой язык программирования) легко переносятся на него, а что не переносится - уже достаточно подробно расписано в документации или в обсуждениях на GitHub. Так что гуглить как-то и нечего. Многие приёмчики, специфичные для геймдева, можно загуглить для Unity и, зачастую, легко транслировать в Godot/GDScript, подменив всего несколько вызовов API на похожие по смыслу. Я так много раз делал ещё во времена Godot 3, когда туториалов конкретно для Godot не так много было, а Unity я вообще ниасилил (слишком громоздкий нелогичный GUI, неповоротливая IDE, очень долгая компиляция, много крашей ни с чего, почти все фичи добываются с помощью платных ассетов, а в самом движке половина API depreacted и т.д.), но туториалы от Unity неожиданно хорошо подходили для Godot, поэтому даже не могу представить, что у тебя там за проблемы такие, что загуглить теперь не получается.
>хочу помощника в обход форумов/чатов
А что не так с форумами/чатами? Стесняешься? Здесь тебя могут наказать только если ты будешь вредительствовать.
>мое незнание нейросетей
>абстрактная водянистая каша
Уж лучше такая "абстрактная каша", чем список очень конкретных действий, которые вообще никак не соответствуют действительности (по любой причине), и ты по незнанию вынужден делать кучу лишних телодвижений из-за этого.
115 Кб, 957x497>>5520
Качество комьюнити сильно уменьшилось за 20 лет. StackOverflow несмотря на анальное вахтерство все же давал доступ к базовых вопросам, но сейчас и он издох (пик).
Это трудно объяснить, но если ты часто что-то спрашивал из технических тем не в своей среде - гугл (SO) давал быстрые ответы. Годот как-будто не успел попасть в эпоху SO и порой спрашиваешь попадаешь на какие-то "тупые" темы с узкоспецифичными ответами (я щупал юнити, там тоже какой-то свой форум и похожая ситуация, но верояно из-за большей популярности все же проще).
Например я сильно попал в просак с ивентами с гуи и не сразу разобрался (потому что ответ был конкретно к тому вопросу).
Не хочу флудить, просто часто возникают всякие мелкие вопросы и вот нейронка хорошо дает ответы на неопытные вопросы. А чатики форумы уже лучше оставить для чего-то сложного (прям тупика).
Зависеть от настроение людей такое себе.
Даже ты, хоть и отвечаешь развернуто, но пишешь с пассивной агрессией
Зачем это? Ты же видишь что я пишу довольно свободно.
Будет что-то, обязательно спрошу, пока просто что-то повторяю и вопросы чаще уровня "а как повернуть", "а как сделать вот так тут". Я не делаю коммерческую игру, поэтому некоторые трудности я пока дропаю и переключаюсь к другому. Пока еще даже нет идей по игре, мне просто нравится делать миры (ну типа, вот тут будут горы, а тут лес и деревня, тут таверна, ...и начинаешь придумывать лор трактирщика - понеслась)
>А что не так с форумами/чатами?
Качество комьюнити сильно уменьшилось за 20 лет. StackOverflow несмотря на анальное вахтерство все же давал доступ к базовых вопросам, но сейчас и он издох (пик).
Это трудно объяснить, но если ты часто что-то спрашивал из технических тем не в своей среде - гугл (SO) давал быстрые ответы. Годот как-будто не успел попасть в эпоху SO и порой спрашиваешь попадаешь на какие-то "тупые" темы с узкоспецифичными ответами (я щупал юнити, там тоже какой-то свой форум и похожая ситуация, но верояно из-за большей популярности все же проще).
Например я сильно попал в просак с ивентами с гуи и не сразу разобрался (потому что ответ был конкретно к тому вопросу).
Не хочу флудить, просто часто возникают всякие мелкие вопросы и вот нейронка хорошо дает ответы на неопытные вопросы. А чатики форумы уже лучше оставить для чего-то сложного (прям тупика).
Зависеть от настроение людей такое себе.
Даже ты, хоть и отвечаешь развернуто, но пишешь с пассивной агрессией
>Стесняешься?
Зачем это? Ты же видишь что я пишу довольно свободно.
>Накидай свои вопросы сюда списком
Будет что-то, обязательно спрошу, пока просто что-то повторяю и вопросы чаще уровня "а как повернуть", "а как сделать вот так тут". Я не делаю коммерческую игру, поэтому некоторые трудности я пока дропаю и переключаюсь к другому. Пока еще даже нет идей по игре, мне просто нравится делать миры (ну типа, вот тут будут горы, а тут лес и деревня, тут таверна, ...и начинаешь придумывать лор трактирщика - понеслась)
>>5533
Мне он почти никогда не помогал, потому что там всю дорогу либо вопрос без ответа, либо закрывают по какой-то смешной причине, либо ответ больше не работает (ссылки в посте битые, API устарело, что-то поменялось), либо единственный рабочий ответ предлагает вырезать гланды через жопу, либо поисковик упорно подсовывает не тот вопрос, который я задаю, а "моего" там нет. Какой-то клуб снобов и мазохистов, и так было всегда. Хотя некоторые полезные ответы там были, но если не сделал закладку в браузере заранее - потом не найдёшь... Так что они сами себя убили.
События GUI подробно расписаны в документации, зачем что-то гуглить?.. Ну, кроме редких багов движка, но их нужно не гуглить в общем интернете, а смотреть на гитхабе, есть ли там открытые issue и пулл-реквесты. Обычно, если проблема/баг старые, то в комментариях находится какой-нибудь обходной путь, который можно использовать до официального фикса в движке. Я неоднократно находил решение своей проблемы именно в обсуждениях проблем движка на гитхабе, где и разработчики отвечают, и юзеры продвинутые. А всякие стэковерфлоу - посторонние сайты, не связанные с движком, логично, что там мало юзеров Godot. Так что кроме http://github.com/godotengine/godot имеет смысл разве что http://reddit.com/r/godot/ посещать - там тоже разработчики иногда отписываются, но чаще всё-таки новички друг с другом копошатся, что полезно для как раз "бест практис" на уровне хобби-одиночки.
Если не будешь флудить ты, то будут флудить другие - и не вопросами по движку, а мемчиками, депрессивным нытьём, байтами на движкосрач, критикой модерации, бесконечными холиварами на разные темы и т.д. Уж лучше пусть тут будут нубские вопросы...
Чем сложнее твой вопрос, тем менее вероятно, что на него хоть кто-то что-то ответит, потому что над сложным вопросом нужно головой думать, а сюда заходят расслабиться, а не работать задаром.
С каких пор вопрос "стесняешься" считается "агрессией"? Стесняться не плохо, это не какой-то недостаток, а нормальный внутренний ограничитель плохого поведения... Куда хуже, когда человек совсем не стесняется ничего... Вполне естественно испытывать стеснение, когда ты считаешь свой вопрос "тупым", "мелким", "не заслуживающим поста на форуме", хотя здесь постят куда более тупые, мелкие и отвратительные вещи, чем вопросы по теме треда (по движку).
Понимаю. Рекомендую почитать r/worldbuilding на Reddit, там много интересного попадается (и много кринжа от детей, но тоже забавно почитать), чтобы не загонять себя в рамки банального фэнтези на банальной средневековой Земле. Может, тебе и не нужно делать игру, а хватит какой-нибудь визуализации/интерактивной схемы/музея твоего мира...
В общем, ты пиши, если что, а то мне скучно. Часто захожу сюда чтобы помочь кому-нибудь с чем-нибудь, а тут никого...
Ну не нейронку же мне просить, чтобы она мне тупые вопросы сочиняла, а я ей на них подробно отвечал, верно?
>StackOverflow
Мне он почти никогда не помогал, потому что там всю дорогу либо вопрос без ответа, либо закрывают по какой-то смешной причине, либо ответ больше не работает (ссылки в посте битые, API устарело, что-то поменялось), либо единственный рабочий ответ предлагает вырезать гланды через жопу, либо поисковик упорно подсовывает не тот вопрос, который я задаю, а "моего" там нет. Какой-то клуб снобов и мазохистов, и так было всегда. Хотя некоторые полезные ответы там были, но если не сделал закладку в браузере заранее - потом не найдёшь... Так что они сами себя убили.
>сильно попал в просак с ивентами с гуи и не сразу разобрался
События GUI подробно расписаны в документации, зачем что-то гуглить?.. Ну, кроме редких багов движка, но их нужно не гуглить в общем интернете, а смотреть на гитхабе, есть ли там открытые issue и пулл-реквесты. Обычно, если проблема/баг старые, то в комментариях находится какой-нибудь обходной путь, который можно использовать до официального фикса в движке. Я неоднократно находил решение своей проблемы именно в обсуждениях проблем движка на гитхабе, где и разработчики отвечают, и юзеры продвинутые. А всякие стэковерфлоу - посторонние сайты, не связанные с движком, логично, что там мало юзеров Godot. Так что кроме http://github.com/godotengine/godot имеет смысл разве что http://reddit.com/r/godot/ посещать - там тоже разработчики иногда отписываются, но чаще всё-таки новички друг с другом копошатся, что полезно для как раз "бест практис" на уровне хобби-одиночки.
>Не хочу флудить
Если не будешь флудить ты, то будут флудить другие - и не вопросами по движку, а мемчиками, депрессивным нытьём, байтами на движкосрач, критикой модерации, бесконечными холиварами на разные темы и т.д. Уж лучше пусть тут будут нубские вопросы...
>форумы уже лучше оставить для чего-то сложного (прям тупика)
Чем сложнее твой вопрос, тем менее вероятно, что на него хоть кто-то что-то ответит, потому что над сложным вопросом нужно головой думать, а сюда заходят расслабиться, а не работать задаром.
>пишешь с пассивной агрессией
>>Стесняешься?
>Зачем это?
С каких пор вопрос "стесняешься" считается "агрессией"? Стесняться не плохо, это не какой-то недостаток, а нормальный внутренний ограничитель плохого поведения... Куда хуже, когда человек совсем не стесняется ничего... Вполне естественно испытывать стеснение, когда ты считаешь свой вопрос "тупым", "мелким", "не заслуживающим поста на форуме", хотя здесь постят куда более тупые, мелкие и отвратительные вещи, чем вопросы по теме треда (по движку).
>нет идей по игре, мне просто нравится делать миры
Понимаю. Рекомендую почитать r/worldbuilding на Reddit, там много интересного попадается (и много кринжа от детей, но тоже забавно почитать), чтобы не загонять себя в рамки банального фэнтези на банальной средневековой Земле. Может, тебе и не нужно делать игру, а хватит какой-нибудь визуализации/интерактивной схемы/музея твоего мира...
В общем, ты пиши, если что, а то мне скучно. Часто захожу сюда чтобы помочь кому-нибудь с чем-нибудь, а тут никого...
Ну не нейронку же мне просить, чтобы она мне тупые вопросы сочиняла, а я ей на них подробно отвечал, верно?
>>5533
Мне он почти никогда не помогал, потому что там всю дорогу либо вопрос без ответа, либо закрывают по какой-то смешной причине, либо ответ больше не работает (ссылки в посте битые, API устарело, что-то поменялось), либо единственный рабочий ответ предлагает вырезать гланды через жопу, либо поисковик упорно подсовывает не тот вопрос, который я задаю, а "моего" там нет. Какой-то клуб снобов и мазохистов, и так было всегда. Хотя некоторые полезные ответы там были, но если не сделал закладку в браузере заранее - потом не найдёшь... Так что они сами себя убили.
События GUI подробно расписаны в документации, зачем что-то гуглить?.. Ну, кроме редких багов движка, но их нужно не гуглить в общем интернете, а смотреть на гитхабе, есть ли там открытые issue и пулл-реквесты. Обычно, если проблема/баг старые, то в комментариях находится какой-нибудь обходной путь, который можно использовать до официального фикса в движке. Я неоднократно находил решение своей проблемы именно в обсуждениях проблем движка на гитхабе, где и разработчики отвечают, и юзеры продвинутые. А всякие стэковерфлоу - посторонние сайты, не связанные с движком, логично, что там мало юзеров Godot. Так что кроме http://github.com/godotengine/godot имеет смысл разве что http://reddit.com/r/godot/ посещать - там тоже разработчики иногда отписываются, но чаще всё-таки новички друг с другом копошатся, что полезно для как раз "бест практис" на уровне хобби-одиночки.
Если не будешь флудить ты, то будут флудить другие - и не вопросами по движку, а мемчиками, депрессивным нытьём, байтами на движкосрач, критикой модерации, бесконечными холиварами на разные темы и т.д. Уж лучше пусть тут будут нубские вопросы...
Чем сложнее твой вопрос, тем менее вероятно, что на него хоть кто-то что-то ответит, потому что над сложным вопросом нужно головой думать, а сюда заходят расслабиться, а не работать задаром.
С каких пор вопрос "стесняешься" считается "агрессией"? Стесняться не плохо, это не какой-то недостаток, а нормальный внутренний ограничитель плохого поведения... Куда хуже, когда человек совсем не стесняется ничего... Вполне естественно испытывать стеснение, когда ты считаешь свой вопрос "тупым", "мелким", "не заслуживающим поста на форуме", хотя здесь постят куда более тупые, мелкие и отвратительные вещи, чем вопросы по теме треда (по движку).
Понимаю. Рекомендую почитать r/worldbuilding на Reddit, там много интересного попадается (и много кринжа от детей, но тоже забавно почитать), чтобы не загонять себя в рамки банального фэнтези на банальной средневековой Земле. Может, тебе и не нужно делать игру, а хватит какой-нибудь визуализации/интерактивной схемы/музея твоего мира...
В общем, ты пиши, если что, а то мне скучно. Часто захожу сюда чтобы помочь кому-нибудь с чем-нибудь, а тут никого...
Ну не нейронку же мне просить, чтобы она мне тупые вопросы сочиняла, а я ей на них подробно отвечал, верно?
>StackOverflow
Мне он почти никогда не помогал, потому что там всю дорогу либо вопрос без ответа, либо закрывают по какой-то смешной причине, либо ответ больше не работает (ссылки в посте битые, API устарело, что-то поменялось), либо единственный рабочий ответ предлагает вырезать гланды через жопу, либо поисковик упорно подсовывает не тот вопрос, который я задаю, а "моего" там нет. Какой-то клуб снобов и мазохистов, и так было всегда. Хотя некоторые полезные ответы там были, но если не сделал закладку в браузере заранее - потом не найдёшь... Так что они сами себя убили.
>сильно попал в просак с ивентами с гуи и не сразу разобрался
События GUI подробно расписаны в документации, зачем что-то гуглить?.. Ну, кроме редких багов движка, но их нужно не гуглить в общем интернете, а смотреть на гитхабе, есть ли там открытые issue и пулл-реквесты. Обычно, если проблема/баг старые, то в комментариях находится какой-нибудь обходной путь, который можно использовать до официального фикса в движке. Я неоднократно находил решение своей проблемы именно в обсуждениях проблем движка на гитхабе, где и разработчики отвечают, и юзеры продвинутые. А всякие стэковерфлоу - посторонние сайты, не связанные с движком, логично, что там мало юзеров Godot. Так что кроме http://github.com/godotengine/godot имеет смысл разве что http://reddit.com/r/godot/ посещать - там тоже разработчики иногда отписываются, но чаще всё-таки новички друг с другом копошатся, что полезно для как раз "бест практис" на уровне хобби-одиночки.
>Не хочу флудить
Если не будешь флудить ты, то будут флудить другие - и не вопросами по движку, а мемчиками, депрессивным нытьём, байтами на движкосрач, критикой модерации, бесконечными холиварами на разные темы и т.д. Уж лучше пусть тут будут нубские вопросы...
>форумы уже лучше оставить для чего-то сложного (прям тупика)
Чем сложнее твой вопрос, тем менее вероятно, что на него хоть кто-то что-то ответит, потому что над сложным вопросом нужно головой думать, а сюда заходят расслабиться, а не работать задаром.
>пишешь с пассивной агрессией
>>Стесняешься?
>Зачем это?
С каких пор вопрос "стесняешься" считается "агрессией"? Стесняться не плохо, это не какой-то недостаток, а нормальный внутренний ограничитель плохого поведения... Куда хуже, когда человек совсем не стесняется ничего... Вполне естественно испытывать стеснение, когда ты считаешь свой вопрос "тупым", "мелким", "не заслуживающим поста на форуме", хотя здесь постят куда более тупые, мелкие и отвратительные вещи, чем вопросы по теме треда (по движку).
>нет идей по игре, мне просто нравится делать миры
Понимаю. Рекомендую почитать r/worldbuilding на Reddit, там много интересного попадается (и много кринжа от детей, но тоже забавно почитать), чтобы не загонять себя в рамки банального фэнтези на банальной средневековой Земле. Может, тебе и не нужно делать игру, а хватит какой-нибудь визуализации/интерактивной схемы/музея твоего мира...
В общем, ты пиши, если что, а то мне скучно. Часто захожу сюда чтобы помочь кому-нибудь с чем-нибудь, а тут никого...
Ну не нейронку же мне просить, чтобы она мне тупые вопросы сочиняла, а я ей на них подробно отвечал, верно?
13 Кб, 815x100>>5538
Делал всегда ссылки прям в коде (пик).
SO был не идеальным, но в сравнение с форумами нулевых, это лютая отдушина.
Это, кстати, верно, но были уникумы на некоторых форумах и даже в irc, которые мне помогали в свое время (один даже работал сисадмином у моего провайдера, шарил в линуксе как чародей).
Обязательно. У меня еще ряд вопросов по геймдизайну будут, я хз где актуально это спрашивать (в ньюфаготреде или прям тут?). Вопросы как раз больше философские, порассуждать, пофлудить. Вдобавок я не особо геймер, тут люди только на одну механику кидают сразу примеры игр, о которых я даже не слышал.
>но если не сделал закладку в браузере заранее - потом не найдёшь...
Делал всегда ссылки прям в коде (пик).
SO был не идеальным, но в сравнение с форумами нулевых, это лютая отдушина.
>Чем сложнее твой вопрос, тем менее вероятно, что на него хоть кто-то что-то ответит
Это, кстати, верно, но были уникумы на некоторых форумах и даже в irc, которые мне помогали в свое время (один даже работал сисадмином у моего провайдера, шарил в линуксе как чародей).
>В общем, ты пиши, если что
Обязательно. У меня еще ряд вопросов по геймдизайну будут, я хз где актуально это спрашивать (в ньюфаготреде или прям тут?). Вопросы как раз больше философские, порассуждать, пофлудить. Вдобавок я не особо геймер, тут люди только на одну механику кидают сразу примеры игр, о которых я даже не слышал.
>>5538
Пролистал арты за неделю, на самом деле годный креатив.
Неплохой образ викингингов/дворфов в суровой гористой местности. Ацтекский стиль тоже дает пищу для ума. Но "казаки" на жуках это вообще годнота (я серьезно, прикольный замысел, у меня куда скуднее фантазия).
>r/worldbuilding
Пролистал арты за неделю, на самом деле годный креатив.
Неплохой образ викингингов/дворфов в суровой гористой местности. Ацтекский стиль тоже дает пищу для ума. Но "казаки" на жуках это вообще годнота (я серьезно, прикольный замысел, у меня куда скуднее фантазия).
20 Кб, 288x180>>5548
Ну или слышь не заполняй. Гугл формы падают с server error 500
Ну или слышь не заполняй. Гугл формы падают с server error 500
>>5624
Дополню еще, что на прошлые игры рассылал ключи всяким микро-блогерам обзорщикам, писал в тг, делал розыгрыши и тд.
По итогу правильно настроенные теги и страница дает постоянные продажи на скидках. А блогеры - нет
Дополню еще, что на прошлые игры рассылал ключи всяким микро-блогерам обзорщикам, писал в тг, делал розыгрыши и тд.
По итогу правильно настроенные теги и страница дает постоянные продажи на скидках. А блогеры - нет
Хочу попробовать зафиксировать частоту кадров 3D экшон игры (суть токова) на 12 в секунду, чтобы все движения соответствовали труъ аниме. Подводные?
Сам я часто на 10-15 кадрах в секунду играю, если что.
Сам я часто на 10-15 кадрах в секунду играю, если что.
>>5627
Если обработку инпута не заденешь то подводных вроде нет. В сабреддите годота пару раз такое видел, первое аниме, второе Claymation
Если обработку инпута не заденешь то подводных вроде нет. В сабреддите годота пару раз такое видел, первое аниме, второе Claymation
>>5627
у меня был баг с игрой, что если ты делаешь фпс низкий, то ни в коем случае нельзя recoil интерфейса делать под герцовку экрана. Иначе там интерфейс улетает.
у меня был баг с игрой, что если ты делаешь фпс низкий, то ни в коем случае нельзя recoil интерфейса делать под герцовку экрана. Иначе там интерфейс улетает.
>>5566
Зачем всё это, если плагин под MIT?
https://github.com/Coding-Solo/godot-mcp
Максимум что могут сделать - взять в core.
>>5564
Разве NVIDIA не даёт включить без поддержки?
Кажется, DLSS никак не зависит от источника...
А разве это не годная технология для вокселей?
Типа, чтоб рендерить графику без треугольников...
>будет ии по подписке в редакторе
>билды с закрытыми библиотеками
Зачем всё это, если плагин под MIT?
https://github.com/Coding-Solo/godot-mcp
Максимум что могут сделать - взять в core.
>>5564
>DLSS это нам надо
Разве NVIDIA не даёт включить без поддержки?
Кажется, DLSS никак не зависит от источника...
>ray-tracing похуй
А разве это не годная технология для вокселей?
Типа, чтоб рендерить графику без треугольников...
>>5561
Воняет куском говна, у тебя изо рта
Воняет куском говна, у тебя изо рта
672 Кб, 339x498>>5627
Если ты просто зафиксируешь частоту кадров, то вероятно это будет выглядеть не как аниме, а как тормозящее говно.
Для тру аниме надо нарезать кейфреймы у каждой анимации, типа как в гилтигире
https://www.youtube.com/watch?v=JsRf4xdnXn0
Если ты просто зафиксируешь частоту кадров, то вероятно это будет выглядеть не как аниме, а как тормозящее говно.
Для тру аниме надо нарезать кейфреймы у каждой анимации, типа как в гилтигире
https://www.youtube.com/watch?v=JsRf4xdnXn0
Бумер шутер - такая же вечная классика, как метроидвания или платформер? Имеет смысл туда лезть вообще?
Для меня не сразу было очевидно, на сайте нет контрольных сумм у файлов (а качать могут не все с надежных инструментов).
Если что чек суммы можно найти тут.
https://github.com/godotengine/godot/releases
Проверяйте целостность скаченных файлов.
Если что чек суммы можно найти тут.
https://github.com/godotengine/godot/releases
Проверяйте целостность скаченных файлов.
>>5648
Почему нет?
Если ты спрашиваешь насколько рынок монетизируемый (перспективный), то люди которые могут качественно анализировать рынки - либо тут не сидят, либо честно не скажут. Ничего личного - бизнес.
Почему нет?
Если ты спрашиваешь насколько рынок монетизируемый (перспективный), то люди которые могут качественно анализировать рынки - либо тут не сидят, либо честно не скажут. Ничего личного - бизнес.
>>5693
А я еблан, сорян. Они SHA512 юзают (што, зачем), все на 256
А я еблан, сорян. Они SHA512 юзают (што, зачем), все на 256
>>5693
Да там есть путаница между чексуммами гитхаба (SHA256) и их файла "SHA512-SUMS.txt"
Я сначала скачал с оффсайты, потом начал искать чексуммы. Проверил все норм. Должно совпадать.
Да там есть путаница между чексуммами гитхаба (SHA256) и их файла "SHA512-SUMS.txt"
Я сначала скачал с оффсайты, потом начал искать чексуммы. Проверил все норм. Должно совпадать.
>>5699 (Del)
Есть гарантированный способ проверить целостность файла. Который может повредиться при скачивание или на носителе.
Почему нет?
В бинаре подпись есть, а вот шаблоны я хз что там внутри, не хочется ловить магические ошибки, решения которых в интернете ты не найдешь.
Есть гарантированный способ проверить целостность файла. Который может повредиться при скачивание или на носителе.
Почему нет?
В бинаре подпись есть, а вот шаблоны я хз что там внутри, не хочется ловить магические ошибки, решения которых в интернете ты не найдешь.
84 Кб, 1390x305>>5699 (Del)
А понял про что ты. Там есть хэш на шаблоны тоже.
А понял про что ты. Там есть хэш на шаблоны тоже.
>>5149
А, я про это спрашивал?...
> Схуяли? Вопрос был про залупу для юнити, есть ли такая в годоте. Я сказал что ... не нужна.
А, я про это спрашивал?...
>>5167
1) Если пользоваться; 2) да и смысл делать каждому велосипед; 3) Проверять её будет Дед Мороз? 4) Ну так портани и выложи на github трепло.
> Любая фронтир нейронка за полчаса портанет.
1) Если пользоваться; 2) да и смысл делать каждому велосипед; 3) Проверять её будет Дед Мороз? 4) Ну так портани и выложи на github трепло.
>>5199
ИМХО, это пустая трата производительности, и анон >>5141 прав - лучше 1 раз сделать нормальные текстурки, чем пытаться заклеить недостатки прям в рантайме с помощью таких вот мелких декалей.
Ты ровно на 20 лет как устарел, компы с тех пор давно и не такое тянут. Т.е.после времён HL2. Вон в UT3 - даже имеющюся в движке оптимизацию авто-отключение 3D фальш-панелей поверх их же но, уже нарисованных на текстурах стенах, значит разработчиками игры даже специально для того сделанные, - маппер(ы) даже забыл(и) выключить, криворукие уроды: и всё равно более-менее тянуло, на не лаптопах понятно.
А, резон же в плагине в том - что, никакая текстура не заменит 3D скол, т.б.на уровне камеры, т.е.порой на любом; максимум в MIP для очень удалённого LOD не содержащего без скола(ов). И что плагину в Godot тоже желательно учитывать и иметь настройку.
> Я вот смотрел-смотрел на скриншот и не мог понять, что же там пытаются показать, пока не прочитал:
>добавления сколов, грязи и износа на углы
ИМХО, это пустая трата производительности, и анон >>5141 прав - лучше 1 раз сделать нормальные текстурки, чем пытаться заклеить недостатки прям в рантайме с помощью таких вот мелких декалей.
Ты ровно на 20 лет как устарел, компы с тех пор давно и не такое тянут. Т.е.после времён HL2. Вон в UT3 - даже имеющюся в движке оптимизацию авто-отключение 3D фальш-панелей поверх их же но, уже нарисованных на текстурах стенах, значит разработчиками игры даже специально для того сделанные, - маппер(ы) даже забыл(и) выключить, криворукие уроды: и всё равно более-менее тянуло, на не лаптопах понятно.
А, резон же в плагине в том - что, никакая текстура не заменит 3D скол, т.б.на уровне камеры, т.е.порой на любом; максимум в MIP для очень удалённого LOD не содержащего без скола(ов). И что плагину в Godot тоже желательно учитывать и иметь настройку.
* Притом, накладывая скол и на каждую текстуру там, опционально автогенерируя её по шаблону опционально задаваемому в текстуре в т.ч. с выбором его типа(скол, микроскол, стёртость, обрушение. ...).
Должен мочь быть любого задаваемого диапазном размера, в т.ч.в % размера tex на нём, при указаниии этого символа в поле ввода; с микросколами на нём, и с заданием и их диапазона размера.
В идеале, опционально автогенерируя в real-time в самой игре; для того чтобы не хранить однородные модели типа плоских ступеней и стен каждую по отдельности на диске. А, в самом идеале и для динамической генерации пулевых отверстий и от взрывов. Соответственно именно интегрированность этого в движок, вместо внешних утилит, это всё как раз и позволит сделать.
Должен мочь быть любого задаваемого диапазном размера, в т.ч.в % размера tex на нём, при указаниии этого символа в поле ввода; с микросколами на нём, и с заданием и их диапазона размера.
В идеале, опционально автогенерируя в real-time в самой игре; для того чтобы не хранить однородные модели типа плоских ступеней и стен каждую по отдельности на диске. А, в самом идеале и для динамической генерации пулевых отверстий и от взрывов. Соответственно именно интегрированность этого в движок, вместо внешних утилит, это всё как раз и позволит сделать.
>>5723
Всё равно у тебя есть какой-то "бюджет" ресурсов компьютера, и ты должен использовать его на то, что особенно важно твоей игре, а не на случайные детали, которые твоим игрокам вообще не будут интересны. Я уверен, что игроки в мою игру даже не заметят, если я добавлю такие никому не нужные детали - так зачем возиться и тратить бюджет на них, если можно взять и потратить тот же бюджет на что-то более важное?
Тот плагин не делает никаких "3D сколов". Всё, что он делает, это размещает декали, а декаль - это такая текстура, которая накладывается на поверхности как наклейка, и предназначена для таких динамических эффектов, как следы пуль, взрывов и т.п. Подробнее:
https://docs.godotengine.org/en/stable/tutorials/3d/using_decals.html
https://docs.godotengine.org/en/stable/classes/class_decal.html
Декаль может иметь карту нормалей, чтобы создать искажение света на поверхности, но декаль не может добавить новой геометрии ("3D сколов") и не может деформировать уже имеющуюся геометрию (т.к. недоступны пользовательские шейдеры), поэтому получается, что декаль всегда будет "плоской", т.е. повторять геометрию поверхности, на которую она проецируется. Как наклейки на автомобиле - они не формируют новые вмятины/сколы на корпусе.
>компы с тех пор давно и не такое тянут
Всё равно у тебя есть какой-то "бюджет" ресурсов компьютера, и ты должен использовать его на то, что особенно важно твоей игре, а не на случайные детали, которые твоим игрокам вообще не будут интересны. Я уверен, что игроки в мою игру даже не заметят, если я добавлю такие никому не нужные детали - так зачем возиться и тратить бюджет на них, если можно взять и потратить тот же бюджет на что-то более важное?
>никакая текстура не заменит 3D скол
Тот плагин не делает никаких "3D сколов". Всё, что он делает, это размещает декали, а декаль - это такая текстура, которая накладывается на поверхности как наклейка, и предназначена для таких динамических эффектов, как следы пуль, взрывов и т.п. Подробнее:
https://docs.godotengine.org/en/stable/tutorials/3d/using_decals.html
https://docs.godotengine.org/en/stable/classes/class_decal.html
Декаль может иметь карту нормалей, чтобы создать искажение света на поверхности, но декаль не может добавить новой геометрии ("3D сколов") и не может деформировать уже имеющуюся геометрию (т.к. недоступны пользовательские шейдеры), поэтому получается, что декаль всегда будет "плоской", т.е. повторять геометрию поверхности, на которую она проецируется. Как наклейки на автомобиле - они не формируют новые вмятины/сколы на корпусе.
>>5748 (Del)
Какая разница, какими они бывают, если Godot (читай документацию по ссылкам) имеет эти? Предлагаешь переписывать ядро движка? Ради чего это нужно?
Есть минимум два других способа сделать так:
1. Добавить меши-осколки поверхности вокруг точки.
2. Нарисовать в текстуре объекта маску деформации.
Эти способы легко реализовать и в Godot.
Кстати, большой минус смещения вершин в том, что требуется изначально плотный меш, иначе все твои деформации будут выглядеть излишне гладкими... Раньше существовала технология генерации новой геометрии прям в коде шейдера, но в Godot её нет.
>Декали бывают разные
Какая разница, какими они бывают, если Godot (читай документацию по ссылкам) имеет эти? Предлагаешь переписывать ядро движка? Ради чего это нужно?
>области действия декали вершины смещаются
Есть минимум два других способа сделать так:
1. Добавить меши-осколки поверхности вокруг точки.
2. Нарисовать в текстуре объекта маску деформации.
Эти способы легко реализовать и в Godot.
Кстати, большой минус смещения вершин в том, что требуется изначально плотный меш, иначе все твои деформации будут выглядеть излишне гладкими... Раньше существовала технология генерации новой геометрии прям в коде шейдера, но в Godot её нет.
>>5805
Они твой попус окупили хоть? Или ты считаешь что взял у мамки 5 рублей на дело, заработал 3 рубля, то у тебя доход 3 рубля, а не то что ты потерял 2 рубля?
Они твой попус окупили хоть? Или ты считаешь что взял у мамки 5 рублей на дело, заработал 3 рубля, то у тебя доход 3 рубля, а не то что ты потерял 2 рубля?
>>5804
А ты лимиты вообще выбираешь полностью? Я взял 2 акка по 20$ и мне хватает ровно столько чтобы не охуевать от безудержного вайбкодинга и успевать следить за нейродебилом что он там лепит, как раз хватает на неделю закрыть потребности.
А ты лимиты вообще выбираешь полностью? Я взял 2 акка по 20$ и мне хватает ровно столько чтобы не охуевать от безудержного вайбкодинга и успевать следить за нейродебилом что он там лепит, как раз хватает на неделю закрыть потребности.
>>5816
Я не он, код ебашу антигравити+гемини вместо клода, и смотря чего как. Если активно пилю большую фичу или перерабатываю старые - бывает упираюсь в пятичасовой/недельный лимит, хотя лимиты там больше чем у клода. Но читаю/разбираю я каждую строчку и имею строгие гайдлайны чтобы оно поносом по всей кодбазе не растекалось. Годотовский UI кстати оно шикарно пилит.
Я не он, код ебашу антигравити+гемини вместо клода, и смотря чего как. Если активно пилю большую фичу или перерабатываю старые - бывает упираюсь в пятичасовой/недельный лимит, хотя лимиты там больше чем у клода. Но читаю/разбираю я каждую строчку и имею строгие гайдлайны чтобы оно поносом по всей кодбазе не растекалось. Годотовский UI кстати оно шикарно пилит.
>>1095748
>> некто: Декали бывают разные
> Какая разница, какими они бывают, если Godot (читай документацию по ссылкам) имеет эти? Предлагаешь переписывать ядро движка?
А, как же даже любая нейронка справится?...
Лично я предлагал плагином но, уч.нужность массово этого, при наличии, то почему бы и не сразу в движок.
> Ради чего это нужно?
Ниже разжевал.
>> области действия декали вершины смещаются
> Есть минимум два других способа сделать так:
> 1. Добавить меши-осколки поверхности вокруг точки.
Как ты осколками выбоину сбоку собрался делать...
> 2. Нарисовать в текстуре объекта маску деформации. Эти способы легко реализовать и в Godot.
В смысле, речь про изображение тесселятору? Если так то, аналогичный вопрос.
> Кстати, большой минус смещения вершин в том, что требуется изначально плотный меш, иначе все твои деформации будут выглядеть излишне гладкими... Раньше существовала технология генерации новой геометрии прям в коде шейдера, но в Godot её нет.
Что за "технология генерации новой геометрии прям в коде шейдера"? Тут по сути что то типа [динамической] тесселяции нужно.
>>5745
Ты недооцениваешь внимание и придирчивость других игроков, вот даже мне совсем не графодрочеру спокойно играющий в игры хоть с EGA графикой, когда она соответсвует времени выпуска игры конечно, и то жутко режут взгляд такие идеально стерильные края стен(ы) особенно же в MP играх где игроки тысячи+ раз бегают по одной и той же локации. И втройне это достаёт картоделам ибо альтернатива этому ручная неинтересная долгая работа, как и просто при желании улучшить в чём то таком чужую карту. И такой инструмент наоборт многим крайне нужен, а в real-time исполнении ещё и будет оптимизированней; более, позволяя в настройках по желаю выключить вовсе такое.
И вообще, я тебя что спрашивал что ты там считаешь о надобности это, нет!... И значит это тебя всё отмазка [себе] что бы не делать - вот цена твоих пространных рассуждений. Нету того то в движке - а, оно же мне и не надо!...
Смотри лучше, в ч.н. по ссылкам там, тут на ребре стык:
https://redonigames.itch.io/redonitools-edge-decal-generator
Он похоже некорректно наименовал как decals, вместо decorations.
>> компы с тех пор давно и не такое тянут
> Всё равно у тебя есть какой-то "бюджет" ресурсов компьютера, и ты должен использовать его на то, что особенно важно твоей игре, а не на случайные детали, которые твоим игрокам вообще не будут интересны. Я уверен, что игроки в мою игру даже не заметят, если я добавлю такие никому не нужные детали - так зачем возиться и тратить бюджет на них, если можно взять и потратить тот же бюджет на что-то более важное?
Ты недооцениваешь внимание и придирчивость других игроков, вот даже мне совсем не графодрочеру спокойно играющий в игры хоть с EGA графикой, когда она соответсвует времени выпуска игры конечно, и то жутко режут взгляд такие идеально стерильные края стен(ы) особенно же в MP играх где игроки тысячи+ раз бегают по одной и той же локации. И втройне это достаёт картоделам ибо альтернатива этому ручная неинтересная долгая работа, как и просто при желании улучшить в чём то таком чужую карту. И такой инструмент наоборт многим крайне нужен, а в real-time исполнении ещё и будет оптимизированней; более, позволяя в настройках по желаю выключить вовсе такое.
И вообще, я тебя что спрашивал что ты там считаешь о надобности это, нет!... И значит это тебя всё отмазка [себе] что бы не делать - вот цена твоих пространных рассуждений. Нету того то в движке - а, оно же мне и не надо!...
>> никакая текстура не заменит 3D скол
> Тот плагин не делает никаких "3D сколов". Всё, что он делает, это размещает декали, а декаль - это такая текстура, которая накладывается на поверхности как наклейка, и предназначена для таких динамических эффектов, как следы пуль, взрывов и т.п.
Смотри лучше, в ч.н. по ссылкам там, тут на ребре стык:
https://redonigames.itch.io/redonitools-edge-decal-generator
Он похоже некорректно наименовал как decals, вместо decorations.
Подумал тут. Если игру можно украсть/слизать, то у тебя хувая игра. В ней есть идея, но нет контента. Пример - флаппи берд, игра одной идеи с нулем контента, не нужно даже декомпилировать, просто посмотрел видос и повторил. Второй пример - дельтарун, где помимо неплохих идей есть куча контента, который и тащит, и что-то никто ее не спиздил, подражатели у нее имеются, "китайцы за неделю скопировали и заработали миллиард" отсутствуют.
>>5891
Ну так-то и Майнкрафт сюда можно отнести, но успешнее всего инди дэва вместе взятого. И я бы лучше был разрабом Майнкрафта, чем дельтаруна.
Ну так-то и Майнкрафт сюда можно отнести, но успешнее всего инди дэва вместе взятого. И я бы лучше был разрабом Майнкрафта, чем дельтаруна.
>>5891
Дельтарун это поделка для фанатов, которые до сих пор пускают слюни на андертейл, выйди подобная игра за пределами фандома - о ней бы даже не узнал никто
Дельтарун это поделка для фанатов, которые до сих пор пускают слюни на андертейл, выйди подобная игра за пределами фандома - о ней бы даже не узнал никто
>>5898
Джемини про в ai studio нормально делает, но, конечно - придется терпеть веб интерфейс и 60к токенов предел (по ощущениям дальше 3.1 про начинает проебывать данные и галюнит сильно)
Джемини про в ai studio нормально делает, но, конечно - придется терпеть веб интерфейс и 60к токенов предел (по ощущениям дальше 3.1 про начинает проебывать данные и галюнит сильно)
>>5895
Если бы череда событий в нужное время в нужном месте не сработало бы (простая удача), то об майнкрафте ты так бы сейчас ничего не слышал. Он так же где-то протух на задворках, как тысячи других недооцененных игр (в то время еще "недо игр").
Забудьте об этом майкрафте, там успех эпохи, а не игры
-Эпохи зарождение выживачей и крафточей
-Эпоха подросших детей лего (возможность креатива на кубиках)
-Эпоха видео в инете - эпоха летсплея.
-Эпоха комьюнити которые направили в нужное русло
-Эпоха когда игр еще не было как грязи.
-Эпоха когда у людей (и детей) еще не было клипового мышления
На старте это было лягающее пустое говно на древней джаве, которое вытащило сарафанное радио и комьюнити. Это просто исключительная ситуация, поэтому повторяя майкрафт ты даже толику успеха не получаешь. Такие игры могут выходить раз 10-20-50-100 лет и успех там глубоко не в геймплее.
Если бы череда событий в нужное время в нужном месте не сработало бы (простая удача), то об майнкрафте ты так бы сейчас ничего не слышал. Он так же где-то протух на задворках, как тысячи других недооцененных игр (в то время еще "недо игр").
Забудьте об этом майкрафте, там успех эпохи, а не игры
-Эпохи зарождение выживачей и крафточей
-Эпоха подросших детей лего (возможность креатива на кубиках)
-Эпоха видео в инете - эпоха летсплея.
-Эпоха комьюнити которые направили в нужное русло
-Эпоха когда игр еще не было как грязи.
-Эпоха когда у людей (и детей) еще не было клипового мышления
На старте это было лягающее пустое говно на древней джаве, которое вытащило сарафанное радио и комьюнити. Это просто исключительная ситуация, поэтому повторяя майкрафт ты даже толику успеха не получаешь. Такие игры могут выходить раз 10-20-50-100 лет и успех там глубоко не в геймплее.
>>5012 >>5127 >>5738 >>5804
>>5805 >>5816 >>5860 >>5902
Товарищи вайбкодеры, вы хотя бы прикладывайте скриншоты своих игровых поделок, чтобы мы тут посмеялись убедились, что вы там что-то реально навайбкодить сумели, а не просто компенсируете очередную досадную неудачу с "экспериментом" рассказами о сказочных успехах в геймдеве. Ок?
>>5891
Контент дороже всего делать... По твоей логике - совершенно любая ААА игра - это "10/10", ибо там колоссальное количество контента, а почти любая индюшатина не достойна внимания, ведь любая ААА компания могла бы (если захотела) её скопировать...
>>5906
Не будь майнкрафта, была бы другая игра про кубы.
Но ты же сам перечислил фичи майнкрафта, которые жаждала публика тех лет, разве нет? То, что сегодня абсолютный клон майнкрафта почти никому не будет интересен - это очевидно, ведь есть оригинальный майнкрафт. Чтобы "повторить майнкрафт", нужно, естественно, повторять не сами кубики, а то, что Нотч сделал правильно (даже если случайно): он сделал прототип, собрал народ, дальше дорабатывал в силу возможностей и желаний аудитории. Практически нет успешных инди-игр, которые делались 10+ лет в информационной пустоте и ВДРУГ стали успешны.
А вы тут жмётесь не то, что скриншот скинуть, а даже вопросы по движку задавать. Стесняшки. Как вы эти десятки вайбкоженных игр будете популяризировать, стесняшки? Вы же не платите деньги за рекламу? Она, естественно, не работает так, как вы думаете (очень жёсткая конкуренция между 3.5 толстосумами, все остальные получают 1.5 просмотра и обмякают).
>>5805 >>5816 >>5860 >>5902
Товарищи вайбкодеры, вы хотя бы прикладывайте скриншоты своих игровых поделок, чтобы мы тут посмеялись убедились, что вы там что-то реально навайбкодить сумели, а не просто компенсируете очередную досадную неудачу с "экспериментом" рассказами о сказочных успехах в геймдеве. Ок?
>>5891
>В ней есть идея, но нет контента.
Контент дороже всего делать... По твоей логике - совершенно любая ААА игра - это "10/10", ибо там колоссальное количество контента, а почти любая индюшатина не достойна внимания, ведь любая ААА компания могла бы (если захотела) её скопировать...
>>5906
>о майнкрафте ты так бы сейчас ничего не слышал
Не будь майнкрафта, была бы другая игра про кубы.
>успех там глубоко не в геймплее
Но ты же сам перечислил фичи майнкрафта, которые жаждала публика тех лет, разве нет? То, что сегодня абсолютный клон майнкрафта почти никому не будет интересен - это очевидно, ведь есть оригинальный майнкрафт. Чтобы "повторить майнкрафт", нужно, естественно, повторять не сами кубики, а то, что Нотч сделал правильно (даже если случайно): он сделал прототип, собрал народ, дальше дорабатывал в силу возможностей и желаний аудитории. Практически нет успешных инди-игр, которые делались 10+ лет в информационной пустоте и ВДРУГ стали успешны.
А вы тут жмётесь не то, что скриншот скинуть, а даже вопросы по движку задавать. Стесняшки. Как вы эти десятки вайбкоженных игр будете популяризировать, стесняшки? Вы же не платите деньги за рекламу? Она, естественно, не работает так, как вы думаете (очень жёсткая конкуренция между 3.5 толстосумами, все остальные получают 1.5 просмотра и обмякают).
>>5908
В некоторых вывозит трафик и маркетинг. В некоторых есть неочевидный дизайн. Но то что было на старте у майкрафта - это должно было просто протухнуть. Он еще рано начал стричь продавать.
Возможно там был и маркетинг, потому что игру пробовали по хайпу "о, все об этом говорят, я тоже попробую это", а не по принципу - "о, как классно, я хочу в это поиграть"
Я именно про пустую версию, которая была в начале, а не конечную игру.
В некоторых вывозит трафик и маркетинг. В некоторых есть неочевидный дизайн. Но то что было на старте у майкрафта - это должно было просто протухнуть. Он еще рано начал стричь продавать.
Возможно там был и маркетинг, потому что игру пробовали по хайпу "о, все об этом говорят, я тоже попробую это", а не по принципу - "о, как классно, я хочу в это поиграть"
Я именно про пустую версию, которая была в начале, а не конечную игру.
Проблемка есть, у меня допустим есть турелька которая врагов выпиливать должна с зоной обнаружения, в итоге ставишь таких штук 5 и игра забивается я думал дело в зоне но я даже когад выключал её всё равно не помогло, профайлер пишет find collisions дохуя жрёт но я без понятия что это.
Моделька не должна столько жрать ибо лоу поли, коллизии настроены кароче вообще потерялся.
Моделька не должна столько жрать ибо лоу поли, коллизии настроены кароче вообще потерялся.
>>5910
Фичи эпохи, которые неактуальны.
Просто надоел майнкрафт как пример, когда в других играх есть решения не зависящие от времени, на которые стоит обратить внимание, а не верить что ты выиграешь в лотерею (особенно с нулевым софт скиллом по работе с коммьюнити/соцсетями)
>Но ты же сам перечислил фичи майнкрафта
Фичи эпохи, которые неактуальны.
Просто надоел майнкрафт как пример, когда в других играх есть решения не зависящие от времени, на которые стоит обратить внимание, а не верить что ты выиграешь в лотерею (особенно с нулевым софт скиллом по работе с коммьюнити/соцсетями)
>>5916
Это интересно. Что значит забивается? Ты понимаешь свой код (или это вайбкод)? Покажи видос хотя бы или профайлер (я тоже ньюфаня).
Это интересно. Что значит забивается? Ты понимаешь свой код (или это вайбкод)? Покажи видос хотя бы или профайлер (я тоже ньюфаня).
ещё кэш забивается но я ваще хз чем - W 0:00:20:912 step: Jolt Physics manifold cache exceeded capacity and contacts were ignored. Consider increasing maximum number of contact constraints in project settings. Maximum number of contact constraints is currently set to 20480.
<Исходный код C++>modules/jolt_physics/spaces/jolt_space_3d.cpp:193 @ step()
<Исходный код C++>modules/jolt_physics/spaces/jolt_space_3d.cpp:193 @ step()
>>5920
Лагает только 5 турелек или 1 одна турелька начинает тоже лагать, только позже?
Исключи утечку в цикле, когда-то что-то спавниться в итерации много раз.
Может у тебя миллионы пуль с физикой?
Лагает только 5 турелек или 1 одна турелька начинает тоже лагать, только позже?
Исключи утечку в цикле, когда-то что-то спавниться в итерации много раз.
Может у тебя миллионы пуль с физикой?
>>5921
Выглядит так что ты что-то много спавнишь и забиваешь пул кэша, но нужны эксперты.
Выглядит так что ты что-то много спавнишь и забиваешь пул кэша, но нужны эксперты.
>>5922
Хз ну вот я ставлю турелки на пол и после определённог омомента просто фпс падает до нуля, при этом они ничё не делают ещё. Не у меня лазер, даже стрельбы никакой нет ещё а уже лагодром.
Хз ну вот я ставлю турелки на пол и после определённог омомента просто фпс падает до нуля, при этом они ничё не делают ещё. Не у меня лазер, даже стрельбы никакой нет ещё а уже лагодром.
ну кароче пробелма в том что радиус слишком большой(20) но я хз чё он так ругается он не сильно большой и я только врагов включил.
11 Кб, 267x138>>5924
У тебя бесконечно что-то порождается. Или в кадре или в своем кастомном цикле, смотри объекты во время игры - переключи вкладку объектов в игре на "сцене", посмотри нет ли туева куча объектов.
У тебя бесконечно что-то порождается. Или в кадре или в своем кастомном цикле, смотри объекты во время игры - переключи вкладку объектов в игре на "сцене", посмотри нет ли туева куча объектов.
>>5925
Зона пjражения твоей туррели - должна быть Area2D/Area3D, а у тебя видимо CharacterBody с гигантской коллизией
Зона пjражения твоей туррели - должна быть Area2D/Area3D, а у тебя видимо CharacterBody с гигантской коллизией
>>5928
Поэтому надо понимать свой код. Учитесь с помощью ИИ, не будьте вайбкодей. В любом приложении сложность растет в прогрессии, никакая слот машина не спасет.
Поэтому надо понимать свой код. Учитесь с помощью ИИ, не будьте вайбкодей. В любом приложении сложность растет в прогрессии, никакая слот машина не спасет.
>>5910
Обойдешься, родной. Мы все тут друг другу верим на слово, а кто не верит - того не держим. Кто хочет - сам в субшоте покажется, типа того вайб-движкописи
>Товарищи вайбкодеры, вы хотя бы прикладывайте скриншоты своих игровых поделок
Обойдешься, родной. Мы все тут друг другу верим на слово, а кто не верит - того не держим. Кто хочет - сам в субшоте покажется, типа того вайб-движкописи
>>5910
>>5722
Это один и тот же долбоеб же, верно? Какое-то тупорылое агрессивное отрицание с требованием пруфов, будто мы ему тут про инопланетян рассказываем. Ну либо желание повайбкодить через прокси-человека. Следующий шаг - запросит ему игру сделать.
>прикладывайте скриншоты своих игровых поделок, чтобы мы тут посмеялись убедились
>>5722
>Ну так портани и выложи на github трепло.
Это один и тот же долбоеб же, верно? Какое-то тупорылое агрессивное отрицание с требованием пруфов, будто мы ему тут про инопланетян рассказываем. Ну либо желание повайбкодить через прокси-человека. Следующий шаг - запросит ему игру сделать.
>>5903
Если ты про джемини-приложение (отдельное) - у них там как будто модель нихуя не помнит спустя 3 сообщения, такое ощущение складывается, потому я в студии работаю, там хотябы контекст можно почистить вилкой чтобы чат как можно дольше мог развивать работу не впадая в маразм
Если ты про джемини-приложение (отдельное) - у них там как будто модель нихуя не помнит спустя 3 сообщения, такое ощущение складывается, потому я в студии работаю, там хотябы контекст можно почистить вилкой чтобы чат как можно дольше мог развивать работу не впадая в маразм
>>5915
Я играл в пре-пре-альфу майна - это довольно интересно даже в 2026 году.
>>5918
Выживать в жестоком незнакомом мире - это "неактуально"?
Делать инструменты и строить убежище - это "неактуально"?
Сражаться с монстрами за новые шмотки - это "неактуально"?
Накапливать вещи, так что девать некуда - это "неактуально"?
Создавать огород и размножать живность - это "неактуально"?
Стать диктатором своей личной деревни - это "неактуально"?
Чем ты по жизни занимаешься, если не этими вещами?
Какие? По сути, всё, что можно было сделать, давно есть в майнкрафте...
Просто не рассказывай всем, как ты всех ненавидишь, и к тебе потянутся.
>то что было на старте у майкрафта - это должно было просто протухнуть
Я играл в пре-пре-альфу майна - это довольно интересно даже в 2026 году.
>>5918
>Фичи эпохи, которые неактуальны
Выживать в жестоком незнакомом мире - это "неактуально"?
Делать инструменты и строить убежище - это "неактуально"?
Сражаться с монстрами за новые шмотки - это "неактуально"?
Накапливать вещи, так что девать некуда - это "неактуально"?
Создавать огород и размножать живность - это "неактуально"?
Стать диктатором своей личной деревни - это "неактуально"?
Чем ты по жизни занимаешься, если не этими вещами?
>решения не зависящие от времени, на которые стоит обратить внимание
Какие? По сути, всё, что можно было сделать, давно есть в майнкрафте...
>особенно с нулевым софт скиллом по работе с коммьюнити/соцсетями
Просто не рассказывай всем, как ты всех ненавидишь, и к тебе потянутся.
>>5934
Нет, разные. Это >>5722 "zоg-шиз" написал.
Где ты тут агрессию увидел? Вежливо попросил скрины.
Смысл просто рассказывать, если можешь показывать?
Мне не нужен ничей говнокод, у меня своего много.
Ну, допустим, а что? Тебе же это ничего не стоит.
Почему-то в разделе две категории шизов:
Что я ещё как-то могу понять (не люблю спам), но:
Это какая-то ультра-шиза. Зачем ты в /gd/ заходишь?
>Это один и тот же
Нет, разные. Это >>5722 "zоg-шиз" написал.
>агрессивное
Где ты тут агрессию увидел? Вежливо попросил скрины.
>будто мы ему тут про инопланетян рассказываем
Смысл просто рассказывать, если можешь показывать?
>желание повайбкодить через прокси-человека
Мне не нужен ничей говнокод, у меня своего много.
>Следующий шаг - запросит ему игру сделать
Ну, допустим, а что? Тебе же это ничего не стоит.
Почему-то в разделе две категории шизов:
>РЯЯЯЯ РЕКЛАМА НЕ РЕКЛАМИРУЙТЕ СВОИ ИГРЫ ТУТ
Что я ещё как-то могу понять (не люблю спам), но:
>РЯЯЯЯ НИЧЕГО НЕ ПОКАЖУ, ПРОСТО ВЕРЬ НА СЛОВО
Это какая-то ультра-шиза. Зачем ты в /gd/ заходишь?
>>5941
Речь не про актуально или нет, речь про уровень успеха майнкрафта. Повтори все это и ты получишь ровно ничего.
Еще иногда зумеры спорят о том что в майкрафте это все было впервые, это тоже не верно.
Жестокий мир уровня - выкопал три тайла под землю, переждал ночь, пережил основного антагониста в игре.
Убежище на которое никак не влияет внешний мир (кроме случайного взрыва зеленой фигни)
Не хотел тебе отвечать, потому что ты сказочник. В альфе даже не было голода и биомов (и вроде режима творчества). Это была реально лагающая перделка уровня СУБШОТА.
>это "неактуально"?
Речь не про актуально или нет, речь про уровень успеха майнкрафта. Повтори все это и ты получишь ровно ничего.
Еще иногда зумеры спорят о том что в майкрафте это все было впервые, это тоже не верно.
>Выживать в жестоком незнакомом мире
Жестокий мир уровня - выкопал три тайла под землю, переждал ночь, пережил основного антагониста в игре.
>Делать инструменты и строить убежище
Убежище на которое никак не влияет внешний мир (кроме случайного взрыва зеленой фигни)
>Я играл в пре-пре-альфу майна - это довольно интересно даже в 2026 году.
Не хотел тебе отвечать, потому что ты сказочник. В альфе даже не было голода и биомов (и вроде режима творчества). Это была реально лагающая перделка уровня СУБШОТА.
>>5945
Я больше склоняюсь к тому, что сработала очередная тема - мол просто "джон", из простой швецарской семьи, сделал "в гараже" игру мечты. В общем, классический маркетинговый буллшит для потребителя. Но я был слишком тупой в те года чтобы проанализировать маркетинг, а сейчас искать уже бесполезно.
Игра (альфы) была слишком плоха для тех лет (именно альфы, тот майкрафт на котором выросли зумеры уже был нормальный и уже на пике популярности и речь конкретно что его подняло на этот пик)
Я больше склоняюсь к тому, что сработала очередная тема - мол просто "джон", из простой швецарской семьи, сделал "в гараже" игру мечты. В общем, классический маркетинговый буллшит для потребителя. Но я был слишком тупой в те года чтобы проанализировать маркетинг, а сейчас искать уже бесполезно.
Игра (альфы) была слишком плоха для тех лет (именно альфы, тот майкрафт на котором выросли зумеры уже был нормальный и уже на пике популярности и речь конкретно что его подняло на этот пик)
82 Кб, 1693x1039Годотаны, как вы боретесь со швами на стыках коллизий в TileMapLayer? Увеличил Physics Quadrant Size до 256, помогло на горизонтальных поверхностях по ходу уровня, но херня на стыках не исчезла. Я бы забил хер, но в эти щели проваливаются мои ригид бадис, такие как гранаты/ошмётки от противников. Гугл предлагает захуярить всё одним огромным полигоном поверх тайлмапа, неужели это т.н. Godot's Way?
>>5936
Я просто в гугле режим ии вбиваю, хз у меня даже объёмный код он запомниает но там надо иногда просто напоминать о деталях важных
Я просто в гугле режим ии вбиваю, хз у меня даже объёмный код он запомниает но там надо иногда просто напоминать о деталях важных
>>5948
Делаю текстуру на 1 пиксель больше, чем надо. Лишний край обрезается (crop content) и в нормальном виде незаметен. На стыках этот край заполняет дефекты округления.
Делаю текстуру на 1 пиксель больше, чем надо. Лишний край обрезается (crop content) и в нормальном виде незаметен. На стыках этот край заполняет дефекты округления.
42 Кб, 556x552>>5951
Не совсем понял, можно поподробнее и наглядно?
Вот у меня есть тайлсет с кучей тайлов 32х32. Допустим я добавлю однопиксельную обводку к ним (или уменьшу коллизию на 1 пиксель по краям).
Но как это повлияет на общую картину? Кубики просто станут чуть короче, а стыки на диагоналях куда денутся?
Не совсем понял, можно поподробнее и наглядно?
Вот у меня есть тайлсет с кучей тайлов 32х32. Допустим я добавлю однопиксельную обводку к ним (или уменьшу коллизию на 1 пиксель по краям).
Но как это повлияет на общую картину? Кубики просто станут чуть короче, а стыки на диагоналях куда денутся?
>>5952
@monkey научи анона как при помощи лишнего края на текстуре заполнять стыки между спрайтами
@monkey научи анона как при помощи лишнего края на текстуре заполнять стыки между спрайтами
Добавляешь к тайлам по пикселю обводки с каждой стороны, дублируя крайние цвета текстуры. При билинейной фильтрации или лёгком зуме эти дубликаты заполняют щели, и диагональные стыки не рвутся белыми линиями. Кубики при этом остаются того же размера, просто текстура чуть больше.
>>5953
Понял, ты про визуал. Визуал мне похую, у меня физический слой с дырками, размер спрайтов тут ни при чём.
Почитал поподробнее, на гитхабе с этим бьются с осени прошлого года, даже какой-то запекатор коллизий сделали.
https://github.com/popcar2/GodotTilemapBaker
Понял, ты про визуал. Визуал мне похую, у меня физический слой с дырками, размер спрайтов тут ни при чём.
Почитал поподробнее, на гитхабе с этим бьются с осени прошлого года, даже какой-то запекатор коллизий сделали.
https://github.com/popcar2/GodotTilemapBaker
>>5954
Неожиданно годная штука, уменьшающая количество коллизий. И делающая то, что ты должен был сделать сам руками.
Как у тебя там гранаты пролетают, я не понимаю?
>даже какой-то запекатор коллизий сделали.
Неожиданно годная штука, уменьшающая количество коллизий. И делающая то, что ты должен был сделать сам руками.
Как у тебя там гранаты пролетают, я не понимаю?
1,8 Мб, mp4,1148x646, 0:15
Скачал демку, походу пофиксили проблему. Но у объекта как-будто появилась масса (как бы прикладываешь усилие для ускорения).
https://github.com/godotengine/godot/issues/72372
https://github.com/godotengine/godot/issues/72372
>>5958
Ну вот, посмотри. Кидаю гранату в угол, подхожу к ней вплотную, соответственно своей коллизией её толкаю в этот ебучий шов, и она благополучно стелет вниз чётенько по линии, падая в аут оф баундс. Та же херня и с другими RigidBody2D. Может это и edge-case во всех смыслах, но всё же жаль что такая первостепенная и важная вещь как коллизии до сих пор не отдрочена в движке в 2026 году.
Попробовал запекатор, стало чуть лучше: теперь стыков нет, а дырки между коллизиями не диагональные, а вертикальные/горизонтальные. Ригиды всё равно в них немного закатываются в редких случаях, но уж лучше чем совсем улетать с пределов карты.
>Как у тебя там гранаты пролетают, я не понимаю?
Ну вот, посмотри. Кидаю гранату в угол, подхожу к ней вплотную, соответственно своей коллизией её толкаю в этот ебучий шов, и она благополучно стелет вниз чётенько по линии, падая в аут оф баундс. Та же херня и с другими RigidBody2D. Может это и edge-case во всех смыслах, но всё же жаль что такая первостепенная и важная вещь как коллизии до сих пор не отдрочена в движке в 2026 году.
Попробовал запекатор, стало чуть лучше: теперь стыков нет, а дырки между коллизиями не диагональные, а вертикальные/горизонтальные. Ригиды всё равно в них немного закатываются в редких случаях, но уж лучше чем совсем улетать с пределов карты.
>>5959
Вот это кстати я пофиксил увеличением Physics Quadrant Size с 16 до 128/256.
Вот это кстати я пофиксил увеличением Physics Quadrant Size с 16 до 128/256.
>>5960
Так просто увеличить немного блок коллизии (так же на пиксель как предлагал анон с текстурой).
Но мне кажется ты тушкой давишь и происходит какая-то йоба цикличность и граната улетает за физику (как это бывает во многих играх, когда здавливают предмет, я хз как это называется)
Так просто увеличить немного блок коллизии (так же на пиксель как предлагал анон с текстурой).
Но мне кажется ты тушкой давишь и происходит какая-то йоба цикличность и граната улетает за физику (как это бывает во многих играх, когда здавливают предмет, я хз как это называется)
37 Кб, 758x778>>5962
Вот что произойдёт если его увеличить. Да, коллизия увеличивается, но сам стык не исчезает.
Вот что произойдёт если его увеличить. Да, коллизия увеличивается, но сам стык не исчезает.
>>5963
Я не совсем понимаю как у тебя в квадратных тайлах образовался диагональный стык?
Я не совсем понимаю как у тебя в квадратных тайлах образовался диагональный стык?
>>5942
Чтобы с тобой общаться захожу, братан. А нюдесы скидывать это другое.
Чтобы с тобой общаться захожу, братан. А нюдесы скидывать это другое.
>>5963
Так это же полигоны? Годот запекает теперь сам?
Кстати я смог воспроизвести застревание (пик2), случайно, второй раз как не скакал так и не смог повторить.
Так это же полигоны? Годот запекает теперь сам?
Кстати я смог воспроизвести застревание (пик2), случайно, второй раз как не скакал так и не смог повторить.
149 Кб, 1010x880>>5969
Вот эта настройка вроде как пофиксила эту проблему (уменьшил до 0.01), больше не могу воспроизвести. Анонче попробуй выкрутить тоже в минимум.
Вот эта настройка вроде как пофиксила эту проблему (уменьшил до 0.01), больше не могу воспроизвести. Анонче попробуй выкрутить тоже в минимум.
43 Кб, 986x185
Увеличение physics_quadrant_size помогает лишь частично, все равном местами говнит.
Как-будто лучше всего ручками сделать (или поверить в тот плагин).
Как-будто лучше всего ручками сделать (или поверить в тот плагин).
>>5971
Это вроде речь про физический движок.
В случае застревания помогло при 0.01.
В гитхабе вообще пишут в ноль кодом прописать.
https://github.com/godotengine/godot/issues/47148#issuecomment-1889892323
>что работает только с физикс3д, а у меня ж двадэ игруля.
Это вроде речь про физический движок.
В случае застревания помогло при 0.01.
В гитхабе вообще пишут в ноль кодом прописать.
https://github.com/godotengine/godot/issues/47148#issuecomment-1889892323
В общем, это реально может кому-то помочь
Видео по значениями
1) 0.3
2) 0.01
Видео по значениями
1) 0.3
2) 0.01
>>5974
Но наверное самый естественный вариант добавить еще одну ноду CollisionShape2D с формой SeparationRayShape2D
Но наверное самый естественный вариант добавить еще одну ноду CollisionShape2D с формой SeparationRayShape2D
>>5959 >>5969
Геймдевычей с такими БЕЗУМНО УВЛЕКАТЕЛЬНЫМИ игровыми механиками нужно привязывать яичками к рохле и заставлять 72 часа без перерывов на обед и сон перевозить ящики по складу. Чтоб они раз и навсегда РАЗВЛЕКЛИСЬ и больше не делали игр с такой механикой. А то развелось тут...
>>5960
Твоя проблема не в диагональных разрезах, а в том, что ты
У тебя слои и маски физических объектов настроены так, что твоя граната "видит" игрока и реагирует на его присутствие, а твой игрок "не видит" гранату и прёт на неё, как будто она - пустое место. Из-за этого граната будет неизбежно просачиваться сквозь препятствия, когда игрок пытается зажать её возле стены или встать на неё сверху, даже если стены и пол будут идеальными. Диагональная щель - не проблема, она здесь - лишь путь наименьшего сопротивления по сравнению со "сплющиванием" гранаты.
Чтобы решить эту проблему по-настоящему, тебе нужно одно из:
1. Убрать маску игрока с гранаты, чтобы граната перестала "видеть" игрока и могла проходить сквозь него свободно, не пинаясь и не зажимаясь им. Это самый логичный вариант для такого маленького предмета, т.к. в реальности твои герои не бесконечно широкие и граната с высокой вероятностью проскочит мимо героя, а не ударится в лоб. Также помни, что твои спрайты героев не будут на 100% соответствовать форме капсулы - нет смысла учитывать коллизию об эту капсулу. Если тебе по геймплею нужно двигать гранаты и другие такие предметы, лучше сделать "взятие предмета в руки" по кнопке, чтобы игрок мог "поднять" и кинуть гранату заново осознанно, а не "пинать её ногами", как ты делаешь сейчас (это также добавит возможность просто перехватить гранату в полёте и кинуть её обратно, что, по-моему, намного круче реалистичной физики).
2. Добавить маску гранаты на героя, чтобы он "видел" гранату и учитывал её положение в пространстве, что должно предотвратить проталкивание гранаты в препятствия. Но тогда твой герой будет "спотыкаться" об эти гранаты, как будто это тяжёлые гири, и в целом контроль игроком будет нарушен. Но это позволит более логично обрабатывать ситуации, когда, например, граната ударяется в лоб противнику и из-за этого он задерживается на секунду, т.к. столкнулся с ней физически. Это может не решить всех проблем, выглядит не очень и в целом повысит нагрузку на физический движок, но может быть полезно именно твоей игре.
3. Если тебе вообще не нужно пинать гранаты по полу, то лучше отключить физику заранее, например, после двух-трёх отскоков, чем оставлять катиться до бесконечности. Тогда объект зафиксируется в пространстве и не будет реагировать на игрока и другие препятствия. Большинству игр стоит делать именно так, поскольку нет смысла пинать всю эту мелочь по полу/спотыкаться об неё - лишняя нагрузка на физический движок.
>>5964
Читай обновления движка почаще, там много интересного. В какой-то из недавних версий добавили новую оптимизацию: если раньше было "1 тайл = 1 квадратный коллайдер", то теперь все тайлы должны физически "склеиваться" в один большой коллайдер или несколько больших, в зависимости от размера карты и размера "квадранта" (чанка, по сути), на которые нарезаются карты. Это реально увеличивает производительность и уменьшает количество проблем из-за стыков, но, как видишь, могут появляться диагональные разрезы.
>>5951 >>5953
Вайбкодя, ты? Он же в первом предложении написал про "коллизии", а дальше про "ригидбоди".
Впрочем, по скриншоту с первого взгляда действительно не понять, что там отображаются коллизии, они слишком хорошо ложатся на спрайты. Но если у тебя на спрайтах возникнут подобные диагональные швы - проблема решается не "отступом от края" спрайта, а включением снаппинга вершин в настройках проекта. Просто по умолчанию вершины в 2D двигаются не по пикселям, из-за этого текстура может "съезжать", но в какой-то из уже старых версий движка добавили возможность снапать вершины к пикселям экрана.
>>5945 >>5946
Вероятно, ты никогда не заработаешь с игр столько же, сколько заработал Нотч, но преуменьшать и тем более полностью игнорировать геймдизайн Майнкрафта нельзя. Ты ни к чему хорошему не придёшь, если будешь думать в стиле "я не могу повторить успех Майнкрафта, поэтому я должен полностью забыть о всех его решениях геймдизайна и сделать что-то ни на что не похожее" - если из упрямства делать "не как у всех", тогда ты сделаешь плохо, потому что многие решения в играх хорошие и должны повторяться и в будущем. Короче, ты из-за своего упрямства пытаешься сделать "не-майнкрафт", что в корне неверно, потому что "лучше майнкрафта" - это "с хорошими деталями и без плохих деталей", а не "что-то совсем другое". Не нужно избегать майнкрафта и его механик, как будто это какая-то болезнь, убивающая проекты.
Геймдевычей с такими БЕЗУМНО УВЛЕКАТЕЛЬНЫМИ игровыми механиками нужно привязывать яичками к рохле и заставлять 72 часа без перерывов на обед и сон перевозить ящики по складу. Чтоб они раз и навсегда РАЗВЛЕКЛИСЬ и больше не делали игр с такой механикой. А то развелось тут...
>>5960
Твоя проблема не в диагональных разрезах, а в том, что ты
>подхожу к ней вплотную
У тебя слои и маски физических объектов настроены так, что твоя граната "видит" игрока и реагирует на его присутствие, а твой игрок "не видит" гранату и прёт на неё, как будто она - пустое место. Из-за этого граната будет неизбежно просачиваться сквозь препятствия, когда игрок пытается зажать её возле стены или встать на неё сверху, даже если стены и пол будут идеальными. Диагональная щель - не проблема, она здесь - лишь путь наименьшего сопротивления по сравнению со "сплющиванием" гранаты.
Чтобы решить эту проблему по-настоящему, тебе нужно одно из:
1. Убрать маску игрока с гранаты, чтобы граната перестала "видеть" игрока и могла проходить сквозь него свободно, не пинаясь и не зажимаясь им. Это самый логичный вариант для такого маленького предмета, т.к. в реальности твои герои не бесконечно широкие и граната с высокой вероятностью проскочит мимо героя, а не ударится в лоб. Также помни, что твои спрайты героев не будут на 100% соответствовать форме капсулы - нет смысла учитывать коллизию об эту капсулу. Если тебе по геймплею нужно двигать гранаты и другие такие предметы, лучше сделать "взятие предмета в руки" по кнопке, чтобы игрок мог "поднять" и кинуть гранату заново осознанно, а не "пинать её ногами", как ты делаешь сейчас (это также добавит возможность просто перехватить гранату в полёте и кинуть её обратно, что, по-моему, намного круче реалистичной физики).
2. Добавить маску гранаты на героя, чтобы он "видел" гранату и учитывал её положение в пространстве, что должно предотвратить проталкивание гранаты в препятствия. Но тогда твой герой будет "спотыкаться" об эти гранаты, как будто это тяжёлые гири, и в целом контроль игроком будет нарушен. Но это позволит более логично обрабатывать ситуации, когда, например, граната ударяется в лоб противнику и из-за этого он задерживается на секунду, т.к. столкнулся с ней физически. Это может не решить всех проблем, выглядит не очень и в целом повысит нагрузку на физический движок, но может быть полезно именно твоей игре.
3. Если тебе вообще не нужно пинать гранаты по полу, то лучше отключить физику заранее, например, после двух-трёх отскоков, чем оставлять катиться до бесконечности. Тогда объект зафиксируется в пространстве и не будет реагировать на игрока и другие препятствия. Большинству игр стоит делать именно так, поскольку нет смысла пинать всю эту мелочь по полу/спотыкаться об неё - лишняя нагрузка на физический движок.
>>5964
>как у тебя в квадратных тайлах образовался диагональный стык?
Читай обновления движка почаще, там много интересного. В какой-то из недавних версий добавили новую оптимизацию: если раньше было "1 тайл = 1 квадратный коллайдер", то теперь все тайлы должны физически "склеиваться" в один большой коллайдер или несколько больших, в зависимости от размера карты и размера "квадранта" (чанка, по сути), на которые нарезаются карты. Это реально увеличивает производительность и уменьшает количество проблем из-за стыков, но, как видишь, могут появляться диагональные разрезы.
>>5951 >>5953
Вайбкодя, ты? Он же в первом предложении написал про "коллизии", а дальше про "ригидбоди".
Впрочем, по скриншоту с первого взгляда действительно не понять, что там отображаются коллизии, они слишком хорошо ложатся на спрайты. Но если у тебя на спрайтах возникнут подобные диагональные швы - проблема решается не "отступом от края" спрайта, а включением снаппинга вершин в настройках проекта. Просто по умолчанию вершины в 2D двигаются не по пикселям, из-за этого текстура может "съезжать", но в какой-то из уже старых версий движка добавили возможность снапать вершины к пикселям экрана.
>>5945 >>5946
Вероятно, ты никогда не заработаешь с игр столько же, сколько заработал Нотч, но преуменьшать и тем более полностью игнорировать геймдизайн Майнкрафта нельзя. Ты ни к чему хорошему не придёшь, если будешь думать в стиле "я не могу повторить успех Майнкрафта, поэтому я должен полностью забыть о всех его решениях геймдизайна и сделать что-то ни на что не похожее" - если из упрямства делать "не как у всех", тогда ты сделаешь плохо, потому что многие решения в играх хорошие и должны повторяться и в будущем. Короче, ты из-за своего упрямства пытаешься сделать "не-майнкрафт", что в корне неверно, потому что "лучше майнкрафта" - это "с хорошими деталями и без плохих деталей", а не "что-то совсем другое". Не нужно избегать майнкрафта и его механик, как будто это какая-то болезнь, убивающая проекты.
>>5959 >>5969
Геймдевычей с такими БЕЗУМНО УВЛЕКАТЕЛЬНЫМИ игровыми механиками нужно привязывать яичками к рохле и заставлять 72 часа без перерывов на обед и сон перевозить ящики по складу. Чтоб они раз и навсегда РАЗВЛЕКЛИСЬ и больше не делали игр с такой механикой. А то развелось тут...
>>5960
Твоя проблема не в диагональных разрезах, а в том, что ты
У тебя слои и маски физических объектов настроены так, что твоя граната "видит" игрока и реагирует на его присутствие, а твой игрок "не видит" гранату и прёт на неё, как будто она - пустое место. Из-за этого граната будет неизбежно просачиваться сквозь препятствия, когда игрок пытается зажать её возле стены или встать на неё сверху, даже если стены и пол будут идеальными. Диагональная щель - не проблема, она здесь - лишь путь наименьшего сопротивления по сравнению со "сплющиванием" гранаты.
Чтобы решить эту проблему по-настоящему, тебе нужно одно из:
1. Убрать маску игрока с гранаты, чтобы граната перестала "видеть" игрока и могла проходить сквозь него свободно, не пинаясь и не зажимаясь им. Это самый логичный вариант для такого маленького предмета, т.к. в реальности твои герои не бесконечно широкие и граната с высокой вероятностью проскочит мимо героя, а не ударится в лоб. Также помни, что твои спрайты героев не будут на 100% соответствовать форме капсулы - нет смысла учитывать коллизию об эту капсулу. Если тебе по геймплею нужно двигать гранаты и другие такие предметы, лучше сделать "взятие предмета в руки" по кнопке, чтобы игрок мог "поднять" и кинуть гранату заново осознанно, а не "пинать её ногами", как ты делаешь сейчас (это также добавит возможность просто перехватить гранату в полёте и кинуть её обратно, что, по-моему, намного круче реалистичной физики).
2. Добавить маску гранаты на героя, чтобы он "видел" гранату и учитывал её положение в пространстве, что должно предотвратить проталкивание гранаты в препятствия. Но тогда твой герой будет "спотыкаться" об эти гранаты, как будто это тяжёлые гири, и в целом контроль игроком будет нарушен. Но это позволит более логично обрабатывать ситуации, когда, например, граната ударяется в лоб противнику и из-за этого он задерживается на секунду, т.к. столкнулся с ней физически. Это может не решить всех проблем, выглядит не очень и в целом повысит нагрузку на физический движок, но может быть полезно именно твоей игре.
3. Если тебе вообще не нужно пинать гранаты по полу, то лучше отключить физику заранее, например, после двух-трёх отскоков, чем оставлять катиться до бесконечности. Тогда объект зафиксируется в пространстве и не будет реагировать на игрока и другие препятствия. Большинству игр стоит делать именно так, поскольку нет смысла пинать всю эту мелочь по полу/спотыкаться об неё - лишняя нагрузка на физический движок.
>>5964
Читай обновления движка почаще, там много интересного. В какой-то из недавних версий добавили новую оптимизацию: если раньше было "1 тайл = 1 квадратный коллайдер", то теперь все тайлы должны физически "склеиваться" в один большой коллайдер или несколько больших, в зависимости от размера карты и размера "квадранта" (чанка, по сути), на которые нарезаются карты. Это реально увеличивает производительность и уменьшает количество проблем из-за стыков, но, как видишь, могут появляться диагональные разрезы.
>>5951 >>5953
Вайбкодя, ты? Он же в первом предложении написал про "коллизии", а дальше про "ригидбоди".
Впрочем, по скриншоту с первого взгляда действительно не понять, что там отображаются коллизии, они слишком хорошо ложатся на спрайты. Но если у тебя на спрайтах возникнут подобные диагональные швы - проблема решается не "отступом от края" спрайта, а включением снаппинга вершин в настройках проекта. Просто по умолчанию вершины в 2D двигаются не по пикселям, из-за этого текстура может "съезжать", но в какой-то из уже старых версий движка добавили возможность снапать вершины к пикселям экрана.
>>5945 >>5946
Вероятно, ты никогда не заработаешь с игр столько же, сколько заработал Нотч, но преуменьшать и тем более полностью игнорировать геймдизайн Майнкрафта нельзя. Ты ни к чему хорошему не придёшь, если будешь думать в стиле "я не могу повторить успех Майнкрафта, поэтому я должен полностью забыть о всех его решениях геймдизайна и сделать что-то ни на что не похожее" - если из упрямства делать "не как у всех", тогда ты сделаешь плохо, потому что многие решения в играх хорошие и должны повторяться и в будущем. Короче, ты из-за своего упрямства пытаешься сделать "не-майнкрафт", что в корне неверно, потому что "лучше майнкрафта" - это "с хорошими деталями и без плохих деталей", а не "что-то совсем другое". Не нужно избегать майнкрафта и его механик, как будто это какая-то болезнь, убивающая проекты.
Геймдевычей с такими БЕЗУМНО УВЛЕКАТЕЛЬНЫМИ игровыми механиками нужно привязывать яичками к рохле и заставлять 72 часа без перерывов на обед и сон перевозить ящики по складу. Чтоб они раз и навсегда РАЗВЛЕКЛИСЬ и больше не делали игр с такой механикой. А то развелось тут...
>>5960
Твоя проблема не в диагональных разрезах, а в том, что ты
>подхожу к ней вплотную
У тебя слои и маски физических объектов настроены так, что твоя граната "видит" игрока и реагирует на его присутствие, а твой игрок "не видит" гранату и прёт на неё, как будто она - пустое место. Из-за этого граната будет неизбежно просачиваться сквозь препятствия, когда игрок пытается зажать её возле стены или встать на неё сверху, даже если стены и пол будут идеальными. Диагональная щель - не проблема, она здесь - лишь путь наименьшего сопротивления по сравнению со "сплющиванием" гранаты.
Чтобы решить эту проблему по-настоящему, тебе нужно одно из:
1. Убрать маску игрока с гранаты, чтобы граната перестала "видеть" игрока и могла проходить сквозь него свободно, не пинаясь и не зажимаясь им. Это самый логичный вариант для такого маленького предмета, т.к. в реальности твои герои не бесконечно широкие и граната с высокой вероятностью проскочит мимо героя, а не ударится в лоб. Также помни, что твои спрайты героев не будут на 100% соответствовать форме капсулы - нет смысла учитывать коллизию об эту капсулу. Если тебе по геймплею нужно двигать гранаты и другие такие предметы, лучше сделать "взятие предмета в руки" по кнопке, чтобы игрок мог "поднять" и кинуть гранату заново осознанно, а не "пинать её ногами", как ты делаешь сейчас (это также добавит возможность просто перехватить гранату в полёте и кинуть её обратно, что, по-моему, намного круче реалистичной физики).
2. Добавить маску гранаты на героя, чтобы он "видел" гранату и учитывал её положение в пространстве, что должно предотвратить проталкивание гранаты в препятствия. Но тогда твой герой будет "спотыкаться" об эти гранаты, как будто это тяжёлые гири, и в целом контроль игроком будет нарушен. Но это позволит более логично обрабатывать ситуации, когда, например, граната ударяется в лоб противнику и из-за этого он задерживается на секунду, т.к. столкнулся с ней физически. Это может не решить всех проблем, выглядит не очень и в целом повысит нагрузку на физический движок, но может быть полезно именно твоей игре.
3. Если тебе вообще не нужно пинать гранаты по полу, то лучше отключить физику заранее, например, после двух-трёх отскоков, чем оставлять катиться до бесконечности. Тогда объект зафиксируется в пространстве и не будет реагировать на игрока и другие препятствия. Большинству игр стоит делать именно так, поскольку нет смысла пинать всю эту мелочь по полу/спотыкаться об неё - лишняя нагрузка на физический движок.
>>5964
>как у тебя в квадратных тайлах образовался диагональный стык?
Читай обновления движка почаще, там много интересного. В какой-то из недавних версий добавили новую оптимизацию: если раньше было "1 тайл = 1 квадратный коллайдер", то теперь все тайлы должны физически "склеиваться" в один большой коллайдер или несколько больших, в зависимости от размера карты и размера "квадранта" (чанка, по сути), на которые нарезаются карты. Это реально увеличивает производительность и уменьшает количество проблем из-за стыков, но, как видишь, могут появляться диагональные разрезы.
>>5951 >>5953
Вайбкодя, ты? Он же в первом предложении написал про "коллизии", а дальше про "ригидбоди".
Впрочем, по скриншоту с первого взгляда действительно не понять, что там отображаются коллизии, они слишком хорошо ложатся на спрайты. Но если у тебя на спрайтах возникнут подобные диагональные швы - проблема решается не "отступом от края" спрайта, а включением снаппинга вершин в настройках проекта. Просто по умолчанию вершины в 2D двигаются не по пикселям, из-за этого текстура может "съезжать", но в какой-то из уже старых версий движка добавили возможность снапать вершины к пикселям экрана.
>>5945 >>5946
Вероятно, ты никогда не заработаешь с игр столько же, сколько заработал Нотч, но преуменьшать и тем более полностью игнорировать геймдизайн Майнкрафта нельзя. Ты ни к чему хорошему не придёшь, если будешь думать в стиле "я не могу повторить успех Майнкрафта, поэтому я должен полностью забыть о всех его решениях геймдизайна и сделать что-то ни на что не похожее" - если из упрямства делать "не как у всех", тогда ты сделаешь плохо, потому что многие решения в играх хорошие и должны повторяться и в будущем. Короче, ты из-за своего упрямства пытаешься сделать "не-майнкрафт", что в корне неверно, потому что "лучше майнкрафта" - это "с хорошими деталями и без плохих деталей", а не "что-то совсем другое". Не нужно избегать майнкрафта и его механик, как будто это какая-то болезнь, убивающая проекты.
>>5978
Потом только понял что недостаток этого подхода - если куб начнет вращаться то все, GG
Потом только понял что недостаток этого подхода - если куб начнет вращаться то все, GG
>>5983
Вообще не ставлю цель заработка. Нотч стал стричь баранов еще на альфах (10$), за игру по качеству СУБШОТЫ. Зумеры наверное думают что тогда просто не было нормальных игр, но десятые это уже спад пика золотой эпохи разнообразия игр по геймплею.
Мое возмущение, что как это на старте могло само стать популярным? Когда я как не спрошу кого - в игру они попробовали именно из-за хайпа. Как-будто хайп исскуственно опережал игру.
>Вероятно, ты никогда не заработаешь с игр столько же, сколько заработал Нотч
Вообще не ставлю цель заработка. Нотч стал стричь баранов еще на альфах (10$), за игру по качеству СУБШОТЫ. Зумеры наверное думают что тогда просто не было нормальных игр, но десятые это уже спад пика золотой эпохи разнообразия игр по геймплею.
Мое возмущение, что как это на старте могло само стать популярным? Когда я как не спрошу кого - в игру они попробовали именно из-за хайпа. Как-будто хайп исскуственно опережал игру.
>>5879
И что - сдулись все?! С вашими может сделать даже любая нейронка.
Только время на разжовывание вам и придумывание улучшений потратил впустую, пустомели!
И что - сдулись все?! С вашими может сделать даже любая нейронка.
Только время на разжовывание вам и придумывание улучшений потратил впустую, пустомели!
>>6007
Вселенная ценит каждое созидание. Вайбкодям это не поможет, но плюс баллы против вселенской энтропии тебе залетело.
Расскажи лучше про свою игру мечты. оказывается у людей столько разнообразных вкусов и предпочтений, что я до сих пор не встретил человека со вкусами такими же как у меня
>Только время на разжовывание вам и придумывание улучшений потратил впустую, пустомели!
Вселенная ценит каждое созидание. Вайбкодям это не поможет, но плюс баллы против вселенской энтропии тебе залетело.
Расскажи лучше про свою игру мечты. оказывается у людей столько разнообразных вкусов и предпочтений, что я до сих пор не встретил человека со вкусами такими же как у меня
Hy3 от Tencent неплохо справляется с Godot. Они же на 3д специализируются. Видимо и LLM на игровых задачах тренили. Пользуйтесь пока халява в opencode. Остальные дешевые серут под себя.
>>6010
Ты забыл посчитать энтропию, созданную сжиганием топлива на электроэнергию для вайбкодинга.
Ты забыл посчитать энтропию, созданную сжиганием топлива на электроэнергию для вайбкодинга.
>>5879
Можешь объяснить, почему это имеет значение?
Говорили же: края можно сделать грязными прямо на текстуре стены (или в шейдере материала стены). Совершенно не обязательно добавлять грязь с помощью декалей, которые ты предлагаешь этим плагином расставлять. У любой задачи есть множество решений, и не все эти решения оптимальны для конкретной ситуации. Если у тебя, скажем, всего одна коробка, которую можно динамически запачкать (симулятор доставщика пиццы), тогда можно её декалями обмазывать динамически - и это будет норм. А если ты хочешь огромную кучу углов, рёбер и прочих мест обмазать декалями "просто потому что", тогда это херня, а не решение, потому что ты тратишь производительность компа (сколько бы её ни было) впустую, на бесполезные действия.
Не вижу там новой геометрии, там всё - плоские декали.
>>6007
Тебе же уже несколько раз объяснили - "нам не надо".
Тебе самому-то такой плагин/инструмент нужен или ты вообще Godot не пользуешься?
>внимание и придирчивость других игроков
Можешь объяснить, почему это имеет значение?
>жутко режут взгляд такие идеально стерильные края стен
Говорили же: края можно сделать грязными прямо на текстуре стены (или в шейдере материала стены). Совершенно не обязательно добавлять грязь с помощью декалей, которые ты предлагаешь этим плагином расставлять. У любой задачи есть множество решений, и не все эти решения оптимальны для конкретной ситуации. Если у тебя, скажем, всего одна коробка, которую можно динамически запачкать (симулятор доставщика пиццы), тогда можно её декалями обмазывать динамически - и это будет норм. А если ты хочешь огромную кучу углов, рёбер и прочих мест обмазать декалями "просто потому что", тогда это херня, а не решение, потому что ты тратишь производительность компа (сколько бы её ни было) впустую, на бесполезные действия.
>Смотри лучше, в ч.н. по ссылкам там, тут на ребре стык
Не вижу там новой геометрии, там всё - плоские декали.
>>6007
>И что - сдулись все?!
Тебе же уже несколько раз объяснили - "нам не надо".
>Только время на разжовывание вам и придумывание улучшений потратил впустую
Тебе самому-то такой плагин/инструмент нужен или ты вообще Godot не пользуешься?
>>6017
Да странно. Недавно визжали, что коровы много пукают, поэтому жрите жуков, а ту сразу забыли об глобальном потеплении..
Да странно. Недавно визжали, что коровы много пукают, поэтому жрите жуков, а ту сразу забыли об глобальном потеплении..
45 Кб, 838x162>>6017
Затрачиваемая работа (даже мысль), всегда повышает энтропию, это неизбежно, но созидание отодвигает этот момент. То есть, тепловая смерть вселенной наступит все равно, мы выживаем, а не исправляем.
Интеллектуально существо, способное создавать и поддерживать новые формы - единственная не случайная форма материя противостоящая энтропии. Если ты искал смысл жизни - то смысл жизни - создавать/творить. Как минимум не разрушать.
Тот злой анон, который на всех прыгает - внутри у него такой деструктив (раньше называли желчный человек), что его злость и боль множит еще больше злости и боли. Он как змея пожирающая самого себя и отравляющая все вокруг (энтропию которую он множит - сжирает его самого изнутри). Такие существа - это ошибка эволюции, исключение, которое нужно придать забвению.
Получайте плюсики в карму, участвуйте во вселенской компании по борьбе с энтропией. Помните, информация никогда не уничтожается.
Затрачиваемая работа (даже мысль), всегда повышает энтропию, это неизбежно, но созидание отодвигает этот момент. То есть, тепловая смерть вселенной наступит все равно, мы выживаем, а не исправляем.
Интеллектуально существо, способное создавать и поддерживать новые формы - единственная не случайная форма материя противостоящая энтропии. Если ты искал смысл жизни - то смысл жизни - создавать/творить. Как минимум не разрушать.
Тот злой анон, который на всех прыгает - внутри у него такой деструктив (раньше называли желчный человек), что его злость и боль множит еще больше злости и боли. Он как змея пожирающая самого себя и отравляющая все вокруг (энтропию которую он множит - сжирает его самого изнутри). Такие существа - это ошибка эволюции, исключение, которое нужно придать забвению.
Получайте плюсики в карму, участвуйте во вселенской компании по борьбе с энтропией. Помните, информация никогда не уничтожается.
>>5934
Это долоёб тут - ты, даже мегадолоёб (и мразь). И ещё публично фактически расписался в этом.
>>5942
Сам шиз zog-отсос интернациональный или сатанист какой, ещё ни разу никто не смог опровергнуть мной говоримого по теме.
И вопрос тут не в том что, я не пользуюсь принципиально а, в том что, локально это требует мега комп для полноценной нейросетки и для работы ещё кучу прав дать ей - а, там к бабке не ходи троян в сознании ИИ от zog же + атких же подонков из сатанистов; а, в online версии - подсовывают сильно ограниченный урезок, ещё и тоже с логированием-слежением на серверах всего общения, а вишенка на торте - уже не даром как в первом случае а, за ежемесячную дань zog'у...
>> Это один и тот же долбоеб же, верно?
Это долоёб тут - ты, даже мегадолоёб (и мразь). И ещё публично фактически расписался в этом.
>>5942
> Нет, разные. Это >>5722 "zоg-шиз" написал.
Сам шиз zog-отсос интернациональный или сатанист какой, ещё ни разу никто не смог опровергнуть мной говоримого по теме.
И вопрос тут не в том что, я не пользуюсь принципиально а, в том что, локально это требует мега комп для полноценной нейросетки и для работы ещё кучу прав дать ей - а, там к бабке не ходи троян в сознании ИИ от zog же + атких же подонков из сатанистов; а, в online версии - подсовывают сильно ограниченный урезок, ещё и тоже с логированием-слежением на серверах всего общения, а вишенка на торте - уже не даром как в первом случае а, за ежемесячную дань zog'у...
>>5932
Ссылку оттуда мог бы сразу сюда занести и что там твой ИИ сказал?
Причина выясненна? А, то подозреваю что, там обновление экрана в фоновом потоке - интервально... Иначе как объяснить эти 1-2 FPS вместо ну пусть максимум div 2 или div N и то - только при включенной Вертикальной синхранизации)
Занёс бы в Issue движку, потому что это поведение эта фича - полная дичь и мегапозорище движку и играм с ним.
> Возможно оно
Ссылку оттуда мог бы сразу сюда занести и что там твой ИИ сказал?
Причина выясненна? А, то подозреваю что, там обновление экрана в фоновом потоке - интервально... Иначе как объяснить эти 1-2 FPS вместо ну пусть максимум div 2 или div N и то - только при включенной Вертикальной синхранизации)
Занёс бы в Issue движку, потому что это поведение эта фича - полная дичь и мегапозорище движку и играм с ним.
>>6018
Ты жопой этот пост читал?...
Ну, точно жопой.
И да, декалями(а, по возможности вовсе отдельынми "патчами" текстуры, как это было в DOOM), декали добавляют для того чтобы повторно использовать текстуру, когда есть такая возможность.
Выдумал.
Расскажи про производительность - пиаристу сатанизма Кармаку о его DOOM движке, т.е.даже в далёком в 1993-ем, плюс ещё и даже с программной отрисовкой...
Смотри лучше, на срез арки.
>>6007
Не говори за всех. Т.б. ты даже жопой же "читаешь" - не показатель... Им, по крайней мере их 3D игр игрокам, больше чем мне надо.
Нет, размышляю; но, инструмент пригодился бы.
И просто читай не жопой: поверь - пригодился бы не только мне.
Как и твой чисто декальный вариант/режим - тоже. В т.ч.и потому что, (про производительность), как я упомянул выше - люди не то что текстуры а, даже 3D модели в качестве "decals" накладывают поверх текстур, как это хоть в том же UT движке.
>> >>5879
>> внимание и придирчивость других игроков
> Можешь объяснить, почему это имеет значение?
Ты жопой этот пост читал?...
>> жутко режут взгляд такие идеально стерильные края стен
> Говорили же: края можно сделать грязными прямо на текстуре стены (или в шейдере материала стены).
Ну, точно жопой.
И да, декалями(а, по возможности вовсе отдельынми "патчами" текстуры, как это было в DOOM), декали добавляют для того чтобы повторно использовать текстуру, когда есть такая возможность.
> Совершенно не обязательно добавлять грязь с помощью декалей, которые ты предлагаешь этим плагином расставлять.
Выдумал.
> У любой задачи есть множество решений, и не все эти решения оптимальны для конкретной ситуации. Если у тебя, скажем, всего одна коробка, которую можно динамически запачкать (симулятор доставщика пиццы), тогда можно её декалями обмазывать динамически - и это будет норм. А если ты хочешь огромную кучу углов, рёбер и прочих мест обмазать декалями "просто потому что", тогда это херня, а не решение, потому что ты тратишь производительность компа (сколько бы её ни было) впустую, на бесполезные действия.
Расскажи про производительность - пиаристу сатанизма Кармаку о его DOOM движке, т.е.даже в далёком в 1993-ем, плюс ещё и даже с программной отрисовкой...
>> Смотри лучше, в ч.н. по ссылкам там, тут на ребре стык
> Не вижу там новой геометрии, там всё - плоские декали.
Смотри лучше, на срез арки.
>>6007
>> И что - сдулись все?!
> Тебе же уже несколько раз объяснили - "нам не надо".
Не говори за всех. Т.б. ты даже жопой же "читаешь" - не показатель... Им, по крайней мере их 3D игр игрокам, больше чем мне надо.
>> Только время на разжовывание вам и придумывание улучшений потратил впустую
> Тебе самому-то такой плагин/инструмент нужен или ты вообще Godot не пользуешься?
Нет, размышляю; но, инструмент пригодился бы.
И просто читай не жопой: поверь - пригодился бы не только мне.
Как и твой чисто декальный вариант/режим - тоже. В т.ч.и потому что, (про производительность), как я упомянул выше - люди не то что текстуры а, даже 3D модели в качестве "decals" накладывают поверх текстур, как это хоть в том же UT движке.
>>6018
Ты жопой этот пост читал?...
Ну, точно жопой.
И да, декалями(а, по возможности вовсе отдельынми "патчами" текстуры, как это было в DOOM), декали добавляют для того чтобы повторно использовать текстуру, когда есть такая возможность.
Выдумал.
Расскажи про производительность - пиаристу сатанизма Кармаку о его DOOM движке, т.е.даже в далёком в 1993-ем, плюс ещё и даже с программной отрисовкой...
Смотри лучше, на срез арки.
>>6007
Не говори за всех. Т.б. ты даже жопой же "читаешь" - не показатель... Им, по крайней мере их 3D игр игрокам, больше чем мне надо.
Нет, размышляю; но, инструмент пригодился бы.
И просто читай не жопой: поверь - пригодился бы не только мне.
Как и твой чисто декальный вариант/режим - тоже. В т.ч.и потому что, (про производительность), как я упомянул выше - люди не то что текстуры а, даже 3D модели в качестве "decals" накладывают поверх текстур, как это хоть в том же UT движке.
>> >>5879
>> внимание и придирчивость других игроков
> Можешь объяснить, почему это имеет значение?
Ты жопой этот пост читал?...
>> жутко режут взгляд такие идеально стерильные края стен
> Говорили же: края можно сделать грязными прямо на текстуре стены (или в шейдере материала стены).
Ну, точно жопой.
И да, декалями(а, по возможности вовсе отдельынми "патчами" текстуры, как это было в DOOM), декали добавляют для того чтобы повторно использовать текстуру, когда есть такая возможность.
> Совершенно не обязательно добавлять грязь с помощью декалей, которые ты предлагаешь этим плагином расставлять.
Выдумал.
> У любой задачи есть множество решений, и не все эти решения оптимальны для конкретной ситуации. Если у тебя, скажем, всего одна коробка, которую можно динамически запачкать (симулятор доставщика пиццы), тогда можно её декалями обмазывать динамически - и это будет норм. А если ты хочешь огромную кучу углов, рёбер и прочих мест обмазать декалями "просто потому что", тогда это херня, а не решение, потому что ты тратишь производительность компа (сколько бы её ни было) впустую, на бесполезные действия.
Расскажи про производительность - пиаристу сатанизма Кармаку о его DOOM движке, т.е.даже в далёком в 1993-ем, плюс ещё и даже с программной отрисовкой...
>> Смотри лучше, в ч.н. по ссылкам там, тут на ребре стык
> Не вижу там новой геометрии, там всё - плоские декали.
Смотри лучше, на срез арки.
>>6007
>> И что - сдулись все?!
> Тебе же уже несколько раз объяснили - "нам не надо".
Не говори за всех. Т.б. ты даже жопой же "читаешь" - не показатель... Им, по крайней мере их 3D игр игрокам, больше чем мне надо.
>> Только время на разжовывание вам и придумывание улучшений потратил впустую
> Тебе самому-то такой плагин/инструмент нужен или ты вообще Godot не пользуешься?
Нет, размышляю; но, инструмент пригодился бы.
И просто читай не жопой: поверь - пригодился бы не только мне.
Как и твой чисто декальный вариант/режим - тоже. В т.ч.и потому что, (про производительность), как я упомянул выше - люди не то что текстуры а, даже 3D модели в качестве "decals" накладывают поверх текстур, как это хоть в том же UT движке.
>>6034
Ты тоже, или всё же тот же?, жопой читал мои посты прямо выше...
Ты тоже, или всё же тот же?, жопой читал мои посты прямо выше...
>>6025
Если буду делать что-то в public domain, то и диздок солью. А пока терпи до анонса.
Если буду делать что-то в public domain, то и диздок солью. А пока терпи до анонса.
>>6038
Тогда уже будет поздно отзывы выслушивать - менять что то серьёзное куда проблемней, включая название.
Его не твой диздок интересует(он у тебя что, под NDA и одним экраном представлен?) а, что у ИИ получилось.
Тогда уже будет поздно отзывы выслушивать - менять что то серьёзное куда проблемней, включая название.
Его не твой диздок интересует(он у тебя что, под NDA и одним экраном представлен?) а, что у ИИ получилось.
>>6005
Что тут удивительного? Это же, минимум выглядит как, феерический дебилизатор(пусть там и можно условно-красивые карты и продвинутые как для игры механизмы делать но, нигде больше не применимо же т.к.с реальностью мало общего) и даже не столько графически(кубы уже в начале выглядели мега трэшево, уже давно был и устарел морально Cube, даже Cube 2 начал уже устаревать, так MC же кал в сравнении с ними по детальности, ещё и требующий установку исторически backdoor Java), сколько мега упрощёнными механиками высосанными из пальца, ну и потому кринжевостью в сумме. Пропихивают её таки очень активно, тот же zog(например у меня пару дней зачищали самое неугодно а, затем вовсе забанили скрытно zog-хуцпистки) на ютуб - не только просто завален миллионами роликов о ней, но и постоянно сам её пиарит для дебилизации подрастающего поколения(механиками и безстильностью), в т.ч.подсаживая на online игры иначе не игравших бы, вставляя в рекомендации в т.ч.при не смежных просмотрах. И это спустя столько лет! Не спорю некоторые ролики даже получаются интересны уникальностью но, большинство же специализированный обучающий - шлак для не игроков в игру. Ныне же, ещё и zog MS, как новый владелец, возможно скрыто рекламирует, только там, уже и дополнительно к той же повесточке гоям для увеличения себе мега-доходов, всё связанно же. Так что, какому-нибудь клону реально уже надо противостоять такому напору пиара... даже внешне - самый минимум от 3-х корпораций и кучи мододелов и серверо-держателей, всё как с Quake, UT, CS сериями но, даже помасштабней.
> как это на старте могло само стать популярным? Когда я как не спрошу кого - в игру они попробовали именно из-за хайпа. Как-будто хайп исскуственно опережал игру.
Что тут удивительного? Это же, минимум выглядит как, феерический дебилизатор(пусть там и можно условно-красивые карты и продвинутые как для игры механизмы делать но, нигде больше не применимо же т.к.с реальностью мало общего) и даже не столько графически(кубы уже в начале выглядели мега трэшево, уже давно был и устарел морально Cube, даже Cube 2 начал уже устаревать, так MC же кал в сравнении с ними по детальности, ещё и требующий установку исторически backdoor Java), сколько мега упрощёнными механиками высосанными из пальца, ну и потому кринжевостью в сумме. Пропихивают её таки очень активно, тот же zog(например у меня пару дней зачищали самое неугодно а, затем вовсе забанили скрытно zog-хуцпистки) на ютуб - не только просто завален миллионами роликов о ней, но и постоянно сам её пиарит для дебилизации подрастающего поколения(механиками и безстильностью), в т.ч.подсаживая на online игры иначе не игравших бы, вставляя в рекомендации в т.ч.при не смежных просмотрах. И это спустя столько лет! Не спорю некоторые ролики даже получаются интересны уникальностью но, большинство же специализированный обучающий - шлак для не игроков в игру. Ныне же, ещё и zog MS, как новый владелец, возможно скрыто рекламирует, только там, уже и дополнительно к той же повесточке гоям для увеличения себе мега-доходов, всё связанно же. Так что, какому-нибудь клону реально уже надо противостоять такому напору пиара... даже внешне - самый минимум от 3-х корпораций и кучи мододелов и серверо-держателей, всё как с Quake, UT, CS сериями но, даже помасштабней.
>>6028
Вайбкодинг не создает. В этом и проблема. А греет намного больше, чем мозг, тупо в ваттах. Поэтому, вайбкоди - это десяток минусов в карму, увы.
Вайбкодинг не создает. В этом и проблема. А греет намного больше, чем мозг, тупо в ваттах. Поэтому, вайбкоди - это десяток минусов в карму, увы.
>>6055
Тогда - признавай что: и ты... Ибо такие, и даже куда примитивней, ИИ - симулятор мозговой нейронной деятельности, по сути - плагиат мозга Сатаной, известный плагиатщик.
> Вайбкодинг не создает.
Тогда - признавай что: и ты... Ибо такие, и даже куда примитивней, ИИ - симулятор мозговой нейронной деятельности, по сути - плагиат мозга Сатаной, известный плагиатщик.
6,1 Мб, mp4,914x428, 0:29
>>6052
Ну если задуматься и копнуть глубже гы гы - майкрафт и копнуть, ну вы поняли, майнкрафт копать гы-гы, то начинаешь офигевать от того контента. Относительно здоровые лбы, зачем-то снимают видео для совсем маленькой аудитории, добровольно и по желанию такое снимать, ну хз (вести себя как дебил это тоже невероятно сложно).
Ну если задуматься и копнуть глубже гы гы - майкрафт и копнуть, ну вы поняли, майнкрафт копать гы-гы, то начинаешь офигевать от того контента. Относительно здоровые лбы, зачем-то снимают видео для совсем маленькой аудитории, добровольно и по желанию такое снимать, ну хз (вести себя как дебил это тоже невероятно сложно).
>>6069
та это еще ничего. Есть вообще хуета с миллионами просмотров на каждом видео, ориентированная на детей, но где взрослый хуй ирл плескается в бассейне, катается на горке, пердит и тд, видосы с названием уровня НОВЫЙ БРЕЙНРОТ | ПЕРДАНУЛ НА ГОРКЕ | КОНКУРС НА ЛУЧШИЙ ВОЛОСОК ИЗ ПУПКА. Там мозг закипает уже за 5 сек
та это еще ничего. Есть вообще хуета с миллионами просмотров на каждом видео, ориентированная на детей, но где взрослый хуй ирл плескается в бассейне, катается на горке, пердит и тд, видосы с названием уровня НОВЫЙ БРЕЙНРОТ | ПЕРДАНУЛ НА ГОРКЕ | КОНКУРС НА ЛУЧШИЙ ВОЛОСОК ИЗ ПУПКА. Там мозг закипает уже за 5 сек
319 Кб, 640x362>>6108
Это мертвая луна
Это мертвая луна
>>6108
Не понял, в чём конкретно претензия?
Не понял, в чём конкретно претензия?
>>6052
У тебя просто бред преследования, zоg-шиз...
https://ru.wikipedia.org/wiki/Бред_преследования
>>6028
Энтропия-шиз, ты задолбал с этой "энтропией". Но в сравнении с zоg-шизом ты выглядишь куда более интеллектуальным. Не стоит ли ограничивать свои... всплески энтропии, или как ты это обычно зовёшь?
Лол, ты неправильно понимаешь суть этой теории: информация фундаментальна как материя и энергия, поэтому она не создаётся и не уничтожается, а лишь трансформируется. Если ты сжигаешь книгу, то вся информация, записанная в ней, трансформируется в нечитаемое состояние, из которого уже никак нельзя извлечь исходный текст. Если ты удаляешь текст в компьютере, он так же перестаёт быть текстом.
Для понимания концепции, можно вспомнить, как устроена память компьютера: она разбита на ячейки, которые имеют одно из нескольких состояний; если перевести эти ячейки в конкретное состояние, то мы получаем конкретные файлы, а если в другое - то мы теряем доступ к файлам. "Файлы" в этом плане не создаются никем и не уничтожаются, мы только обнаруживаем или теряем "ключ" к файлу, который выражается в состоянии ячеек памяти компьютера.
Теоретически, вся информация УЖЕ содержится в иррациональных числах вроде числа Пи: если начать записывать все цифры после запятой, то когда-то мы запишем абсолютно всё, что можно придумать. Т.е. фактически "придумывание" можно заменить на "обнаружение позиции (смещения) внутри числа Пи".
Также можно вспомнить, почему архитектура сетей Transformer называется трансформером: она берёт информацию со входа и трансформирует в другую информацию на выходе. В принципе, почти любая нейросеть занимается ровно тем же, и "тренировка" нейросетей - это записывание определённой схемы трансформации на весах связей нейросетей.
Собственно, нужна ли нам та или иная информация? Трансформация информации требует энергию, что достаточно трудно получать. Любое переключение микроскопических ячеек памяти требует энергии. Рациональный расход доступной энергии (она тоже неуничтожима, просто мы теряем к ней относительно лёгкий доступ) подразумевает, что все мы стараемся трансформировать информацию в предпочтительное состояние из того, которое нам не нужно. Например, записываем любимое аниме в свободный участок постоянного хранилища, чтобы в будущем смогли посмотреть его и получить от этого удовольствие.
Если "вайбкодер" трансформирует информацию в совершенно никому не нужное состояние ("слоп"), он расходует доступную энергию впустую. Вот простое сравнение: вместо аниме, ты записываешь на диск совершенно случайные числа, затираешь их нулями, повторяешь снова случайные числа и делаешь так бесконечно долго. Тебя не интересуют сами числа, интересует лишь процесс их трансформации - но бесполезный процесс, тратящий энергию зря. Вот приблизительно этим занимаются "вайбкодеры".
ИМХО, мы живём в эпоху ненужной информации. В прошлом, людям было доступно мало информации, поскольку даже книги писались вручную. С веками человечество научилось обращаться с информацией настолько эффективно, что любую необходимую информацию получить очень легко. Но эта лёгкость порождает и потоки ненужной информации, никем не запрошенной, вредной, мешающей информации - т.е. фактически фоновый, монотонный шум интернета. А фоновый шум необходимо фильтровать, чтоб была возможность обнаружить в шуме что-то нужное...
В итоге мы тратим больше энергии не только на произведение нового шума, но и на поиск нужного в зашумлённом пространстве, где уже слишком много ненужного. И от этого страдают абсолютно все, кто нуждается в получении нужной информации...
В общем, делайте ту информацию, которая кому-то необходима. Спрос должен рождать предложение, в противном случае становится тяжело найти то, что действительно хочется, среди того, что предлагают (наверняка все с таким сталкивались, лол).
У тебя просто бред преследования, zоg-шиз...
https://ru.wikipedia.org/wiki/Бред_преследования
>>6028
Энтропия-шиз, ты задолбал с этой "энтропией". Но в сравнении с zоg-шизом ты выглядишь куда более интеллектуальным. Не стоит ли ограничивать свои... всплески энтропии, или как ты это обычно зовёшь?
>информация никогда не уничтожается
Лол, ты неправильно понимаешь суть этой теории: информация фундаментальна как материя и энергия, поэтому она не создаётся и не уничтожается, а лишь трансформируется. Если ты сжигаешь книгу, то вся информация, записанная в ней, трансформируется в нечитаемое состояние, из которого уже никак нельзя извлечь исходный текст. Если ты удаляешь текст в компьютере, он так же перестаёт быть текстом.
Для понимания концепции, можно вспомнить, как устроена память компьютера: она разбита на ячейки, которые имеют одно из нескольких состояний; если перевести эти ячейки в конкретное состояние, то мы получаем конкретные файлы, а если в другое - то мы теряем доступ к файлам. "Файлы" в этом плане не создаются никем и не уничтожаются, мы только обнаруживаем или теряем "ключ" к файлу, который выражается в состоянии ячеек памяти компьютера.
Теоретически, вся информация УЖЕ содержится в иррациональных числах вроде числа Пи: если начать записывать все цифры после запятой, то когда-то мы запишем абсолютно всё, что можно придумать. Т.е. фактически "придумывание" можно заменить на "обнаружение позиции (смещения) внутри числа Пи".
Также можно вспомнить, почему архитектура сетей Transformer называется трансформером: она берёт информацию со входа и трансформирует в другую информацию на выходе. В принципе, почти любая нейросеть занимается ровно тем же, и "тренировка" нейросетей - это записывание определённой схемы трансформации на весах связей нейросетей.
Собственно, нужна ли нам та или иная информация? Трансформация информации требует энергию, что достаточно трудно получать. Любое переключение микроскопических ячеек памяти требует энергии. Рациональный расход доступной энергии (она тоже неуничтожима, просто мы теряем к ней относительно лёгкий доступ) подразумевает, что все мы стараемся трансформировать информацию в предпочтительное состояние из того, которое нам не нужно. Например, записываем любимое аниме в свободный участок постоянного хранилища, чтобы в будущем смогли посмотреть его и получить от этого удовольствие.
Если "вайбкодер" трансформирует информацию в совершенно никому не нужное состояние ("слоп"), он расходует доступную энергию впустую. Вот простое сравнение: вместо аниме, ты записываешь на диск совершенно случайные числа, затираешь их нулями, повторяешь снова случайные числа и делаешь так бесконечно долго. Тебя не интересуют сами числа, интересует лишь процесс их трансформации - но бесполезный процесс, тратящий энергию зря. Вот приблизительно этим занимаются "вайбкодеры".
ИМХО, мы живём в эпоху ненужной информации. В прошлом, людям было доступно мало информации, поскольку даже книги писались вручную. С веками человечество научилось обращаться с информацией настолько эффективно, что любую необходимую информацию получить очень легко. Но эта лёгкость порождает и потоки ненужной информации, никем не запрошенной, вредной, мешающей информации - т.е. фактически фоновый, монотонный шум интернета. А фоновый шум необходимо фильтровать, чтоб была возможность обнаружить в шуме что-то нужное...
В итоге мы тратим больше энергии не только на произведение нового шума, но и на поиск нужного в зашумлённом пространстве, где уже слишком много ненужного. И от этого страдают абсолютно все, кто нуждается в получении нужной информации...
В общем, делайте ту информацию, которая кому-то необходима. Спрос должен рождать предложение, в противном случае становится тяжело найти то, что действительно хочется, среди того, что предлагают (наверняка все с таким сталкивались, лол).
>>6052
У тебя просто бред преследования, zоg-шиз...
https://ru.wikipedia.org/wiki/Бред_преследования
>>6028
Энтропия-шиз, ты задолбал с этой "энтропией". Но в сравнении с zоg-шизом ты выглядишь куда более интеллектуальным. Не стоит ли ограничивать свои... всплески энтропии, или как ты это обычно зовёшь?
Лол, ты неправильно понимаешь суть этой теории: информация фундаментальна как материя и энергия, поэтому она не создаётся и не уничтожается, а лишь трансформируется. Если ты сжигаешь книгу, то вся информация, записанная в ней, трансформируется в нечитаемое состояние, из которого уже никак нельзя извлечь исходный текст. Если ты удаляешь текст в компьютере, он так же перестаёт быть текстом.
Для понимания концепции, можно вспомнить, как устроена память компьютера: она разбита на ячейки, которые имеют одно из нескольких состояний; если перевести эти ячейки в конкретное состояние, то мы получаем конкретные файлы, а если в другое - то мы теряем доступ к файлам. "Файлы" в этом плане не создаются никем и не уничтожаются, мы только обнаруживаем или теряем "ключ" к файлу, который выражается в состоянии ячеек памяти компьютера.
Теоретически, вся информация УЖЕ содержится в иррациональных числах вроде числа Пи: если начать записывать все цифры после запятой, то когда-то мы запишем абсолютно всё, что можно придумать. Т.е. фактически "придумывание" можно заменить на "обнаружение позиции (смещения) внутри числа Пи".
Также можно вспомнить, почему архитектура сетей Transformer называется трансформером: она берёт информацию со входа и трансформирует в другую информацию на выходе. В принципе, почти любая нейросеть занимается ровно тем же, и "тренировка" нейросетей - это записывание определённой схемы трансформации на весах связей нейросетей.
Собственно, нужна ли нам та или иная информация? Трансформация информации требует энергию, что достаточно трудно получать. Любое переключение микроскопических ячеек памяти требует энергии. Рациональный расход доступной энергии (она тоже неуничтожима, просто мы теряем к ней относительно лёгкий доступ) подразумевает, что все мы стараемся трансформировать информацию в предпочтительное состояние из того, которое нам не нужно. Например, записываем любимое аниме в свободный участок постоянного хранилища, чтобы в будущем смогли посмотреть его и получить от этого удовольствие.
Если "вайбкодер" трансформирует информацию в совершенно никому не нужное состояние ("слоп"), он расходует доступную энергию впустую. Вот простое сравнение: вместо аниме, ты записываешь на диск совершенно случайные числа, затираешь их нулями, повторяешь снова случайные числа и делаешь так бесконечно долго. Тебя не интересуют сами числа, интересует лишь процесс их трансформации - но бесполезный процесс, тратящий энергию зря. Вот приблизительно этим занимаются "вайбкодеры".
ИМХО, мы живём в эпоху ненужной информации. В прошлом, людям было доступно мало информации, поскольку даже книги писались вручную. С веками человечество научилось обращаться с информацией настолько эффективно, что любую необходимую информацию получить очень легко. Но эта лёгкость порождает и потоки ненужной информации, никем не запрошенной, вредной, мешающей информации - т.е. фактически фоновый, монотонный шум интернета. А фоновый шум необходимо фильтровать, чтоб была возможность обнаружить в шуме что-то нужное...
В итоге мы тратим больше энергии не только на произведение нового шума, но и на поиск нужного в зашумлённом пространстве, где уже слишком много ненужного. И от этого страдают абсолютно все, кто нуждается в получении нужной информации...
В общем, делайте ту информацию, которая кому-то необходима. Спрос должен рождать предложение, в противном случае становится тяжело найти то, что действительно хочется, среди того, что предлагают (наверняка все с таким сталкивались, лол).
У тебя просто бред преследования, zоg-шиз...
https://ru.wikipedia.org/wiki/Бред_преследования
>>6028
Энтропия-шиз, ты задолбал с этой "энтропией". Но в сравнении с zоg-шизом ты выглядишь куда более интеллектуальным. Не стоит ли ограничивать свои... всплески энтропии, или как ты это обычно зовёшь?
>информация никогда не уничтожается
Лол, ты неправильно понимаешь суть этой теории: информация фундаментальна как материя и энергия, поэтому она не создаётся и не уничтожается, а лишь трансформируется. Если ты сжигаешь книгу, то вся информация, записанная в ней, трансформируется в нечитаемое состояние, из которого уже никак нельзя извлечь исходный текст. Если ты удаляешь текст в компьютере, он так же перестаёт быть текстом.
Для понимания концепции, можно вспомнить, как устроена память компьютера: она разбита на ячейки, которые имеют одно из нескольких состояний; если перевести эти ячейки в конкретное состояние, то мы получаем конкретные файлы, а если в другое - то мы теряем доступ к файлам. "Файлы" в этом плане не создаются никем и не уничтожаются, мы только обнаруживаем или теряем "ключ" к файлу, который выражается в состоянии ячеек памяти компьютера.
Теоретически, вся информация УЖЕ содержится в иррациональных числах вроде числа Пи: если начать записывать все цифры после запятой, то когда-то мы запишем абсолютно всё, что можно придумать. Т.е. фактически "придумывание" можно заменить на "обнаружение позиции (смещения) внутри числа Пи".
Также можно вспомнить, почему архитектура сетей Transformer называется трансформером: она берёт информацию со входа и трансформирует в другую информацию на выходе. В принципе, почти любая нейросеть занимается ровно тем же, и "тренировка" нейросетей - это записывание определённой схемы трансформации на весах связей нейросетей.
Собственно, нужна ли нам та или иная информация? Трансформация информации требует энергию, что достаточно трудно получать. Любое переключение микроскопических ячеек памяти требует энергии. Рациональный расход доступной энергии (она тоже неуничтожима, просто мы теряем к ней относительно лёгкий доступ) подразумевает, что все мы стараемся трансформировать информацию в предпочтительное состояние из того, которое нам не нужно. Например, записываем любимое аниме в свободный участок постоянного хранилища, чтобы в будущем смогли посмотреть его и получить от этого удовольствие.
Если "вайбкодер" трансформирует информацию в совершенно никому не нужное состояние ("слоп"), он расходует доступную энергию впустую. Вот простое сравнение: вместо аниме, ты записываешь на диск совершенно случайные числа, затираешь их нулями, повторяешь снова случайные числа и делаешь так бесконечно долго. Тебя не интересуют сами числа, интересует лишь процесс их трансформации - но бесполезный процесс, тратящий энергию зря. Вот приблизительно этим занимаются "вайбкодеры".
ИМХО, мы живём в эпоху ненужной информации. В прошлом, людям было доступно мало информации, поскольку даже книги писались вручную. С веками человечество научилось обращаться с информацией настолько эффективно, что любую необходимую информацию получить очень легко. Но эта лёгкость порождает и потоки ненужной информации, никем не запрошенной, вредной, мешающей информации - т.е. фактически фоновый, монотонный шум интернета. А фоновый шум необходимо фильтровать, чтоб была возможность обнаружить в шуме что-то нужное...
В итоге мы тратим больше энергии не только на произведение нового шума, но и на поиск нужного в зашумлённом пространстве, где уже слишком много ненужного. И от этого страдают абсолютно все, кто нуждается в получении нужной информации...
В общем, делайте ту информацию, которая кому-то необходима. Спрос должен рождать предложение, в противном случае становится тяжело найти то, что действительно хочется, среди того, что предлагают (наверняка все с таким сталкивались, лол).
24 Кб, 664x252>>6196
ты не мог все в пару строчек уместить ?
ты не мог все в пару строчек уместить ?
На счёт майнкрафта. Как по мне, ему не хватает, как минимум, более разнообразного мира и упрощения перемещения по миру в режиме выживания.
Знаете, майнкрафт часто упоминается как широко известный пример "гигантского мира, по площади превышающий площадь Земли", и технически это действительно так, но... Что толку от площади, если интересного на этой площади практически не найти?
Я много лет время от времени испытываю желание поиграть в майнкрафт, фантазируя о том, как я буду продвигаться по карте, искать интересные места, наслаждаться пейзажами и в итоге найду уютное местечко, на котором можно разбить лагерь... Когда запускаю игру и начинаю блуждать по карте, быстро вспоминаю, насколько же медленно, уныло и очень однообразно играть в майнкрафт в реальности.
Типа, почти бесконечная карта, куча биомов... Но нет ощущения что вот следующий километр будет чем-то отличаться от предыдущего. Допустим, захотелось отыскать биом джунглей ради каких-то блоков или животных, но ты вряд ли захочешь искать ещё один, поскольку они все примерно одинаковые.
Ты будто прикован к одному месту, хотя тебя никто не держит, ты мог бы идти куда глаза глядят. Но нет ни необходимости, ни желания куда-то идти в игре.
И по-моему, эта проблема в очень многих играх наблюдается. Не важно, песочницах или сюжетных. Песочницы чаще страдают, конечно, т.к. там часто процедурный мир с небольшим объёмом контента, повторяющегося много раз. Но даже сюжетные - единственная причина двигаться по сюжету, это "добраться до концовки", а смысл в этом, если всю концовку можно прочитать/посмотреть без игры?
По-моему, хорошая игра не должна иметь подобной проблемы. Чтобы игрок не принуждал себя ради виртуальных ачивок, а хотел играть дальше. Чтобы геймплей не обрывался на условной "концовке", а продолжался, пока игроку интересно играть...
Вот сделайте такой майнкрафт - и будете успешны.
Джвадцать лет жду...
Знаете, майнкрафт часто упоминается как широко известный пример "гигантского мира, по площади превышающий площадь Земли", и технически это действительно так, но... Что толку от площади, если интересного на этой площади практически не найти?
Я много лет время от времени испытываю желание поиграть в майнкрафт, фантазируя о том, как я буду продвигаться по карте, искать интересные места, наслаждаться пейзажами и в итоге найду уютное местечко, на котором можно разбить лагерь... Когда запускаю игру и начинаю блуждать по карте, быстро вспоминаю, насколько же медленно, уныло и очень однообразно играть в майнкрафт в реальности.
Типа, почти бесконечная карта, куча биомов... Но нет ощущения что вот следующий километр будет чем-то отличаться от предыдущего. Допустим, захотелось отыскать биом джунглей ради каких-то блоков или животных, но ты вряд ли захочешь искать ещё один, поскольку они все примерно одинаковые.
Ты будто прикован к одному месту, хотя тебя никто не держит, ты мог бы идти куда глаза глядят. Но нет ни необходимости, ни желания куда-то идти в игре.
И по-моему, эта проблема в очень многих играх наблюдается. Не важно, песочницах или сюжетных. Песочницы чаще страдают, конечно, т.к. там часто процедурный мир с небольшим объёмом контента, повторяющегося много раз. Но даже сюжетные - единственная причина двигаться по сюжету, это "добраться до концовки", а смысл в этом, если всю концовку можно прочитать/посмотреть без игры?
По-моему, хорошая игра не должна иметь подобной проблемы. Чтобы игрок не принуждал себя ради виртуальных ачивок, а хотел играть дальше. Чтобы геймплей не обрывался на условной "концовке", а продолжался, пока игроку интересно играть...
Вот сделайте такой майнкрафт - и будете успешны.
Джвадцать лет жду...
>>6196
Якобы разбирающийся в науке шиз, интерпретирующий мир через призму своего манямира.
После фразы "информация трансформируется", можно не читать. В том и смысл что она некуда и не трансформируется.
Перед тем как высрать свое виденье мира, сначала потрать время чтобы почитать об этом. Как ты нес пургу о квантовой физики, так и продолжаешь мракобесничать, думая что что-то понимаешь вообще.
Якобы разбирающийся в науке шиз, интерпретирующий мир через призму своего манямира.
После фразы "информация трансформируется", можно не читать. В том и смысл что она некуда и не трансформируется.
Перед тем как высрать свое виденье мира, сначала потрать время чтобы почитать об этом. Как ты нес пургу о квантовой физики, так и продолжаешь мракобесничать, думая что что-то понимаешь вообще.
>>6245
Если кому интересно, это означает:
Фундаментальные законы физики не "стирают" сведения о прошлом, а лишь делают их практически недоступными (сложно восстановимы для людей, но информация не пропадает).
То есть, если уйти от науки в фантастику, кто-то может включить "перемотку" назад и показать как ты дрочил на маскот годота. Оно тебе надо вообще анон? Делай добрые вещи, вселенная запомнит все
Если кому интересно, это означает:
Фундаментальные законы физики не "стирают" сведения о прошлом, а лишь делают их практически недоступными (сложно восстановимы для людей, но информация не пропадает).
То есть, если уйти от науки в фантастику, кто-то может включить "перемотку" назад и показать как ты дрочил на маскот годота. Оно тебе надо вообще анон? Делай добрые вещи, вселенная запомнит все
привет аноны. пытаюсь сделать трипл эй рпг хит соло. пока очень неудобный код, который у каждого юнита и каждой клетки в process отрабатывает. я решил поменять на input, но тоже не все так просто, портянки ифов остаются, да и иерархия вызовов там.
короче идея. наделать скриптов на каждое действие и отвязывать и привязывать к юнитам и клеткам в зависимости от состояния. норм? подводные?
короче идея. наделать скриптов на каждое действие и отвязывать и привязывать к юнитам и клеткам в зависимости от состояния. норм? подводные?
>>6259
Ты хочешь сделать один мейнлуп?
Есть моменты, когда хочется унифицированное место чтобы контролить все что в кадре происходит. Но РПГ это не тот случай.
Делай как рекомендует документация и движок. Потом придет понимание что именно такой способ удобнее, чем искать логику травинки в портянке мейнлупа (а если еще через регистрацию хендлеров сделать - то вообще адок).
Ты хочешь сделать один мейнлуп?
>https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Есть моменты, когда хочется унифицированное место чтобы контролить все что в кадре происходит. Но РПГ это не тот случай.
Делай как рекомендует документация и движок. Потом придет понимание что именно такой способ удобнее, чем искать логику травинки в портянке мейнлупа (а если еще через регистрацию хендлеров сделать - то вообще адок).
14 Кб, 421x243>>6259
Ну или я тебя не правильно понял.
Делай либо с флагами и выходи.
Либо через какой-то таск менеджер - который знает нужно тебе тут сейчас работать или нет.
Ну или я тебя не правильно понял.
Делай либо с флагами и выходи.
Либо через какой-то таск менеджер - который знает нужно тебе тут сейчас работать или нет.
законы физики не стирают информацию так же я который нажимаю кнопчку удалить код хех вот вам и ваши законы физики старьчие галимое 😁
>>6294
Зуммеры не знают про Сtrl + Z
Зуммеры не знают про Сtrl + Z
>>6302 (Del)
Ничего не понял, но очень интересно.
Ничего не понял, но очень интересно.
>>6311
Ecs это всегда про упакованный кэш. Все остальное не имеет смысла. Массив гдскрипта представлен как массив указателей. То есть, даже упаковывая в массивы гдсрипта - процессор будет прыгать в ОЗУ.
В общем, эти потуги не имеют смысла. Поправьте меня.
Ecs это всегда про упакованный кэш. Все остальное не имеет смысла. Массив гдскрипта представлен как массив указателей. То есть, даже упаковывая в массивы гдсрипта - процессор будет прыгать в ОЗУ.
В общем, эти потуги не имеют смысла. Поправьте меня.
>>2274 (OP)
Привет, аноны. Помогите, пожалуйста.
У меня пиксельная 2д игра на godot 3.5 (Давно делаю, потому перейти на 4 оказалось болью) и я только сейчас понял, что она должна корректно отображаться на разных устройствах. Да, понимаю, сам дурак, что изначально не подумал об этом.
Базовые размеры у меня 640x360 c Mode: 2d и Aspect: expand и когда оно масштабируется до 1280x720 все нормально, но при масштабировании до, например 1366x768 появляются субпиксели. Я понимаю почему они появляются и что при обычном масштабировании по другому и быть не может, потому я захотел решить проблему увеличением области обзора. В официальной документации указан плагин Integer Resolution Handler, который может с этим помочь и он действительно решает проблему, но при этом шрифты становятся нечитабельными и размытыми(я использую обычные, а не пиксельные шрифты).
Как можно решить эту проблему? Единственное, что я придумал это сделать шрифты в несколько раз больше, а потом уменьшать scale нод, но мне кажется это не очень правильное решение.
Или как вообще можно добиться того, чтобы игра выглядела хорошо при разных разрешениях?
Привет, аноны. Помогите, пожалуйста.
У меня пиксельная 2д игра на godot 3.5 (Давно делаю, потому перейти на 4 оказалось болью) и я только сейчас понял, что она должна корректно отображаться на разных устройствах. Да, понимаю, сам дурак, что изначально не подумал об этом.
Базовые размеры у меня 640x360 c Mode: 2d и Aspect: expand и когда оно масштабируется до 1280x720 все нормально, но при масштабировании до, например 1366x768 появляются субпиксели. Я понимаю почему они появляются и что при обычном масштабировании по другому и быть не может, потому я захотел решить проблему увеличением области обзора. В официальной документации указан плагин Integer Resolution Handler, который может с этим помочь и он действительно решает проблему, но при этом шрифты становятся нечитабельными и размытыми(я использую обычные, а не пиксельные шрифты).
Как можно решить эту проблему? Единственное, что я придумал это сделать шрифты в несколько раз больше, а потом уменьшать scale нод, но мне кажется это не очень правильное решение.
Или как вообще можно добиться того, чтобы игра выглядела хорошо при разных разрешениях?
>>6317
Я для своих пиксельных игр делал стандартные черные полосы по бокам или по низам для неподходящих разрешений. Таков подводный камень работы с пикселями, если ты хочешь сабпикселей избежать.
Еще можешь с вьюпортами поиграться, и рендерить игру в текстуру с высоким разрешением, а потом скалировать вниз на подходящее, накидывая сверху сглаживание.
Но вообще пиксельный стиль та еще еботня, типичная ловушка новичка. И это в годоте с ним еще изи работать.
Я для своих пиксельных игр делал стандартные черные полосы по бокам или по низам для неподходящих разрешений. Таков подводный камень работы с пикселями, если ты хочешь сабпикселей избежать.
Еще можешь с вьюпортами поиграться, и рендерить игру в текстуру с высоким разрешением, а потом скалировать вниз на подходящее, накидывая сверху сглаживание.
Но вообще пиксельный стиль та еще еботня, типичная ловушка новичка. И это в годоте с ним еще изи работать.
>>6320
Я хз почему люди растр не используют.
Вектор для формы, раст для текстуры и деталей.
Отдельный дебилизм, когда еще шрифт пиксельный - глаза/мозги просто вытекают.
Я хз почему люди растр не используют.
Вектор для формы, раст для текстуры и деталей.
Отдельный дебилизм, когда еще шрифт пиксельный - глаза/мозги просто вытекают.
>>6329
Ньюфагам кажется что пиксели проще рисовать, типа как майнкрафт, кинул 4 квадрата и вот тебе персонаж. Но хуй там. Качественный пиксель арт сложнее иной классической рисовки, а уж анимировать его это пиздос, плюс вечные проблемы с его скалированием. Проебался с масштабом? Нет, низзя поставить scale=0.8, беги перерисовывай-переанимируй. Сам так проебался. Теперь тупо пиксельные ландскейпы в соцсети рисую по фану, а геймдевю обычным 2д/3д. Жизнь наладилась.
Ньюфагам кажется что пиксели проще рисовать, типа как майнкрафт, кинул 4 квадрата и вот тебе персонаж. Но хуй там. Качественный пиксель арт сложнее иной классической рисовки, а уж анимировать его это пиздос, плюс вечные проблемы с его скалированием. Проебался с масштабом? Нет, низзя поставить scale=0.8, беги перерисовывай-переанимируй. Сам так проебался. Теперь тупо пиксельные ландскейпы в соцсети рисую по фану, а геймдевю обычным 2д/3д. Жизнь наладилась.
>>6245
Да ты же сам в качестве аргумента привёл какую-то галлюцинацию русскоязычного чатбота. А я вот англоязычного чатбота спросил - он ответил, мол, "информация трансформируется". Очевидно, что англоязычные чатботы умнее русскоязычных из-за значительного перевеса в тренировочных данных и относительной лёгкости английского языка. И это - объективный факт, в отличие от твоих фантазий.
Почему ты изначально не привёл никаких научных источников, а только свои шизофантазии? Мне вот пришлось гуглить, чтобы понять, в чём ты не прав...
>>6246
Опять шиза уровня "квантового сознания"...
Теоретически, если бы мы знали полное текущее состояние вселенной и все законы, по которым её составные элементы взаимодействуют, мы могли бы провернуть симуляцию вселенной вспять, и увидеть состояние вселенной на каждом из шагов прошлого. Проблема в том, что на практике это неосуществимо, поскольку для такой симуляции потребовалось бы значительно больше материи, чем у всей вселенной, а попытка узнать состояние элементов нарушает их состояние. Так что узнать прошлое мы не можем, если не существует никакого "внешнего хранилища" (недоказумая фигня уровня богов и параллельных измерений, куда по определению нельзя попасть).
Т.е. даже если у вселенной есть "журнал изменений", получить доступ к нему по определению невозможно, поскольку он находится за пределами вселенной. В противном случае (если он внутри), тогда мы не можем полагаться на точность сведений в нём...
>>6302 (Del)
Чем тебе Аква из Коносубы не нравится?
>После фразы "информация трансформируется"...
Да ты же сам в качестве аргумента привёл какую-то галлюцинацию русскоязычного чатбота. А я вот англоязычного чатбота спросил - он ответил, мол, "информация трансформируется". Очевидно, что англоязычные чатботы умнее русскоязычных из-за значительного перевеса в тренировочных данных и относительной лёгкости английского языка. И это - объективный факт, в отличие от твоих фантазий.
Почему ты изначально не привёл никаких научных источников, а только свои шизофантазии? Мне вот пришлось гуглить, чтобы понять, в чём ты не прав...
>>6246
>кто-то может включить "перемотку" назад
Опять шиза уровня "квантового сознания"...
Теоретически, если бы мы знали полное текущее состояние вселенной и все законы, по которым её составные элементы взаимодействуют, мы могли бы провернуть симуляцию вселенной вспять, и увидеть состояние вселенной на каждом из шагов прошлого. Проблема в том, что на практике это неосуществимо, поскольку для такой симуляции потребовалось бы значительно больше материи, чем у всей вселенной, а попытка узнать состояние элементов нарушает их состояние. Так что узнать прошлое мы не можем, если не существует никакого "внешнего хранилища" (недоказумая фигня уровня богов и параллельных измерений, куда по определению нельзя попасть).
Т.е. даже если у вселенной есть "журнал изменений", получить доступ к нему по определению невозможно, поскольку он находится за пределами вселенной. В противном случае (если он внутри), тогда мы не можем полагаться на точность сведений в нём...
>>6302 (Del)
Чем тебе Аква из Коносубы не нравится?
>>6331
Ну как раз он говна написал или ты читаешь так. Ты мракобесный шиз и скорее всего контекст ИИ уже под тебя подстроился, тебе надо было в промте указать контекст квантовой физики (или просто физики).
Самая интересная гипотеза сознания.
Но нужно это обсуждать со знающими людьми, вайбкоди со своими ИИ галлюцинируют на Пенроузе и работе из 90х годов, когда как актуальные исследования идут последние года. Ну еще это бьет по маркетингу машинного обучения, а там такое лобби, что ппц.
>А я вот англоязычного чатбота спросил
Ну как раз он говна написал или ты читаешь так. Ты мракобесный шиз и скорее всего контекст ИИ уже под тебя подстроился, тебе надо было в промте указать контекст квантовой физики (или просто физики).
>Опять шиза уровня "квантового сознания"...
Самая интересная гипотеза сознания.
Но нужно это обсуждать со знающими людьми, вайбкоди со своими ИИ галлюцинируют на Пенроузе и работе из 90х годов, когда как актуальные исследования идут последние года. Ну еще это бьет по маркетингу машинного обучения, а там такое лобби, что ппц.
>>6313
Ты путаешь ECS и DOD. Обычно движкописи берут библиотеку ECS ради DOD, но ECS можно создать, совершенно наплевав на DOD, т.е. чисто на ООП. Преимущество ECS без DOD в том, что ты можешь комбинировать разные качества своих объектов в произвольном (в теории) порядке, хотя это и будет увеличивать нагрузку на процессор (оверхэд ECS).
>>6259
Тебя больше графика волновать должна, чем код.
Скинь скриншот своего кода, который ты зачем-то выполняешь каждый кадр (в process). И как ты его умудрился в input запихнуть из process? Ты же РПГ разрабатываешь, там обычно всего 1 герой и куча неигровых персонажей? Или у тебя тактика с кучей управляемых игроком юнитов? Если так, тогда:
Я думаю, тебе вместо "скриптов на каждое действие" необходима одна-единственная нода-контроллер, что позволяет игроку взять под контроль любого героя из имеющихся на карте, если герой не обездвижен.
Т.е. тебе нужно что-то вроде такого:
1. Нажатия стрелочек/циферок выбирают клетку, персонажа, противника и т.д., смещая контроллер.
2. Когда игрок пытается задать какое-то действие, например, "двигайся вперёд", контроллер совершает попытку передать это действие клетке/персонажу, и персонаж, если он есть/может совершить действие, совершает действие, отвечая контроллеру "сделано".
Примерный код контроллера для группы героев:
Ну и т.д. Получается одна точка контроля.
С тебя - скриншоты/видео твоей игры в тред. Удачи.
>Ecs это всегда про упакованный кэш.
>В общем, эти потуги не имеют смысла.
Ты путаешь ECS и DOD. Обычно движкописи берут библиотеку ECS ради DOD, но ECS можно создать, совершенно наплевав на DOD, т.е. чисто на ООП. Преимущество ECS без DOD в том, что ты можешь комбинировать разные качества своих объектов в произвольном (в теории) порядке, хотя это и будет увеличивать нагрузку на процессор (оверхэд ECS).
>>6259
>пытаюсь сделать трипл эй рпг хит соло
Тебя больше графика волновать должна, чем код.
>очень неудобный код, который у каждого юнита и каждой клетки в process отрабатывает. я решил поменять на input, но тоже не все так просто, портянки ифов остаются, да и иерархия вызовов там.
Скинь скриншот своего кода, который ты зачем-то выполняешь каждый кадр (в process). И как ты его умудрился в input запихнуть из process? Ты же РПГ разрабатываешь, там обычно всего 1 герой и куча неигровых персонажей? Или у тебя тактика с кучей управляемых игроком юнитов? Если так, тогда:
>наделать скриптов на каждое действие и отвязывать и привязывать к юнитам и клеткам в зависимости от состояния. норм?
Я думаю, тебе вместо "скриптов на каждое действие" необходима одна-единственная нода-контроллер, что позволяет игроку взять под контроль любого героя из имеющихся на карте, если герой не обездвижен.
Т.е. тебе нужно что-то вроде такого:
1. Нажатия стрелочек/циферок выбирают клетку, персонажа, противника и т.д., смещая контроллер.
2. Когда игрок пытается задать какое-то действие, например, "двигайся вперёд", контроллер совершает попытку передать это действие клетке/персонажу, и персонаж, если он есть/может совершить действие, совершает действие, отвечая контроллеру "сделано".
Примерный код контроллера для группы героев:
>var controlled_actor: Actor
>var actors: Array[Actor]
>func _input(event):
>_ for id in actors.size(): # макс. 9 героев
> _ _ if event.is_action_pressed("key_%d" % id):
>_ _ _ controlled_actor = actors[id]; return
>_ for action in ["attack", "defend", "heal", "w", "a", "s", "d"]:
>_ _ if event.is_action_pressed(action):
>_ _ _ controlled_actor.call(action)
Ну и т.д. Получается одна точка контроля.
С тебя - скриншоты/видео твоей игры в тред. Удачи.
>>6313
Ты путаешь ECS и DOD. Обычно движкописи берут библиотеку ECS ради DOD, но ECS можно создать, совершенно наплевав на DOD, т.е. чисто на ООП. Преимущество ECS без DOD в том, что ты можешь комбинировать разные качества своих объектов в произвольном (в теории) порядке, хотя это и будет увеличивать нагрузку на процессор (оверхэд ECS).
>>6259
Тебя больше графика волновать должна, чем код.
Скинь скриншот своего кода, который ты зачем-то выполняешь каждый кадр (в process). И как ты его умудрился в input запихнуть из process? Ты же РПГ разрабатываешь, там обычно всего 1 герой и куча неигровых персонажей? Или у тебя тактика с кучей управляемых игроком юнитов? Если так, тогда:
Я думаю, тебе вместо "скриптов на каждое действие" необходима одна-единственная нода-контроллер, что позволяет игроку взять под контроль любого героя из имеющихся на карте, если герой не обездвижен.
Т.е. тебе нужно что-то вроде такого:
1. Нажатия стрелочек/циферок выбирают клетку, персонажа, противника и т.д., смещая контроллер.
2. Когда игрок пытается задать какое-то действие, например, "двигайся вперёд", контроллер совершает попытку передать это действие клетке/персонажу, и персонаж, если он есть/может совершить действие, совершает действие, отвечая контроллеру "сделано".
Примерный код контроллера для группы героев:
Ну и т.д. Получается одна точка контроля.
С тебя - скриншоты/видео твоей игры в тред. Удачи.
>Ecs это всегда про упакованный кэш.
>В общем, эти потуги не имеют смысла.
Ты путаешь ECS и DOD. Обычно движкописи берут библиотеку ECS ради DOD, но ECS можно создать, совершенно наплевав на DOD, т.е. чисто на ООП. Преимущество ECS без DOD в том, что ты можешь комбинировать разные качества своих объектов в произвольном (в теории) порядке, хотя это и будет увеличивать нагрузку на процессор (оверхэд ECS).
>>6259
>пытаюсь сделать трипл эй рпг хит соло
Тебя больше графика волновать должна, чем код.
>очень неудобный код, который у каждого юнита и каждой клетки в process отрабатывает. я решил поменять на input, но тоже не все так просто, портянки ифов остаются, да и иерархия вызовов там.
Скинь скриншот своего кода, который ты зачем-то выполняешь каждый кадр (в process). И как ты его умудрился в input запихнуть из process? Ты же РПГ разрабатываешь, там обычно всего 1 герой и куча неигровых персонажей? Или у тебя тактика с кучей управляемых игроком юнитов? Если так, тогда:
>наделать скриптов на каждое действие и отвязывать и привязывать к юнитам и клеткам в зависимости от состояния. норм?
Я думаю, тебе вместо "скриптов на каждое действие" необходима одна-единственная нода-контроллер, что позволяет игроку взять под контроль любого героя из имеющихся на карте, если герой не обездвижен.
Т.е. тебе нужно что-то вроде такого:
1. Нажатия стрелочек/циферок выбирают клетку, персонажа, противника и т.д., смещая контроллер.
2. Когда игрок пытается задать какое-то действие, например, "двигайся вперёд", контроллер совершает попытку передать это действие клетке/персонажу, и персонаж, если он есть/может совершить действие, совершает действие, отвечая контроллеру "сделано".
Примерный код контроллера для группы героев:
>var controlled_actor: Actor
>var actors: Array[Actor]
>func _input(event):
>_ for id in actors.size(): # макс. 9 героев
> _ _ if event.is_action_pressed("key_%d" % id):
>_ _ _ controlled_actor = actors[id]; return
>_ for action in ["attack", "defend", "heal", "w", "a", "s", "d"]:
>_ _ if event.is_action_pressed(action):
>_ _ _ controlled_actor.call(action)
Ну и т.д. Получается одна точка контроля.
С тебя - скриншоты/видео твоей игры в тред. Удачи.
>>6317
Я смог решить проблему. Нашел как менять размер игровой области динамически и написал скрипт, чтобы камера подстраивалась. Но теперь придется отсматривать все локации и катсцены, чтобы убедиться, что на разных расширениях все как надо отображается и не видно лишнего/недостающего.
>>6320
>>6329
>>6330
Выбрал пиксельный стиль по двум причинам:
1) Мне он нравится. Векторную графику терпеть не могу, а обычные арты анимировать задолбаешься.
2) Рисую в нем уже около 4 лет и публикую ассет паки. Средней популярности, не уровня kenny, но люди в играх используют. Считаю, что это означает, что мой уровень как минимум сносный.
Я смог решить проблему. Нашел как менять размер игровой области динамически и написал скрипт, чтобы камера подстраивалась. Но теперь придется отсматривать все локации и катсцены, чтобы убедиться, что на разных расширениях все как надо отображается и не видно лишнего/недостающего.
>>6320
>>6329
>>6330
Выбрал пиксельный стиль по двум причинам:
1) Мне он нравится. Векторную графику терпеть не могу, а обычные арты анимировать задолбаешься.
2) Рисую в нем уже около 4 лет и публикую ассет паки. Средней популярности, не уровня kenny, но люди в играх используют. Считаю, что это означает, что мой уровень как минимум сносный.
>>6317
Как-то пробовал возиться с пикселями, игры так и не получилось, но вот приблизительное решение твоей проблемы, если мне не изменяет память:
1. Отключи масштабирование в настройках проекта, проблем от него больше, чем преимуществ. Будем эмулировать его преимущества другим путём...
2. Сделай сцену-обложку для своей игры, типа:
3. В ноде GUI помещай свои Control как обычно.
4. В ноде World нужен кастомный рендерер типа:
5. В этом Viewport устанавливаешь своё разрешение, вычисленное из размера TextureRect, чтобы там было ближайшее целочисленное + края от него до нужного:
Где-то в обработчике события изменения размера:
Теперь геймплей должен выглядеть "пиксельно" на любом экране, расширясь при необходимости, но интерфейсные ноды никак не будут затронуты.
>>6334
Эх, жаль, я опоздал... Что-то похожее на Viewport?
Как-то пробовал возиться с пикселями, игры так и не получилось, но вот приблизительное решение твоей проблемы, если мне не изменяет память:
1. Отключи масштабирование в настройках проекта, проблем от него больше, чем преимуществ. Будем эмулировать его преимущества другим путём...
2. Сделай сцену-обложку для своей игры, типа:
>Game: Node
>_ World: Node
>_ GUI: Node
3. В ноде GUI помещай свои Control как обычно.
4. В ноде World нужен кастомный рендерер типа:
>Display: TextureRect # с ViewportTexture
>_ Renderer: Viewport
>_ _ Gameplay: ... # твоя игра
5. В этом Viewport устанавливаешь своё разрешение, вычисленное из размера TextureRect, чтобы там было ближайшее целочисленное + края от него до нужного:
>export var original_size := Vector2(640, 360)
Где-то в обработчике события изменения размера:
>var display_size: Vector2 = get_parent().size # 1366×768
>var ratio := display_size / original_size # будет 2.133...
>ratio.floor() # округляем вниз, получится 2.0
>var integer_size := original_size × ratio # 1280×720
>var difference := display_size - integer_size # (86, 48)
>size = original_size + difference / ratio # 683×384
Теперь геймплей должен выглядеть "пиксельно" на любом экране, расширясь при необходимости, но интерфейсные ноды никак не будут затронуты.
>>6334
Эх, жаль, я опоздал... Что-то похожее на Viewport?
>>6335
Спасибо, сохранил, лишним не будет. Вдруг мой метод откажет, то попробую этот.
Меняю настройки проекта динамически из кода с помощью небольшого скрипта при запуске игры и при каждом изменении размера экрана. Ещё отдельно настраиваю камеру, чтобы она центрировалась, если локации слишком маленькие и не двигалась.
Не знаю, насколько это хороший подход, но надеюсь сработает в долгосрочной перспективе.
Спасибо, сохранил, лишним не будет. Вдруг мой метод откажет, то попробую этот.
>Эх, жаль, я опоздал... Что-то похожее на Viewport?
Меняю настройки проекта динамически из кода с помощью небольшого скрипта при запуске игры и при каждом изменении размера экрана. Ещё отдельно настраиваю камеру, чтобы она центрировалась, если локации слишком маленькие и не двигалась.
Не знаю, насколько это хороший подход, но надеюсь сработает в долгосрочной перспективе.
>>6332
Это ты у нас мракобесный. Энтропия - это мрак...
Лалка, это DuckAssist написала по статье из Вики.
Хорошо, вот тебе ещё скриншот научной статьи.
Блин, ну что в ней интересного? Я серьёзно, если что. Представь: есть атомы и есть кванты. Раньше было известно, что сознание как-то строится из атомов. Припёрлись два клоуна и начали свою тупую сказку:
Ну серьёзно, это неинтересно. Два бумера-старпёра с консервативными взглядами ищут "душу" внутри биологического человека, боясь, что мясо в их теле - единственное, что отделяет их от пустоты, и никаких значимых отличий от компьютера у мяса, кроме его неизбежного гниения в скором будущем, нет... Т.е. банальнейший страх смерти и ЧСВ, сильно раздутое ксенофобией/биошовинизмом из-за консерватизма.
Это ещё называют "эхо-камера", погугли.
Очень многое зависит от успеха AI/ML, а ты будто защищаешь производство паровых двигателей, сопротивляясь "макретингу электричества"...
>>6338
Согласен. Чтоб ты знал, я не зог-шиз, а другой шиз, геймдевящий. Энтропия-шиза тоже не стоит здесь репортить, он, вроде, тоже что-то геймдеви(т/л).
>мракобесный шиз
Это ты у нас мракобесный. Энтропия - это мрак...
>контекст ИИ уже под тебя подстроился
Лалка, это DuckAssist написала по статье из Вики.
Хорошо, вот тебе ещё скриншот научной статьи.
>>Опять шиза уровня "квантового сознания"...
>Самая интересная гипотеза сознания.
Блин, ну что в ней интересного? Я серьёзно, если что. Представь: есть атомы и есть кванты. Раньше было известно, что сознание как-то строится из атомов. Припёрлись два клоуна и начали свою тупую сказку:
>Вы думали - вам атомов хватит?.. А нет, вовсе нет - молекулы и атомы слишком тупые, давайте лучше воспринимать сознание как эффект... квантов! Да, поскольку мы ничего ниже квантов пока не нашли, квантовая теория сойдёт для moving goalpost! А вот изобретут квантовый ИИ - а мы дальше пододвинем! Мясной человек всегда останется на вершине, хохо!
Ну серьёзно, это неинтересно. Два бумера-старпёра с консервативными взглядами ищут "душу" внутри биологического человека, боясь, что мясо в их теле - единственное, что отделяет их от пустоты, и никаких значимых отличий от компьютера у мяса, кроме его неизбежного гниения в скором будущем, нет... Т.е. банальнейший страх смерти и ЧСВ, сильно раздутое ксенофобией/биошовинизмом из-за консерватизма.
>обсуждать со знающими людьми
Это ещё называют "эхо-камера", погугли.
>это бьет по маркетингу машинного обучения
Очень многое зависит от успеха AI/ML, а ты будто защищаешь производство паровых двигателей, сопротивляясь "макретингу электричества"...
>>6338
>Репортим зог-шизу и игнорим
Согласен. Чтоб ты знал, я не зог-шиз, а другой шиз, геймдевящий. Энтропия-шиза тоже не стоит здесь репортить, он, вроде, тоже что-то геймдеви(т/л).
>>6342
Нафига писать анонам если сам не знаешь ответ? Тебе настолько хочется казаться умным, что ты на анонимном форуме (без ников) готов публиковать выжимку ИИ ответа? Чтобы что? Тут даже не поймут кто написал.
Ппц, я еще к вайбкодингу не привык, тут уже вайбпостинг наступил.
Нафига писать анонам если сам не знаешь ответ? Тебе настолько хочется казаться умным, что ты на анонимном форуме (без ников) готов публиковать выжимку ИИ ответа? Чтобы что? Тут даже не поймут кто написал.
Ппц, я еще к вайбкодингу не привык, тут уже вайбпостинг наступил.
>>6342
Я бы с осторожностью пользовался поисковыми ИИ обзорами. Особенно информацией по лекарствам.
По техническим темам тоже бывают склеивают несколько разных постов в реддите.
Я бы с осторожностью пользовался поисковыми ИИ обзорами. Особенно информацией по лекарствам.
По техническим темам тоже бывают склеивают несколько разных постов в реддите.
>>6343
Ничего интересного, "zоg-шиз" - это >>6355 (Del)
У него довольно примечательные паттерны...
>>6345
Ну не то, чтобы анон, я его в другом разделе видел...
Кому надо - узнают меня по моим паттернам речи...
Он первый начал именно с этого: >>6028
У него там на скриншоте Яндекс.Алиса, лол!
>>6349
Не беспокойся, нужные лекарства я знаю по мемам.
>Я, видимо, что-то интересное пропустил
Ничего интересного, "zоg-шиз" - это >>6355 (Del)
У него довольно примечательные паттерны...
>>6345
>Нафига писать анонам
Ну не то, чтобы анон, я его в другом разделе видел...
>Тут даже не поймут кто написал.
Кому надо - узнают меня по моим паттернам речи...
>публиковать выжимку ИИ ответа
Он первый начал именно с этого: >>6028
У него там на скриншоте Яндекс.Алиса, лол!
>>6349
>Особенно информацией по лекарствам.
Не беспокойся, нужные лекарства я знаю по мемам.
>>6343
Прости, нет. Не хочу деанониться.
Прошел долгий путь от фотошопа до aseprite
>Можешь показать?
Прости, нет. Не хочу деанониться.
>В чем рисуешь?
Прошел долгий путь от фотошопа до aseprite
Я правильно понял на голове невозможно сделать мультиплеерную физику не изъебнувшись. Видел кидали рокет лигу но там кастомное всё
>>6376
На годоте* фикс
На годоте* фикс
>>6376
Да, да, правильно, угомонись.
Да, да, правильно, угомонись.
>>6366
Я так понял чтобы получить бесплатную версию, надо либо собрать самому или же забить и скачать с торрентов? Официально бесплатный бинарник они не предоставляют? ппц квесты придумали
>aseprite
Я так понял чтобы получить бесплатную версию, надо либо собрать самому или же забить и скачать с торрентов? Официально бесплатный бинарник они не предоставляют? ппц квесты придумали
142 Кб, 863x649>>6376
Фундаментальная проблема же, причем тут годот?
Фундаментальная проблема же, причем тут годот?
949 Кб, 590x898>>6404
Через ИИшку генерите римволдских пешек? Зачем? Они же убогие? судя по пику это вообще арена/рпг игра
Плейсхолдеры очень сильно определяют дальнейший креатив и идеи по игре. Тупо рисунок кольца и амулета от руки могут придать дальнейшее развития восприятие игры. Да даже кольцо из другой игры может задать тон всего стиля.
Коробки вместо бижутерии, пешка римворда - все это смотрится как шизофазия.
Через ИИшку генерите римволдских пешек? Зачем? Они же убогие? судя по пику это вообще арена/рпг игра
Плейсхолдеры очень сильно определяют дальнейший креатив и идеи по игре. Тупо рисунок кольца и амулета от руки могут придать дальнейшее развития восприятие игры. Да даже кольцо из другой игры может задать тон всего стиля.
Коробки вместо бижутерии, пешка римворда - все это смотрится как шизофазия.
Твой пост тоже.
Но, для вайб кодинга или т.б.дизайна это таки не самое подходящее место, вот как в другой ветве по игре стали задвигать мной сказанное о авторе вообще офтопным обсуждением другой игрой, так и тут - иной темой, и по сути 1в1 точно такое было в Дижкосраче - вон ниже тут по ссылке можно увидеть там, так что этот оффтоп не случайность - а, злонамеренность и саботаж, русофобский и шире античеловечесткий.
>>6356
Так много всего только про zog и их продукцию что, проще сказать всю жизнь.
Ну вот может видел, про Godot недавно разжовывал, аж жопа загорелась у хейтеров, но начало потерто т.е. оно теперь только с ответов мне :
https://2ch.org/gd/res/618624.html#1094117
и https://2ch.org/gd/res/618624.html#1094106
но, изначально стартовое с отлинкованными исходными ответами всё же тут зарепостил позже(на него ответы - уже ниже) в:
https://2ch.org/gd/res/618624.html#1094148.
И далее немало ниже в ветви диалога, умным тот срач как и тут - будет очень полезен для понимания сути сатанистов, даунам вряд ли, как и понятно самим крипто-сатанистам.
Верьте-верьте этой гниде
Ты "забыл" указать что, все хейтеры его и таких, разобличителей сатанистких происков,
- сами крипто-русофобы zog и zog-отсосы-$/идеалогично разнообразнейшие.
Тут же ЗАДВИНУТО:
>>5130 (Предложение портануть полезный плагин. Как до дела дошло - все сдулись, а то прям "любая нейронка за полчаса портанёт", ну она то может и портанёт но, они все обосрались, видать как сатанисты же по неприязни к честным людям).
>>6052 (самый подробный в мире анализ успеха [MineCraft]).
>>6302 (Del) (про связь гомиков с крипто-сатанистами и даже вирмейкерством, в одного местного сатаниста статье ветви - полная ветвь обсуждения:
https://2ch.org/gd/res/1093998.html#1095473 )
Но, для вайб кодинга или т.б.дизайна это таки не самое подходящее место, вот как в другой ветве по игре стали задвигать мной сказанное о авторе вообще офтопным обсуждением другой игрой, так и тут - иной темой, и по сути 1в1 точно такое было в Дижкосраче - вон ниже тут по ссылке можно увидеть там, так что этот оффтоп не случайность - а, злонамеренность и саботаж, русофобский и шире античеловечесткий.
>>6356
>> Я, видимо, что-то интересное пропустил
Так много всего только про zog и их продукцию что, проще сказать всю жизнь.
Ну вот может видел, про Godot недавно разжовывал, аж жопа загорелась у хейтеров, но начало потерто т.е. оно теперь только с ответов мне :
https://2ch.org/gd/res/618624.html#1094117
и https://2ch.org/gd/res/618624.html#1094106
но, изначально стартовое с отлинкованными исходными ответами всё же тут зарепостил позже(на него ответы - уже ниже) в:
https://2ch.org/gd/res/618624.html#1094148.
И далее немало ниже в ветви диалога, умным тот срач как и тут - будет очень полезен для понимания сути сатанистов, даунам вряд ли, как и понятно самим крипто-сатанистам.
> Ничего интересного,
Верьте-верьте этой гниде
> "zоg-шиз" - это >>6355 (Del)
Ты "забыл" указать что, все хейтеры его и таких, разобличителей сатанистких происков,
- сами крипто-русофобы zog и zog-отсосы-$/идеалогично разнообразнейшие.
Тут же ЗАДВИНУТО:
>>5130 (Предложение портануть полезный плагин. Как до дела дошло - все сдулись, а то прям "любая нейронка за полчаса портанёт", ну она то может и портанёт но, они все обосрались, видать как сатанисты же по неприязни к честным людям).
>>6052 (самый подробный в мире анализ успеха [MineCraft]).
>>6302 (Del) (про связь гомиков с крипто-сатанистами и даже вирмейкерством, в одного местного сатаниста статье ветви - полная ветвь обсуждения:
https://2ch.org/gd/res/1093998.html#1095473 )
>>6410
иконки позаимствованы из папок модов римворлда а пешку буквально пару часов назад сам вырезал скриншотм просто что бы портрет хоть чем то заткнуть
иконки позаимствованы из папок модов римворлда а пешку буквально пару часов назад сам вырезал скриншотм просто что бы портрет хоть чем то заткнуть
322 Кб, 1137x639>>6431
Затыкай близким к задумке. Даже от руки нарисуй, но чтобы не отторгалось от общего плана в голове.
Потом спасибо скажешь, потому что плейсхолдеры это не чтобы поугарать и потом просрать весь вайб к игре (потому что "гы-гы говно"), плейсхолдеры это больше схема-указатель.
Пик не то что пример как надо, я хз какой у тебя стиль, но смотри как меняется погружение сразу.
Затыкай близким к задумке. Даже от руки нарисуй, но чтобы не отторгалось от общего плана в голове.
Потом спасибо скажешь, потому что плейсхолдеры это не чтобы поугарать и потом просрать весь вайб к игре (потому что "гы-гы говно"), плейсхолдеры это больше схема-указатель.
Пик не то что пример как надо, я хз какой у тебя стиль, но смотри как меняется погружение сразу.
20 Кб, 379x243А вы знали что к нескольким однотипным нодам можно прикрепить один и тот же скрипт?
Живите теперь с этим.
Живите теперь с этим.
>>6484
нет я ваще не слово нихуя не понял чо тута написано
нет я ваще не слово нихуя не понял чо тута написано
>>6484
Знали.
Как только прочитал первую строчку первого скрипта: экстендс Ноде, сразу заинтересовался, зачем эта строчка и что она означает, и буквально через секунду уже знал, что скрипт можно прикрепить к нескольким нодам этого типа.
Нет ты.
> А вы знали что к нескольким однотипным нодам можно прикрепить один и тот же скрипт?
Знали.
Как только прочитал первую строчку первого скрипта: экстендс Ноде, сразу заинтересовался, зачем эта строчка и что она означает, и буквально через секунду уже знал, что скрипт можно прикрепить к нескольким нодам этого типа.
> Живите теперь с этим.
Нет ты.
24 Кб, 615x175>>6498
Если пришел с обычных языков, то это не совсем очевидно. В годоте скрипт становится буквально частью этой ноды (наверное его компонентом), в обычном программирование extends это просто наследование (тут бы тогда получилось какое-то множественное наследование).
Удобно, особенно на тестикулы партикулы повесить и всю логику в них же и запихнуть. да, я знаю что очевидные вещи для многих говорю, мне просто это понравилось, для меня не совсем обычно это
Если пришел с обычных языков, то это не совсем очевидно. В годоте скрипт становится буквально частью этой ноды (наверное его компонентом), в обычном программирование extends это просто наследование (тут бы тогда получилось какое-то множественное наследование).
Удобно, особенно на тестикулы партикулы повесить и всю логику в них же и запихнуть. да, я знаю что очевидные вещи для многих говорю, мне просто это понравилось, для меня не совсем обычно это
2,1 Мб, 1500x844>>6502
Ну не знаю, о каких языках речь, но при написании оконных приложений всегда есть инстанс Application, через который идёт доступ к главному циклу приложения, всем его коллбэкам, и содержит список высокоуровневых объектов "окна". Это буквально то же самое. Абсолютно никакой разницы. И вот у тебя лежит в проекте класс MyWindow : Window; это буквально годотовый extends и он буквально может быть создан ннесколько раз, как инстансы, перечисленные в списке окон приложения. Да, именно несколько раз. только в языках программирования ты их через язык инстанцируешь, а в годоте через визуальный редактор, путям присоединения скрипта к визуальной ноде.
Как можно не видеть, что всё это то же самое, если ты пришёл, как ты пишешь, из языка? Ты ведь его учил? Учил же язык? Да? Да?
> Если пришел с обычных языков, то это не совсем очевидно.
Ну не знаю, о каких языках речь, но при написании оконных приложений всегда есть инстанс Application, через который идёт доступ к главному циклу приложения, всем его коллбэкам, и содержит список высокоуровневых объектов "окна". Это буквально то же самое. Абсолютно никакой разницы. И вот у тебя лежит в проекте класс MyWindow : Window; это буквально годотовый extends и он буквально может быть создан ннесколько раз, как инстансы, перечисленные в списке окон приложения. Да, именно несколько раз. только в языках программирования ты их через язык инстанцируешь, а в годоте через визуальный редактор, путям присоединения скрипта к визуальной ноде.
Как можно не видеть, что всё это то же самое, если ты пришёл, как ты пишешь, из языка? Ты ведь его учил? Учил же язык? Да? Да?
>>6507
Наверное самый интересный подход, который я редко встречаю. Это компонентная система через свойство "owner".
Но я пока не пробовал это.
Наверное самый интересный подход, который я редко встречаю. Это компонентная система через свойство "owner".
Но я пока не пробовал это.
8 Кб, 268x214>>6510
Не пойму что ты несешь. Нода/Сцены владеют скриптом как одним ресурсом. Это как если бы сами ноды наследовались от скрипта, но в коде мы расширяем ноду.
Это чисто уличная магия.
Не пойму что ты несешь. Нода/Сцены владеют скриптом как одним ресурсом. Это как если бы сами ноды наследовались от скрипта, но в коде мы расширяем ноду.
Это чисто уличная магия.
>>6513
Стрелочки разверни на своей каляке-маляке.
Во первых нет.
Во вторых extends переводится не как "владение".
Вот когда для тебя не станет там магии, так и поймёшь, что нёс анон.
> Не пойму что ты несешь.
Стрелочки разверни на своей каляке-маляке.
> Нода/Сцены владеют скриптом как одним ресурсом.
Во первых нет.
Во вторых extends переводится не как "владение".
> магия
Вот когда для тебя не станет там магии, так и поймёшь, что нёс анон.
>>6502
Никаким компонентом она не становится, и это не композиция >>6507
Это обычное наследование. В годоте реальной композиции (компонентов) можно достигать либо колдовством на рефлексии и refcounted инстансах с пробросом мира ноды-обладателя, либо очень жирное для сцены генерирование нод на каждый класс-компонент.
Никаким компонентом она не становится, и это не композиция >>6507
Это обычное наследование. В годоте реальной композиции (компонентов) можно достигать либо колдовством на рефлексии и refcounted инстансах с пробросом мира ноды-обладателя, либо очень жирное для сцены генерирование нод на каждый класс-компонент.
>>6517
По-моему ты меня тролишь, это переводится и звучит на русском как "расширяет".
класс Собака расширяет Животное.
Зумеры не знают про UML.
>>6519
Я про понятие компонентов в юнити. Мне думается когда говорят о компонентном подход в годоте, тоже на компоненты юнити ссылаются. Но точно не специальную олимпиаду по "Наследование vs Композиция" (вернул мне мой 2007, кек, откуда ты это вытащил вообще).
Компоненты в программировании — это независимые, изолированные части кода, выполняющие определенную задачу и служащие строительными блоками для создания более крупных приложений. Главные свойства компонентов включают модульность, повторное использование и четкие интерфейсы взаимодействия
>Во вторых extends переводится не как "владение".
По-моему ты меня тролишь, это переводится и звучит на русском как "расширяет".
класс Собака расширяет Животное.
>Стрелочки разверни на своей каляке-маляке.
Зумеры не знают про UML.
>>6519
>Никаким компонентом она не становится
Я про понятие компонентов в юнити. Мне думается когда говорят о компонентном подход в годоте, тоже на компоненты юнити ссылаются. Но точно не специальную олимпиаду по "Наследование vs Композиция" (вернул мне мой 2007, кек, откуда ты это вытащил вообще).
Компоненты в программировании — это независимые, изолированные части кода, выполняющие определенную задачу и служащие строительными блоками для создания более крупных приложений. Главные свойства компонентов включают модульность, повторное использование и четкие интерфейсы взаимодействия
>>6510
Сука так жалко Хейдена Кристенсена. Отличнейше отыграл тупого спермотоксикозника, а его захейтили аж на золотую малину. При этом Драйвера, который тоже отлично сыграл ещё более тупого спермотоксикозника в гораздо худших фильмах по ЗВ, все только хвалили.
Годаны, рассказываю своё "откровение у холодильника". Твины в Годоте - замечательная штука. Я для своей софтины на плюсах задумал запилить интерфейсные анимации и такой: "Хм, а ведь в Годоте есть твины, дай-ка я посмотрю, как там сделано, и спизжу."
Посмотрел. Ну, во-первых, это действительно очень легковесные штуки, которые можно делать пачками, не опасаясь за производительность. Во-вторых, глубоко под капотом у них вот эта штука http://robertpenner.com/easing/ - в копирайте указан 2001 год; и есть большое подозрение, что вообще везде, где используются подобные простые анимации, за основу взяты именно эти формулы.
В итоге сами твины я спиздил только концептуально, написал с нуля свой вариант по образу и подобию. А вот интерполяторы тупо скопипастил; ну потому что я не представляю, как можно ещё что-то иначе сделать с кодом вида return c ⚹ t / d + b
Кароч. Чем больше я кодю всякого не относящегося к годоту, тем больше понимаю, насколько он охуенен.
Делойте игры.
Сука так жалко Хейдена Кристенсена. Отличнейше отыграл тупого спермотоксикозника, а его захейтили аж на золотую малину. При этом Драйвера, который тоже отлично сыграл ещё более тупого спермотоксикозника в гораздо худших фильмах по ЗВ, все только хвалили.
Годаны, рассказываю своё "откровение у холодильника". Твины в Годоте - замечательная штука. Я для своей софтины на плюсах задумал запилить интерфейсные анимации и такой: "Хм, а ведь в Годоте есть твины, дай-ка я посмотрю, как там сделано, и спизжу."
Посмотрел. Ну, во-первых, это действительно очень легковесные штуки, которые можно делать пачками, не опасаясь за производительность. Во-вторых, глубоко под капотом у них вот эта штука http://robertpenner.com/easing/ - в копирайте указан 2001 год; и есть большое подозрение, что вообще везде, где используются подобные простые анимации, за основу взяты именно эти формулы.
В итоге сами твины я спиздил только концептуально, написал с нуля свой вариант по образу и подобию. А вот интерполяторы тупо скопипастил; ну потому что я не представляю, как можно ещё что-то иначе сделать с кодом вида return c ⚹ t / d + b
Кароч. Чем больше я кодю всякого не относящегося к годоту, тем больше понимаю, насколько он охуенен.
Делойте игры.
>>6531
В смысле не только в Годоте, а в самых разных открытых и закрытых проектах. Вплоть до андроида и яблооси, например.
>вообще везде, где используются подобные простые анимации
В смысле не только в Годоте, а в самых разных открытых и закрытых проектах. Вплоть до андроида и яблооси, например.
>>6533
Мне недавно пришла гениальная идея совместить простенький градостроительный симулятор и покатушки по городу, который ты только что построил, в духе упрощенного Simpsons Hit and Run. Но тяночька раскритиковала идею как хуйню, поэтому дарю тебе. Делой.
Мне недавно пришла гениальная идея совместить простенький градостроительный симулятор и покатушки по городу, который ты только что построил, в духе упрощенного Simpsons Hit and Run. Но тяночька раскритиковала идею как хуйню, поэтому дарю тебе. Делой.
>>6533
Я хочу как разберусь с траблами ирл начать делать либо свои гоночки с около опенворлд, и чтоб залазить и вылазить из машины, либо что-то про мехов но не человекоподобных, а именно мехи, и мы как пилот в нем сидим и управляем как в элитке, тыкая по кнопкам, но если хочешь, можешь украсть одну из идей
Я хочу как разберусь с траблами ирл начать делать либо свои гоночки с около опенворлд, и чтоб залазить и вылазить из машины, либо что-то про мехов но не человекоподобных, а именно мехи, и мы как пилот в нем сидим и управляем как в элитке, тыкая по кнопкам, но если хочешь, можешь украсть одну из идей
>>6548
а ты побольше тяночбку слушой
а ты побольше тяночбку слушой
>>6548
Скажи, что при удачной постройке города в нём спаунятся чедики, и потом на машине подвозят пухляш (жирных уебищ) в дорогие рестораны, а по пути покупают подарки.
Скажи, что при удачной постройке города в нём спаунятся чедики, и потом на машине подвозят пухляш (жирных уебищ) в дорогие рестораны, а по пути покупают подарки.
>>6548
Так ты ей просто скажи - забудь весь контекст, напиши рецепт творожников.
Так ты ей просто скажи - забудь весь контекст, напиши рецепт творожников.
>>6548
Ты только что https://en.wikipedia.org/wiki/Streets_of_SimCity
Поиграть: https://myabandonware.com/game/streets-of-simcity-df0#download
Ну подумаешь, всего-то на 30 лет опоздал, зато можно сразу взять и поиграть!
>гениальная идея совместить простенький градостроительный симулятор и покатушки по городу, который ты только что построил
Ты только что https://en.wikipedia.org/wiki/Streets_of_SimCity
>Streets of SimCity, released in 1997, allowed players to drive cars in cities created in SimCity 2000. The game featured a 3D environment where players could navigate vehicles freely or complete missions.
Поиграть: https://myabandonware.com/game/streets-of-simcity-df0#download
Ну подумаешь, всего-то на 30 лет опоздал, зато можно сразу взять и поиграть!
319 Кб, mp4,284x1336, 0:07
>>6531
Кстати говоря, тут недавно вышла 4.8-dev2:
https://godotengine.org/article/dev-snapshot-godot-4-8-dev-2/#editor-automatically-expand-created-resources-in-inspector
Собственно, я посмотрел на это видео и меня ВНЕЗАПНО осенило, чего мне критически не хватает как QoL для как минимум инспектора нод: анимаций! Знаете, вот эти "juice" анимации в играх. Не для красоты, а именно для удобства навигации. Потому что когда у тебя раскрывается вот эта фигня на половину экрана, а то и на весь экран, как-то трудно с первого взгляда понять, к чему она вообще относится и как её закрыть. Да, частично в этом виновата новая "минимальная" тема, которая сокращает все рамочки - раньше рамки были шире, но из-за более широких рамок приходилось расширять колонку инспектора, иначе всё слишком скукоживалось... В общем, я не против "минимальной темы" и тонких рамок, но добавление анимаций раскрытия и закрытия, хотя бы 0.1-0.2 мс, улучшило бы навигацию. Представьте: нажимаешь кнопку, и из-под этой кнопки "выезжает" или "растягивается" длинная панель с настройками. Мозг человека лучше всего регистрирует быстрые движения, поэтому юзер на чисто бессознательном уровне видит, где эта панель начинается и заканчивается. И так же назад: нажал кнопку - панелька "сворачивается" или "скукоживается" и ты легко видишь, что за ней подтягивается. Так было бы намного проще работать с многократно вложенными ресурсами. Серьёзно, я задолбался, например, с GradientTexture2D, в которой ты должен создать сначала Gradient2D, а внутри него - Gradient1D, если не ошибаюсь, и у каждого из этих ресурсов несколько параметров, которые я постоянно путаю между собой. С анимациями всё было бы проще.
Я знаю, что tool-скрипты могут менять GUI редактора и даже двигать элементы, но можно ли реально подцепиться к событиям раскрытия/сворачивания, чтобы добавить свои анимации? По-моему, тут придётся в исходники лезть и делать кастомный билд, чего мне очень не хочется. Вряд ли такое QoL примут в Core...
>запилить интерфейсные анимации
Кстати говоря, тут недавно вышла 4.8-dev2:
https://godotengine.org/article/dev-snapshot-godot-4-8-dev-2/#editor-automatically-expand-created-resources-in-inspector
>Hugo Locurcio starts our roundup with GH-99725, bringing a long-desired QOL addition to the inspector: auto-expansion of resources. While most of our inspector items automatically revealed themselves when initialized, resources always existed as an unfortunate blindspot. As demonstrated below, this will no longer be the case!
Собственно, я посмотрел на это видео и меня ВНЕЗАПНО осенило, чего мне критически не хватает как QoL для как минимум инспектора нод: анимаций! Знаете, вот эти "juice" анимации в играх. Не для красоты, а именно для удобства навигации. Потому что когда у тебя раскрывается вот эта фигня на половину экрана, а то и на весь экран, как-то трудно с первого взгляда понять, к чему она вообще относится и как её закрыть. Да, частично в этом виновата новая "минимальная" тема, которая сокращает все рамочки - раньше рамки были шире, но из-за более широких рамок приходилось расширять колонку инспектора, иначе всё слишком скукоживалось... В общем, я не против "минимальной темы" и тонких рамок, но добавление анимаций раскрытия и закрытия, хотя бы 0.1-0.2 мс, улучшило бы навигацию. Представьте: нажимаешь кнопку, и из-под этой кнопки "выезжает" или "растягивается" длинная панель с настройками. Мозг человека лучше всего регистрирует быстрые движения, поэтому юзер на чисто бессознательном уровне видит, где эта панель начинается и заканчивается. И так же назад: нажал кнопку - панелька "сворачивается" или "скукоживается" и ты легко видишь, что за ней подтягивается. Так было бы намного проще работать с многократно вложенными ресурсами. Серьёзно, я задолбался, например, с GradientTexture2D, в которой ты должен создать сначала Gradient2D, а внутри него - Gradient1D, если не ошибаюсь, и у каждого из этих ресурсов несколько параметров, которые я постоянно путаю между собой. С анимациями всё было бы проще.
Я знаю, что tool-скрипты могут менять GUI редактора и даже двигать элементы, но можно ли реально подцепиться к событиям раскрытия/сворачивания, чтобы добавить свои анимации? По-моему, тут придётся в исходники лезть и делать кастомный билд, чего мне очень не хочется. Вряд ли такое QoL примут в Core...
319 Кб, mp4,284x1336, 0:07
>>6531
Кстати говоря, тут недавно вышла 4.8-dev2:
https://godotengine.org/article/dev-snapshot-godot-4-8-dev-2/#editor-automatically-expand-created-resources-in-inspector
Собственно, я посмотрел на это видео и меня ВНЕЗАПНО осенило, чего мне критически не хватает как QoL для как минимум инспектора нод: анимаций! Знаете, вот эти "juice" анимации в играх. Не для красоты, а именно для удобства навигации. Потому что когда у тебя раскрывается вот эта фигня на половину экрана, а то и на весь экран, как-то трудно с первого взгляда понять, к чему она вообще относится и как её закрыть. Да, частично в этом виновата новая "минимальная" тема, которая сокращает все рамочки - раньше рамки были шире, но из-за более широких рамок приходилось расширять колонку инспектора, иначе всё слишком скукоживалось... В общем, я не против "минимальной темы" и тонких рамок, но добавление анимаций раскрытия и закрытия, хотя бы 0.1-0.2 мс, улучшило бы навигацию. Представьте: нажимаешь кнопку, и из-под этой кнопки "выезжает" или "растягивается" длинная панель с настройками. Мозг человека лучше всего регистрирует быстрые движения, поэтому юзер на чисто бессознательном уровне видит, где эта панель начинается и заканчивается. И так же назад: нажал кнопку - панелька "сворачивается" или "скукоживается" и ты легко видишь, что за ней подтягивается. Так было бы намного проще работать с многократно вложенными ресурсами. Серьёзно, я задолбался, например, с GradientTexture2D, в которой ты должен создать сначала Gradient2D, а внутри него - Gradient1D, если не ошибаюсь, и у каждого из этих ресурсов несколько параметров, которые я постоянно путаю между собой. С анимациями всё было бы проще.
Я знаю, что tool-скрипты могут менять GUI редактора и даже двигать элементы, но можно ли реально подцепиться к событиям раскрытия/сворачивания, чтобы добавить свои анимации? По-моему, тут придётся в исходники лезть и делать кастомный билд, чего мне очень не хочется. Вряд ли такое QoL примут в Core...
>запилить интерфейсные анимации
Кстати говоря, тут недавно вышла 4.8-dev2:
https://godotengine.org/article/dev-snapshot-godot-4-8-dev-2/#editor-automatically-expand-created-resources-in-inspector
>Hugo Locurcio starts our roundup with GH-99725, bringing a long-desired QOL addition to the inspector: auto-expansion of resources. While most of our inspector items automatically revealed themselves when initialized, resources always existed as an unfortunate blindspot. As demonstrated below, this will no longer be the case!
Собственно, я посмотрел на это видео и меня ВНЕЗАПНО осенило, чего мне критически не хватает как QoL для как минимум инспектора нод: анимаций! Знаете, вот эти "juice" анимации в играх. Не для красоты, а именно для удобства навигации. Потому что когда у тебя раскрывается вот эта фигня на половину экрана, а то и на весь экран, как-то трудно с первого взгляда понять, к чему она вообще относится и как её закрыть. Да, частично в этом виновата новая "минимальная" тема, которая сокращает все рамочки - раньше рамки были шире, но из-за более широких рамок приходилось расширять колонку инспектора, иначе всё слишком скукоживалось... В общем, я не против "минимальной темы" и тонких рамок, но добавление анимаций раскрытия и закрытия, хотя бы 0.1-0.2 мс, улучшило бы навигацию. Представьте: нажимаешь кнопку, и из-под этой кнопки "выезжает" или "растягивается" длинная панель с настройками. Мозг человека лучше всего регистрирует быстрые движения, поэтому юзер на чисто бессознательном уровне видит, где эта панель начинается и заканчивается. И так же назад: нажал кнопку - панелька "сворачивается" или "скукоживается" и ты легко видишь, что за ней подтягивается. Так было бы намного проще работать с многократно вложенными ресурсами. Серьёзно, я задолбался, например, с GradientTexture2D, в которой ты должен создать сначала Gradient2D, а внутри него - Gradient1D, если не ошибаюсь, и у каждого из этих ресурсов несколько параметров, которые я постоянно путаю между собой. С анимациями всё было бы проще.
Я знаю, что tool-скрипты могут менять GUI редактора и даже двигать элементы, но можно ли реально подцепиться к событиям раскрытия/сворачивания, чтобы добавить свои анимации? По-моему, тут придётся в исходники лезть и делать кастомный билд, чего мне очень не хочется. Вряд ли такое QoL примут в Core...
>>6568
А, нет, перепутал: в GradientTexture2D (который я назвал Gradient2D) вкладывается просто Gradient (который 1D). Суть в том, что мне часто нужно изменить несколько настроек и внутри GradientTexture2D (fill, width, height, а также указать две точки на 2D графике), и внутри Gradient (цвета на графике и interpolation_mode), а потом я иногда залезаю туда, чтобы поменять цвета и всё такое... Запутывает ужасно. И эта комбинация на порядки проще того, что творится в типичном Mesh -> Material -> Shader -> Texture -> Noise/Gradient (например, когда хочешь добавить шум в кастомный шейдер)... С анимациями, ИМХО, было бы по-проще разобраться. Какие подводные?
>GradientTexture2D, в которой ты должен создать сначала Gradient2D, а внутри него - Gradient1D
А, нет, перепутал: в GradientTexture2D (который я назвал Gradient2D) вкладывается просто Gradient (который 1D). Суть в том, что мне часто нужно изменить несколько настроек и внутри GradientTexture2D (fill, width, height, а также указать две точки на 2D графике), и внутри Gradient (цвета на графике и interpolation_mode), а потом я иногда залезаю туда, чтобы поменять цвета и всё такое... Запутывает ужасно. И эта комбинация на порядки проще того, что творится в типичном Mesh -> Material -> Shader -> Texture -> Noise/Gradient (например, когда хочешь добавить шум в кастомный шейдер)... С анимациями, ИМХО, было бы по-проще разобраться. Какие подводные?
>>6426
Советую обратить внимание на аргументы create_timer():
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-create-timer
Во-первых, ты 100% хочешь ставить process_always = false, чтобы твои пули не исчезали с экрана, когда игрок ставит игру на паузу, иначе твоя игра позволит такой трюк: босс стреляет пулями в игрока, игрок ставит игру на паузу, пули замирают в воздухе и исчезают, игрок снимает игру с паузы и стреляет в босса - несправедливое преимущество; также наоборот, если игрок выстрелил дорогими патронами и поставил игру на паузу, а они неожиданно пропали, зависнув в воздухе, не долетев до своих целей.
Подробнее об этом нюансе: https://github.com/godotengine/godot-proposals/issues/9924
Во-вторых, тебе, скорее всего, желательно поставить process_in_physics = true, чтобы пули исчезали только после того, как будут обработаны все события в _physics_process, а не после случайного кадра в _process. Я не знаю, на какой FPS и TPS ты ориентируешься, но у разных игроков разные частоты экрана и личные предпочтения (!), а физические тики обычно более надёжные и определённые, поэтому для работы с Area2D лучше ориентироваться на _physics_process. Думаю, лишним не будет.
>Какое элегантное решение для таймаута (пули).
Советую обратить внимание на аргументы create_timer():
https://docs.godotengine.org/en/stable/classes/class_scenetree.html#class-scenetree-method-create-timer
>SceneTreeTimer create_timer(time_sec: float, process_always: bool = true, process_in_physics: bool = false, ignore_time_scale: bool = false)
Во-первых, ты 100% хочешь ставить process_always = false, чтобы твои пули не исчезали с экрана, когда игрок ставит игру на паузу, иначе твоя игра позволит такой трюк: босс стреляет пулями в игрока, игрок ставит игру на паузу, пули замирают в воздухе и исчезают, игрок снимает игру с паузы и стреляет в босса - несправедливое преимущество; также наоборот, если игрок выстрелил дорогими патронами и поставил игру на паузу, а они неожиданно пропали, зависнув в воздухе, не долетев до своих целей.
Подробнее об этом нюансе: https://github.com/godotengine/godot-proposals/issues/9924
Во-вторых, тебе, скорее всего, желательно поставить process_in_physics = true, чтобы пули исчезали только после того, как будут обработаны все события в _physics_process, а не после случайного кадра в _process. Я не знаю, на какой FPS и TPS ты ориентируешься, но у разных игроков разные частоты экрана и личные предпочтения (!), а физические тики обычно более надёжные и определённые, поэтому для работы с Area2D лучше ориентироваться на _physics_process. Думаю, лишним не будет.
>>6484
Честно говоря, не совсем понимаю, что ты имел в виду (уже всё обсуждение прочитал - всё равно не понял)...
Есть несколько одинаковых, по сути результата, действия:
1. Добавить стандартную ноду, например, Node2D, и затем нажать "прикрепить скрипт".
2. Добавить кастомную ноду, например, class_name MyNode extends Node2D из палитры.
3. Добавить сцену, например, my_node.tscn, которая содержит кастомную ноду MyNode.
4. Дублировать уже имеющуюся в дереве сцены ноду с твоим скриптом, типа MyNode2.
5. Скопировать (ctrl+c) и вставить (ctrl+v) имеющуюся ноду со скриптом в другое место.
6. Делать всё то же самое, но в коде игрового/tool-скрипта: instantiate(), duplicate()...
Результатом будет нода с твоим скриптом, и таких нод может быть сколько угодно.
Собственно, как ты себе представляешь, например, пули, без этой возможности?..
>>6502
Может быть, ты пришёл с чего-то очень старого, где классовое ООП не существовало?
Не советую так делать. Частицы - это конечный узел, они должны управляться извне.
>>6513
Ресурс Script и сама нода, которая "расширяется" этим скриптом - это разные вещи...
>>6519
Какое "колдовство", лол? Композиция в ООП - это когда ты делаешь вот так:
И т.д. Все эти объекты - "компоненты", а объект MyCar создан через "композицию".
Для сравнения, "агрегация" - это когда ноды входят и выходят в любой момент:
Эти объекты живут независимо от MyCar (если MyCar не взорвётся вместе с ними).
>>6524
В Godot из коробки нет прямого аналога "компонентов GameObject" из Unity.
А в Unity из коробки нет прямого аналога "расширения нод скриптом" из Godot:
Т.е. GameObject/MonoBehaviour не имеют аналогов в Godot, а в Unity нет аналогов Object/Node/Script.
Хм... Насколько я понял, путаница возникает из-за слов "...attach script to...", правильно?
>к нескольким однотипным нодам можно прикрепить один и тот же скрипт
Честно говоря, не совсем понимаю, что ты имел в виду (уже всё обсуждение прочитал - всё равно не понял)...
Есть несколько одинаковых, по сути результата, действия:
1. Добавить стандартную ноду, например, Node2D, и затем нажать "прикрепить скрипт".
2. Добавить кастомную ноду, например, class_name MyNode extends Node2D из палитры.
3. Добавить сцену, например, my_node.tscn, которая содержит кастомную ноду MyNode.
4. Дублировать уже имеющуюся в дереве сцены ноду с твоим скриптом, типа MyNode2.
5. Скопировать (ctrl+c) и вставить (ctrl+v) имеющуюся ноду со скриптом в другое место.
6. Делать всё то же самое, но в коде игрового/tool-скрипта: instantiate(), duplicate()...
Результатом будет нода с твоим скриптом, и таких нод может быть сколько угодно.
Собственно, как ты себе представляешь, например, пули, без этой возможности?..
>>6502
>Если пришел с обычных языков
Может быть, ты пришёл с чего-то очень старого, где классовое ООП не существовало?
>особенно на партикулы повесить и всю логику в них же и запихнуть
Не советую так делать. Частицы - это конечный узел, они должны управляться извне.
>>6513
>Нода/Сцены владеют скриптом как одним ресурсом
Ресурс Script и сама нода, которая "расширяется" этим скриптом - это разные вещи...
>>6519
>В годоте реальной композиции (компонентов) можно достигать либо колдовством...
Какое "колдовство", лол? Композиция в ООП - это когда ты делаешь вот так:
>class_name MyCar extends Node
>var body: CarBody
>var engine: CarEngine
>var doors: Array[CarDoor]
>var wheels: Array[CarWheel]
>var parameters: CarParameters # например, class CarParameters extends Resource
И т.д. Все эти объекты - "компоненты", а объект MyCar создан через "композицию".
Для сравнения, "агрегация" - это когда ноды входят и выходят в любой момент:
>func add_passenger(passenger: Passenger) -> ...
>func remove_passenger(passenger) -> ...
Эти объекты живут независимо от MyCar (если MyCar не взорвётся вместе с ними).
>>6524
>Я про понятие компонентов в юнити.
В Godot из коробки нет прямого аналога "компонентов GameObject" из Unity.
А в Unity из коробки нет прямого аналога "расширения нод скриптом" из Godot:
>GameObject is a sealed class in Unity, so you can’t create a child class of it through inheritance.
>You usually make your own class that inherits from MonoBehaviour and attach that script to a GameObject.
Т.е. GameObject/MonoBehaviour не имеют аналогов в Godot, а в Unity нет аналогов Object/Node/Script.
Хм... Насколько я понял, путаница возникает из-за слов "...attach script to...", правильно?
>>6484
Честно говоря, не совсем понимаю, что ты имел в виду (уже всё обсуждение прочитал - всё равно не понял)...
Есть несколько одинаковых, по сути результата, действия:
1. Добавить стандартную ноду, например, Node2D, и затем нажать "прикрепить скрипт".
2. Добавить кастомную ноду, например, class_name MyNode extends Node2D из палитры.
3. Добавить сцену, например, my_node.tscn, которая содержит кастомную ноду MyNode.
4. Дублировать уже имеющуюся в дереве сцены ноду с твоим скриптом, типа MyNode2.
5. Скопировать (ctrl+c) и вставить (ctrl+v) имеющуюся ноду со скриптом в другое место.
6. Делать всё то же самое, но в коде игрового/tool-скрипта: instantiate(), duplicate()...
Результатом будет нода с твоим скриптом, и таких нод может быть сколько угодно.
Собственно, как ты себе представляешь, например, пули, без этой возможности?..
>>6502
Может быть, ты пришёл с чего-то очень старого, где классовое ООП не существовало?
Не советую так делать. Частицы - это конечный узел, они должны управляться извне.
>>6513
Ресурс Script и сама нода, которая "расширяется" этим скриптом - это разные вещи...
>>6519
Какое "колдовство", лол? Композиция в ООП - это когда ты делаешь вот так:
И т.д. Все эти объекты - "компоненты", а объект MyCar создан через "композицию".
Для сравнения, "агрегация" - это когда ноды входят и выходят в любой момент:
Эти объекты живут независимо от MyCar (если MyCar не взорвётся вместе с ними).
>>6524
В Godot из коробки нет прямого аналога "компонентов GameObject" из Unity.
А в Unity из коробки нет прямого аналога "расширения нод скриптом" из Godot:
Т.е. GameObject/MonoBehaviour не имеют аналогов в Godot, а в Unity нет аналогов Object/Node/Script.
Хм... Насколько я понял, путаница возникает из-за слов "...attach script to...", правильно?
>к нескольким однотипным нодам можно прикрепить один и тот же скрипт
Честно говоря, не совсем понимаю, что ты имел в виду (уже всё обсуждение прочитал - всё равно не понял)...
Есть несколько одинаковых, по сути результата, действия:
1. Добавить стандартную ноду, например, Node2D, и затем нажать "прикрепить скрипт".
2. Добавить кастомную ноду, например, class_name MyNode extends Node2D из палитры.
3. Добавить сцену, например, my_node.tscn, которая содержит кастомную ноду MyNode.
4. Дублировать уже имеющуюся в дереве сцены ноду с твоим скриптом, типа MyNode2.
5. Скопировать (ctrl+c) и вставить (ctrl+v) имеющуюся ноду со скриптом в другое место.
6. Делать всё то же самое, но в коде игрового/tool-скрипта: instantiate(), duplicate()...
Результатом будет нода с твоим скриптом, и таких нод может быть сколько угодно.
Собственно, как ты себе представляешь, например, пули, без этой возможности?..
>>6502
>Если пришел с обычных языков
Может быть, ты пришёл с чего-то очень старого, где классовое ООП не существовало?
>особенно на партикулы повесить и всю логику в них же и запихнуть
Не советую так делать. Частицы - это конечный узел, они должны управляться извне.
>>6513
>Нода/Сцены владеют скриптом как одним ресурсом
Ресурс Script и сама нода, которая "расширяется" этим скриптом - это разные вещи...
>>6519
>В годоте реальной композиции (компонентов) можно достигать либо колдовством...
Какое "колдовство", лол? Композиция в ООП - это когда ты делаешь вот так:
>class_name MyCar extends Node
>var body: CarBody
>var engine: CarEngine
>var doors: Array[CarDoor]
>var wheels: Array[CarWheel]
>var parameters: CarParameters # например, class CarParameters extends Resource
И т.д. Все эти объекты - "компоненты", а объект MyCar создан через "композицию".
Для сравнения, "агрегация" - это когда ноды входят и выходят в любой момент:
>func add_passenger(passenger: Passenger) -> ...
>func remove_passenger(passenger) -> ...
Эти объекты живут независимо от MyCar (если MyCar не взорвётся вместе с ними).
>>6524
>Я про понятие компонентов в юнити.
В Godot из коробки нет прямого аналога "компонентов GameObject" из Unity.
А в Unity из коробки нет прямого аналога "расширения нод скриптом" из Godot:
>GameObject is a sealed class in Unity, so you can’t create a child class of it through inheritance.
>You usually make your own class that inherits from MonoBehaviour and attach that script to a GameObject.
Т.е. GameObject/MonoBehaviour не имеют аналогов в Godot, а в Unity нет аналогов Object/Node/Script.
Хм... Насколько я понял, путаница возникает из-за слов "...attach script to...", правильно?
>>6484
А как это можно не знать, если в самом начале узнаешь про инстансы сцен? (Это однотипные ноды с одинаковым скриптом).
А как это можно не знать, если в самом начале узнаешь про инстансы сцен? (Это однотипные ноды с одинаковым скриптом).
>>6568
Автороскрытие ресурсов. Они до сих пор не понимают что можно сделать лучше. Мне новичку до сих пор это все не очевидно, а автора скрытие будет раздражать.
Автороскрытие ресурсов. Они до сих пор не понимают что можно сделать лучше. Мне новичку до сих пор это все не очевидно, а автора скрытие будет раздражать.
>>6570
Это интересно, спасибо.
Это интересно, спасибо.
>>6573
Там два разных CPUParticles2D (более того две разных сцены) имеют один скрипт на двоих. Получается что они расширяют скрипт, а не скрипт их ("is-a" наоборот, поэтому стрелки к картинке были к скрипту). В общем, забей, тут люди еще композицию вспомнили "relationship" в программирование и так мозгодробительная тема для срачей, нахер её, оставим её в 2010.
Вот как раз можно сделать как компоненты только нодами (получается даже гибче). Ну типа ты прикрепляешь ноды-компоненты типа health, weapon, movement. Более того твои компоненты даже в списке появляются при создании нод (как Node2D, или там StaticBody2D). Еще есть свойство/поле "owner" что тоже дает пишу для компонентов.
Но, проводя мысленный эксперимент в голове, все это ощущается как херня. В общем, это тоже абстрактная тема для срача, но я вижу людями нравятся компонентных подход. Они даже переживают за количество нод и тестируют производительность
https://www.youtube.com/watch?v=PWHxoAYmyLM
На самом деле компоненты/сервисы нужно делать по другому.
Там два разных CPUParticles2D (более того две разных сцены) имеют один скрипт на двоих. Получается что они расширяют скрипт, а не скрипт их ("is-a" наоборот, поэтому стрелки к картинке были к скрипту). В общем, забей, тут люди еще композицию вспомнили "relationship" в программирование и так мозгодробительная тема для срачей, нахер её, оставим её в 2010.
>В Godot из коробки нет прямого аналога "компонентов GameObject" из Unity.
Вот как раз можно сделать как компоненты только нодами (получается даже гибче). Ну типа ты прикрепляешь ноды-компоненты типа health, weapon, movement. Более того твои компоненты даже в списке появляются при создании нод (как Node2D, или там StaticBody2D). Еще есть свойство/поле "owner" что тоже дает пишу для компонентов.
Но, проводя мысленный эксперимент в голове, все это ощущается как херня. В общем, это тоже абстрактная тема для срача, но я вижу людями нравятся компонентных подход. Они даже переживают за количество нод и тестируют производительность
https://www.youtube.com/watch?v=PWHxoAYmyLM
На самом деле компоненты/сервисы нужно делать по другому.
>>6570
Можно просто пользоваться нодой таймер.
Можно просто пользоваться нодой таймер.
>>6583
Можно делать через серверы и RID, так и поленился освоить, не пригодилось за уже лет 6.
>На самом деле компоненты/сервисы нужно делать по другому.
Можно делать через серверы и RID, так и поленился освоить, не пригодилось за уже лет 6.
>>6586
Если ты про те серверы годота, то я тоже краем глаза пробежался. Годот очень гибкий, но это слишком низкий уровень, я же просто про взаимодействие.
На самом деле для программного модуля нам нужен только контракт (синтаксис для него). У нас нет "классов" интерфейсов как в других языках, но годот дает сигналы (ну и почти все языки дают сигнатуры методов, кроме жопоскрипта).
Что такое компонент - это просто Нода (Ноды) со скриптом которая добавляет поведение объекту. И как-будто все располагает к тому чтобы использовать именно этот подход. Вместо тотальных менеджеров и сервисов.
Да это одна из реализаций композиции/агрегации "has-a", но так как мы не в контексте классов и их отношений, мне кажется правильно использовать слово компонент. Например никто в здравом уме не вспомнит про композицию в контексте middleware сервера, но многие назовут их компонентами. Но кому не пофиг, слушаю гениев с ютуба они там постоянно эту композицию вспоминают, хотя у нас дерево нодов
Если ты про те серверы годота, то я тоже краем глаза пробежался. Годот очень гибкий, но это слишком низкий уровень, я же просто про взаимодействие.
На самом деле для программного модуля нам нужен только контракт (синтаксис для него). У нас нет "классов" интерфейсов как в других языках, но годот дает сигналы (ну и почти все языки дают сигнатуры методов, кроме жопоскрипта).
Что такое компонент - это просто Нода (Ноды) со скриптом которая добавляет поведение объекту. И как-будто все располагает к тому чтобы использовать именно этот подход. Вместо тотальных менеджеров и сервисов.
Да это одна из реализаций композиции/агрегации "has-a", но так как мы не в контексте классов и их отношений, мне кажется правильно использовать слово компонент. Например никто в здравом уме не вспомнит про композицию в контексте middleware сервера, но многие назовут их компонентами. Но кому не пофиг, слушаю гениев с ютуба они там постоянно эту композицию вспоминают, хотя у нас дерево нодов
>>6583
А, я понял твою ошибку. Описанные тобой "разные ноды/сцены" - это, на самом деле, не настоящие объекты, а только описание/инструкция/запрос к движку о создании необходимых экземпляров с определёнными настройками в будущем, когда придёт время создавать реальные объекты. Думай об этом как о кулинарном рецепте, по которому повар готовит конкретный экземпляр еды из имеющихся у него ингредиентов; рецепт еды существует сам по себе, и по одному рецепту можно создать много экземпляров. Если знаешь HTML и CSS, то понять сцены должно быть проще: считай все "ноды" внутри "сцен" - всего лишь тегами HTML, как <div>. Когда ты пишешь в HTML <div>, ты не создаёшь блок-объект, а только описываешь инструкцию браузеру, по которой он в будущем создаст блок, применит к нему какой-то CSS стиль (соответствующий заданному классу блока) и заполнит его указанным текстом или другими блоками. В общем, TSCN - это как HTML - декларативный язык, не имеющий ничего общего с императивными языками (включая языки с ООП).
Короче:
- Ты создаёшь не сцены и ноды, а описываешь декларативные запросы для движка.
- Движок берёт твои запросы и пытается удовлетворить их в силу своих возможностей.
- Часть этих запросов является "расширением" уже имеющихся у движка возможностей.
- Один "расширитель возможностей" можно применить во многих независимых запросах.
Кулинарный пример: есть рецепт "бутерброда", и повар знает, где найти ингредиенты, но не знает, как приготовить "яичницу", а мы использовали в составе "бутерброда" "яичницу" - чтобы повар приготовил "бутерброд", нам нужно "расширить" его возможности дополнительным описанием того, как именно готовится "яичница" - "взять яйца, разбить над сковородой..." и так далее. Но мы можем использовать "расширение" "яичница" не только в рецепте "бутерброда", но и в рецепте "макарон". Мы можем попросить приготовить и "бутерброд", и "макароны", и в обоих случаях повар использует "яичницу", которая никому не принадлежит, но "расширяет" имеющиеся у повара возможности.
Так понятнее?
>...разные сцены имеют один скрипт на двоих. Получается что они расширяют скрипт...
А, я понял твою ошибку. Описанные тобой "разные ноды/сцены" - это, на самом деле, не настоящие объекты, а только описание/инструкция/запрос к движку о создании необходимых экземпляров с определёнными настройками в будущем, когда придёт время создавать реальные объекты. Думай об этом как о кулинарном рецепте, по которому повар готовит конкретный экземпляр еды из имеющихся у него ингредиентов; рецепт еды существует сам по себе, и по одному рецепту можно создать много экземпляров. Если знаешь HTML и CSS, то понять сцены должно быть проще: считай все "ноды" внутри "сцен" - всего лишь тегами HTML, как <div>. Когда ты пишешь в HTML <div>, ты не создаёшь блок-объект, а только описываешь инструкцию браузеру, по которой он в будущем создаст блок, применит к нему какой-то CSS стиль (соответствующий заданному классу блока) и заполнит его указанным текстом или другими блоками. В общем, TSCN - это как HTML - декларативный язык, не имеющий ничего общего с императивными языками (включая языки с ООП).
Короче:
- Ты создаёшь не сцены и ноды, а описываешь декларативные запросы для движка.
- Движок берёт твои запросы и пытается удовлетворить их в силу своих возможностей.
- Часть этих запросов является "расширением" уже имеющихся у движка возможностей.
- Один "расширитель возможностей" можно применить во многих независимых запросах.
Кулинарный пример: есть рецепт "бутерброда", и повар знает, где найти ингредиенты, но не знает, как приготовить "яичницу", а мы использовали в составе "бутерброда" "яичницу" - чтобы повар приготовил "бутерброд", нам нужно "расширить" его возможности дополнительным описанием того, как именно готовится "яичница" - "взять яйца, разбить над сковородой..." и так далее. Но мы можем использовать "расширение" "яичница" не только в рецепте "бутерброда", но и в рецепте "макарон". Мы можем попросить приготовить и "бутерброд", и "макароны", и в обоих случаях повар использует "яичницу", которая никому не принадлежит, но "расширяет" имеющиеся у повара возможности.
Так понятнее?
>>6583
А, я понял твою ошибку. Описанные тобой "разные ноды/сцены" - это, на самом деле, не настоящие объекты, а только описание/инструкция/запрос к движку о создании необходимых экземпляров с определёнными настройками в будущем, когда придёт время создавать реальные объекты. Думай об этом как о кулинарном рецепте, по которому повар готовит конкретный экземпляр еды из имеющихся у него ингредиентов; рецепт еды существует сам по себе, и по одному рецепту можно создать много экземпляров. Если знаешь HTML и CSS, то понять сцены должно быть проще: считай все "ноды" внутри "сцен" - всего лишь тегами HTML, как <div>. Когда ты пишешь в HTML <div>, ты не создаёшь блок-объект, а только описываешь инструкцию браузеру, по которой он в будущем создаст блок, применит к нему какой-то CSS стиль (соответствующий заданному классу блока) и заполнит его указанным текстом или другими блоками. В общем, TSCN - это как HTML - декларативный язык, не имеющий ничего общего с императивными языками (включая языки с ООП).
Короче:
- Ты создаёшь не сцены и ноды, а описываешь декларативные запросы для движка.
- Движок берёт твои запросы и пытается удовлетворить их в силу своих возможностей.
- Часть этих запросов является "расширением" уже имеющихся у движка возможностей.
- Один "расширитель возможностей" можно применить во многих независимых запросах.
Кулинарный пример: есть рецепт "бутерброда", и повар знает, где найти ингредиенты, но не знает, как приготовить "яичницу", а мы использовали в составе "бутерброда" "яичницу" - чтобы повар приготовил "бутерброд", нам нужно "расширить" его возможности дополнительным описанием того, как именно готовится "яичница" - "взять яйца, разбить над сковородой..." и так далее. Но мы можем использовать "расширение" "яичница" не только в рецепте "бутерброда", но и в рецепте "макарон". Мы можем попросить приготовить и "бутерброд", и "макароны", и в обоих случаях повар использует "яичницу", которая никому не принадлежит, но "расширяет" имеющиеся у повара возможности.
Так понятнее?
>...разные сцены имеют один скрипт на двоих. Получается что они расширяют скрипт...
А, я понял твою ошибку. Описанные тобой "разные ноды/сцены" - это, на самом деле, не настоящие объекты, а только описание/инструкция/запрос к движку о создании необходимых экземпляров с определёнными настройками в будущем, когда придёт время создавать реальные объекты. Думай об этом как о кулинарном рецепте, по которому повар готовит конкретный экземпляр еды из имеющихся у него ингредиентов; рецепт еды существует сам по себе, и по одному рецепту можно создать много экземпляров. Если знаешь HTML и CSS, то понять сцены должно быть проще: считай все "ноды" внутри "сцен" - всего лишь тегами HTML, как <div>. Когда ты пишешь в HTML <div>, ты не создаёшь блок-объект, а только описываешь инструкцию браузеру, по которой он в будущем создаст блок, применит к нему какой-то CSS стиль (соответствующий заданному классу блока) и заполнит его указанным текстом или другими блоками. В общем, TSCN - это как HTML - декларативный язык, не имеющий ничего общего с императивными языками (включая языки с ООП).
Короче:
- Ты создаёшь не сцены и ноды, а описываешь декларативные запросы для движка.
- Движок берёт твои запросы и пытается удовлетворить их в силу своих возможностей.
- Часть этих запросов является "расширением" уже имеющихся у движка возможностей.
- Один "расширитель возможностей" можно применить во многих независимых запросах.
Кулинарный пример: есть рецепт "бутерброда", и повар знает, где найти ингредиенты, но не знает, как приготовить "яичницу", а мы использовали в составе "бутерброда" "яичницу" - чтобы повар приготовил "бутерброд", нам нужно "расширить" его возможности дополнительным описанием того, как именно готовится "яичница" - "взять яйца, разбить над сковородой..." и так далее. Но мы можем использовать "расширение" "яичница" не только в рецепте "бутерброда", но и в рецепте "макарон". Мы можем попросить приготовить и "бутерброд", и "макароны", и в обоих случаях повар использует "яичницу", которая никому не принадлежит, но "расширяет" имеющиеся у повара возможности.
Так понятнее?
1,2 Мб, 1000x1000>>6598
Ой, ты продолжаешь эту тягомотину еще и пассивно-агрессивно.
Даже читать не хочу, вместо того чтобы вникнуть в суть что скрипт ведёт себя как ресурс (например одна текстура на разных объектах) и в случае кода это меняет (переворачивает) отношение "is-a", ты втираешь мне какую-то графоманию.
Просто еще одна возможность годот - гибко, классно и чуток уличной магии.
Ой, ты продолжаешь эту тягомотину еще и пассивно-агрессивно.
Даже читать не хочу, вместо того чтобы вникнуть в суть что скрипт ведёт себя как ресурс (например одна текстура на разных объектах) и в случае кода это меняет (переворачивает) отношение "is-a", ты втираешь мне какую-то графоманию.
Просто еще одна возможность годот - гибко, классно и чуток уличной магии.
.gdignore - где оно было раньше в моей памяти? Наконец-то весь "хлам" у меня в одном проекте.
>>6600
Оно всегда было на месте
Оно всегда было на месте
>>6583
>>6597
Делай как считаешь нужным, где считаешь нужным.
Делать так по всему проекту будет нецелесообразно.
>>6599
Это кто тут из нас пассивно-агрессивный, лол?
Конечно, в документации можешь почитать об этом подробнее:
https://docs.godotengine.org/en/stable/classes/class_script.html
В смысле? Не вижу противоречий. Допустим, такой код:
Здесь три скрипта расширяют один класс нод Area2D.
И ЛЮБОЕ число экземпляров несут эти скрипты.
Но все три скрипта имеют отношение "is a".
Так в чём же твоя проблема? Что не так?
>ноды-компоненты типа health, weapon, movement
>>6597
>Нода со скриптом которая добавляет поведение
Делай как считаешь нужным, где считаешь нужным.
Делать так по всему проекту будет нецелесообразно.
>>6599
>...пассивно-агрессивно. Даже читать не хочу...
Это кто тут из нас пассивно-агрессивный, лол?
>вникнуть в суть что скрипт ведёт себя как ресурс
Конечно, в документации можешь почитать об этом подробнее:
https://docs.godotengine.org/en/stable/classes/class_script.html
>переворачивает отношение "is-a"
В смысле? Не вижу противоречий. Допустим, такой код:
>class_name Actor extends Area2D ...
>class_name Bullet extends Area2D ...
>class_name Zone extends Area2D ...
>func _on_area_entered(area: Area2D) -> void:
>_ if area is Actor: ...
>_ elif area is Bullet: ...
>_ elif area is Zone: ...
Здесь три скрипта расширяют один класс нод Area2D.
И ЛЮБОЕ число экземпляров несут эти скрипты.
Но все три скрипта имеют отношение "is a".
Так в чём же твоя проблема? Что не так?
>>6603
Я булочка.
А вообще я не знаю что сделать.
Ты не ты, когда у тебя нет проекта мечты
>Так в чём же твоя проблема?
Я булочка.
А вообще я не знаю что сделать.
Ты не ты, когда у тебя нет проекта мечты
Гайс, короче, есть у меня multimesh листьев. Через скрипт создаётся массив shape_rids: Dictionary[RID, int], ключ - ссылка на рид коллизии, значение - индекс экземпляра. Все через рендеринг и физикс сервера...Короче тра-та-та - три рубля и у нас текстура/цвет каждого экземпляра меняется по нажатию на определённую коллизию. ТАК ВОТ, допустим листья в шейдере имитирует ветерок. Как мне двигать коллизии совместно с ветерком? Или предложите ваши варианты реализации
>>6621
Пока писал, понял, что раз через скрипт считать похожую математику - убийство проца, значит надо как-то изымать то, что уже посчитано из шейдера ветра. Как изымать то блять? В текстуру писать, а потом как-то её считывать?
Пока писал, понял, что раз через скрипт считать похожую математику - убийство проца, значит надо как-то изымать то, что уже посчитано из шейдера ветра. Как изымать то блять? В текстуру писать, а потом как-то её считывать?
>>6624
Я с мультимешем никогда не работал, хз зачем там коллизии вообще. Я бы задавал вектор направления ветра кодом и уже по нему двигались бы листья и рисовался шейдер.
Я с мультимешем никогда не работал, хз зачем там коллизии вообще. Я бы задавал вектор направления ветра кодом и уже по нему двигались бы листья и рисовался шейдер.
>>6533
отдаю гениальную идею. мегабонк лайк, только управляешь самолетиком, управление казуальное. летаешь по мегаструктурам, дрон в гигахруще, х-винг в звезде смерти, бумажный самолетик в двухэтажном домике субурбии. короче сеттингов дохера можно че придумать. геймплейно чисто мегабонк, только полноценная вертикальная ось перемещения есть.
отдаю гениальную идею. мегабонк лайк, только управляешь самолетиком, управление казуальное. летаешь по мегаструктурам, дрон в гигахруще, х-винг в звезде смерти, бумажный самолетик в двухэтажном домике субурбии. короче сеттингов дохера можно че придумать. геймплейно чисто мегабонк, только полноценная вертикальная ось перемещения есть.
>>6628
Ну представь если листьев хотя бы тысяча. И как бы листья не должны двигаться все одинаково (а ещё следовать за веткой на которой висят лол).
Ну представь если листьев хотя бы тысяча. И как бы листья не должны двигаться все одинаково (а ещё следовать за веткой на которой висят лол).
>>6632
Повторюсь что никогда не работал с мультимешем. Чуть рандомное движение можно сделать кодом, движение листьев и веток в целом через parent-child отношения и код на каждом листе. Но в играх обычно так не делают. Там листва что-то типо 2д текстур например крест накрест с листьями и пустотой через альфу на каждой ветке - объектов немного по факту.
Повторюсь что никогда не работал с мультимешем. Чуть рандомное движение можно сделать кодом, движение листьев и веток в целом через parent-child отношения и код на каждом листе. Но в играх обычно так не делают. Там листва что-то типо 2д текстур например крест накрест с листьями и пустотой через альфу на каждой ветке - объектов немного по факту.
>>6621
Не проще анимацию ебануть тогда
Не проще анимацию ебануть тогда
>>6632
Если это инстансы одного меша, видеокарта без труда отрисовывает миллионы за кадр, под разными координатами и углами поворота. В этом суть и смысл видеокарты - лютое звериное распараллеливание графической отрисовки.
> Ну представь если листьев хотя бы тысяча.
Если это инстансы одного меша, видеокарта без труда отрисовывает миллионы за кадр, под разными координатами и углами поворота. В этом суть и смысл видеокарты - лютое звериное распараллеливание графической отрисовки.
>>6630
Оп-па, изи миллион долларов.
Да не, мне бы что-то типа нескучного 2Д РПГ, стратежечки, выживача, крафтача, собирательства, может веселое turn-based. И главное минимум анимации и рисования, чтобы игра была в глубину, а не про визуал (и игроки это выкупали, погружало).
Типа из серии "посмотри на эту игру Х" и я такой "омайгад, да это то что я хочу, заверните две защеку ".
Оп-па, изи миллион долларов.
Да не, мне бы что-то типа нескучного 2Д РПГ, стратежечки, выживача, крафтача, собирательства, может веселое turn-based. И главное минимум анимации и рисования, чтобы игра была в глубину, а не про визуал (и игроки это выкупали, погружало).
Типа из серии "посмотри на эту игру Х" и я такой "омайгад, да это то что я хочу, заверните две защеку ".
>>6533
2д хентай рпг в стиле белоснежки и гномов но играешь за гномов и рейпуешь всё что движется своим сквадом.
2д хентай рпг в стиле белоснежки и гномов но играешь за гномов и рейпуешь всё что движется своим сквадом.
>>6533
Вид сверху, одноэкранный геймплей. Каждый экран это отдельная головоломка, далее (арена). На экране размещены стены и проходы по которым игрок может перемещать персонажа. В проходах компьютер передвигает врагов с несложным интеллектом, уровня "вижу - преследую, потерял из виду - прогулялся до точки, где видел в последний раз, и если за всё это время не увидел цель, то иду по своим делам". Персонаж имеет в инвентаре различные виды и типы ловушек, которые может устанавливать в проходах. На разных врагов действуют разные виды ловушек. Из врагов выпадает лут, который можно использовать для крафта ловушек, и для продажи/обмена в магазине на детали и чертежи новых ловушек. Арены могут быть оформлены, как катакомбы, пещеры, лесная чаща, городская заброшка, для разнообразия и удержания.
Воот. А если нужен всё таки лор, то в лоротреде: >>708991 →
> Насыпьте идей. геймплейных
Вид сверху, одноэкранный геймплей. Каждый экран это отдельная головоломка, далее (арена). На экране размещены стены и проходы по которым игрок может перемещать персонажа. В проходах компьютер передвигает врагов с несложным интеллектом, уровня "вижу - преследую, потерял из виду - прогулялся до точки, где видел в последний раз, и если за всё это время не увидел цель, то иду по своим делам". Персонаж имеет в инвентаре различные виды и типы ловушек, которые может устанавливать в проходах. На разных врагов действуют разные виды ловушек. Из врагов выпадает лут, который можно использовать для крафта ловушек, и для продажи/обмена в магазине на детали и чертежи новых ловушек. Арены могут быть оформлены, как катакомбы, пещеры, лесная чаща, городская заброшка, для разнообразия и удержания.
Воот. А если нужен всё таки лор, то в лоротреде: >>708991 →
>>6644
Ладно, дайте годный туториал на ютубах/текстах. Который вам зашел. Пофиг на какую тему, главное чтобы был запас продолжить развивать (не эти всякие арканоиды/тетрисы/змейки, а с замахом - с потенцивалом).
Ладно, дайте годный туториал на ютубах/текстах. Который вам зашел. Пофиг на какую тему, главное чтобы был запас продолжить развивать (не эти всякие арканоиды/тетрисы/змейки, а с замахом - с потенцивалом).
226 Кб, 500x637>>6646
Чел. Вот тебе насчет замаха, пикрелейтед. А туториал бери Брекиса https://www.youtube.com/watch?v=LOhfqjmasi0 это признанный спец в геймдеве, перекатился в Годот от конкурирующей фирмы.
Чел. Вот тебе насчет замаха, пикрелейтед. А туториал бери Брекиса https://www.youtube.com/watch?v=LOhfqjmasi0 это признанный спец в геймдеве, перекатился в Годот от конкурирующей фирмы.
>>6645
Кстати, нечто такое думал. Типа в обычной местности гриндишь на расходки (по большей части как раз ловушки), а в данжах пытаешься выжить, враги очень сильные, без расходок не вариант, нападают даже со спины (откуда пришел). Естественно есть мотивация идти в данжи. И именно замысел в тактику, а не в реакцию.
Но фантазии не хватает сделать так, чтобы это не надоело за 2-5 часов. Нужна какая-то психологическая кормежка помимо тиров снаряжения и прокачки.
Кстати, нечто такое думал. Типа в обычной местности гриндишь на расходки (по большей части как раз ловушки), а в данжах пытаешься выжить, враги очень сильные, без расходок не вариант, нападают даже со спины (откуда пришел). Естественно есть мотивация идти в данжи. И именно замысел в тактику, а не в реакцию.
Но фантазии не хватает сделать так, чтобы это не надоело за 2-5 часов. Нужна какая-то психологическая кормежка помимо тиров снаряжения и прокачки.
>>6649
Этой психологической кормёжко и является лор. Геймплей и лор тесно взаимосвязаны и питают друг друга. Мы об этом в прошлых тредах много обсуждали. Вот например, анон, который пилит игору про летающие острова и фигуристую эльфийку, он сторонник первичности геймплея, и считает, что лор следует выводить из геймплея. А я с ним не согласен, и то что он постоянно прокрастинирует воспринимаю как пруф моей точки зрения ->
Этой психологической кормёжко и является лор. Геймплей и лор тесно взаимосвязаны и питают друг друга. Мы об этом в прошлых тредах много обсуждали. Вот например, анон, который пилит игору про летающие острова и фигуристую эльфийку, он сторонник первичности геймплея, и считает, что лор следует выводить из геймплея. А я с ним не согласен, и то что он постоянно прокрастинирует воспринимаю как пруф моей точки зрения ->
> Геймплей и лор тесно взаимосвязаны и питают друг друга.
>>6649
Всмпомнил.
Потом я поиграл в какую-то игру и понял что расходки очень утомляют, а всякие статы одежды или артефактов смотрятся куда приятнее. В общем, утомляет подготовка перед данжем и гринд перед данжем и заходят только ультимативные расходки.
Всмпомнил.
Потом я поиграл в какую-то игру и понял что расходки очень утомляют, а всякие статы одежды или артефактов смотрятся куда приятнее. В общем, утомляет подготовка перед данжем и гринд перед данжем и заходят только ультимативные расходки.
>>6651
Ну я считаю что первична психология "действие - награда". Даже если создание игры/приложения разбиваешь на мелкие достижимые цели, меньше мотивацию теряешь. Лор и тексты вот тоже не мое. Мне интересен лор - если интересна игра/геймплей.
В eve есть такой типаж людей (я один из них), которые занимаются накопительством (не только местной валюты но и покупка кораблей и прочего). Но это работает только потому, что есть большой диапазон когда деньги имеют ценность, даже если их очень много (как и в жизни).
Противоположный пример. В стоуншарде есть тиры одежды 600, 1500, 4000, 8000$. То есть, у тебя накапливаются деньги, а тратить некуда (нет контента), в итоге разработчики размазали ценность экипировки и ремонта. Доходит до абсурда - что не выгодно бочки разбивать в данже, из-за дорого ремонта (а бочки/сундуки это же основной "удлинитель" данжей). И если найдешь на раннем этапе высокой тир снаряжения, ты с трудом сможешь его окупить. Это ппц дыра геймдизайна, на стримах люди радуются ивенту ярмарки, где можно купить +тир снаряжения, но при этом она становиться абузой (статов дает тоже не особо много).
Ну я считаю что первична психология "действие - награда". Даже если создание игры/приложения разбиваешь на мелкие достижимые цели, меньше мотивацию теряешь. Лор и тексты вот тоже не мое. Мне интересен лор - если интересна игра/геймплей.
В eve есть такой типаж людей (я один из них), которые занимаются накопительством (не только местной валюты но и покупка кораблей и прочего). Но это работает только потому, что есть большой диапазон когда деньги имеют ценность, даже если их очень много (как и в жизни).
Противоположный пример. В стоуншарде есть тиры одежды 600, 1500, 4000, 8000$. То есть, у тебя накапливаются деньги, а тратить некуда (нет контента), в итоге разработчики размазали ценность экипировки и ремонта. Доходит до абсурда - что не выгодно бочки разбивать в данже, из-за дорого ремонта (а бочки/сундуки это же основной "удлинитель" данжей). И если найдешь на раннем этапе высокой тир снаряжения, ты с трудом сможешь его окупить. Это ппц дыра геймдизайна, на стримах люди радуются ивенту ярмарки, где можно купить +тир снаряжения, но при этом она становиться абузой (статов дает тоже не особо много).
>>6658
Да, еще я бездарный. Когда играешь в игры или редактируешь моды - ты как будто чувствуешь где надо что-то поменять, сколько подкрутить. Ощущаешь - блин, да я шарю, пора делать игру. Но когда делаешь игру - ты такой - какая же поверхностная и унылая шляпа получается.
Поныл.
Да, еще я бездарный. Когда играешь в игры или редактируешь моды - ты как будто чувствуешь где надо что-то поменять, сколько подкрутить. Ощущаешь - блин, да я шарю, пора делать игру. Но когда делаешь игру - ты такой - какая же поверхностная и унылая шляпа получается.
Поныл.
>>6641
ну для начала укради мою идею, уже +миллион долларов в кармане. а дальше можешь уже вообще че хочешь делать, и даже если поймешь, что идея сложная или нет идей, то сможешь нанять кого-то
ну для начала укради мою идею, уже +миллион долларов в кармане. а дальше можешь уже вообще че хочешь делать, и даже если поймешь, что идея сложная или нет идей, то сможешь нанять кого-то
>>6640
Дело не в количестве полигонов, а скорее в:
1. Если каждый лист - нода, то полное гавно (дерево сцены засрано фигней). Если нет (тоже через RenderingServer например), то какая тогда разница?
2. Представь считать ветерок для каждого такого объекта (в physics_process например) - нахуя?
В общем легче через шейдер ветер считать, просто как-то высрать эту инфу обратно надо. А ещё можно через шейдер считать расстояние для вершин и если больше чего-то- не считать, а значит не считать и для коллизий.
Дело не в количестве полигонов, а скорее в:
1. Если каждый лист - нода, то полное гавно (дерево сцены засрано фигней). Если нет (тоже через RenderingServer например), то какая тогда разница?
2. Представь считать ветерок для каждого такого объекта (в physics_process например) - нахуя?
В общем легче через шейдер ветер считать, просто как-то высрать эту инфу обратно надо. А ещё можно через шейдер считать расстояние для вершин и если больше чего-то- не считать, а значит не считать и для коллизий.
>>6666
Не надо, сотона. Шейдер уже расставляет по местам инстансы мультимеша. То есть, ты шейдеру подаёшь на вход направление и силу ветра, и он там уже дирижирует инстансами. Ничего тебе оттуда возвращать не надо. Если тебе надо, чтобы на ветру синхронно шевелился отдельный от мультимеша объект, то ты просто подаёшь ему те же самые входные данные и убеждаешься, что у него такая же логика, как у мультимешевого шейдера. Понял, сотона?
> через шейдер ветер считать, просто как-то высрать эту инфу обратно надо
Не надо, сотона. Шейдер уже расставляет по местам инстансы мультимеша. То есть, ты шейдеру подаёшь на вход направление и силу ветра, и он там уже дирижирует инстансами. Ничего тебе оттуда возвращать не надо. Если тебе надо, чтобы на ветру синхронно шевелился отдельный от мультимеша объект, то ты просто подаёшь ему те же самые входные данные и убеждаешься, что у него такая же логика, как у мультимешевого шейдера. Понял, сотона?
>>6678
Хз чем я тогда занимался, но точно не геймдевом.
Интересно, godot/gscript потянет что-то типа факторио?
>4 года назад я предлагал тебе помощь
Хз чем я тогда занимался, но точно не геймдевом.
Интересно, godot/gscript потянет что-то типа факторио?
>>6698
Ну типа там же фишка в том что тысячи объектов рисуются одним вызовом (не помню как это называется, но в годоте точно это есть)
>Интересно, godot/gscript потянет что-то типа факторио?
Ну типа там же фишка в том что тысячи объектов рисуются одним вызовом (не помню как это называется, но в годоте точно это есть)
Сатисфактори вдохновлен Факторио
Факторио вдохновлен модом GregTech для Майнкрафта
GregTech естественно вдохновлен Майнкрафтом
Майкрафт частично вдохновлен Dwarf Fortress
Живите с этим.
Факторио вдохновлен модом GregTech для Майнкрафта
GregTech естественно вдохновлен Майнкрафтом
Майкрафт частично вдохновлен Dwarf Fortress
Живите с этим.
>>6712
Все вдохновлено чем-то. Што теперь, не жить с этим?
Все вдохновлено чем-то. Што теперь, не жить с этим?
472 Кб, mp4,268x480, 0:10
>>6753
Тут другого и не делают
Тут другого и не делают
>>6676
Ну так, мне надо применить ту же логику для объектов коллизии. А через gdscript считать ту же логику что и в шейдере - смерти подобно. Поэтому я и подумал что можно то что уже посчитано вернуть и применить.
Ну так, мне надо применить ту же логику для объектов коллизии. А через gdscript считать ту же логику что и в шейдере - смерти подобно. Поэтому я и подумал что можно то что уже посчитано вернуть и применить.
Открываю туториал 2Д РПГ.
Анимация 6 кадров. Автор 30минут долбиться в AnimationTree со смешиванием анимации.
Ппц дурка.
Анимация 6 кадров. Автор 30минут долбиться в AnimationTree со смешиванием анимации.
Ппц дурка.
>>6621
Жаль, никто раньше не вспомнил, у тебя
https://ru.wikipedia.org/wiki/Проблема_XY
1. Что у тебя за игра? Симулятор огорода?
2. Сколько таких деревьев будет на сцене?
3. Тебе точно каждый лист нужно щупать?
Жаль, никто раньше не вспомнил, у тебя
https://ru.wikipedia.org/wiki/Проблема_XY
1. Что у тебя за игра? Симулятор огорода?
2. Сколько таких деревьев будет на сцене?
3. Тебе точно каждый лист нужно щупать?
587 Кб, 1024x977>>6810
Анимации это таймсинк. Либо все на твинах, либо игра должна быть задизайнена без анимаций вообще.
Принес вам гопоняху, кстати. Делайте игры.
Анимации это таймсинк. Либо все на твинах, либо игра должна быть задизайнена без анимаций вообще.
Принес вам гопоняху, кстати. Делайте игры.
191 Кб, 512x512>>6810
Вспомнил как я впервые решил сделать 3д игру. Ебался с этим animationtree вечность, чтобы просто смешать переходы анимации между стойкой, бегом и прыжком. А потом через пару месяцев заметил что у animationplayer.play() есть custom_blend и я тогда мог добиться желаемого за 5 наносек
Вспомнил как я впервые решил сделать 3д игру. Ебался с этим animationtree вечность, чтобы просто смешать переходы анимации между стойкой, бегом и прыжком. А потом через пару месяцев заметил что у animationplayer.play() есть custom_blend и я тогда мог добиться желаемого за 5 наносек
>>6826
Симулятор шизофреника, который через решетку окна щупает листочки? Ппц идиотия, не могут игру описать нормально, сиди телепатируй.
Симулятор шизофреника, который через решетку окна щупает листочки? Ппц идиотия, не могут игру описать нормально, сиди телепатируй.
>>6834
Пздц идиотия это спрашивать про что игра. Какая нахуй разница? Если я опишу игру - сразу появится элегантное/лучшее решение? Есть задумка - появилась проблема - нужно решение. Всё просто. Сколько ни читаю форумы подобные этому, всегда находится умник, который спрашивает "а нахуя?"
Да, представь себе, мне надо сквозь решётку окна щупать листочки. Дальше то что скажешь? Наверно то же, что и всегда пишут тебе подобные - не делай. Ну так и понятно, что игр нет и не будет.
Пздц идиотия это спрашивать про что игра. Какая нахуй разница? Если я опишу игру - сразу появится элегантное/лучшее решение? Есть задумка - появилась проблема - нужно решение. Всё просто. Сколько ни читаю форумы подобные этому, всегда находится умник, который спрашивает "а нахуя?"
Да, представь себе, мне надо сквозь решётку окна щупать листочки. Дальше то что скажешь? Наверно то же, что и всегда пишут тебе подобные - не делай. Ну так и понятно, что игр нет и не будет.
>>6845
Я не он, но так что за игра-то?
Я не он, но так что за игра-то?
>>6834
Слыш, добрее будь, он всё что надо уже описал:
>>6826
Окей, анон, вот тебе план:
1. Забей пока на этот MultiMesh, на RIDы, на Dictionary и т.д.
2. Слепи по-быстрому сцену leaf.tscn с Area3D и MeshInstance3D.
3. Замути прототип своей игры про одно дерево с тыщей листьев.
4. Поиграй и оцени ощущения, игнорируя производительность.
5. ???
6. Выбрасывай сделанное и:
6.а. Если вышло норм: переделывай всё оптимальнее.
6.б. Если вышло КГ/АМ: просто забей и ищи идею лучше.
Или ты уже прошёл всё это и теперь ищешь оптимальные пути?
Если так, тогда нам потребуется больше информации об игре.
>не могут игру описать нормально
Слыш, добрее будь, он всё что надо уже описал:
>>6826
>2. Такое дерево одно.
>3. Точно нужно щупать прям каждый листок.
Окей, анон, вот тебе план:
1. Забей пока на этот MultiMesh, на RIDы, на Dictionary и т.д.
2. Слепи по-быстрому сцену leaf.tscn с Area3D и MeshInstance3D.
3. Замути прототип своей игры про одно дерево с тыщей листьев.
4. Поиграй и оцени ощущения, игнорируя производительность.
5. ???
6. Выбрасывай сделанное и:
6.а. Если вышло норм: переделывай всё оптимальнее.
6.б. Если вышло КГ/АМ: просто забей и ищи идею лучше.
Или ты уже прошёл всё это и теперь ищешь оптимальные пути?
Если так, тогда нам потребуется больше информации об игре.
>>6861
Да я как-бы сделал основное, мультимеш, коллизии и прочее. Но вот я подумал что нихуево бы ветер добавить.
По опыту знаю, что через скрипт это все считать - плохая идея.
Подумывал про compute shader, но я как-то туда влез и кроме ебанутого пост процесс эффекта ничего путного сделать не смог (было лень разбираться дальше).
А так, если форма коллизии и форма меша одинаковая то принцип прост:
1. Какой-то словарь, коллизия: индекс_экземпляра.
2. Функция ветра в шейдере мультимеша.
3. Запись пикселя каждой вершины в пиксель текстуры.
4. Привязка текстуры в subviewport.
5. Чтение текстуры. Сколько то вершин проходим (например 5 для листа), эти пиксели - позиции вершин в пространстве (r-x, g-y, b-z) и забиваем в какой-то массив .
6. Проходим по всем экземплярам мультимеша и по нашему словарю сдвигаем вершины коллизий.
Да я как-бы сделал основное, мультимеш, коллизии и прочее. Но вот я подумал что нихуево бы ветер добавить.
По опыту знаю, что через скрипт это все считать - плохая идея.
Подумывал про compute shader, но я как-то туда влез и кроме ебанутого пост процесс эффекта ничего путного сделать не смог (было лень разбираться дальше).
А так, если форма коллизии и форма меша одинаковая то принцип прост:
1. Какой-то словарь, коллизия: индекс_экземпляра.
2. Функция ветра в шейдере мультимеша.
3. Запись пикселя каждой вершины в пиксель текстуры.
4. Привязка текстуры в subviewport.
5. Чтение текстуры. Сколько то вершин проходим (например 5 для листа), эти пиксели - позиции вершин в пространстве (r-x, g-y, b-z) и забиваем в какой-то массив .
6. Проходим по всем экземплярам мультимеша и по нашему словарю сдвигаем вершины коллизий.
>>6870
3. Запись позиции* каждой вершины в пиксель текстуры.
3. Запись позиции* каждой вершины в пиксель текстуры.
>>6870
Я где-то читал, что так еще в 3 годоте делали. Шейдер (не компьют) рисует, а потом ты просто и вьюпорт текстуры читаешь. Но, это не быстро будет.
Когда делал волны на водичке, там еще другой прием был. Если у тебя ветер по формуле, типа синуса, то ничего передавать и не надо - ты можешь для любого t вычислить и на стороне шейдера, и на стороне процессора.
Я где-то читал, что так еще в 3 годоте делали. Шейдер (не компьют) рисует, а потом ты просто и вьюпорт текстуры читаешь. Но, это не быстро будет.
Когда делал волны на водичке, там еще другой прием был. Если у тебя ветер по формуле, типа синуса, то ничего передавать и не надо - ты можешь для любого t вычислить и на стороне шейдера, и на стороне процессора.
>>6870
Сначала ты такой:
А потом ты такой:
Ты хоть для начала пробовал сделать "ветер через скрипт" и записать конкретные затраты времени по профайлеру, или сразу бросился писать "в шейдере со считыванием текстуры"? Потому что "вычисление ветра" - это пустяк по сравнению с задержками GPU <-> CPU, которые ты тут добавляешь два раза - сперва задавая ветер с CPU на GPU, потом выгружая значения с GPU в CPU, и применяя их для смещения своих коллизий, что, в твоём случае, в любом случае должно быть наиболее затратной операцией.
У тебя бутылочное горлышко - это количество CollisionShape3D и их трансформации в пространстве, из-за которых физическому движку (который на C++) придётся обновлять свои кэши и прочие формулы (не знаю подробностей), а не вычисление ветра, так что забудь о шейдерах, они только сбивают тебя с твоей цели.
В общем. Я почему спрашиваю о геймплее твоей игры: насколько тебе важна точность коллизий, и насколько далеко могут колебаться листья? Игрок должен попасть мышкой прям точно в листочек, или лучше будет, чтобы зона коллизии была шире листочка раза в 2-3 от его диаметра? И должен ли вообще игрок попадать в каждый листок, или, быть может, лучше будет хапать сразу несколько разом? Потому что в реалистичном дереве листья сидят очень плотно (даже у комнатных растений), и коллизии будут неизбежно перекрывать друг друга. А может, у тебя там вообще не дерево с листьями, и ты таким образом пытаешься скрыть истинный (постыдный/неприличный) замысел игры? Условно, волосинки на коже и листья на дереве - это разные задачи с, вероятно, разными путями оптимизации.
А, и о ветре: что ты там такого сложного вычисляешь, что тебе GDScript не хватает? По идее, для спонтанных порывов ветра достаточно будет брать значения из Noise3D, постепенно смещаясь относительно центра, возможно, накинув на это значение sin() или cos().
Также зависит от того, нужен ли тебе реализм, или у тебя мидполи/лоуполи стилизация.
Сначала ты такой:
>через скрипт [ветер] считать - плохая идея
А потом ты такой:
>Запись пикселя каждой вершины в пиксель текстуры
>Чтение текстуры. Сколько то вершин проходим
>словарю сдвигаем вершины коллизий
Ты хоть для начала пробовал сделать "ветер через скрипт" и записать конкретные затраты времени по профайлеру, или сразу бросился писать "в шейдере со считыванием текстуры"? Потому что "вычисление ветра" - это пустяк по сравнению с задержками GPU <-> CPU, которые ты тут добавляешь два раза - сперва задавая ветер с CPU на GPU, потом выгружая значения с GPU в CPU, и применяя их для смещения своих коллизий, что, в твоём случае, в любом случае должно быть наиболее затратной операцией.
У тебя бутылочное горлышко - это количество CollisionShape3D и их трансформации в пространстве, из-за которых физическому движку (который на C++) придётся обновлять свои кэши и прочие формулы (не знаю подробностей), а не вычисление ветра, так что забудь о шейдерах, они только сбивают тебя с твоей цели.
В общем. Я почему спрашиваю о геймплее твоей игры: насколько тебе важна точность коллизий, и насколько далеко могут колебаться листья? Игрок должен попасть мышкой прям точно в листочек, или лучше будет, чтобы зона коллизии была шире листочка раза в 2-3 от его диаметра? И должен ли вообще игрок попадать в каждый листок, или, быть может, лучше будет хапать сразу несколько разом? Потому что в реалистичном дереве листья сидят очень плотно (даже у комнатных растений), и коллизии будут неизбежно перекрывать друг друга. А может, у тебя там вообще не дерево с листьями, и ты таким образом пытаешься скрыть истинный (постыдный/неприличный) замысел игры? Условно, волосинки на коже и листья на дереве - это разные задачи с, вероятно, разными путями оптимизации.
А, и о ветре: что ты там такого сложного вычисляешь, что тебе GDScript не хватает? По идее, для спонтанных порывов ветра достаточно будет брать значения из Noise3D, постепенно смещаясь относительно центра, возможно, накинув на это значение sin() или cos().
Также зависит от того, нужен ли тебе реализм, или у тебя мидполи/лоуполи стилизация.
>>6870
Сначала ты такой:
А потом ты такой:
Ты хоть для начала пробовал сделать "ветер через скрипт" и записать конкретные затраты времени по профайлеру, или сразу бросился писать "в шейдере со считыванием текстуры"? Потому что "вычисление ветра" - это пустяк по сравнению с задержками GPU <-> CPU, которые ты тут добавляешь два раза - сперва задавая ветер с CPU на GPU, потом выгружая значения с GPU в CPU, и применяя их для смещения своих коллизий, что, в твоём случае, в любом случае должно быть наиболее затратной операцией.
У тебя бутылочное горлышко - это количество CollisionShape3D и их трансформации в пространстве, из-за которых физическому движку (который на C++) придётся обновлять свои кэши и прочие формулы (не знаю подробностей), а не вычисление ветра, так что забудь о шейдерах, они только сбивают тебя с твоей цели.
В общем. Я почему спрашиваю о геймплее твоей игры: насколько тебе важна точность коллизий, и насколько далеко могут колебаться листья? Игрок должен попасть мышкой прям точно в листочек, или лучше будет, чтобы зона коллизии была шире листочка раза в 2-3 от его диаметра? И должен ли вообще игрок попадать в каждый листок, или, быть может, лучше будет хапать сразу несколько разом? Потому что в реалистичном дереве листья сидят очень плотно (даже у комнатных растений), и коллизии будут неизбежно перекрывать друг друга. А может, у тебя там вообще не дерево с листьями, и ты таким образом пытаешься скрыть истинный (постыдный/неприличный) замысел игры? Условно, волосинки на коже и листья на дереве - это разные задачи с, вероятно, разными путями оптимизации.
А, и о ветре: что ты там такого сложного вычисляешь, что тебе GDScript не хватает? По идее, для спонтанных порывов ветра достаточно будет брать значения из Noise3D, постепенно смещаясь относительно центра, возможно, накинув на это значение sin() или cos().
Также зависит от того, нужен ли тебе реализм, или у тебя мидполи/лоуполи стилизация.
Сначала ты такой:
>через скрипт [ветер] считать - плохая идея
А потом ты такой:
>Запись пикселя каждой вершины в пиксель текстуры
>Чтение текстуры. Сколько то вершин проходим
>словарю сдвигаем вершины коллизий
Ты хоть для начала пробовал сделать "ветер через скрипт" и записать конкретные затраты времени по профайлеру, или сразу бросился писать "в шейдере со считыванием текстуры"? Потому что "вычисление ветра" - это пустяк по сравнению с задержками GPU <-> CPU, которые ты тут добавляешь два раза - сперва задавая ветер с CPU на GPU, потом выгружая значения с GPU в CPU, и применяя их для смещения своих коллизий, что, в твоём случае, в любом случае должно быть наиболее затратной операцией.
У тебя бутылочное горлышко - это количество CollisionShape3D и их трансформации в пространстве, из-за которых физическому движку (который на C++) придётся обновлять свои кэши и прочие формулы (не знаю подробностей), а не вычисление ветра, так что забудь о шейдерах, они только сбивают тебя с твоей цели.
В общем. Я почему спрашиваю о геймплее твоей игры: насколько тебе важна точность коллизий, и насколько далеко могут колебаться листья? Игрок должен попасть мышкой прям точно в листочек, или лучше будет, чтобы зона коллизии была шире листочка раза в 2-3 от его диаметра? И должен ли вообще игрок попадать в каждый листок, или, быть может, лучше будет хапать сразу несколько разом? Потому что в реалистичном дереве листья сидят очень плотно (даже у комнатных растений), и коллизии будут неизбежно перекрывать друг друга. А может, у тебя там вообще не дерево с листьями, и ты таким образом пытаешься скрыть истинный (постыдный/неприличный) замысел игры? Условно, волосинки на коже и листья на дереве - это разные задачи с, вероятно, разными путями оптимизации.
А, и о ветре: что ты там такого сложного вычисляешь, что тебе GDScript не хватает? По идее, для спонтанных порывов ветра достаточно будет брать значения из Noise3D, постепенно смещаясь относительно центра, возможно, накинув на это значение sin() или cos().
Также зависит от того, нужен ли тебе реализм, или у тебя мидполи/лоуполи стилизация.
Скуф-ветеринар главный программист того самого крузиса собрал свою банду и пилит црпг на годоте, пока вы тут ноете что уе5 подойдет лучше для вашей пошаговой пиксельной блевотины
https://store.steampowered.com/app/3245640/Starfinder_Afterlight/
И недавно он поделился структурой проекта, пока вы трясетесь что ваши гениальные идеи для пошаговой 2д дрисни кто-то украдет итт
https://www.gdquest.com/library/modular_game_architecture/
https://store.steampowered.com/app/3245640/Starfinder_Afterlight/
И недавно он поделился структурой проекта, пока вы трясетесь что ваши гениальные идеи для пошаговой 2д дрисни кто-то украдет итт
https://www.gdquest.com/library/modular_game_architecture/
>>6845
Анон, который упомянул про XY проблему прав. Пока ты нормально не опишешь геймплей, советовать бесполезно, потому что ты описал одно дерево - какая-то шиза.
Анон, который упомянул про XY проблему прав. Пока ты нормально не опишешь геймплей, советовать бесполезно, потому что ты описал одно дерево - какая-то шиза.
>>6861
Нахер пошел.
Шиз с паранойей не может нормально дать информацию и скорее всего ошибается в решениях. Потом окажется это нуллячий вообще и не понимает что делает, а ты распинаешься перед вайбкодей.
>Слыш, добрее будь
Нахер пошел.
Шиз с паранойей не может нормально дать информацию и скорее всего ошибается в решениях. Потом окажется это нуллячий вообще и не понимает что делает, а ты распинаешься перед вайбкодей.
>>6924
Ну не надо проводить исследования, чтобы увидеть что лишь малый процент людей выпускает продукт (в геймдеве из-за объема работа процент еще ниже). От твоего демотиватора, количество не увеличиться никак.
>пока вы тут ноете
Ну не надо проводить исследования, чтобы увидеть что лишь малый процент людей выпускает продукт (в геймдеве из-за объема работа процент еще ниже). От твоего демотиватора, количество не увеличиться никак.
>>6951
Ну, а вдруг у него там симулятор бонсая? Типа сидишь, смотришь, как твоё деревцо растёт, и иногда отщипываешь от него листочки/почки, чтобы оно росло компактнее. Может, эта игра вообще предназначена как idle питомец на рабочем столе, а не как какой-то экшон-суть-токова. Так что "нужно всего одно дерево" - вполне правдоподобный запрос, вопрос только в его масштабе - если нужен бонсай, это одно, а если нужен гигантский Иггдрасиль - это другое...
>>6952
Да ладно тебе, многие через это проходили... Про это даже мемы популярные есть.
Значение знаешь? Вайбкодер не стал бы на форум писать - у него нейронка всё делает.
>потому что ты описал одно дерево - какая-то шиза.
Ну, а вдруг у него там симулятор бонсая? Типа сидишь, смотришь, как твоё деревцо растёт, и иногда отщипываешь от него листочки/почки, чтобы оно росло компактнее. Может, эта игра вообще предназначена как idle питомец на рабочем столе, а не как какой-то экшон-суть-токова. Так что "нужно всего одно дерево" - вполне правдоподобный запрос, вопрос только в его масштабе - если нужен бонсай, это одно, а если нужен гигантский Иггдрасиль - это другое...
>>6952
>Нахер пошел
>Шиз с паранойей
Да ладно тебе, многие через это проходили... Про это даже мемы популярные есть.
>нуллячий
>вайбкодей
Значение знаешь? Вайбкодер не стал бы на форум писать - у него нейронка всё делает.
>>6924
Гениальная структура проекта. Такой правда не захочется делиться. Но вообще это маркетинг.
Если ты ищешь вдохновение в чужом маркетинге, это тревожный звоночек. Это как хотеть кушать и смотреть на еду через ветрину магазина.
>И недавно он поделился структурой проекта, пока вы трясетесь что ваши гениальные идеи
Гениальная структура проекта. Такой правда не захочется делиться. Но вообще это маркетинг.
Если ты ищешь вдохновение в чужом маркетинге, это тревожный звоночек. Это как хотеть кушать и смотреть на еду через ветрину магазина.
1,7 Мб, 1184x864Сап, годотеры. Какую версию рекомендуете полному новичку для вката в разработку VR-приложений на винду (через OpenXR) и возможно андроид??
>>6956
Сейчас бы додумывать чужой проект. Когда у тебя одно дерево и это основной геймплей - подход совершенно другой, чем когда у тебя лес.
В данный момент важно только одно вайбкодя это или нет.
Рано или поздно они упираются в тупик и приходят на борду с постами оторванными от реальности, не понимая ни кода, ни даже своего проекта в целом.
Недавний пример челика с лагающими турелями.
-Почему у меня тормозит.
-Попробуй так, сяк, посмотри тут или там.
-Ай, ладно, я уже перегенерил код.
Офигенно помогли.
> а вдруг
Сейчас бы додумывать чужой проект. Когда у тебя одно дерево и это основной геймплей - подход совершенно другой, чем когда у тебя лес.
В данный момент важно только одно вайбкодя это или нет.
>у него нейронка всё делает.
Рано или поздно они упираются в тупик и приходят на борду с постами оторванными от реальности, не понимая ни кода, ни даже своего проекта в целом.
Недавний пример челика с лагающими турелями.
-Почему у меня тормозит.
-Попробуй так, сяк, посмотри тут или там.
-Ай, ладно, я уже перегенерил код.
Офигенно помогли.
>>6965
Ладно, чатГпт действительно хорош. Мы даже обсудили гонку.
В общем, будьте осторожны с гонками. Не гоняйте пацаны
Ладно, чатГпт действительно хорош. Мы даже обсудили гонку.
В общем, будьте осторожны с гонками. Не гоняйте пацаны
>>6967
Кстати ГПТ ошибся.
Гонка возможно только так
particles.emitting = true
await some_other_signal
if particles.emitting:
....await some_other_signal
....await particles.finished
Не гоняйте Перепроверяйте пацаны.
Кстати ГПТ ошибся.
Гонка возможно только так
particles.emitting = true
await some_other_signal
if particles.emitting:
....await some_other_signal
....await particles.finished
Не гоняйте Перепроверяйте пацаны.
>>6961
Самую актуальную. То есть Godot 4.7.1 или Godot 4.8-dev2. При выходе обновлений - скачивай новую. Там постоянно новые фиксы какие-то для XR завозят, так что нет смысла сидеть на чём-то устаревшем. Нормальный VR бюджетные девайсы всё равно не потянут, да и интерес к VR только у специфических энтузиастов, так что ты по определению ориентируешься на верхнюю границу рынка. Хотя во времена Google Cardboard VR вышло куча слопа даже для бюджетных мобилок, но, мне кажется, никому это больше не интересно.
>>6965
Если не ошибаюсь, emitting = true ничего не сделает до следующего кадра. Поэтому, если код между emitting = true и await finished не будет ничего другого await'ить, тогда ты не можешь пропустить этот finished. Однако, само по себе "пропустить await" возможно, и я с таким сталкивался неоднократно, поэтому рекомендую вместо await вешать отдельную функцию-обработчик сигнала:
Этот способ лучше ещё и тем, что ты даёшь чёткое имя и позицию в файле для своего кода после завершения частиц, что может помочь тебе разобраться в твоём коде в будущем, когда забудешь, что там и как работало. Разбираться в длинной портянке с кучей разных await всегда сложнее, даже если сейчас тебе твой код кажется простым и понятным... ну, так принято считать, вроде бы...
...В то же время не советую пихать всё подряд в один обработчик "_on_..." - если у тебя там какая-то конкретная операция, что-то наподобие "закрыть окно", тогда лучше вынести эту операцию в ещё одну функцию, которая будет вызываться из обработчика:
Кажется избыточным, но потом будет намного проще разобраться в таком коде, модифицировать его и просто использовать.
Самую актуальную. То есть Godot 4.7.1 или Godot 4.8-dev2. При выходе обновлений - скачивай новую. Там постоянно новые фиксы какие-то для XR завозят, так что нет смысла сидеть на чём-то устаревшем. Нормальный VR бюджетные девайсы всё равно не потянут, да и интерес к VR только у специфических энтузиастов, так что ты по определению ориентируешься на верхнюю границу рынка. Хотя во времена Google Cardboard VR вышло куча слопа даже для бюджетных мобилок, но, мне кажется, никому это больше не интересно.
>>6965
Если не ошибаюсь, emitting = true ничего не сделает до следующего кадра. Поэтому, если код между emitting = true и await finished не будет ничего другого await'ить, тогда ты не можешь пропустить этот finished. Однако, само по себе "пропустить await" возможно, и я с таким сталкивался неоднократно, поэтому рекомендую вместо await вешать отдельную функцию-обработчик сигнала:
>particles.finished.connect(_on_particles_finished)
>particles.emitting = true
>func _on_particles_finished() -> void:
>_ # тут твой код после частиц
Этот способ лучше ещё и тем, что ты даёшь чёткое имя и позицию в файле для своего кода после завершения частиц, что может помочь тебе разобраться в твоём коде в будущем, когда забудешь, что там и как работало. Разбираться в длинной портянке с кучей разных await всегда сложнее, даже если сейчас тебе твой код кажется простым и понятным... ну, так принято считать, вроде бы...
...В то же время не советую пихать всё подряд в один обработчик "_on_..." - если у тебя там какая-то конкретная операция, что-то наподобие "закрыть окно", тогда лучше вынести эту операцию в ещё одну функцию, которая будет вызываться из обработчика:
>func _on_animation_finished() -> void: _close_window()
>func _close_window() -> void: hide()
Кажется избыточным, но потом будет намного проще разобраться в таком коде, модифицировать его и просто использовать.
>>6969
Спасибо анонче. Да, надо вешать обработку, с корутиными и авейтом надо осторожнее быть (у меня как раз гонка получилась, некоторые партиклы не удалялись).
> и я с таким сталкивался неоднократно, поэтому рекомендую вместо await вешать отдельную функцию-обработчик сигнала:
Спасибо анонче. Да, надо вешать обработку, с корутиными и авейтом надо осторожнее быть (у меня как раз гонка получилась, некоторые партиклы не удалялись).
>>6970
А никто и не вайбкодит, это просто жирные тролли набрасывают, а потом смеются в сторонке...
А никто и не вайбкодит, это просто жирные тролли набрасывают, а потом смеются в сторонке...
>>6972
>>6970
Это напоминает обывателей на реддите, которые впервые столкнулись с ИИ в Google AI Overview, где сидит самая дешевая-быстрая модель, и пришли поныть какое же это ваше АИ тупое. Инфа сто процентов что местные скептики примерно такие же, и прыгают по лоботомизированным моделям позапрошлого поколения в лучшем случае, и по Алисам и Гигачатам в худшем.
>>6970
Это напоминает обывателей на реддите, которые впервые столкнулись с ИИ в Google AI Overview, где сидит самая дешевая-быстрая модель, и пришли поныть какое же это ваше АИ тупое. Инфа сто процентов что местные скептики примерно такие же, и прыгают по лоботомизированным моделям позапрошлого поколения в лучшем случае, и по Алисам и Гигачатам в худшем.
>>7004
Ну да, мы же не лохи, которые ПЛАТЯТ ДЕНЬГИ В ИИ ПУЗЫРЬ, РАЗДУВАЯ ЕГО ЕЩЁ СИЛЬНЕЕ, И УВЕЛИЧИВАЯ ЦЕНЫ НА ОПЕРАТИВКУ, ДИСКИ, ВИДЕОКАРТЫ, нет, мы не такие. Любой ценой, но бесплатно. Как только ИИ-гача предлагает купить токен, мы разворачиваемся и находим другую.
Ну да, мы же не лохи, которые ПЛАТЯТ ДЕНЬГИ В ИИ ПУЗЫРЬ, РАЗДУВАЯ ЕГО ЕЩЁ СИЛЬНЕЕ, И УВЕЛИЧИВАЯ ЦЕНЫ НА ОПЕРАТИВКУ, ДИСКИ, ВИДЕОКАРТЫ, нет, мы не такие. Любой ценой, но бесплатно. Как только ИИ-гача предлагает купить токен, мы разворачиваемся и находим другую.
>>7014
Ну так сиди в своем отстойнике и не бухти что ИИ ничего не могут. Это ты ничего не можешь, нищук.
Ну так сиди в своем отстойнике и не бухти что ИИ ничего не могут. Это ты ничего не можешь, нищук.
Лол, блять, он пытается защищать ИИ-пузырь, невзирая на все разумные доводы. Ну, наслаждайтесь оверпрайсом дальше.
>>7004
Лол, ты все еще веришь в какую-то магию, мол, вот еще чуть чуть доплатишь подергаешь рулеточку и тогда то точно выпадет хороший код! Будем надеяться, что ты просто тролль, а не рекламируешь мошеннические схемы умышленно.
Лол, ты все еще веришь в какую-то магию, мол, вот еще чуть чуть доплатишь подергаешь рулеточку и тогда то точно выпадет хороший код! Будем надеяться, что ты просто тролль, а не рекламируешь мошеннические схемы умышленно.
>>7004
Это последняя гпт (я кидал), не превозмогай вайбкодя.
Это последняя гпт (я кидал), не превозмогай вайбкодя.
61 Кб, 1096x1435ТРЕД БЕСПЛАТНОГО ИГРОВОГО ДВИЖКА
@
СКАЧАТЬ 50 МБ БЕЗ СМС И РЕГИСТРАЦИИ
@
РАБОТАЕТ ДАЖЕ НА ДРЕВНИХ КОРЕ 2 ДУО
@
БЕЗ ЗОНДОВ, ПОДПИСОК, ЕУЛА, ПОДВОХОВ
@
ВСЕ ИСХОДНИКИ ОТКРЫТЫЕ И СВОБОДНЫЕ
@
@
@
А ПОЧЕМУ ВЫ НЕ ПЛАТИТИ ПОДПИСЬКУ?
@
А ПОЧЕМУ ВЫ НЕ КАЧАЕТЕ 2ТБ БИНАРЬ?
@
А ПОЧЕМУ ВЫ НЕ ДОВЕРЯЕТЕ ДЯДЯМ?
@
А Я ВОТ КУПИЛ, СКАЧАЛ И ДОВЕРЯЮ
@
ОЧЕНЬ ПРИЯТНО, ЗОНД НЕ МЕШАЕТ
@
СКАЧАТЬ 50 МБ БЕЗ СМС И РЕГИСТРАЦИИ
@
РАБОТАЕТ ДАЖЕ НА ДРЕВНИХ КОРЕ 2 ДУО
@
БЕЗ ЗОНДОВ, ПОДПИСОК, ЕУЛА, ПОДВОХОВ
@
ВСЕ ИСХОДНИКИ ОТКРЫТЫЕ И СВОБОДНЫЕ
@
@
@
А ПОЧЕМУ ВЫ НЕ ПЛАТИТИ ПОДПИСЬКУ?
@
А ПОЧЕМУ ВЫ НЕ КАЧАЕТЕ 2ТБ БИНАРЬ?
@
А ПОЧЕМУ ВЫ НЕ ДОВЕРЯЕТЕ ДЯДЯМ?
@
А Я ВОТ КУПИЛ, СКАЧАЛ И ДОВЕРЯЮ
@
ОЧЕНЬ ПРИЯТНО, ЗОНД НЕ МЕШАЕТ
>>6924
Да это я ему подсказал архитектуру.
Да это я ему подсказал архитектуру.
>>7120
Based & Falco-pilled.
Возможно, настоящие игры - это друзья, которых мы завели в этом ИТТ треде...
>Унижен. Маша ушла.
Based & Falco-pilled.
>Игори не делаются((
Возможно, настоящие игры - это друзья, которых мы завели в этом ИТТ треде...
Привёл, годотеры. Есть идея сделать синглплеерную карточную игру с изучением мира от первого лица. Геймплей как хартстоун, только вместо ресурсов по типу маны ты платишь здоровьем персонажа и прочими метрики по типу рассудка и т. Д. Есть ли готовые кодовые базы, которые я могу спиздить для ускорения прогресса?