Добро пожаловать в тред любви, взаимопомощи и создания сцен в рантайме при помощи ResourceSaver!
Шапка: https://hipolink.me/godothread
Предыдущий: >>1008211 (OP)
Архивный: >>1000909 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>1008211 (OP)
Архивный: >>1000909 (OP)
>>4044 (OP)
Ты троллишь? Это не имеет отношения к движку...
Лучше бы запостил прозрачный рендер с бликами.
>суть.gif
>решение.gif
Ты троллишь? Это не имеет отношения к движку...
Лучше бы запостил прозрачный рендер с бликами.
>>4047
Первый сделал игру? Первый пришел к успеху? Первый в топчартах стима?
Первый сделал игру? Первый пришел к успеху? Первый в топчартах стима?
270 Кб, 1566x2048Не забывайте: даже если вы в данный момент не делаете игру, Godot внимательно смотрит на вас.
Делайте игру.
Делайте игру.
>>4056
Но симуляции это тоже игры...
https://en.wikipedia.org/wiki/Non-game
https://en.wikipedia.org/wiki/Simulation_video_game
Покажешь свои симуляции?
>лучше какую нибудь симуляцию
Но симуляции это тоже игры...
https://en.wikipedia.org/wiki/Non-game
https://en.wikipedia.org/wiki/Simulation_video_game
Покажешь свои симуляции?
>>1014000 →
Внезапно оно в самом же редакторе используется, так что это довольно очевидно.
С другой стороны, изобретение своего велосипеда помогает понять принципы и детали его работы.
>>4048
Или Jiggle-физику
>в Годо есть встроенное решение для undo/redo!
Внезапно оно в самом же редакторе используется, так что это довольно очевидно.
С другой стороны, изобретение своего велосипеда помогает понять принципы и детали его работы.
>>4048
>Лучше бы запостил прозрачный рендер с бликами.
Или Jiggle-физику
>>4062
И люто бесит. Когда ты нажимаешь ctrl+z, отмена происходит там, где ты сейчас сфокусировался... Например, если хочешь отменить удаление ноды - нажимаешь на дерево сцены, а если параметров материала - на инспектор материала. Дико бесит, особенно когда меняешь всё и сразу, понемногу.
Привык, что полагаться на undo/redo в Godot нельзя.
>оно в самом же редакторе используется
И люто бесит. Когда ты нажимаешь ctrl+z, отмена происходит там, где ты сейчас сфокусировался... Например, если хочешь отменить удаление ноды - нажимаешь на дерево сцены, а если параметров материала - на инспектор материала. Дико бесит, особенно когда меняешь всё и сразу, понемногу.
Привык, что полагаться на undo/redo в Godot нельзя.
>>1014033 →
https://docs.godotengine.org/en/stable/classes/class_undoredo.html
>>4070
Это еще ладно. Бывает, что оно вообще перестает работать и начинает удалять какие-то рандомные строки кода вместо undo. Помогает только перезапуск редактора.
https://docs.godotengine.org/en/stable/classes/class_undoredo.html
>>4070
Это еще ладно. Бывает, что оно вообще перестает работать и начинает удалять какие-то рандомные строки кода вместо undo. Помогает только перезапуск редактора.
>>4073
А ты историю изменений пробовал? В какой-то версии реализовали - по умолчанию там, где инспектор, вроде третья вкладка. По идее, глобальный откат/повтор, но лично я выключил это меню в настройках (кажется, тормозило, не помню уже; нужно ещё попробовать).
Впрочем, обычно ничего кроме одного ctrl+z не нужно.
А ты историю изменений пробовал? В какой-то версии реализовали - по умолчанию там, где инспектор, вроде третья вкладка. По идее, глобальный откат/повтор, но лично я выключил это меню в настройках (кажется, тормозило, не помню уже; нужно ещё попробовать).
Впрочем, обычно ничего кроме одного ctrl+z не нужно.
26,5 Мб, mp4,1920x1080, 1:04
>>4058
Нет, свои не покажу.
Нет, свои не покажу.
8 Кб, 756x60Кстати, как вы справляетесь с тем, как Godot часто избыточно пересохраняет никак не изменявшиеся ресурсы (tres)? По-моему, замедляет сохранение.
Баг древний, но его почему-то игнорируют:
https://github.com/godotengine/godot/issues/31186
Меня задолбало... Как оптимизировать структуру проекта, чтоб избежать этих лишних сохранений? Пробовал закрывать все вкладки сцен - пикрил...
Баг древний, но его почему-то игнорируют:
https://github.com/godotengine/godot/issues/31186
Меня задолбало... Как оптимизировать структуру проекта, чтоб избежать этих лишних сохранений? Пробовал закрывать все вкладки сцен - пикрил...
Локализация в годоте делается изи-изян. Зря забивал на локализацию своих прошлых игр.
>>4087
Хз, сам не встречал этот баг, хотя гитом пользуюсь с 3.х. Думаю он не столько про замедление сколько про замусоривание лога гита.
Хз, сам не встречал этот баг, хотя гитом пользуюсь с 3.х. Думаю он не столько про замедление сколько про замусоривание лога гита.
>>4101
Самый простой способ с переменной:
Если объект не MyType, то в obj будет null.
Разница между is и as:
obj is T == true/false (bool)
obj as T == obj/null (T)
В условиях:
null == false
instance == true
freed_instance == false
Поэтому можно делать так:
Если другие типы недопустимы, лучше так:
Это упадёт с обращением к null если не MyType.
>>4119
Было уже несколько, это банальная идея...
Самый простой способ с переменной:
>var obj := get_some_object() as MyType
>if obj: obj.do_my_func()
Если объект не MyType, то в obj будет null.
Разница между is и as:
obj is T == true/false (bool)
obj as T == obj/null (T)
В условиях:
null == false
instance == true
freed_instance == false
Поэтому можно делать так:
>if obj: # если obj создан и пока существует...
Если другие типы недопустимы, лучше так:
>(get_some_object() as MyType).do_my_func()
Это упадёт с обращением к null если не MyType.
>>4119
>Симулятора алкоголика еще, вроде, не было.
Было уже несколько, это банальная идея...
>>4127
Мне нравится когда в условии if создаётся локальная переменная и к ней подтягивается автодополнение редактора. Сделойти.
Мне нравится когда в условии if создаётся локальная переменная и к ней подтягивается автодополнение редактора. Сделойти.
>>4130
Это же просто синтаксический сахар, не более...
Если тебя волнует локальность - ты говнокодишь.
Здесь оно тоже подтягивается:
И здесь тоже подтягивается:
Алсо, GDScript позволяет форматировать так:
Если очень надо, можно всё в одну строчку через ";".
Делай сам. Но в основную версию вряд ли пустят.
>в условии if создаётся локальная переменная
Это же просто синтаксический сахар, не более...
Если тебя волнует локальность - ты говнокодишь.
>подтягивается автодополнение
Здесь оно тоже подтягивается:
>var obj := get_some_object() as MyType
>if obj: obj.do_my_func()
И здесь тоже подтягивается:
>(get_some_object() as MyType).do_my_func()
Алсо, GDScript позволяет форматировать так:
>var obj := get_some_object() as MyType; if obj:
>_ obj.do_my_func()
Если очень надо, можно всё в одну строчку через ";".
>Сделойти
Делай сам. Но в основную версию вряд ли пустят.
28 Кб, 377x317И так не получается. И эдак не получается. Ой, всё. Ну и ладно. Ну и не надо.
>>4135
Они уже очень много притянули из шарпа. Неужели я многого прошу ещё одну фичу притянуть. Из шарпа.
> Но в основную версию вряд ли пустят.
Они уже очень много притянули из шарпа. Неужели я многого прошу ещё одну фичу притянуть. Из шарпа.
А ещё пора в гдскрипт ввести модификаторы доступа.
Для обратной совместимости считать все переменные и функции публичными, но добавить аннотацию, которая задаёт режим:
> @private @onready var something : String = "hurr durr"
Для обратной совместимости считать все переменные и функции публичными, но добавить аннотацию, которая задаёт режим:
> @private_default
>>4140
Очевидно, что мешает необходимость проверять несколько подтипов в цепочке наследования.
> Что мешает написать так?
Очевидно, что мешает необходимость проверять несколько подтипов в цепочке наследования.
>>4141
https://github.com/godotengine/godot/pull/103768
Ты серьёзно пишешь в своём коде такое?
Это ж максимально неприятно выглядит ("._").
Естественно, что приватное начинается с "_".
>>4143
https://ru.wikipedia.org/wiki/Проблема_XY
Конкретно зачем тебе это нужно?
Если в твоём коде часто случается такое:
Тогда тебе нужно учить базу ООП.
https://ru.wikipedia.org/wiki/SOLID
Реальное решение будет выглядеть так:
В каждом классе - свой личный do_work().
>модификаторы доступа
https://github.com/godotengine/godot/pull/103768
Ты серьёзно пишешь в своём коде такое?
>other_object._private_var = value
>other_object._private_func()
Это ж максимально неприятно выглядит ("._").
Естественно, что приватное начинается с "_".
>>4143
>проверять несколько подтипов в цепочке
https://ru.wikipedia.org/wiki/Проблема_XY
Конкретно зачем тебе это нужно?
Если в твоём коде часто случается такое:
>если а типа А, то...
>иначе если а типа Б, то...
>иначе если а типа В, то...
>иначе если а типа Г, то...
Тогда тебе нужно учить базу ООП.
https://ru.wikipedia.org/wiki/SOLID
Реальное решение будет выглядеть так:
>get_object().do_work() # никаких проверок
В каждом классе - свой личный do_work().
>>4152
Вроде бы можно так, и это даже будет побыстрее:
Но это если у тебя obj может не иметь do_work().
Речь шла про ситуации, когда ты делаешь так (плохо!):
Вместо этого лучше сделать так:
Cat, Dog, Bird, Duck и Human сами решат, как им звучать.
Если у тебя есть Fish, то у неё тоже есть этот метод:
Чтобы не было проверок типа "можешь ли ты звучать".
Суть в том, что ты ПРОСТО создаёшь новый класс:
И реализуешь ему все необходимые Animal методы:
ВСЁ. Не нужно никуда добавлять "elif animal is Zombie..."
Для RayCast/ShapeCast/Area лучше всего настроить слои.
>has_method
Вроде бы можно так, и это даже будет побыстрее:
>if "do_work" in obj: obj.do_work()
Но это если у тебя obj может не иметь do_work().
Речь шла про ситуации, когда ты делаешь так (плохо!):
>if animal is Cat: animal.meow()
>elif animal is Dog: animal.bark()
>elif animal is Bird: animal.chirp()
>elif animal is Duck: animal.quack()
>elif animal is Human: animal.shout()
Вместо этого лучше сделать так:
>animal.make_sound()
Cat, Dog, Bird, Duck и Human сами решат, как им звучать.
Если у тебя есть Fish, то у неё тоже есть этот метод:
>class_name Fish extends Animal
>func make_sound() -> void: pass # fish can't make sound
Чтобы не было проверок типа "можешь ли ты звучать".
Суть в том, что ты ПРОСТО создаёшь новый класс:
>class_name Zombie extends Animal
И реализуешь ему все необходимые Animal методы:
>func make_sound() -> void: play_sound("Aaarghhhh!")
ВСЁ. Не нужно никуда добавлять "elif animal is Zombie..."
Для RayCast/ShapeCast/Area лучше всего настроить слои.
>>4152
Вроде бы можно так, и это даже будет побыстрее:
Но это если у тебя obj может не иметь do_work().
Речь шла про ситуации, когда ты делаешь так (плохо!):
Вместо этого лучше сделать так:
Cat, Dog, Bird, Duck и Human сами решат, как им звучать.
Если у тебя есть Fish, то у неё тоже есть этот метод:
Чтобы не было проверок типа "можешь ли ты звучать".
Суть в том, что ты ПРОСТО создаёшь новый класс:
И реализуешь ему все необходимые Animal методы:
ВСЁ. Не нужно никуда добавлять "elif animal is Zombie..."
Для RayCast/ShapeCast/Area лучше всего настроить слои.
>has_method
Вроде бы можно так, и это даже будет побыстрее:
>if "do_work" in obj: obj.do_work()
Но это если у тебя obj может не иметь do_work().
Речь шла про ситуации, когда ты делаешь так (плохо!):
>if animal is Cat: animal.meow()
>elif animal is Dog: animal.bark()
>elif animal is Bird: animal.chirp()
>elif animal is Duck: animal.quack()
>elif animal is Human: animal.shout()
Вместо этого лучше сделать так:
>animal.make_sound()
Cat, Dog, Bird, Duck и Human сами решат, как им звучать.
Если у тебя есть Fish, то у неё тоже есть этот метод:
>class_name Fish extends Animal
>func make_sound() -> void: pass # fish can't make sound
Чтобы не было проверок типа "можешь ли ты звучать".
Суть в том, что ты ПРОСТО создаёшь новый класс:
>class_name Zombie extends Animal
И реализуешь ему все необходимые Animal методы:
>func make_sound() -> void: play_sound("Aaarghhhh!")
ВСЁ. Не нужно никуда добавлять "elif animal is Zombie..."
Для RayCast/ShapeCast/Area лучше всего настроить слои.
>>4159
Поправка: этот метод скорее всего есть у предка - Animal:
Многие потомки Animal делают свою версию, но не Fish.
Таким образом любые потомки Animal могут "звучать".
>>func make_sound() -> void: pass # fish can't make sound
Поправка: этот метод скорее всего есть у предка - Animal:
>class_name Animal extends...
>func make_sound() -> void: pass
Многие потомки Animal делают свою версию, но не Fish.
Таким образом любые потомки Animal могут "звучать".
1 Кб, 166x66>>4105
У меня Godot начал зависать при сохранении.
Сохраняю один простой скрипт - жду секунд 10.
Почему это может быть? Как искать причину?
>Думаю он не столько про замедление
У меня Godot начал зависать при сохранении.
Сохраняю один простой скрипт - жду секунд 10.
Почему это может быть? Как искать причину?
>>4164
Чекай жёсткий диск. Походу пришло время, его время.
Чекай жёсткий диск. Походу пришло время, его время.
>>4101
Это не соответствует парадигме duck typing. Используй has_method.
>>4141
Никогда не понимал, зачем это нужно. Ну ладно, в компилируемых языках, возможно, применяются какие-то оптимизации, которые могут добавить производительности, если правильно разграничить права доступа. Наверное. Но в гдскрипте-то это зачем? Почему нельзя написать коммент "## это приватный мембер" и просто не использовать его извне? Это ж никак не влияет на производительность. Зачем эти искусственные ограничения?
Это не соответствует парадигме duck typing. Используй has_method.
>>4141
Никогда не понимал, зачем это нужно. Ну ладно, в компилируемых языках, возможно, применяются какие-то оптимизации, которые могут добавить производительности, если правильно разграничить права доступа. Наверное. Но в гдскрипте-то это зачем? Почему нельзя написать коммент "## это приватный мембер" и просто не использовать его извне? Это ж никак не влияет на производительность. Зачем эти искусственные ограничения?
>>4190
У меня детская травма, я не люблю строковые литералы в коде. И даже то что Хуан сделал для таких как я стрингнеймы - не сильно помогает.
> Используй has_method(&"method_name")
У меня детская травма, я не люблю строковые литералы в коде. И даже то что Хуан сделал для таких как я стрингнеймы - не сильно помогает.
69 Кб, 736x736>>4190
КАЧАЕШЬ ПРИКОЛЬНЫЙ АДДОНЧИК
@
ОН ПОЧТИ ИДЕАЛЕН ДЛЯ ТВОЕЙ ИГРЫ
@
НАДО ЛИШЬ КОЕ-ЧТО ИЗВНЕ ПОПРАВИТЬ
@
НАХОДИШЬ ИНТЕРЕСНОЕ ПОЛЕ _ПЕРДЫХ
@
ДА ЭТО ЖЕ ЛУЧШАЯ ФИЧА ВСЕГО АДДОНА!
@
СКАЗАНО НЕ ИСПОЛЬЗОВАТЬ, НУ ДА ЛАДНО
@
НИКАКИХ ПОБОЧНЫХ ЭФФЕКТОВ НЕ ВИДНО
@
ОБМАЗЫВАЕШЬ ВСЮ ИГРУ ЭТИМ _ПЕРДЫХ
@
ВСЯ ИГРА СВИСТИТ И ПЕРДИТ - КРАСОТА!
@
ПРОХОДИТ ПАРА МЕСЯЦЕВ РАЗРАБОТКИ
@
ОБНОВЛЯЕШЬ АДДОН ДО ВЕРСИИ 1.0.1
@
ТАМ ФИКС КРИТИЧЕСКОГО ОБДРИСТА
@
БЕЗ НЕГО ИГРА РАСТЕКАЕТСЯ В ЛУЖИЦУ
@
ПРОВЕРЯЕШЬ, КАК ОНО ПОСЛЕ АПДЕЙТА
@
_ПЕРДЫХ ВЕДЁТ СЕБЯ КАК-ТО СТРАННО
@
ПРОЕКТ СЛОМАЛСЯ И БОЛЬШЕ НЕ ПЕРДИТ
@
ВСЯ ТВОЯ ИГРА БЫЛА ПРО ЭТОТ ПЕРДЁЖ
@
РЕШАЕШЬСЯ САМ ПОФИКСИТЬ _ПЕРДЫХ
@
В АДДОНЕ 100500 СТРОК ГОВНОКОДА...
>просто не использовать его извне
КАЧАЕШЬ ПРИКОЛЬНЫЙ АДДОНЧИК
@
ОН ПОЧТИ ИДЕАЛЕН ДЛЯ ТВОЕЙ ИГРЫ
@
НАДО ЛИШЬ КОЕ-ЧТО ИЗВНЕ ПОПРАВИТЬ
@
НАХОДИШЬ ИНТЕРЕСНОЕ ПОЛЕ _ПЕРДЫХ
@
ДА ЭТО ЖЕ ЛУЧШАЯ ФИЧА ВСЕГО АДДОНА!
@
СКАЗАНО НЕ ИСПОЛЬЗОВАТЬ, НУ ДА ЛАДНО
@
НИКАКИХ ПОБОЧНЫХ ЭФФЕКТОВ НЕ ВИДНО
@
ОБМАЗЫВАЕШЬ ВСЮ ИГРУ ЭТИМ _ПЕРДЫХ
@
ВСЯ ИГРА СВИСТИТ И ПЕРДИТ - КРАСОТА!
@
ПРОХОДИТ ПАРА МЕСЯЦЕВ РАЗРАБОТКИ
@
ОБНОВЛЯЕШЬ АДДОН ДО ВЕРСИИ 1.0.1
@
ТАМ ФИКС КРИТИЧЕСКОГО ОБДРИСТА
@
БЕЗ НЕГО ИГРА РАСТЕКАЕТСЯ В ЛУЖИЦУ
@
ПРОВЕРЯЕШЬ, КАК ОНО ПОСЛЕ АПДЕЙТА
@
_ПЕРДЫХ ВЕДЁТ СЕБЯ КАК-ТО СТРАННО
@
ПРОЕКТ СЛОМАЛСЯ И БОЛЬШЕ НЕ ПЕРДИТ
@
ВСЯ ТВОЯ ИГРА БЫЛА ПРО ЭТОТ ПЕРДЁЖ
@
РЕШАЕШЬСЯ САМ ПОФИКСИТЬ _ПЕРДЫХ
@
В АДДОНЕ 100500 СТРОК ГОВНОКОДА...
69 Кб, 736x736>>4190
КАЧАЕШЬ ПРИКОЛЬНЫЙ АДДОНЧИК
@
ОН ПОЧТИ ИДЕАЛЕН ДЛЯ ТВОЕЙ ИГРЫ
@
НАДО ЛИШЬ КОЕ-ЧТО ИЗВНЕ ПОПРАВИТЬ
@
НАХОДИШЬ ИНТЕРЕСНОЕ ПОЛЕ _ПЕРДЫХ
@
ДА ЭТО ЖЕ ЛУЧШАЯ ФИЧА ВСЕГО АДДОНА!
@
СКАЗАНО НЕ ИСПОЛЬЗОВАТЬ, НУ ДА ЛАДНО
@
НИКАКИХ ПОБОЧНЫХ ЭФФЕКТОВ НЕ ВИДНО
@
ОБМАЗЫВАЕШЬ ВСЮ ИГРУ ЭТИМ _ПЕРДЫХ
@
ВСЯ ИГРА СВИСТИТ И ПЕРДИТ - КРАСОТА!
@
ПРОХОДИТ ПАРА МЕСЯЦЕВ РАЗРАБОТКИ
@
ОБНОВЛЯЕШЬ АДДОН ДО ВЕРСИИ 1.0.1
@
ТАМ ФИКС КРИТИЧЕСКОГО ОБДРИСТА
@
БЕЗ НЕГО ИГРА РАСТЕКАЕТСЯ В ЛУЖИЦУ
@
ПРОВЕРЯЕШЬ, КАК ОНО ПОСЛЕ АПДЕЙТА
@
_ПЕРДЫХ ВЕДЁТ СЕБЯ КАК-ТО СТРАННО
@
ПРОЕКТ СЛОМАЛСЯ И БОЛЬШЕ НЕ ПЕРДИТ
@
ВСЯ ТВОЯ ИГРА БЫЛА ПРО ЭТОТ ПЕРДЁЖ
@
РЕШАЕШЬСЯ САМ ПОФИКСИТЬ _ПЕРДЫХ
@
В АДДОНЕ 100500 СТРОК ГОВНОКОДА...
>просто не использовать его извне
КАЧАЕШЬ ПРИКОЛЬНЫЙ АДДОНЧИК
@
ОН ПОЧТИ ИДЕАЛЕН ДЛЯ ТВОЕЙ ИГРЫ
@
НАДО ЛИШЬ КОЕ-ЧТО ИЗВНЕ ПОПРАВИТЬ
@
НАХОДИШЬ ИНТЕРЕСНОЕ ПОЛЕ _ПЕРДЫХ
@
ДА ЭТО ЖЕ ЛУЧШАЯ ФИЧА ВСЕГО АДДОНА!
@
СКАЗАНО НЕ ИСПОЛЬЗОВАТЬ, НУ ДА ЛАДНО
@
НИКАКИХ ПОБОЧНЫХ ЭФФЕКТОВ НЕ ВИДНО
@
ОБМАЗЫВАЕШЬ ВСЮ ИГРУ ЭТИМ _ПЕРДЫХ
@
ВСЯ ИГРА СВИСТИТ И ПЕРДИТ - КРАСОТА!
@
ПРОХОДИТ ПАРА МЕСЯЦЕВ РАЗРАБОТКИ
@
ОБНОВЛЯЕШЬ АДДОН ДО ВЕРСИИ 1.0.1
@
ТАМ ФИКС КРИТИЧЕСКОГО ОБДРИСТА
@
БЕЗ НЕГО ИГРА РАСТЕКАЕТСЯ В ЛУЖИЦУ
@
ПРОВЕРЯЕШЬ, КАК ОНО ПОСЛЕ АПДЕЙТА
@
_ПЕРДЫХ ВЕДЁТ СЕБЯ КАК-ТО СТРАННО
@
ПРОЕКТ СЛОМАЛСЯ И БОЛЬШЕ НЕ ПЕРДИТ
@
ВСЯ ТВОЯ ИГРА БЫЛА ПРО ЭТОТ ПЕРДЁЖ
@
РЕШАЕШЬСЯ САМ ПОФИКСИТЬ _ПЕРДЫХ
@
В АДДОНЕ 100500 СТРОК ГОВНОКОДА...
Если считать только донаты, не учитывая прямые инвестиции от гуглов и тд, то годот в год собирает 525 тысяч евро.
>>4267
Как стану миллиардером и перееду на запад - обязательно буду переводить процентов 5% дохода.
Как стану миллиардером и перееду на запад - обязательно буду переводить процентов 5% дохода.
46 Кб, 408x439>>4243
Да действительно, блять, что же это такое? Давайте поможем Даше найти гугл, блять.
Да действительно, блять, что же это такое? Давайте поможем Даше найти гугл, блять.
>>4246
Каким образом гит/бэкап поможет тебе обновить посторонний аддон до новой версии, сохранив функциональность игры, которая опиралась на секретную (приватную) возможность, которую ты не должен был использовать и которая изменилась?
С приватными полями всё просто: редактор тебе автоматически по рукам бьёт и говорит "низя". Без приватных полей ты говнокодишь без ограничений.
Это как со слабой типизацией: да, МОЖНО хранить в одной и той же переменой любые данные. Но будут последствия для твоего психического здоровья, при условии, что код проживёт дольше одного вечера.
Ещё более наглядный пример - глобальные данные, синглтоны. Хочешь обмазаться лапшой и дрочить?
Писать говнокод слишком легко - нужен начальник, наказывающий тебя за говнокод автоматически.
>Гит, бекапы
Каким образом гит/бэкап поможет тебе обновить посторонний аддон до новой версии, сохранив функциональность игры, которая опиралась на секретную (приватную) возможность, которую ты не должен был использовать и которая изменилась?
С приватными полями всё просто: редактор тебе автоматически по рукам бьёт и говорит "низя". Без приватных полей ты говнокодишь без ограничений.
Это как со слабой типизацией: да, МОЖНО хранить в одной и той же переменой любые данные. Но будут последствия для твоего психического здоровья, при условии, что код проживёт дольше одного вечера.
Ещё более наглядный пример - глобальные данные, синглтоны. Хочешь обмазаться лапшой и дрочить?
Писать говнокод слишком легко - нужен начальник, наказывающий тебя за говнокод автоматически.
35 Кб, 385x912>>4286
Обоже опять эти ужасные антипаттерны повылезали из под кровати.
> Ещё более наглядный пример - глобальные данные, синглтоны. Хочешь обмазаться лапшой и дрочить?
Обоже опять эти ужасные антипаттерны повылезали из под кровати.
41 Кб, 736x736>>4282
Ты чё такой помогающий?
>>4243
https://docs.godotengine.org/en/stable/classes/class_stringname.html
>Давайте поможем Даше
Ты чё такой помогающий?
>>4243
>>стрингнеймы
>Это что такое?
https://docs.godotengine.org/en/stable/classes/class_stringname.html
>>4288
Хорошо, делай синглтоны:
Sprite: уникальная аватарка для Player.
Player: принимает ввод и меняет Sprite.pos.
Health: выводит над Sprite.pos здоровье Player.
Enemy: движется к Sprite.pos, снижает Health.value.
Shield: копирует Sprite.pos, поднимает Health.value.
И так далее. Не смей избегать синглтонов в игре.
Потом расскажешь, какой это чудесный паттерн.
Хорошо, делай синглтоны:
Sprite: уникальная аватарка для Player.
Player: принимает ввод и меняет Sprite.pos.
Health: выводит над Sprite.pos здоровье Player.
Enemy: движется к Sprite.pos, снижает Health.value.
Shield: копирует Sprite.pos, поднимает Health.value.
И так далее. Не смей избегать синглтонов в игре.
Потом расскажешь, какой это чудесный паттерн.
>>4286
ПРОСТО откатишься на старую версию, когда все работало. Стремление всегда использовать последнее - болезнь мозга и подвид прокрастинации.
ПРОСТО откатишься на старую версию, когда все работало. Стремление всегда использовать последнее - болезнь мозга и подвид прокрастинации.
>>4300
В версии 1.0 всё работает, но из-за бага компьютер игроков взламывается кулхацкером фалько и жжёт пердаки до температуры поверхности Солнца. Это обнаружили только спустя несколько месяцев.
В весии 1.0.1 баг пофиксили, но из-за него ты будешь вынужден изменить 100500 строчек в проекте. Но и релизить игру с багом из 1.0 тоже недопустимо.
Влошил 100500 трудочасов и теперь откатишь их?
А ты просто заюзал то, что мог, но не должен был...
В версии 1.0 всё работает, но из-за бага компьютер игроков взламывается кулхацкером фалько и жжёт пердаки до температуры поверхности Солнца. Это обнаружили только спустя несколько месяцев.
В весии 1.0.1 баг пофиксили, но из-за него ты будешь вынужден изменить 100500 строчек в проекте. Но и релизить игру с багом из 1.0 тоже недопустимо.
Влошил 100500 трудочасов и теперь откатишь их?
А ты просто заюзал то, что мог, но не должен был...
>>4302
Их реализовали только в 4.0 для оптимизации...
Начиная с 4.0, используют во многих API движка.
Так-то да, но можно использовать вручную, но много непонятных нюансов. По идее StringName - это просто целое число, поэтому их очень легко сравнивать - нет необходимости проверять каждый символ строки. Но преобразование String в StringName занимает много времени, равно как и создание нового StringName... Поэтому лучше их создавать заранее как константы.
>Ни разу не встречал.
Их реализовали только в 4.0 для оптимизации...
Начиная с 4.0, используют во многих API движка.
>Оно где-то под капотом работает?
Так-то да, но можно использовать вручную, но много непонятных нюансов. По идее StringName - это просто целое число, поэтому их очень легко сравнивать - нет необходимости проверять каждый символ строки. Но преобразование String в StringName занимает много времени, равно как и создание нового StringName... Поэтому лучше их создавать заранее как константы.
>>4299
Перестань строить из себя клоуна. Синглтоны нужны там, где они нужны, на своих местах. Я не буду реализовывать приведённое тобой соломенное чучело, чучело.
Перестань строить из себя клоуна. Синглтоны нужны там, где они нужны, на своих местах. Я не буду реализовывать приведённое тобой соломенное чучело, чучело.
>>4307
Приведи примеры, где они обязательно нужны.
Не из API движка, а из твоей собственной игры.
Где ты никак не смог обойтись без синглтона?
Алсо, как новичок определит, где они нужны?
>Синглтоны нужны там, где они нужны
Приведи примеры, где они обязательно нужны.
Не из API движка, а из твоей собственной игры.
Где ты никак не смог обойтись без синглтона?
Алсо, как новичок определит, где они нужны?
46 Кб, 1180x732>>4312
В редот коммитит примерно никто. Смотрю у них сил не осталось даже на таскание коммитов из годота.
Бля, а вони-то было.
В редот коммитит примерно никто. Смотрю у них сил не осталось даже на таскание коммитов из годота.
Бля, а вони-то было.
>>4308
Данный код запрашивает у синглтонового менеджера диалогов старт диалога, первый параметр - ресурс со строками диалога в формате жсон, второй параметр - точка на которой был прерван диалог, точка входа. Берется из синглтонового менеджера управления данными для сохранения.
> DialogueSingleton.start_dialogue(npc.get_current_lines(), WorldDataSingleton.get_dialogue_point(npc))
Данный код запрашивает у синглтонового менеджера диалогов старт диалога, первый параметр - ресурс со строками диалога в формате жсон, второй параметр - точка на которой был прерван диалог, точка входа. Берется из синглтонового менеджера управления данными для сохранения.
196 Кб, 1294x920А судя по активности в 3.х ветке годота нас ждет еще и 3.7 версия. Охуенно.
>>4317
Уже год жду...
Уже год жду...
>>4321
Не стоит. Пусть коммитит Хуану.
Не стоит. Пусть коммитит Хуану.
>>4316
Что не получится сделать из-за этих синглтонов:
1. Сплит-скрин мультиплеер: нужны от 2 до 4 диалогов.
2. Параллельный разговор с NPC: нужно от 2 диалогов и более.
3. Параллельные вселенные в игре: нужны разные ветки сохранения.
Без синглтонов подобное решается простым созданием экземпляров классов.
Почему ты решил сделать именно так, через очевидно не обязательные синглтоны?
>DialogueSingleton.start_dialogue
>WorldDataSingleton.get_dialogue_point
Что не получится сделать из-за этих синглтонов:
1. Сплит-скрин мультиплеер: нужны от 2 до 4 диалогов.
2. Параллельный разговор с NPC: нужно от 2 диалогов и более.
3. Параллельные вселенные в игре: нужны разные ветки сохранения.
Без синглтонов подобное решается простым созданием экземпляров классов.
Почему ты решил сделать именно так, через очевидно не обязательные синглтоны?
>>4388
Нет пусть остается.
Нет пусть остается.
>>4388
Я здесь чтобы обсуждать какие-то фичи в движке, которые мне интересны.
Я здесь чтобы обсуждать какие-то фичи в движке, которые мне интересны.
>>4375
Может быть только одним - это прослойка перед железом/ОСью.
Может быть только одним - это основное API движка, а он один.
Наш диалог:
Я: не делай сиденье синглтоном, в машине их обычно несколько.
Ты: а вот двигатель в машине один, значит и сиденье тоже одно!
Я: не делай дверь синглтоном, в машине их обычно несколько.
Ты: а вот руль в машине один, значит и дверь только одна!
Я: вообще, двигателей и рулей может быть несколько...
Ты: а вот в моём запорожце их по одной штуке!!!
Я: а если тебе нужно будет вездеход сделать?
Ты: ряяяя, в запорожце так, значит так!!!
Я: а почему ты так привязался к этому?
Ты: а я уже сказал - запорожец! так!
Не чувствуешь проблему?..
>...Server..., IP, Input..., Native..., OS, Java..., GDExtension...
Может быть только одним - это прослойка перед железом/ОСью.
>ClassDB, Editor..., Engine..., Performance, Project..., Navigation...
Может быть только одним - это основное API движка, а он один.
Наш диалог:
Я: не делай сиденье синглтоном, в машине их обычно несколько.
Ты: а вот двигатель в машине один, значит и сиденье тоже одно!
Я: не делай дверь синглтоном, в машине их обычно несколько.
Ты: а вот руль в машине один, значит и дверь только одна!
Я: вообще, двигателей и рулей может быть несколько...
Ты: а вот в моём запорожце их по одной штуке!!!
Я: а если тебе нужно будет вездеход сделать?
Ты: ряяяя, в запорожце так, значит так!!!
Я: а почему ты так привязался к этому?
Ты: а я уже сказал - запорожец! так!
Не чувствуешь проблему?..
>>4399
>AudioServer может быть только один
>Как же так, баги когда игрок переключается с динамика на Bluetooth
>DisplayServer может быть только один
>Годами приходится добавлять поддержку второго глаза для ВиАр или второй монитор со своим разрешением
>PhysicsServer может быть только один
>Приходится городить костыли когда нужно две разных физических симуляции (например одна для платформера, а вторая для инвентаря).
>>4403
Смеюсь, показываю пальцем и фотографирую.
Смеюсь, показываю пальцем и фотографирую.
>>4244
Вот здесь проблема. В кривых руках кодера, который полез нажимать красную кнопку, на которой написано не нажимать. Не зная, что под капотом эта кнопка делает, почему нажимать нельзя и какие могут быть скрытые последствия.
Это всё равно что засунуть посторонний металлический предмет в розетку, а потом жаловаться, что током ёбнуло - ну ты же смог его туда запихнуть, значит это было можно, да?
>СКАЗАНО НЕ ИСПОЛЬЗОВАТЬ, НУ ДА ЛАДНО
Вот здесь проблема. В кривых руках кодера, который полез нажимать красную кнопку, на которой написано не нажимать. Не зная, что под капотом эта кнопка делает, почему нажимать нельзя и какие могут быть скрытые последствия.
Это всё равно что засунуть посторонний металлический предмет в розетку, а потом жаловаться, что током ёбнуло - ну ты же смог его туда запихнуть, значит это было можно, да?
>>4411
Это защита от случайного попадания предметов. От преднамеренного поможет только живительная эвтаназия.
Это защита от случайного попадания предметов. От преднамеренного поможет только живительная эвтаназия.
93 Кб, 266x159Есть идеи как сделать круговой эффект кулдауна без шейдера? Легко сделать заливку сверху-вниз и выдать это за кулдаун, но хотелось бы как положено - круговой.
С шейдером уже сделал. Теперь интересно без.
С шейдером уже сделал. Теперь интересно без.
>>4418
Да, без шейдеров. Оно использует draw_polygon() из https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
Да, без шейдеров. Оно использует draw_polygon() из https://docs.godotengine.org/en/stable/tutorials/2d/custom_drawing_in_2d.html
Чего бы я делал без годотик-треда. Ебаное одиночество.
Ну и че этим красноглазикам так не нравится иф елс?
Работает же. Нахуя тогда вобще в яп добавляют условия?
Работает же. Нахуя тогда вобще в яп добавляют условия?
>>4436
поч не нравится? мне все нравится. главное не делать много этажей.
поч не нравится? мне все нравится. главное не делать много этажей.
>>4428
Так, важен не факт наличия шейдера, а тяжелость его вычислений.
Например шейдеры который лежит на godotshaders выглядит очень тяжелым.
Во первых там fragment(), это вычисления для каждого пикселя, а не для полигона. И они все с синусами. С нодой по идее один раз считается при повороте (ну может еще раза 4 для вершин прямоугольрника).
Во вторых там if, в шейдерах это насколько помню сбивает конвеер.
А clip, скорее всего, превращается во встроенную в opengl функцию отсечения.
>>4444
Мне игры делать неинтересно, писал же выше. А оптимизон под веб/мобилки интересно.
Так, важен не факт наличия шейдера, а тяжелость его вычислений.
Например шейдеры который лежит на godotshaders выглядит очень тяжелым.
Во первых там fragment(), это вычисления для каждого пикселя, а не для полигона. И они все с синусами. С нодой по идее один раз считается при повороте (ну может еще раза 4 для вершин прямоугольрника).
Во вторых там if, в шейдерах это насколько помню сбивает конвеер.
А clip, скорее всего, превращается во встроенную в opengl функцию отсечения.
>>4444
Мне игры делать неинтересно, писал же выше. А оптимизон под веб/мобилки интересно.
>>4465
Не увидите, я анонимен.
Не увидите, я анонимен.
>>4471
Чего-то там про круелти сквад? Не интересует как жанр, но видел всплывало повсюду. Удачи ему.
Чего-то там про круелти сквад? Не интересует как жанр, но видел всплывало повсюду. Удачи ему.
>>4424
>>4458
А ты знаешь, как реализован этот клипинг?
Не знаю, попиксельный ли клипинг или нет, но:
Возможно, лучше использовать полигон:
https://docs.godotengine.org/en/stable/classes/class_polygon2d.html
И двигать одну из вершин.
Алсо, если тебя интересует оптимизация:
1. Реализуешь каждый вариант по отдельности.
2. Размещаешь десятки тысяч каждого варианта.
3. Собираешь статистику на реальном устройстве.
4. Смотришь, какой вариант тормозит меньше всего.
Всё остальное - бесполезное теоретизирование.
Ты симуляцию делать хотел, зачем прогресс-бар?
>клипуем
>>4458
>вычисления для каждого пикселя
А ты знаешь, как реализован этот клипинг?
Не знаю, попиксельный ли клипинг или нет, но:
>Note: Clipping nodes cannot be nested or placed within CanvasGroups. If an ancestor of this node clips its children or is a CanvasGroup, then this node's clip mode should be set to CLIP_CHILDREN_DISABLED to avoid unexpected behavior.
>оптимизон под веб/мобилки интересно
Возможно, лучше использовать полигон:
https://docs.godotengine.org/en/stable/classes/class_polygon2d.html
И двигать одну из вершин.
Алсо, если тебя интересует оптимизация:
1. Реализуешь каждый вариант по отдельности.
2. Размещаешь десятки тысяч каждого варианта.
3. Собираешь статистику на реальном устройстве.
4. Смотришь, какой вариант тормозит меньше всего.
Всё остальное - бесполезное теоретизирование.
>Мне игры делать неинтересно
Ты симуляцию делать хотел, зачем прогресс-бар?
>>4410
>>4414
Ты не понимаешь психологии человеческой.
Если что-то лежит в открытом виде, как оголённые провода под напряжением - кто-то когда-то за них обязательно схватится голыми руками. Не "дурак", а случайно, по ошибке, от усталости, от лени и т.д.
Если провода спрятаны в ящик, что нужно открыть, прежде чем коснуться провода - это сильно снижает вероятность случайных и ошибочных действий, но уставший, ленивый или забывчивый всё же может проигнорировать перчатки/отключение питания.
Если ящик с проводами физически нельзя открыть, сохранив питание цепи - это снижает вероятность в ситуации с усталостью/ленью - перчатки больше не нужны. Если ящик с проводами закрыт на замок, а ключик у ответственного контролёра - это снижает вероятность забывчивого/ленивого залезть внутрь.
Если человек действительно ХОЧЕТ схватиться за оголённые провода и получить удар током, тогда он обязательно найдёт способ это сделать. Но все эти "защиты от дурака" не против злоумышленников, а против случайных, ошибочных, непреднамеренных действий, которые допускают даже умные люди, особенно уставшие после долгой тяжёлой работы.
Так и с public/private полями. Да, ты всегда можешь забраться в исходники, заменить private на public и получить доступ к тому, к чему не следует. Но это потребует осознанных усилий, а не обычного кода снаружи класса, что получает доступ к чему-то. Т.е. предупреждение компилятора/интерпретатора о потенциально непреднамеренной ошибке более чем достаточно, чтоб избежать 99% проблем в будущем.
Комментарии тут не решают проблему, т.к. их нужно сознательно читать в исходниках. Предупреждение компилятора/интерпретатора выводится туда, где допускается потенциальная ошибка, в точку вызова.
Это просто удобнее. В том числе умным людям.
>кодера, который полез нажимать
>>4414
>От преднамеренного поможет только
Ты не понимаешь психологии человеческой.
Если что-то лежит в открытом виде, как оголённые провода под напряжением - кто-то когда-то за них обязательно схватится голыми руками. Не "дурак", а случайно, по ошибке, от усталости, от лени и т.д.
Если провода спрятаны в ящик, что нужно открыть, прежде чем коснуться провода - это сильно снижает вероятность случайных и ошибочных действий, но уставший, ленивый или забывчивый всё же может проигнорировать перчатки/отключение питания.
Если ящик с проводами физически нельзя открыть, сохранив питание цепи - это снижает вероятность в ситуации с усталостью/ленью - перчатки больше не нужны. Если ящик с проводами закрыт на замок, а ключик у ответственного контролёра - это снижает вероятность забывчивого/ленивого залезть внутрь.
Если человек действительно ХОЧЕТ схватиться за оголённые провода и получить удар током, тогда он обязательно найдёт способ это сделать. Но все эти "защиты от дурака" не против злоумышленников, а против случайных, ошибочных, непреднамеренных действий, которые допускают даже умные люди, особенно уставшие после долгой тяжёлой работы.
Так и с public/private полями. Да, ты всегда можешь забраться в исходники, заменить private на public и получить доступ к тому, к чему не следует. Но это потребует осознанных усилий, а не обычного кода снаружи класса, что получает доступ к чему-то. Т.е. предупреждение компилятора/интерпретатора о потенциально непреднамеренной ошибке более чем достаточно, чтоб избежать 99% проблем в будущем.
Комментарии тут не решают проблему, т.к. их нужно сознательно читать в исходниках. Предупреждение компилятора/интерпретатора выводится туда, где допускается потенциальная ошибка, в точку вызова.
Это просто удобнее. В том числе умным людям.
13,9 Мб, webm,854x480, 1:48
>>4484
У меня еще родилась идея сделать шейдер, только не фрагментный, а вершинный - рисовать полигон смещая вершину. Приду с прогулки попробую.
Не пользуюсь пока, да и не помню есть ли в 3-ке.
В смысле зачем? А если мне надо симуляцию с десятками тысяч прогресс баров? Как в CivIdle. Симуляцию сапера 10000х10000 тут уже делали, вроде.
Это эксперимент, а эксперимент проверяет теорию. А ее сначала можно построить в голове, на основе знания, то есть представить цепочку как проходят операции, тоже в каком то смысле игра-паззл. Если результат эксперимента не совпадет с теорией, то теория корректируется. А поскольку я занимаюсь оптимизациями по работе много лет, то и ошибаюсь со временем реже. Вот прям практически гарантировано фрагментный шейдер с if- для каждого пикселя медленнее.
У меня еще родилась идея сделать шейдер, только не фрагментный, а вершинный - рисовать полигон смещая вершину. Приду с прогулки попробую.
>CanvasGroups
Не пользуюсь пока, да и не помню есть ли в 3-ке.
>Ты симуляцию делать хотел, зачем прогресс-бар?
В смысле зачем? А если мне надо симуляцию с десятками тысяч прогресс баров? Как в CivIdle. Симуляцию сапера 10000х10000 тут уже делали, вроде.
>1. Реализуешь каждый вариант по отдельности.
>2. Размещаешь десятки тысяч каждого варианта.
>3. Собираешь статистику на реальном устройстве.
>4. Смотришь, какой вариант тормозит меньше всего.
>Всё остальное - бесполезное теоретизирование.
Это эксперимент, а эксперимент проверяет теорию. А ее сначала можно построить в голове, на основе знания, то есть представить цепочку как проходят операции, тоже в каком то смысле игра-паззл. Если результат эксперимента не совпадет с теорией, то теория корректируется. А поскольку я занимаюсь оптимизациями по работе много лет, то и ошибаюсь со временем реже. Вот прям практически гарантировано фрагментный шейдер с if- для каждого пикселя медленнее.
>>4490
Суть шейдера - нарисовать КРАСИВО. Если нужен переливающийся всеми цветами радуги градиент с интересными волнообразными колебаниями, твои оптимизации сразу идут лесом. И как следствие, потраченное на них время - потрачено впустую. Вот поэтому всегда говорят, что преждевременные оптимизации - корень всех зол, и нужно сначала состряпать рабочую систему/игру из того, что есть.
Теория может быть выведена из экспериментов. В геймдизайне ты мало что можешь предсказать теоретическими размышлениями об игроках. А оптимизации должны идти после геймдизайна. Т.е. стряпаешь сырой тормозной прототип, потом, если сработает дизайн, делаешь варианты оптимизации. Нодовая система Godot как раз на это заточена.
Тогда ты отображаешь максимум 100 таких баров, остальные скрываются за пределами экрана, ибо отображаются только когда камера приближена. И упрощаешь геометрию баров до прямоугольников. Заменяешь бары на тробберы. Объединяешь сотни отдельных юнитов в группы с одним баром. И т.п. Универсального решения нет, нужно смотреть игру.
На видео нет баров, там только тробберы:
https://en.wikipedia.org/wiki/Throbber
https://ru.wikipedia.org/wiki/Троббер
А, описанного выше клипинга в тройке вообще нет:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-clip-children
В тройке раньше для этого юзали Light2D:
https://docs.godotengine.org/en/3.6/classes/class_light2d.html
Клипинг прямоугольников, как я понимаю, проще. Поэтому твой способ, в теории, может работать.
https://docs.godotengine.org/en/3.6/classes/class_control.html#class-control-property-rect-clip-content
В актуальной версии переименовали:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-clip-contents
Вершинный шейдер будет эффективен только если регулярно меняешь позиции вершин. Если бар очень медленный, то вершинный шейдер тоже избыточен. Впрочем, разница наверняка минимальная.
Повторюсь, если нужен троббер - это отдельная тема. Вращающийся троббер равно вращающийся спрайт, особенно если без дополнительных эффектов.
У тебя что-нибудь играбельное есть?
Или ты пока делаешь компоненты?
>фрагментный шейдер
Суть шейдера - нарисовать КРАСИВО. Если нужен переливающийся всеми цветами радуги градиент с интересными волнообразными колебаниями, твои оптимизации сразу идут лесом. И как следствие, потраченное на них время - потрачено впустую. Вот поэтому всегда говорят, что преждевременные оптимизации - корень всех зол, и нужно сначала состряпать рабочую систему/игру из того, что есть.
>эксперимент проверяет теорию
Теория может быть выведена из экспериментов. В геймдизайне ты мало что можешь предсказать теоретическими размышлениями об игроках. А оптимизации должны идти после геймдизайна. Т.е. стряпаешь сырой тормозной прототип, потом, если сработает дизайн, делаешь варианты оптимизации. Нодовая система Godot как раз на это заточена.
>если мне надо симуляцию с десятками тысяч
Тогда ты отображаешь максимум 100 таких баров, остальные скрываются за пределами экрана, ибо отображаются только когда камера приближена. И упрощаешь геометрию баров до прямоугольников. Заменяешь бары на тробберы. Объединяешь сотни отдельных юнитов в группы с одним баром. И т.п. Универсального решения нет, нужно смотреть игру.
>Как в CivIdle
На видео нет баров, там только тробберы:
https://en.wikipedia.org/wiki/Throbber
https://ru.wikipedia.org/wiki/Троббер
>есть ли в 3-ке
А, описанного выше клипинга в тройке вообще нет:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-clip-children
В тройке раньше для этого юзали Light2D:
https://docs.godotengine.org/en/3.6/classes/class_light2d.html
Клипинг прямоугольников, как я понимаю, проще. Поэтому твой способ, в теории, может работать.
https://docs.godotengine.org/en/3.6/classes/class_control.html#class-control-property-rect-clip-content
В актуальной версии переименовали:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-clip-contents
>вершинный
Вершинный шейдер будет эффективен только если регулярно меняешь позиции вершин. Если бар очень медленный, то вершинный шейдер тоже избыточен. Впрочем, разница наверняка минимальная.
Повторюсь, если нужен троббер - это отдельная тема. Вращающийся троббер равно вращающийся спрайт, особенно если без дополнительных эффектов.
У тебя что-нибудь играбельное есть?
Или ты пока делаешь компоненты?
>>4490
Суть шейдера - нарисовать КРАСИВО. Если нужен переливающийся всеми цветами радуги градиент с интересными волнообразными колебаниями, твои оптимизации сразу идут лесом. И как следствие, потраченное на них время - потрачено впустую. Вот поэтому всегда говорят, что преждевременные оптимизации - корень всех зол, и нужно сначала состряпать рабочую систему/игру из того, что есть.
Теория может быть выведена из экспериментов. В геймдизайне ты мало что можешь предсказать теоретическими размышлениями об игроках. А оптимизации должны идти после геймдизайна. Т.е. стряпаешь сырой тормозной прототип, потом, если сработает дизайн, делаешь варианты оптимизации. Нодовая система Godot как раз на это заточена.
Тогда ты отображаешь максимум 100 таких баров, остальные скрываются за пределами экрана, ибо отображаются только когда камера приближена. И упрощаешь геометрию баров до прямоугольников. Заменяешь бары на тробберы. Объединяешь сотни отдельных юнитов в группы с одним баром. И т.п. Универсального решения нет, нужно смотреть игру.
На видео нет баров, там только тробберы:
https://en.wikipedia.org/wiki/Throbber
https://ru.wikipedia.org/wiki/Троббер
А, описанного выше клипинга в тройке вообще нет:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-clip-children
В тройке раньше для этого юзали Light2D:
https://docs.godotengine.org/en/3.6/classes/class_light2d.html
Клипинг прямоугольников, как я понимаю, проще. Поэтому твой способ, в теории, может работать.
https://docs.godotengine.org/en/3.6/classes/class_control.html#class-control-property-rect-clip-content
В актуальной версии переименовали:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-clip-contents
Вершинный шейдер будет эффективен только если регулярно меняешь позиции вершин. Если бар очень медленный, то вершинный шейдер тоже избыточен. Впрочем, разница наверняка минимальная.
Повторюсь, если нужен троббер - это отдельная тема. Вращающийся троббер равно вращающийся спрайт, особенно если без дополнительных эффектов.
У тебя что-нибудь играбельное есть?
Или ты пока делаешь компоненты?
>фрагментный шейдер
Суть шейдера - нарисовать КРАСИВО. Если нужен переливающийся всеми цветами радуги градиент с интересными волнообразными колебаниями, твои оптимизации сразу идут лесом. И как следствие, потраченное на них время - потрачено впустую. Вот поэтому всегда говорят, что преждевременные оптимизации - корень всех зол, и нужно сначала состряпать рабочую систему/игру из того, что есть.
>эксперимент проверяет теорию
Теория может быть выведена из экспериментов. В геймдизайне ты мало что можешь предсказать теоретическими размышлениями об игроках. А оптимизации должны идти после геймдизайна. Т.е. стряпаешь сырой тормозной прототип, потом, если сработает дизайн, делаешь варианты оптимизации. Нодовая система Godot как раз на это заточена.
>если мне надо симуляцию с десятками тысяч
Тогда ты отображаешь максимум 100 таких баров, остальные скрываются за пределами экрана, ибо отображаются только когда камера приближена. И упрощаешь геометрию баров до прямоугольников. Заменяешь бары на тробберы. Объединяешь сотни отдельных юнитов в группы с одним баром. И т.п. Универсального решения нет, нужно смотреть игру.
>Как в CivIdle
На видео нет баров, там только тробберы:
https://en.wikipedia.org/wiki/Throbber
https://ru.wikipedia.org/wiki/Троббер
>есть ли в 3-ке
А, описанного выше клипинга в тройке вообще нет:
https://docs.godotengine.org/en/stable/classes/class_canvasitem.html#class-canvasitem-property-clip-children
В тройке раньше для этого юзали Light2D:
https://docs.godotengine.org/en/3.6/classes/class_light2d.html
Клипинг прямоугольников, как я понимаю, проще. Поэтому твой способ, в теории, может работать.
https://docs.godotengine.org/en/3.6/classes/class_control.html#class-control-property-rect-clip-content
В актуальной версии переименовали:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-clip-contents
>вершинный
Вершинный шейдер будет эффективен только если регулярно меняешь позиции вершин. Если бар очень медленный, то вершинный шейдер тоже избыточен. Впрочем, разница наверняка минимальная.
Повторюсь, если нужен троббер - это отдельная тема. Вращающийся троббер равно вращающийся спрайт, особенно если без дополнительных эффектов.
У тебя что-нибудь играбельное есть?
Или ты пока делаешь компоненты?
45 Кб, 427x347>>4527
А может не идут - градиент можно пустить и по моему квадрату и скорее всего он все еще будет быстрее.
А у меня не должны.
Ну в принципе да можно замутить что-то наподобие радара из полупрозрачной текстуры. А может я захочу чтобы там кулдаун у каждого был независимый.
А может это преждевременная оптимизация.
Так у меня в примере и была 3-йка и рект клиппинг.
Если повернуть родительский объект, то клиппинг работает внутри нового bounding box, возможно этому можно придумать какие то применения для спецэффектов.
Сказал же, мне это сейчас неинтересно. Может на Ludum dare сделаю что то за пару дней. Или до ТВГ подожду.
> Если нужен переливающийся всеми цветами радуги градиент с интересными волнообразными колебаниями, твои оптимизации сразу идут лесом.
А может не идут - градиент можно пустить и по моему квадрату и скорее всего он все еще будет быстрее.
>А оптимизации должны идти после геймдизайна
А у меня не должны.
>тробберы
Ну в принципе да можно замутить что-то наподобие радара из полупрозрачной текстуры. А может я захочу чтобы там кулдаун у каждого был независимый.
> упрощаешь геометрию баров до прямоугольников. Заменяешь бары на тробберы. Объединяешь сотни отдельных юнитов в группы с одним баром
А может это преждевременная оптимизация.
>А, описанного выше клипинга в тройке вообще нет:
Так у меня в примере и была 3-йка и рект клиппинг.
Если повернуть родительский объект, то клиппинг работает внутри нового bounding box, возможно этому можно придумать какие то применения для спецэффектов.
>У тебя что-нибудь играбельное есть?
>Геймдизайн, геймдизайн
Сказал же, мне это сейчас неинтересно. Может на Ludum dare сделаю что то за пару дней. Или до ТВГ подожду.
Как можно хранить прогрессию в игре-песочнице? Как из маркера прогресса доставать доступные диалоги и прочее? Пока сделал парочку простых булей для проверок, но это ведь немасштабируемая тема. Сейчас добавляю мясо, и уже не хочется с этими булями работать. А дальше ведь только хуже. Есть получше варианты?
>>4556
Я просто сохраняю всю сцену в packed scene, дальше загружаю и продолжаю. В рот ебал вручную все восстанавливать.
Я просто сохраняю всю сцену в packed scene, дальше загружаю и продолжаю. В рот ебал вручную все восстанавливать.
>>4557
Это про диалоги? Ссылки на внутренние (внутри игры) кастомные ресурсы диалоговой очереди внутри сейва? Или для чего-то еще можно ресурсы уместно в данном контексте применить? Для сохранения прогресса я просто не представляю как их можно использовать. Это ведь те же самые були будут.
>>4559
Не знал, что так можно. А поля автолод классов такой подход затрагивает?
Это про диалоги? Ссылки на внутренние (внутри игры) кастомные ресурсы диалоговой очереди внутри сейва? Или для чего-то еще можно ресурсы уместно в данном контексте применить? Для сохранения прогресса я просто не представляю как их можно использовать. Это ведь те же самые були будут.
>>4559
Не знал, что так можно. А поля автолод классов такой подход затрагивает?
>>4560
Используй силу ООП. Заведи во всех важных классах функции save и load. В save сохраняй только важное геймплейное об объекте. Например позицию, кулдауны итд. А не всякие там состояния анимационного дерева. И каждому объекту выдай уникальный ID, и при сохранении например выбранной врагом цели сохраняй не ссылку на врага, а этот ID. Потом при спавне соответственно функцией load располагаешь все на нужные места, инициализируешь стейтмашины в нужное состояние. Вообще какие то готовые аддоны на это есть, я не пробовал правда.
Используй силу ООП. Заведи во всех важных классах функции save и load. В save сохраняй только важное геймплейное об объекте. Например позицию, кулдауны итд. А не всякие там состояния анимационного дерева. И каждому объекту выдай уникальный ID, и при сохранении например выбранной врагом цели сохраняй не ссылку на врага, а этот ID. Потом при спавне соответственно функцией load располагаешь все на нужные места, инициализируешь стейтмашины в нужное состояние. Вообще какие то готовые аддоны на это есть, я не пробовал правда.
Самый топ чит, который я нашел, это расписать кучу конкретных разных задач, и делать их под настроение. Сегодня лень кодить? Отлично, вот задача для простенького 3д моделирования, вот для саунда, а вот тут текста не хватает. Как ммо, где под разное настроение идешь в разные локации и делаешь разные активити. Чем выше потенциал к разнообразию, тем ниже шанс что сегодня ты не найдешь интересной для себя активности.
У меня все.
У меня все.
>>4586
Я пошел еще дальше - даже не расписываю ничего. Что нравится, тем и занимаюсь. Правда, игру так и не доделал.
Я пошел еще дальше - даже не расписываю ничего. Что нравится, тем и занимаюсь. Правда, игру так и не доделал.
>>4588
Тоже так делал, пока не застрял с сегодня лень выдумывать задачи, нужны готовые
Тоже так делал, пока не застрял с сегодня лень выдумывать задачи, нужны готовые
>>4586
У легких задач больший шанс оказаться выполненными, причем быстро. И остаются сложные длинные задачи в которых ты застреваешь, и мозг быстро зарезает весь бюджет допамина выделенный на эту затею. Конец.
Тебе нужно в первую очередь умение деребанить большие задачи на маленкие, и воспринимать их соответственно. Это главный скилл, который появляется с опытом. Чтобы получить этот скилл, нужно просто начать и делать, понимая что ошибки это часть процесса. Одновременно почитывая книжки по сабжу(системное мышление) и консультируясь с нейронкой. Плставив этот скилл на рельсы ты получаешь чит на неограниченный допамин для решения задач любой глубины.
У легких задач больший шанс оказаться выполненными, причем быстро. И остаются сложные длинные задачи в которых ты застреваешь, и мозг быстро зарезает весь бюджет допамина выделенный на эту затею. Конец.
Тебе нужно в первую очередь умение деребанить большие задачи на маленкие, и воспринимать их соответственно. Это главный скилл, который появляется с опытом. Чтобы получить этот скилл, нужно просто начать и делать, понимая что ошибки это часть процесса. Одновременно почитывая книжки по сабжу(системное мышление) и консультируясь с нейронкой. Плставив этот скилл на рельсы ты получаешь чит на неограниченный допамин для решения задач любой глубины.
>>4556
Если хочешь, чтоб игрок мог редактировать в Блокноте: JSON.
Если хочешь сжато/чтоб игрок не мог править: бинарные файлы.
Если много сложных данных: база данных, как упомянул >>4558
Если ты про квесты/линейный сюжет, то это делается примерно так:
1. Есть глобальная последовательность ID (целые числа), которые переключаются друг за другом при достижении игроком определённых триггеров - например, завершение квестов. Это сюжет. Он может быть разветвлённым и нелинейным - главное, чтобы ID были уникальными для каждого этапа/эпизода/главы сюжета. Для простого наглядного примера (без графики и геймплея, чисто сюжет) - посмотри, как создаются и хранятся истории в https://twinery.org/ - его и в более сложных играх используют. "Профессиональные" инструменты отличаются только количеством дополнительных свистелок и тормозами.
2. Глобальная последовательность может делиться на линейки квестов. У каждой линейки квестов есть своя последовательность ID, свои квестодатели, свои условия перехода, свои награды и т.д. Т.е. игрок может проходить параллельно несколько независимых квестовых линеек - в сейве, соответственно, помимо/вместо одного глобального числа-ID будет набор из нескольких чисел. Они могут интегрироваться в глобальный сюжет, если он есть, например, "следующая глава начинается только если игрок завершил N-ное число побочных линеек квестов на текущей локации".
Также есть много плагинов с готовыми решениями - смотри сам, что нравится.
>>4557
>>4559
Записывать и считывать ресурсы (.tres/.res и .tscn/.scn) на компьютере игрока из произвольного места на диске чревато заражением вирусом в худшем случае (т.к. Godot автоматически выполняет любые загруженные скрипты, а антивирусы эти скрипты никак не распознают, а игроки постоянно обмениваются сейвами; давно уже предлагали сделать песочницу/вырубить скрипты из этих файлов) или просто тяжёлой поломкой сейва в случае неудачного обновления игры (твои скрипты/сцены или какие-то изменения API в новой версии движка), что будет сложно восстановить автоматически и игроку придётся начинать игру с начала. Система ресурсов и сцен удобна только для данных, которые ты экспортируешь в .pck и не пересохраняешь на компе игрока.
Надёжнее хранить все сохраняемые данные в JSON/XML/INI/бинарных файлах/базе данных и заниматься сохранением и восстановлением вручную. Однако, XML избыточно сложный, а INI (ConfigFile) слишком ограниченный. Поэтому либо JSON/бинарные файлы, либо подключать СУБД на свой выбор.
Не надо бояться "ручного" сохранения/загрузки. Там всё легко абстрагируется и управляется.
>Как можно хранить прогрессию в игре-песочнице?
Если хочешь, чтоб игрок мог редактировать в Блокноте: JSON.
Если хочешь сжато/чтоб игрок не мог править: бинарные файлы.
Если много сложных данных: база данных, как упомянул >>4558
>Как из маркера прогресса доставать доступные диалоги и прочее?
Если ты про квесты/линейный сюжет, то это делается примерно так:
1. Есть глобальная последовательность ID (целые числа), которые переключаются друг за другом при достижении игроком определённых триггеров - например, завершение квестов. Это сюжет. Он может быть разветвлённым и нелинейным - главное, чтобы ID были уникальными для каждого этапа/эпизода/главы сюжета. Для простого наглядного примера (без графики и геймплея, чисто сюжет) - посмотри, как создаются и хранятся истории в https://twinery.org/ - его и в более сложных играх используют. "Профессиональные" инструменты отличаются только количеством дополнительных свистелок и тормозами.
2. Глобальная последовательность может делиться на линейки квестов. У каждой линейки квестов есть своя последовательность ID, свои квестодатели, свои условия перехода, свои награды и т.д. Т.е. игрок может проходить параллельно несколько независимых квестовых линеек - в сейве, соответственно, помимо/вместо одного глобального числа-ID будет набор из нескольких чисел. Они могут интегрироваться в глобальный сюжет, если он есть, например, "следующая глава начинается только если игрок завершил N-ное число побочных линеек квестов на текущей локации".
Также есть много плагинов с готовыми решениями - смотри сам, что нравится.
>>4557
>Ресурсы. Кастомные ресурсы.
>>4559
>сохраняю всю сцену в packed scene
Записывать и считывать ресурсы (.tres/.res и .tscn/.scn) на компьютере игрока из произвольного места на диске чревато заражением вирусом в худшем случае (т.к. Godot автоматически выполняет любые загруженные скрипты, а антивирусы эти скрипты никак не распознают, а игроки постоянно обмениваются сейвами; давно уже предлагали сделать песочницу/вырубить скрипты из этих файлов) или просто тяжёлой поломкой сейва в случае неудачного обновления игры (твои скрипты/сцены или какие-то изменения API в новой версии движка), что будет сложно восстановить автоматически и игроку придётся начинать игру с начала. Система ресурсов и сцен удобна только для данных, которые ты экспортируешь в .pck и не пересохраняешь на компе игрока.
Надёжнее хранить все сохраняемые данные в JSON/XML/INI/бинарных файлах/базе данных и заниматься сохранением и восстановлением вручную. Однако, XML избыточно сложный, а INI (ConfigFile) слишком ограниченный. Поэтому либо JSON/бинарные файлы, либо подключать СУБД на свой выбор.
Не надо бояться "ручного" сохранения/загрузки. Там всё легко абстрагируется и управляется.
>>4556
Если хочешь, чтоб игрок мог редактировать в Блокноте: JSON.
Если хочешь сжато/чтоб игрок не мог править: бинарные файлы.
Если много сложных данных: база данных, как упомянул >>4558
Если ты про квесты/линейный сюжет, то это делается примерно так:
1. Есть глобальная последовательность ID (целые числа), которые переключаются друг за другом при достижении игроком определённых триггеров - например, завершение квестов. Это сюжет. Он может быть разветвлённым и нелинейным - главное, чтобы ID были уникальными для каждого этапа/эпизода/главы сюжета. Для простого наглядного примера (без графики и геймплея, чисто сюжет) - посмотри, как создаются и хранятся истории в https://twinery.org/ - его и в более сложных играх используют. "Профессиональные" инструменты отличаются только количеством дополнительных свистелок и тормозами.
2. Глобальная последовательность может делиться на линейки квестов. У каждой линейки квестов есть своя последовательность ID, свои квестодатели, свои условия перехода, свои награды и т.д. Т.е. игрок может проходить параллельно несколько независимых квестовых линеек - в сейве, соответственно, помимо/вместо одного глобального числа-ID будет набор из нескольких чисел. Они могут интегрироваться в глобальный сюжет, если он есть, например, "следующая глава начинается только если игрок завершил N-ное число побочных линеек квестов на текущей локации".
Также есть много плагинов с готовыми решениями - смотри сам, что нравится.
>>4557
>>4559
Записывать и считывать ресурсы (.tres/.res и .tscn/.scn) на компьютере игрока из произвольного места на диске чревато заражением вирусом в худшем случае (т.к. Godot автоматически выполняет любые загруженные скрипты, а антивирусы эти скрипты никак не распознают, а игроки постоянно обмениваются сейвами; давно уже предлагали сделать песочницу/вырубить скрипты из этих файлов) или просто тяжёлой поломкой сейва в случае неудачного обновления игры (твои скрипты/сцены или какие-то изменения API в новой версии движка), что будет сложно восстановить автоматически и игроку придётся начинать игру с начала. Система ресурсов и сцен удобна только для данных, которые ты экспортируешь в .pck и не пересохраняешь на компе игрока.
Надёжнее хранить все сохраняемые данные в JSON/XML/INI/бинарных файлах/базе данных и заниматься сохранением и восстановлением вручную. Однако, XML избыточно сложный, а INI (ConfigFile) слишком ограниченный. Поэтому либо JSON/бинарные файлы, либо подключать СУБД на свой выбор.
Не надо бояться "ручного" сохранения/загрузки. Там всё легко абстрагируется и управляется.
>Как можно хранить прогрессию в игре-песочнице?
Если хочешь, чтоб игрок мог редактировать в Блокноте: JSON.
Если хочешь сжато/чтоб игрок не мог править: бинарные файлы.
Если много сложных данных: база данных, как упомянул >>4558
>Как из маркера прогресса доставать доступные диалоги и прочее?
Если ты про квесты/линейный сюжет, то это делается примерно так:
1. Есть глобальная последовательность ID (целые числа), которые переключаются друг за другом при достижении игроком определённых триггеров - например, завершение квестов. Это сюжет. Он может быть разветвлённым и нелинейным - главное, чтобы ID были уникальными для каждого этапа/эпизода/главы сюжета. Для простого наглядного примера (без графики и геймплея, чисто сюжет) - посмотри, как создаются и хранятся истории в https://twinery.org/ - его и в более сложных играх используют. "Профессиональные" инструменты отличаются только количеством дополнительных свистелок и тормозами.
2. Глобальная последовательность может делиться на линейки квестов. У каждой линейки квестов есть своя последовательность ID, свои квестодатели, свои условия перехода, свои награды и т.д. Т.е. игрок может проходить параллельно несколько независимых квестовых линеек - в сейве, соответственно, помимо/вместо одного глобального числа-ID будет набор из нескольких чисел. Они могут интегрироваться в глобальный сюжет, если он есть, например, "следующая глава начинается только если игрок завершил N-ное число побочных линеек квестов на текущей локации".
Также есть много плагинов с готовыми решениями - смотри сам, что нравится.
>>4557
>Ресурсы. Кастомные ресурсы.
>>4559
>сохраняю всю сцену в packed scene
Записывать и считывать ресурсы (.tres/.res и .tscn/.scn) на компьютере игрока из произвольного места на диске чревато заражением вирусом в худшем случае (т.к. Godot автоматически выполняет любые загруженные скрипты, а антивирусы эти скрипты никак не распознают, а игроки постоянно обмениваются сейвами; давно уже предлагали сделать песочницу/вырубить скрипты из этих файлов) или просто тяжёлой поломкой сейва в случае неудачного обновления игры (твои скрипты/сцены или какие-то изменения API в новой версии движка), что будет сложно восстановить автоматически и игроку придётся начинать игру с начала. Система ресурсов и сцен удобна только для данных, которые ты экспортируешь в .pck и не пересохраняешь на компе игрока.
Надёжнее хранить все сохраняемые данные в JSON/XML/INI/бинарных файлах/базе данных и заниматься сохранением и восстановлением вручную. Однако, XML избыточно сложный, а INI (ConfigFile) слишком ограниченный. Поэтому либо JSON/бинарные файлы, либо подключать СУБД на свой выбор.
Не надо бояться "ручного" сохранения/загрузки. Там всё легко абстрагируется и управляется.
8 Кб, 380x450>>4556 >>4604
Приведу пример, как это можно оформить в коде.
Допустим, есть три+ главы сюжета и квест "ограбление банка":
Как триггерить каждый из этапов, что, как и где спавнить - дело твоё.
В больших ААА-играх плюс-минус такая же система используется...
Приведу пример, как это можно оформить в коде.
Допустим, есть три+ главы сюжета и квест "ограбление банка":
>bank.tscn / bank.gd
># save_data может быть локальным для этого экземпляра банка
>func load_state(save_data: SaveData) -> void:
>_ match save_data["story"].phase:
>_ _ 1: # первая глава: банк в норме (сюжет о чём-то другом идёт)
>_ _ _ spawn_default_state() # банк - всего лишь декорация
>_ _ 2: # вторая глава: игрок обнаружил, что банк грабят
>_ _ _ match save_data["bank"].phase:
>_ _ _ _ 1: spawn_bandits() # игрок поблизости - начато ограбление
>_ _ _ _ 2: spawn_cops(false) # приехали копы, игрок их не трогал
>_ _ _ _ 3: spawn_cops(true) # приехали копы, игрок в них пострелял
>_ _ 3: # третья глава: после ограбления
>_ _ _ match save_data["bank"].phase:
>_ _ _ _ 4: spawn_robbed_state() # банк ограблен и закрыт (3 -> 4)
>_ _ _ _ 5: spawn_with_cute_maid() # в банк ходит горничная (2 -> 5)
>_ _ _ _ 6: spawn_default_state() # игрок нанял горничную (5 -> 6)
>_ _ _: # все остальные главы после третьей
>_ _ _ spawn_default_state() # банк восстановлен или горничная ушла
Как триггерить каждый из этапов, что, как и где спавнить - дело твоё.
В больших ААА-играх плюс-минус такая же система используется...
>>4604
Думал об этом, пришел к выводу что во-первых сам я так никогда не делал, а во-вторых что мне пофиг на людей, которые качают рандомное дерьмо из интернета. Таким везде соломки не подложишь, не сейвы так вирусный чит энжн скачают, а страдать с сейвами я ради них не хочу.
Аргумент с поломкой сейва актуален и для классических сейвов в JSON/XML/whatever. Знаем мы эти истории, когда разработчикам приходилось городить целую цепочку конверторов сейвов, от игры версии 1 до игры версии 9000, и все равно оно ломалось. А потом в чейнджлогах ААА игорь видишь "для фичи Х придется начать новую игру".
А у меня буквально 3 строки кода и идеально полное сохранение/загрузка всего.
>Записывать и считывать ресурсы (.tres/.res и .tscn/.scn) на компьютере игрока из произвольного места на диске чревато заражением вирусом в худшем случае
>а игроки постоянно обмениваются сейвами
Думал об этом, пришел к выводу что во-первых сам я так никогда не делал, а во-вторых что мне пофиг на людей, которые качают рандомное дерьмо из интернета. Таким везде соломки не подложишь, не сейвы так вирусный чит энжн скачают, а страдать с сейвами я ради них не хочу.
Аргумент с поломкой сейва актуален и для классических сейвов в JSON/XML/whatever. Знаем мы эти истории, когда разработчикам приходилось городить целую цепочку конверторов сейвов, от игры версии 1 до игры версии 9000, и все равно оно ломалось. А потом в чейнджлогах ААА игорь видишь "для фичи Х придется начать новую игру".
А у меня буквально 3 строки кода и идеально полное сохранение/загрузка всего.
>>4620
Вот только претензия "не качайте там вирус" будет прилетать именно к твоей игре.
>мне пофиг на людей, которые качают рандомное дерьмо из интернета
Вот только претензия "не качайте там вирус" будет прилетать именно к твоей игре.
>>4621
Шизы любят раскидываться такими заявлениями. Одна моя игра вообще без сейвов получала такой отзыв. Поглядываю за бывшим мейнтейнером годота, Юрой Сизовым, он со своим саунд-редактором тоже подобного огреб, ныл потом в соцсетях. Конкретно в моей игре вирусов нет, а чего там пользователь понакачал хуй пойми откуда - меня не касается, я ему не мамка. В точности как вирусы в крякнутых ААА торрентах не касаются разработчиков ААА игр.
Шизы любят раскидываться такими заявлениями. Одна моя игра вообще без сейвов получала такой отзыв. Поглядываю за бывшим мейнтейнером годота, Юрой Сизовым, он со своим саунд-редактором тоже подобного огреб, ныл потом в соцсетях. Конкретно в моей игре вирусов нет, а чего там пользователь понакачал хуй пойми откуда - меня не касается, я ему не мамка. В точности как вирусы в крякнутых ААА торрентах не касаются разработчиков ААА игр.
>>4621
И если уж на то пошло, то модами обмениваются чаще чем сейвами, и говна туда напихать легче. Не вижу чтобы за вирусный мод прилетало разработчику игры.
И если уж на то пошло, то модами обмениваются чаще чем сейвами, и говна туда напихать легче. Не вижу чтобы за вирусный мод прилетало разработчику игры.
Внезапно!
Туториал на немецком.
https://www.youtube.com/watch?v=gwsAIawjMwE
Впрочем, 21 век, будущее наступило, ИИ переводит с немецкого и озвучивает.
Туториал на немецком.
https://www.youtube.com/watch?v=gwsAIawjMwE
Впрочем, 21 век, будущее наступило, ИИ переводит с немецкого и озвучивает.
>>4625
Моды качают "на свой страх и риск", т.е. все должны осознавать потенциальные риски и выбирать только проверенный источник (steamworks, например). А классический сейв - это как txt-файлик. Часто ли ты задумываешься в стиле "а вдруг в txt файле вирус"? Представь, качаешь txt-файл, открываешь на своём рабочем компе, а там какой-то скрипт выполняется. Подобное поведение игры обманывает ожидания, а обманутые ожидания игроков - главная причина для негатива в отзывах к твоей игре. И речь о нормисах, а не каких-то там красноглазых шизолинуксоидах.
TL;DR:
- вирус в ожидаемом месте - ладно
- вирус в неожиданном месте - пипец
>модами обмениваются
Моды качают "на свой страх и риск", т.е. все должны осознавать потенциальные риски и выбирать только проверенный источник (steamworks, например). А классический сейв - это как txt-файлик. Часто ли ты задумываешься в стиле "а вдруг в txt файле вирус"? Представь, качаешь txt-файл, открываешь на своём рабочем компе, а там какой-то скрипт выполняется. Подобное поведение игры обманывает ожидания, а обманутые ожидания игроков - главная причина для негатива в отзывах к твоей игре. И речь о нормисах, а не каких-то там красноглазых шизолинуксоидах.
TL;DR:
- вирус в ожидаемом месте - ладно
- вирус в неожиданном месте - пипец
>>4638
Шизик /gd перешёл на годот?
Шизик /gd перешёл на годот?
>>4647
Сейвы тоже качают на свой страх и риск. Причем в разы меньше чем моды. Он вот знает, когда качает, что это реально сейв-файл, а не говно под видом сейва? Ничего он не знает. Тем более если речь о нормисах, они вообще не ебут что где-то какие-то сейвы хранятся и ими можно обменяться.
Короче я думаю это надуманная проблема и твердо намерен релизнуть как есть. Если вылезут непредвиденные последствия - обязательно приду рассказать ИТТ.
Сейвы тоже качают на свой страх и риск. Причем в разы меньше чем моды. Он вот знает, когда качает, что это реально сейв-файл, а не говно под видом сейва? Ничего он не знает. Тем более если речь о нормисах, они вообще не ебут что где-то какие-то сейвы хранятся и ими можно обменяться.
Короче я думаю это надуманная проблема и твердо намерен релизнуть как есть. Если вылезут непредвиденные последствия - обязательно приду рассказать ИТТ.
>>4620
Нет, ты не понимаешь сути проблемы.
В случае ресурсов:
1. Ты создал поле mob_amount.
2. Игрок сохранил игру в версии 0.1.
3. Ты переименовал mob_amount -> mob_count.
4. Игрок загружает сохранение в версии 0.2.
5. Godot БЕЗ ПРЕДУПРЕЖДЕНИЯ устанавливает в mob_count значение по умолчанию, а mob_amount игнорирует, и оно утратится после сохранения. В зависимости от предназначения поля, игровые последствия утраты могут быть от незаметных до полностью ломающих геймплей. Хуже всего, когда геймплей полностью ломается, но незаметно...
Godot даже в редакторе об этом никак не может предупредить и помочь сохранить утраченное; в результате приходится придумывать костыли, но в рантайме эти костыли будут намного сложнее.
В случае сцен:
1. Ты создал digger с нодой shovel.
2. Игрок сохранил игру в версии 0.1.
3. Ты поменял ноду shovel на pickaxe.
4. Игрок загрузил игру в версии 0.2.
5. Godot БЕЗ ПРЕДУПРЕЖДЕНИЯ ломается, т.к. не способен найти удалённую сцену shovel и даже не пытается добавить персонажу в руки pickaxe. В лучшем случае это будет мелкая проблема - чувак будет с пустыми руками бегать. В худшем случае игрок проиграет +50 часов и ВНЕЗАПНО обнаружит, что отсутствие кирки, необходимой для продвижения по сюжету, фиксится только началом игры с нуля.
В редакторе Godot иногда предупреждает о таких проблемах, но в рантайме такие проблемы будет значительно сложнее пофиксить автоматически. Текущая версия системы UID тут не помогает.
Во-первых, с кастомным форматом ты ИМЕЕШЬ ВОЗМОЖНОСТЬ написать эту цепочку конвертеров. Стандартные ресурсы в Godot ломаются часто и без предупреждения, формат записи у них сложный и встроенные инструменты конвертации недоступны. Задолбаешься парсить tres вручную в обход Godot.
Во-вторых, с кастомным форматом ты всегда чётко контролируешь состояние сейвов и того, как игра загружается, поэтому можешь не создавать лишние конвертеры из-за того, что ты что-то в игре поменял, обновил версию движка или какого-либо плагина. Контроль за сейвами остаётся в твоих руках и он значительно проще ковыряния в формате tres.
Ты просто ленивый ассетфлипер или вся твоя игра состоит из нескольких строчек кода, которые ты за один день написал. То, что нормально работает для настолько мелких игрушек, может быть опасно для серьёзных проектов - там, где кода больше 3 строк.
Никто тебя не заставляет делать по-другому... Просто учитывай, что твоя поделка попадает в категорию
Сразу отвечу на следующие аргументы:
Ответ: если твоя игра позволяет ничего в себе не обновлять, то ты флипнул ассеты за вечер и теперь называешь это игрой. Представь себе, некоторые игровые проекты обновляются более 25 лет, и они вынуждены вносить существенные изменения. Большинство поделок, конечно, так долго не живут, однако не путайте причину со следствием - если вы наговнокодили, разумеется, обновлять будет очень больно, даже если игра вдруг станет популярной, и множество проектов сдохли из-за говнокода (или потеряли в популярности/проиграли конкурентам).
>Аргумент с поломкой сейва актуален
Нет, ты не понимаешь сути проблемы.
В случае ресурсов:
1. Ты создал поле mob_amount.
2. Игрок сохранил игру в версии 0.1.
3. Ты переименовал mob_amount -> mob_count.
4. Игрок загружает сохранение в версии 0.2.
5. Godot БЕЗ ПРЕДУПРЕЖДЕНИЯ устанавливает в mob_count значение по умолчанию, а mob_amount игнорирует, и оно утратится после сохранения. В зависимости от предназначения поля, игровые последствия утраты могут быть от незаметных до полностью ломающих геймплей. Хуже всего, когда геймплей полностью ломается, но незаметно...
Godot даже в редакторе об этом никак не может предупредить и помочь сохранить утраченное; в результате приходится придумывать костыли, но в рантайме эти костыли будут намного сложнее.
В случае сцен:
1. Ты создал digger с нодой shovel.
2. Игрок сохранил игру в версии 0.1.
3. Ты поменял ноду shovel на pickaxe.
4. Игрок загрузил игру в версии 0.2.
5. Godot БЕЗ ПРЕДУПРЕЖДЕНИЯ ломается, т.к. не способен найти удалённую сцену shovel и даже не пытается добавить персонажу в руки pickaxe. В лучшем случае это будет мелкая проблема - чувак будет с пустыми руками бегать. В худшем случае игрок проиграет +50 часов и ВНЕЗАПНО обнаружит, что отсутствие кирки, необходимой для продвижения по сюжету, фиксится только началом игры с нуля.
В редакторе Godot иногда предупреждает о таких проблемах, но в рантайме такие проблемы будет значительно сложнее пофиксить автоматически. Текущая версия системы UID тут не помогает.
>городить целую цепочку конверторов сейвов
Во-первых, с кастомным форматом ты ИМЕЕШЬ ВОЗМОЖНОСТЬ написать эту цепочку конвертеров. Стандартные ресурсы в Godot ломаются часто и без предупреждения, формат записи у них сложный и встроенные инструменты конвертации недоступны. Задолбаешься парсить tres вручную в обход Godot.
Во-вторых, с кастомным форматом ты всегда чётко контролируешь состояние сейвов и того, как игра загружается, поэтому можешь не создавать лишние конвертеры из-за того, что ты что-то в игре поменял, обновил версию движка или какого-либо плагина. Контроль за сейвами остаётся в твоих руках и он значительно проще ковыряния в формате tres.
>А у меня буквально 3 строки кода
Ты просто ленивый ассетфлипер или вся твоя игра состоит из нескольких строчек кода, которые ты за один день написал. То, что нормально работает для настолько мелких игрушек, может быть опасно для серьёзных проектов - там, где кода больше 3 строк.
Никто тебя не заставляет делать по-другому... Просто учитывай, что твоя поделка попадает в категорию
>рандомное дерьмо из интернета.
Сразу отвечу на следующие аргументы:
>просто не меняй поля в tres
>просто не меняй ноды в tscn
>просто не обновляй аддоны
>просто не обновляй Godot
>просто не обновляй игру
Ответ: если твоя игра позволяет ничего в себе не обновлять, то ты флипнул ассеты за вечер и теперь называешь это игрой. Представь себе, некоторые игровые проекты обновляются более 25 лет, и они вынуждены вносить существенные изменения. Большинство поделок, конечно, так долго не живут, однако не путайте причину со следствием - если вы наговнокодили, разумеется, обновлять будет очень больно, даже если игра вдруг станет популярной, и множество проектов сдохли из-за говнокода (или потеряли в популярности/проиграли конкурентам).
>>4620
Нет, ты не понимаешь сути проблемы.
В случае ресурсов:
1. Ты создал поле mob_amount.
2. Игрок сохранил игру в версии 0.1.
3. Ты переименовал mob_amount -> mob_count.
4. Игрок загружает сохранение в версии 0.2.
5. Godot БЕЗ ПРЕДУПРЕЖДЕНИЯ устанавливает в mob_count значение по умолчанию, а mob_amount игнорирует, и оно утратится после сохранения. В зависимости от предназначения поля, игровые последствия утраты могут быть от незаметных до полностью ломающих геймплей. Хуже всего, когда геймплей полностью ломается, но незаметно...
Godot даже в редакторе об этом никак не может предупредить и помочь сохранить утраченное; в результате приходится придумывать костыли, но в рантайме эти костыли будут намного сложнее.
В случае сцен:
1. Ты создал digger с нодой shovel.
2. Игрок сохранил игру в версии 0.1.
3. Ты поменял ноду shovel на pickaxe.
4. Игрок загрузил игру в версии 0.2.
5. Godot БЕЗ ПРЕДУПРЕЖДЕНИЯ ломается, т.к. не способен найти удалённую сцену shovel и даже не пытается добавить персонажу в руки pickaxe. В лучшем случае это будет мелкая проблема - чувак будет с пустыми руками бегать. В худшем случае игрок проиграет +50 часов и ВНЕЗАПНО обнаружит, что отсутствие кирки, необходимой для продвижения по сюжету, фиксится только началом игры с нуля.
В редакторе Godot иногда предупреждает о таких проблемах, но в рантайме такие проблемы будет значительно сложнее пофиксить автоматически. Текущая версия системы UID тут не помогает.
Во-первых, с кастомным форматом ты ИМЕЕШЬ ВОЗМОЖНОСТЬ написать эту цепочку конвертеров. Стандартные ресурсы в Godot ломаются часто и без предупреждения, формат записи у них сложный и встроенные инструменты конвертации недоступны. Задолбаешься парсить tres вручную в обход Godot.
Во-вторых, с кастомным форматом ты всегда чётко контролируешь состояние сейвов и того, как игра загружается, поэтому можешь не создавать лишние конвертеры из-за того, что ты что-то в игре поменял, обновил версию движка или какого-либо плагина. Контроль за сейвами остаётся в твоих руках и он значительно проще ковыряния в формате tres.
Ты просто ленивый ассетфлипер или вся твоя игра состоит из нескольких строчек кода, которые ты за один день написал. То, что нормально работает для настолько мелких игрушек, может быть опасно для серьёзных проектов - там, где кода больше 3 строк.
Никто тебя не заставляет делать по-другому... Просто учитывай, что твоя поделка попадает в категорию
Сразу отвечу на следующие аргументы:
Ответ: если твоя игра позволяет ничего в себе не обновлять, то ты флипнул ассеты за вечер и теперь называешь это игрой. Представь себе, некоторые игровые проекты обновляются более 25 лет, и они вынуждены вносить существенные изменения. Большинство поделок, конечно, так долго не живут, однако не путайте причину со следствием - если вы наговнокодили, разумеется, обновлять будет очень больно, даже если игра вдруг станет популярной, и множество проектов сдохли из-за говнокода (или потеряли в популярности/проиграли конкурентам).
>Аргумент с поломкой сейва актуален
Нет, ты не понимаешь сути проблемы.
В случае ресурсов:
1. Ты создал поле mob_amount.
2. Игрок сохранил игру в версии 0.1.
3. Ты переименовал mob_amount -> mob_count.
4. Игрок загружает сохранение в версии 0.2.
5. Godot БЕЗ ПРЕДУПРЕЖДЕНИЯ устанавливает в mob_count значение по умолчанию, а mob_amount игнорирует, и оно утратится после сохранения. В зависимости от предназначения поля, игровые последствия утраты могут быть от незаметных до полностью ломающих геймплей. Хуже всего, когда геймплей полностью ломается, но незаметно...
Godot даже в редакторе об этом никак не может предупредить и помочь сохранить утраченное; в результате приходится придумывать костыли, но в рантайме эти костыли будут намного сложнее.
В случае сцен:
1. Ты создал digger с нодой shovel.
2. Игрок сохранил игру в версии 0.1.
3. Ты поменял ноду shovel на pickaxe.
4. Игрок загрузил игру в версии 0.2.
5. Godot БЕЗ ПРЕДУПРЕЖДЕНИЯ ломается, т.к. не способен найти удалённую сцену shovel и даже не пытается добавить персонажу в руки pickaxe. В лучшем случае это будет мелкая проблема - чувак будет с пустыми руками бегать. В худшем случае игрок проиграет +50 часов и ВНЕЗАПНО обнаружит, что отсутствие кирки, необходимой для продвижения по сюжету, фиксится только началом игры с нуля.
В редакторе Godot иногда предупреждает о таких проблемах, но в рантайме такие проблемы будет значительно сложнее пофиксить автоматически. Текущая версия системы UID тут не помогает.
>городить целую цепочку конверторов сейвов
Во-первых, с кастомным форматом ты ИМЕЕШЬ ВОЗМОЖНОСТЬ написать эту цепочку конвертеров. Стандартные ресурсы в Godot ломаются часто и без предупреждения, формат записи у них сложный и встроенные инструменты конвертации недоступны. Задолбаешься парсить tres вручную в обход Godot.
Во-вторых, с кастомным форматом ты всегда чётко контролируешь состояние сейвов и того, как игра загружается, поэтому можешь не создавать лишние конвертеры из-за того, что ты что-то в игре поменял, обновил версию движка или какого-либо плагина. Контроль за сейвами остаётся в твоих руках и он значительно проще ковыряния в формате tres.
>А у меня буквально 3 строки кода
Ты просто ленивый ассетфлипер или вся твоя игра состоит из нескольких строчек кода, которые ты за один день написал. То, что нормально работает для настолько мелких игрушек, может быть опасно для серьёзных проектов - там, где кода больше 3 строк.
Никто тебя не заставляет делать по-другому... Просто учитывай, что твоя поделка попадает в категорию
>рандомное дерьмо из интернета.
Сразу отвечу на следующие аргументы:
>просто не меняй поля в tres
>просто не меняй ноды в tscn
>просто не обновляй аддоны
>просто не обновляй Godot
>просто не обновляй игру
Ответ: если твоя игра позволяет ничего в себе не обновлять, то ты флипнул ассеты за вечер и теперь называешь это игрой. Представь себе, некоторые игровые проекты обновляются более 25 лет, и они вынуждены вносить существенные изменения. Большинство поделок, конечно, так долго не живут, однако не путайте причину со следствием - если вы наговнокодили, разумеется, обновлять будет очень больно, даже если игра вдруг станет популярной, и множество проектов сдохли из-за говнокода (или потеряли в популярности/проиграли конкурентам).
>>4662
Решение есть, просто не переименовывай, а помечай deprecated и добавляй новое поле.
Решение есть, просто не переименовывай, а помечай deprecated и добавляй новое поле.
>>4662
Давай тут без своих корявых гаданий на кофейной гуще. Ассеты все делаю сам в 3д редакторе, 2д арт тоже, игра в разработке больше года. Решение для обновления старых .scn-сейвов на новые написано. Остальные твои аргументы меня не ебут, потому что они из разряда "а что если васян с крыши упадет, ты виноват ведь ты дом построил!11".
Давай тут без своих корявых гаданий на кофейной гуще. Ассеты все делаю сам в 3д редакторе, 2д арт тоже, игра в разработке больше года. Решение для обновления старых .scn-сейвов на новые написано. Остальные твои аргументы меня не ебут, потому что они из разряда "а что если васян с крыши упадет, ты виноват ведь ты дом построил!11".
>>4662
А я двачую этот пост. Всегда был сторонником кастомного формата. Как правило жсон.
А я двачую этот пост. Всегда был сторонником кастомного формата. Как правило жсон.
>>4604
>>4609
Большое спасибо! Особенно за пример. Я такую систему уже успел выдумать сам, только постеснялся здесь писать. Думал, что глупости совсем. Можно еще эти фазы оформлять как инт из битфлага, например, чтоб это не были числа из головы. Там, где это уместно, разумеется.
Годонирс, кажется, выпускал аддон, который пробегается по сейву и отменяет его чтение как ресурса, если в нем есть скриптовая часть. Но я тебя понял. На json формат перейду наверное, с tscn я уже намучился.
Эмбеддил кастомный ресурс в заэмбеженный кастомный ресурс внутрь кастомного ресурса сейва, каюсь.
>>4609
Большое спасибо! Особенно за пример. Я такую систему уже успел выдумать сам, только постеснялся здесь писать. Думал, что глупости совсем. Можно еще эти фазы оформлять как инт из битфлага, например, чтоб это не были числа из головы. Там, где это уместно, разумеется.
>чревато заражением вирусом
Годонирс, кажется, выпускал аддон, который пробегается по сейву и отменяет его чтение как ресурса, если в нем есть скриптовая часть. Но я тебя понял. На json формат перейду наверное, с tscn я уже намучился.
Эмбеддил кастомный ресурс в заэмбеженный кастомный ресурс внутрь кастомного ресурса сейва, каюсь.
>>4656
Если вдруг из-за этого твоя дочь исчезнет из пространственно-временного континуума - обязательно расскажи.
Но вообще, сохранение состояния в словарь, а из него в жсон - это очень просто, хотя бы в следующем проекте крайне рекомендую освоить данную технологию. Она тебе в будущем пригодится там, где ты сейчас даже и предположить не можешь. Вот тебе пример из жизни. Я щас пишу софтину на плюсах (годот отложил пока) и написал сохранение в жсон. Использую библиотеку, с которой работа с жсон-объектом не отличается от работы с вложенными словарями в годоте. Так вот, когда дошло до написания гуя, я сначала очень расстроился, что слишком геморно для этого использовать Годот, как изначально планировалось, я обнаружил, что самый практичный способ общения между основой и гуём - это те самые жсон-объекты, которые я планировал использовать только для сохранения в файл.
И вообще, помни: разрабатывая игру, ты получаешь навыки и знания, которые пригодятя в самых разных прочих областях разработки.
>Если вылезут непредвиденные последствия - обязательно приду рассказать ИТТ.
Если вдруг из-за этого твоя дочь исчезнет из пространственно-временного континуума - обязательно расскажи.
Но вообще, сохранение состояния в словарь, а из него в жсон - это очень просто, хотя бы в следующем проекте крайне рекомендую освоить данную технологию. Она тебе в будущем пригодится там, где ты сейчас даже и предположить не можешь. Вот тебе пример из жизни. Я щас пишу софтину на плюсах (годот отложил пока) и написал сохранение в жсон. Использую библиотеку, с которой работа с жсон-объектом не отличается от работы с вложенными словарями в годоте. Так вот, когда дошло до написания гуя, я сначала очень расстроился, что слишком геморно для этого использовать Годот, как изначально планировалось, я обнаружил, что самый практичный способ общения между основой и гуём - это те самые жсон-объекты, которые я планировал использовать только для сохранения в файл.
И вообще, помни: разрабатывая игру, ты получаешь навыки и знания, которые пригодятя в самых разных прочих областях разработки.
86 Кб, 730x940>>4668
Поделись же им с нами, раз ты так сильно рекомендуешь этот чудесный способ.
Виноват, если ты сделал слабую крышу, что обвалилась под васяном, который эту крышу после тебя доделывал, или даже над васяном, который просто мимо стройки проходил. Нормальные строители ГОСТы соблюдают, а ещё есть УК РФ 216: "Нарушение правил безопасности при ведении строительных или иных работ". Будешь спорить и доказывать, что васян всё ещё сам виноват, что проходил мимо, когда твоя крыша обвалилась ему на голову?
К счастью, ты не строитель и крыши не строишь, поэтому твоя поделка на чью-то голову не упадёт. Но рекомендую ознакомиться с УК РФ 273: "Создание, использование и распространение вредоносных компьютерных программ". Оправдываться, что ты не знал об уязвимости и не пытался намеренно совершать сделанное, будешь уже перед другими людьми...
>Решение для обновления старых .scn-сейвов на новые
Поделись же им с нами, раз ты так сильно рекомендуешь этот чудесный способ.
>а что если васян с крыши упадет, ты виноват ведь ты дом построил
Виноват, если ты сделал слабую крышу, что обвалилась под васяном, который эту крышу после тебя доделывал, или даже над васяном, который просто мимо стройки проходил. Нормальные строители ГОСТы соблюдают, а ещё есть УК РФ 216: "Нарушение правил безопасности при ведении строительных или иных работ". Будешь спорить и доказывать, что васян всё ещё сам виноват, что проходил мимо, когда твоя крыша обвалилась ему на голову?
К счастью, ты не строитель и крыши не строишь, поэтому твоя поделка на чью-то голову не упадёт. Но рекомендую ознакомиться с УК РФ 273: "Создание, использование и распространение вредоносных компьютерных программ". Оправдываться, что ты не знал об уязвимости и не пытался намеренно совершать сделанное, будешь уже перед другими людьми...
>>4704
Покажешь? Для годота.
>Но вообще, сохранение состояния в словарь, а из него в жсон - это очень просто,
Покажешь? Для годота.
>>4704
Освоил в двух предыдущих играх, больше не хочу, спасибо. Чем комплексней структура проекта, чем больше взаимосвязей между объектами, тем больше мозгоебли.
>>4705
Какой ты унылый бюрократ. ГОСТ на обкладывание соломой еще принеси, и пригрози УК всем кто делает иначе.
>Но вообще, сохранение состояния в словарь, а из него в жсон - это очень просто, хотя бы в следующем проекте крайне рекомендую освоить данную технологию.
Освоил в двух предыдущих играх, больше не хочу, спасибо. Чем комплексней структура проекта, чем больше взаимосвязей между объектами, тем больше мозгоебли.
>>4705
Какой ты унылый бюрократ. ГОСТ на обкладывание соломой еще принеси, и пригрози УК всем кто делает иначе.
>>4713
Главное - не тащить структуру проекта в сейв. Отношение к сейву должно быть как к таблице базы данных. И ЖСОН позволяет сделать структуру как таблица. Вот есть такой сайт жсон-редактор-онлайн. Так вот там есть возможность представить особым образом составленный жсон как таблицу. В чём состоит эта особость? В жсоне должен быть один или больше массив [] однотипных объектов {}, ключи из этих объектов становятся именами столбцов виртуальной таблицы, значения - значениями строк.
Необязательно юзать редакторы, но вышеприведённый редактор позволяет постигнуть эту идею.
> больше не хочу, спасибо. Чем комплексней структура проекта, чем больше взаимосвязей между объектами, тем больше мозгоебли
Главное - не тащить структуру проекта в сейв. Отношение к сейву должно быть как к таблице базы данных. И ЖСОН позволяет сделать структуру как таблица. Вот есть такой сайт жсон-редактор-онлайн. Так вот там есть возможность представить особым образом составленный жсон как таблицу. В чём состоит эта особость? В жсоне должен быть один или больше массив [] однотипных объектов {}, ключи из этих объектов становятся именами столбцов виртуальной таблицы, значения - значениями строк.
Необязательно юзать редакторы, но вышеприведённый редактор позволяет постигнуть эту идею.
>>4720
Проще скринами показать. Допустим есть такой жсон (пикча1) включаем режим, выбираем таблицу и редактируем. А в движке соответственно делаем несложный код, который находит в файле таблицы и читает их последовательно, извлекая данные и определяя их по полю наподобие "type". Таким подходом частично решается и немного упрощается вышеописанная проблема смены формата. Ты не добавляешь в сейв произвольные данные, ты добавляешь структурированные данные, у которых есть тип, подтип, имя, значение, иные параметры. И когда ты начнёшь мыслить в этой парадигме (парадигме СУБД) тебе будет сложнее "случайно" вносить ломающие изменения в свои же форматы.
Проще скринами показать. Допустим есть такой жсон (пикча1) включаем режим, выбираем таблицу и редактируем. А в движке соответственно делаем несложный код, который находит в файле таблицы и читает их последовательно, извлекая данные и определяя их по полю наподобие "type". Таким подходом частично решается и немного упрощается вышеописанная проблема смены формата. Ты не добавляешь в сейв произвольные данные, ты добавляешь структурированные данные, у которых есть тип, подтип, имя, значение, иные параметры. И когда ты начнёшь мыслить в этой парадигме (парадигме СУБД) тебе будет сложнее "случайно" вносить ломающие изменения в свои же форматы.
35 Кб, 378x618>>4723
Обычно вот такие жсоны пихают в сейв, а потом жалуются, что их масштабировать сложно. Здесь только инвентарь в виде таблицы, остальное прибито гвоздями к внутренней реализации.
Обычно вот такие жсоны пихают в сейв, а потом жалуются, что их масштабировать сложно. Здесь только инвентарь в виде таблицы, остальное прибито гвоздями к внутренней реализации.
>>4709
Сохраняем:
func to_dict() -> Dictionary:
. var dict = {
. . foo = foo, # int
. . bar = bar, # String
. . obj = obj.to_dict();
. . connections = {
. . . connected_node1.name, connected_node2.name
. . }
. }
. return dict
Загружаем:
func from_dict(dict: Dictionary)
. if dict.has("foo") and dict.foo is int: foo = dict.foo
. if dict.has("bar") and dict.bar is String: bar = dict.bar
. if dict.has("obj") and dict.obj is Dictionary:
. . obj = new Obj
. . obj.from_dict(dict.obj)
После восстановления всех нод восстанавливаем соединения
func connections_from_dict(dict: Dictionary)
. if not dict.has("connections") or not (dict.connections is Array): return
. for connection in dict.connections:
. . conn: Node = get_node(connection)
. . if is_instance_valid(node): restore_connection_with(node)
Всё. и так можно сохранить проект ЛЮБОЙ сложности.
>>4713
Вообще, это огромный редфлаг, обозначающий, что пора бы заняться рефакторингом. Энивей, см.выше.
Сохраняем:
func to_dict() -> Dictionary:
. var dict = {
. . foo = foo, # int
. . bar = bar, # String
. . obj = obj.to_dict();
. . connections = {
. . . connected_node1.name, connected_node2.name
. . }
. }
. return dict
Загружаем:
func from_dict(dict: Dictionary)
. if dict.has("foo") and dict.foo is int: foo = dict.foo
. if dict.has("bar") and dict.bar is String: bar = dict.bar
. if dict.has("obj") and dict.obj is Dictionary:
. . obj = new Obj
. . obj.from_dict(dict.obj)
После восстановления всех нод восстанавливаем соединения
func connections_from_dict(dict: Dictionary)
. if not dict.has("connections") or not (dict.connections is Array): return
. for connection in dict.connections:
. . conn: Node = get_node(connection)
. . if is_instance_valid(node): restore_connection_with(node)
Всё. и так можно сохранить проект ЛЮБОЙ сложности.
>>4713
>Чем комплексней структура проекта, чем больше взаимосвязей между объектами
Вообще, это огромный редфлаг, обозначающий, что пора бы заняться рефакторингом. Энивей, см.выше.
>>4709
Сохраняем:
func to_dict() -> Dictionary:
. var dict = {
. . foo = foo, # int
. . bar = bar, # String
. . obj = obj.to_dict();
. . connections = {
. . . connected_node1.name, connected_node2.name
. . }
. }
. return dict
Загружаем:
func from_dict(dict: Dictionary)
. if dict.has("foo") and dict.foo is int: foo = dict.foo
. if dict.has("bar") and dict.bar is String: bar = dict.bar
. if dict.has("obj") and dict.obj is Dictionary:
. . obj = new Obj
. . obj.from_dict(dict.obj)
После восстановления всех нод восстанавливаем соединения
func connections_from_dict(dict: Dictionary)
. if not dict.has("connections") or not (dict.connections is Array): return
. for connection in dict.connections:
. . conn: Node = get_node(connection)
. . if is_instance_valid(node): restore_connection_with(node)
Всё. и так можно сохранить проект ЛЮБОЙ сложности.
>>4713
Вообще, это огромный редфлаг, обозначающий, что пора бы заняться рефакторингом. Энивей, см.выше.
Сохраняем:
func to_dict() -> Dictionary:
. var dict = {
. . foo = foo, # int
. . bar = bar, # String
. . obj = obj.to_dict();
. . connections = {
. . . connected_node1.name, connected_node2.name
. . }
. }
. return dict
Загружаем:
func from_dict(dict: Dictionary)
. if dict.has("foo") and dict.foo is int: foo = dict.foo
. if dict.has("bar") and dict.bar is String: bar = dict.bar
. if dict.has("obj") and dict.obj is Dictionary:
. . obj = new Obj
. . obj.from_dict(dict.obj)
После восстановления всех нод восстанавливаем соединения
func connections_from_dict(dict: Dictionary)
. if not dict.has("connections") or not (dict.connections is Array): return
. for connection in dict.connections:
. . conn: Node = get_node(connection)
. . if is_instance_valid(node): restore_connection_with(node)
Всё. и так можно сохранить проект ЛЮБОЙ сложности.
>>4713
>Чем комплексней структура проекта, чем больше взаимосвязей между объектами
Вообще, это огромный редфлаг, обозначающий, что пора бы заняться рефакторингом. Энивей, см.выше.
>>4732
Интересно. А как ты, например, сохраняешь текущую анимацию, ее скорость, направление и позицию?
Интересно. А как ты, например, сохраняешь текущую анимацию, ее скорость, направление и позицию?
>>4732
Вот эту хрень надо выносить в метод. Что-то типа
Ну и после этого уже элегантнее будет:
> if dict.has("foo") and dict.foo is int: foo
Вот эту хрень надо выносить в метод. Что-то типа
> func _cast_to_type(dict: Dictionary, key: String, type: int, default: Variant) -> Variant:
> > if dict.has(key) and type_of(dict[key]) == type:
> > > return dict[key]
> > return default
Ну и после этого уже элегантнее будет:
> foo = _cast_to_type(dict, "foo", TYPE_INT, foo)
> bar = _cast_to_type(dict, "bar", TYPE_STRING, bar)
>>4738
Эх, в шарпе такие штуки ещё элегантнее пишутся, там caller member name выводится.
Эх, в шарпе такие штуки ещё элегантнее пишутся, там caller member name выводится.
>>4720 >>4723 >>4726
Я всё внимательно прочитал и попробовал этот онлайн-редактор, но не понял, как ты это предлагаешь использовать, если у тебя в проекте больше одного экземпляра объекта. И зачем нужны дублирующиеся поля? Ты собираешься это вручную читать? Если ты предлагаешь создавать SQL запросы к этому сейву, не проще ли будет сразу подключить СУБД к проекту, а не делать велосипед с квадратными колёсами (JSON)? Я не понимаю, чем твой способ будет лучше.
Твой способ, как я его понимаю:
Очень странно. Это будет долго и неэффективно.
Возможно, через SQL будет быстрее и эффективнее?..
Нормальный способ, который тебе чем-то не нравится (чем?):
Легко и понятно. Никакого "прибивания гвоздями" (где?) тут нет.
Если у тебя изменится первый вариант:
Если у тебя изменится второй вариант:
Как видишь, разницы в обратной совместимости нет.
>>4732
Проще так записать:
А если у тебя там тип неправильный, то всё уже сломалось.
Можно так записать:
>>4734
О какой анимации речь? И нужно ли её вообще сохранять?
Сохраняй только то, что нельзя восстановить при загрузке.
Я всё внимательно прочитал и попробовал этот онлайн-редактор, но не понял, как ты это предлагаешь использовать, если у тебя в проекте больше одного экземпляра объекта. И зачем нужны дублирующиеся поля? Ты собираешься это вручную читать? Если ты предлагаешь создавать SQL запросы к этому сейву, не проще ли будет сразу подключить СУБД к проекту, а не делать велосипед с квадратными колёсами (JSON)? Я не понимаю, чем твой способ будет лучше.
Твой способ, как я его понимаю:
>location.gd
>func load(data): # получаем все данные, ибо хрен разберёшь
>_ for line in data.world_data:
>_ _ if line.type == "location":
>_ _ _ match line.name:
>_ _ _ _ "name": name = line.value
>_ _ _ _ "state": state = line.value
>_ _ _ _ "weather": weather = line.value
>_ _ _ _ "time": time = line.value
Очень странно. Это будет долго и неэффективно.
Возможно, через SQL будет быстрее и эффективнее?..
Нормальный способ, который тебе чем-то не нравится (чем?):
>location.gd
>func load(data): # получаем кусочек данных от заботливого родителя
>_ name = data.name
>_ state = data.state
>_ weather = data.weather
>_ time = data.time
Легко и понятно. Никакого "прибивания гвоздями" (где?) тут нет.
Если у тебя изменится первый вариант:
>_ _ _ _ "state": status = line.value
Если у тебя изменится второй вариант:
>_ status = data.state
Как видишь, разницы в обратной совместимости нет.
>>4732
>if dict.has("foo") and dict.foo is int: foo = dict.foo
Проще так записать:
>foo = dict.get("foo", foo)
А если у тебя там тип неправильный, то всё уже сломалось.
>if not dict.has("connections") or not (dict.connections is Array):
Можно так записать:
>if "connections" not in dict or dict.connections is not Array:
>>4734
>сохраняешь текущую анимацию
О какой анимации речь? И нужно ли её вообще сохранять?
Сохраняй только то, что нельзя восстановить при загрузке.
>>4720 >>4723 >>4726
Я всё внимательно прочитал и попробовал этот онлайн-редактор, но не понял, как ты это предлагаешь использовать, если у тебя в проекте больше одного экземпляра объекта. И зачем нужны дублирующиеся поля? Ты собираешься это вручную читать? Если ты предлагаешь создавать SQL запросы к этому сейву, не проще ли будет сразу подключить СУБД к проекту, а не делать велосипед с квадратными колёсами (JSON)? Я не понимаю, чем твой способ будет лучше.
Твой способ, как я его понимаю:
Очень странно. Это будет долго и неэффективно.
Возможно, через SQL будет быстрее и эффективнее?..
Нормальный способ, который тебе чем-то не нравится (чем?):
Легко и понятно. Никакого "прибивания гвоздями" (где?) тут нет.
Если у тебя изменится первый вариант:
Если у тебя изменится второй вариант:
Как видишь, разницы в обратной совместимости нет.
>>4732
Проще так записать:
А если у тебя там тип неправильный, то всё уже сломалось.
Можно так записать:
>>4734
О какой анимации речь? И нужно ли её вообще сохранять?
Сохраняй только то, что нельзя восстановить при загрузке.
Я всё внимательно прочитал и попробовал этот онлайн-редактор, но не понял, как ты это предлагаешь использовать, если у тебя в проекте больше одного экземпляра объекта. И зачем нужны дублирующиеся поля? Ты собираешься это вручную читать? Если ты предлагаешь создавать SQL запросы к этому сейву, не проще ли будет сразу подключить СУБД к проекту, а не делать велосипед с квадратными колёсами (JSON)? Я не понимаю, чем твой способ будет лучше.
Твой способ, как я его понимаю:
>location.gd
>func load(data): # получаем все данные, ибо хрен разберёшь
>_ for line in data.world_data:
>_ _ if line.type == "location":
>_ _ _ match line.name:
>_ _ _ _ "name": name = line.value
>_ _ _ _ "state": state = line.value
>_ _ _ _ "weather": weather = line.value
>_ _ _ _ "time": time = line.value
Очень странно. Это будет долго и неэффективно.
Возможно, через SQL будет быстрее и эффективнее?..
Нормальный способ, который тебе чем-то не нравится (чем?):
>location.gd
>func load(data): # получаем кусочек данных от заботливого родителя
>_ name = data.name
>_ state = data.state
>_ weather = data.weather
>_ time = data.time
Легко и понятно. Никакого "прибивания гвоздями" (где?) тут нет.
Если у тебя изменится первый вариант:
>_ _ _ _ "state": status = line.value
Если у тебя изменится второй вариант:
>_ status = data.state
Как видишь, разницы в обратной совместимости нет.
>>4732
>if dict.has("foo") and dict.foo is int: foo = dict.foo
Проще так записать:
>foo = dict.get("foo", foo)
А если у тебя там тип неправильный, то всё уже сломалось.
>if not dict.has("connections") or not (dict.connections is Array):
Можно так записать:
>if "connections" not in dict or dict.connections is not Array:
>>4734
>сохраняешь текущую анимацию
О какой анимации речь? И нужно ли её вообще сохранять?
Сохраняй только то, что нельзя восстановить при загрузке.
>>4740
У меня animation player и долгая анимация в нем. Иногда я ее запускаю задним ходом через play_backwards
>О какой анимации речь?
У меня animation player и долгая анимация в нем. Иногда я ее запускаю задним ходом через play_backwards
>>4742
А сверху мускуля обязательно прослойку с ORM, на случай если базу на полпути сменить придется.
А сверху мускуля обязательно прослойку с ORM, на случай если базу на полпути сменить придется.
>>4743
И мультиплеерные кнопки непременно.
И мультиплеерные кнопки непременно.
109 Кб, 911x611Скулять.
>>4741
Что за анимация-то?
Основные варианты:
1. Кат-сцена. Сохраняешься ПЕРЕД кат-сценой, а не во время.
2. Действие персонажа. Сохраняешься перед/после действия.
3. Состояние персонажа. Запускаешь анимацию с нуля/с конца.
В любом случае, анимации - обычно декорации, а не геймплей.
Что плохого в том, что декорации "неправильно" загрузятся?
>долгая анимация в нем
Что за анимация-то?
Основные варианты:
1. Кат-сцена. Сохраняешься ПЕРЕД кат-сценой, а не во время.
2. Действие персонажа. Сохраняешься перед/после действия.
3. Состояние персонажа. Запускаешь анимацию с нуля/с конца.
В любом случае, анимации - обычно декорации, а не геймплей.
Что плохого в том, что декорации "неправильно" загрузятся?
>>4746
То есть твой подход, который:
Разваливается как только я делаю шаг в сторону от банального менеджера инвентаря, и начинаются костыли-подпорки либо "нинужно". Представляю что будет если я захочу сохраниться во время скриптованной на твинах интерактивной нелинейной сцены, или если у меня физическая симуляция с _integrate_forces, или процедурное создание материалов, или ...
То есть твой подход, который:
>и так можно сохранить проект ЛЮБОЙ сложности.
Разваливается как только я делаю шаг в сторону от банального менеджера инвентаря, и начинаются костыли-подпорки либо "нинужно". Представляю что будет если я захочу сохраниться во время скриптованной на твинах интерактивной нелинейной сцены, или если у меня физическая симуляция с _integrate_forces, или процедурное создание материалов, или ...
>>4749
Страдать. Я не нашел универсального и удобного способа или готового решения, способного безболезненно сохранить любое состояние любой ноды/объекта/сцены/скрипта/анимации/диалога/физики/звука. Чем более нестандартный проект тем хуже. Поэтому всегда охуеваю с ваших советов уровня "просто используй жысон/ресурсы/sql", когда совсем не в них дело.
В этом плане приятно мобильные дрочильни делать, где ты сохраняешь int пройденных уровней и больше ничего.
Страдать. Я не нашел универсального и удобного способа или готового решения, способного безболезненно сохранить любое состояние любой ноды/объекта/сцены/скрипта/анимации/диалога/физики/звука. Чем более нестандартный проект тем хуже. Поэтому всегда охуеваю с ваших советов уровня "просто используй жысон/ресурсы/sql", когда совсем не в них дело.
В этом плане приятно мобильные дрочильни делать, где ты сохраняешь int пройденных уровней и больше ничего.
>>4751
Не ты один страдаешь. Заметил, что в подавляющем большинстве современных игор сохранения специально установленными чекпоинтами? То-то же. Игра набита под завязку рандомно генерирующимися эффектами постобработки и сохранить всё это барахло дороже, чем. Чем.
Алсо для анимационного плеера:
Сохраняй на здоровье.
Со звуком и физикой так же.
Просто ты заебёшься всё сохранять, а игроки этих трудов не оценят и будут обсирать тебя на форумах, что когда они траят босса, приходится по несколько минут ждать загрузки.
Не ты один страдаешь. Заметил, что в подавляющем большинстве современных игор сохранения специально установленными чекпоинтами? То-то же. Игра набита под завязку рандомно генерирующимися эффектами постобработки и сохранить всё это барахло дороже, чем. Чем.
Алсо для анимационного плеера:
> current_animation
> current_animation_length
> current_animation_position
Сохраняй на здоровье.
Со звуком и физикой так же.
Просто ты заебёшься всё сохранять, а игроки этих трудов не оценят и будут обсирать тебя на форумах, что когда они траят босса, приходится по несколько минут ждать загрузки.
>>4740
Не душни, суть-то не в этом
>>4734
dict = {
...
. anim_name = animation_player.assigned_animtion,
. anim_speed = animation_player.get_playing_speed(),
. anim_pos = animation_player.current_animation_position
...
}
Но, во-первых, нахуя, а во-вторых упаковкой сцены ты вроде эти вещи даже и не сохранишь.
>>4748
Опять же, чёрт его знает, как поведёт себя упаковка сцены с этим всем говном. А вот записать в словарь, что вот сейчас работает такой-то твин с такими-то параметрами, а при загрузке его перезапустить - фигня вопрос.
Симулируется заново; параметры симуляции пишутся в словарь.
Сид пишется в словарь, и у тебя всё воссоздастся точно так же.
Ах да, ну и да, у меня случился эффект манделы, и я забыл, что встроенной функции преобразования словаря в жсон нету. Зато можно сделать var_to_str(dict) и получить сериализованный словарь, очень похожий на жсон. Ну и обратное str_to_var тоже работает.
Анимация действительно тут самое сложное; но если у тебя в игре присутствует прям реально длинная сложная анимация, которая ещё и влияет на геймплей, которую ещё и надо сохранять-загружать - значит где-то ты свернул не туда. Такие штуки - это бомбы замедленного действия, лучше сразу проектировать без них, чем на поздней стадии разработки понять, что теперь придётся всё переделывать.
>Проще так записать
>Можно так записать
Не душни, суть-то не в этом
>>4734
>А как ты, например, сохраняешь текущую анимацию, ее скорость, направление и позицию?
dict = {
...
. anim_name = animation_player.assigned_animtion,
. anim_speed = animation_player.get_playing_speed(),
. anim_pos = animation_player.current_animation_position
...
}
Но, во-первых, нахуя, а во-вторых упаковкой сцены ты вроде эти вещи даже и не сохранишь.
>>4748
>скриптованной на твинах интерактивной нелинейной сцены, или
Опять же, чёрт его знает, как поведёт себя упаковка сцены с этим всем говном. А вот записать в словарь, что вот сейчас работает такой-то твин с такими-то параметрами, а при загрузке его перезапустить - фигня вопрос.
>физическая симуляция
Симулируется заново; параметры симуляции пишутся в словарь.
>процедурное создание
Сид пишется в словарь, и у тебя всё воссоздастся точно так же.
Ах да, ну и да, у меня случился эффект манделы, и я забыл, что встроенной функции преобразования словаря в жсон нету. Зато можно сделать var_to_str(dict) и получить сериализованный словарь, очень похожий на жсон. Ну и обратное str_to_var тоже работает.
Анимация действительно тут самое сложное; но если у тебя в игре присутствует прям реально длинная сложная анимация, которая ещё и влияет на геймплей, которую ещё и надо сохранять-загружать - значит где-то ты свернул не туда. Такие штуки - это бомбы замедленного действия, лучше сразу проектировать без них, чем на поздней стадии разработки понять, что теперь придётся всё переделывать.
>>4756
Я не он, но я помню шутеры 90х-2000х, когда сохраняешься с летящей в полёте пулей, а при загрузке пуля тебя застреливает. Это раздражало, но это была фича.
> если у тебя в игре присутствует прям реально длинная сложная анимация, которая ещё и влияет на геймплей, которую ещё и надо сохранять-загружать - значит где-то ты свернул не туда
Я не он, но я помню шутеры 90х-2000х, когда сохраняешься с летящей в полёте пулей, а при загрузке пуля тебя застреливает. Это раздражало, но это была фича.
>>4756
Физика не детерминирована, даже с Jolt'ом, и вот твой подход развалился. А может ты физический паззл делаешь. А может симуляция была долгой и важной, и сиди теперь пару минут жди чтобы вернуться туда где остановился.
Снова, чуть в сторону от менеджера инвентаря и все разваливается и слышь переделывай.
Сейвы, по сути, каждый раз одно и то же простое действие - запиши-прочитай - но каждый сука раз оно достаточно разное чтобы прыгать с бубном и тратить время на унылые обвязки-бойлерплейты. А напишут ли мне в отзывах что у меня охуенные сейвы? Нет, всем похуй, ведь это базовый функционал, а ты каждый раз ебись с ним. А мог бы потратить это время на что-то интересное.
>Симулируется заново;
Физика не детерминирована, даже с Jolt'ом, и вот твой подход развалился. А может ты физический паззл делаешь. А может симуляция была долгой и важной, и сиди теперь пару минут жди чтобы вернуться туда где остановился.
>у тебя в игре присутствует прям реально длинная сложная анимация, которая ещё и влияет на геймплей, которую ещё и надо сохранять-загружать - значит где-то ты свернул не туда
Снова, чуть в сторону от менеджера инвентаря и все разваливается и слышь переделывай.
Сейвы, по сути, каждый раз одно и то же простое действие - запиши-прочитай - но каждый сука раз оно достаточно разное чтобы прыгать с бубном и тратить время на унылые обвязки-бойлерплейты. А напишут ли мне в отзывах что у меня охуенные сейвы? Нет, всем похуй, ведь это базовый функционал, а ты каждый раз ебись с ним. А мог бы потратить это время на что-то интересное.
>>4763
В рамках одной платформы всё воспроизводимо, как раз таки с джолтом
https://github.com/godot-jolt/godot-jolt/discussions/548?ysclid=m8penlk9ee155947311
> Физика не детерминирована, даже с Jolt'ом
В рамках одной платформы всё воспроизводимо, как раз таки с джолтом
https://github.com/godot-jolt/godot-jolt/discussions/548?ysclid=m8penlk9ee155947311
>>4759
Пулю сохранить просто, достаточно записать вид пули, положение в пространстве и скорость.
>>4763
Не натягивай сову на глобус. Сохраняй текущее состояние - восстанавливайся с него и продолжай симуляцию. Если дальше события будут при каждой загрузке идти по-разному, то
а) это не проблема сейвов, а проблема физики,
б) игроки могут сейвскамить, и лучше вообще запретить сохраняться в такие моменты,
в) это никак не зависит от того, сохраняешь ты избранные параметры в словарь или же сразу упаковываешь всю сцену.
Ну тут да. Не помню, у кого из блогеров видел этот тезис (наверняка у GMTK), мол, в разработке игр есть fun part, когда ты делаешь непосредственно игру, а есть огромная куча всего, что сделать всё равно необходимо, но это скучная рутина, которую игрок даже не заметит. И это касается не только сейвов, это ещё настройки, логика работы гуя, всякие там стейт-машины и куча другого.
Ну, c'est la vie, чо.
>я помню шутеры 90х-2000х, когда сохраняешься с летящей в полёте пулей, а при загрузке пуля тебя застреливает
Пулю сохранить просто, достаточно записать вид пули, положение в пространстве и скорость.
>>4763
>Физика не детерминирована
Не натягивай сову на глобус. Сохраняй текущее состояние - восстанавливайся с него и продолжай симуляцию. Если дальше события будут при каждой загрузке идти по-разному, то
а) это не проблема сейвов, а проблема физики,
б) игроки могут сейвскамить, и лучше вообще запретить сохраняться в такие моменты,
в) это никак не зависит от того, сохраняешь ты избранные параметры в словарь или же сразу упаковываешь всю сцену.
>Сейвы, по сути,
Ну тут да. Не помню, у кого из блогеров видел этот тезис (наверняка у GMTK), мол, в разработке игр есть fun part, когда ты делаешь непосредственно игру, а есть огромная куча всего, что сделать всё равно необходимо, но это скучная рутина, которую игрок даже не заметит. И это касается не только сейвов, это ещё настройки, логика работы гуя, всякие там стейт-машины и куча другого.
Ну, c'est la vie, чо.
>>4748
Да, не нужно. Ты вообще в игры играешь? Ты часто замечаешь, в каком состоянии загружается игра? В каком состоянии находятся все анимации, физика? Большинство игроков невнимательны к деталям. Загрузка игры должна восстановить всё, что может потребоваться для прохождения игры на 100% - всё остальное может быть в произвольном состоянии.
Зачем? Сохраняйся перед началом/после конца. В крайнем случае можешь загрузить сцену с начала и прокрутить симуляцию в ускоренном режиме, пока закрываешь весь экран непрозрачным затвором. Практического смысла в этом, правда, мало.
>>4756
Кто тебе такой бред сказал? Всё есть и работает:
https://docs.godotengine.org/en/stable/classes/class_json.html#class-json-method-stringify
https://docs.godotengine.org/en/3.6/classes/class_json.html#class-json-method-print
>>4763
Главное, чтоб объекты не проваливались в пол.
Вот когда ты его сделаешь - тогда и поговорим.
В чём проблема подождать всего лишь 2 минуты?
Это и есть разработка программного обеспечения.
А ты делай весёлые обвязки.
>костыли-подпорки либо "нинужно"
Да, не нужно. Ты вообще в игры играешь? Ты часто замечаешь, в каком состоянии загружается игра? В каком состоянии находятся все анимации, физика? Большинство игроков невнимательны к деталям. Загрузка игры должна восстановить всё, что может потребоваться для прохождения игры на 100% - всё остальное может быть в произвольном состоянии.
>Представляю что будет если я захочу сохраниться во время скриптованной на твинах интерактивной нелинейной сцены, или если у меня физическая симуляция с _integrate_forces, или процедурное создание материалов, или ...
Зачем? Сохраняйся перед началом/после конца. В крайнем случае можешь загрузить сцену с начала и прокрутить симуляцию в ускоренном режиме, пока закрываешь весь экран непрозрачным затвором. Практического смысла в этом, правда, мало.
>>4756
>функции преобразования словаря в жсон нету
Кто тебе такой бред сказал? Всё есть и работает:
https://docs.godotengine.org/en/stable/classes/class_json.html#class-json-method-stringify
https://docs.godotengine.org/en/3.6/classes/class_json.html#class-json-method-print
>>4763
>>Симулируется заново;
>Физика не детерминирована
Главное, чтоб объекты не проваливались в пол.
>может ты физический паззл делаешь
Вот когда ты его сделаешь - тогда и поговорим.
>сиди теперь пару минут жди чтобы вернуться
В чём проблема подождать всего лишь 2 минуты?
>все разваливается и слышь переделывай
Это и есть разработка программного обеспечения.
>унылые обвязки-бойлерплейты
А ты делай весёлые обвязки.
>>4812
ГУЙ хотя бы стилизовать можно по-новому, а над UX интересно работать. Сейвы же просто подкапотная муть, которую никто не увидит.
>>4844
Не нужен тут только твой бесполезный коммент, сорян.
>И это касается не только сейвов, это ещё настройки, логика работы гуя, всякие там стейт-машины и куча другого.
ГУЙ хотя бы стилизовать можно по-новому, а над UX интересно работать. Сейвы же просто подкапотная муть, которую никто не увидит.
>>4844
>не нужно
>не нужно
>не нужно яскозал
Не нужен тут только твой бесполезный коммент, сорян.
>>4844
Я кстати не в первый раз вижу длиннопосты с подобными воззрениями на движок. Складывается ощущение, что какой-то хуй, ни разу не открывавший годот, залез в тред и жирно набрасывает движкосрача на вентилятор.
>>4812
Нужно поглядывать в ассетлиб, может оказаться, что множество бойлерплейтовых работ уже произведено, только скачивай да используй.
Вот, например, менеджер сохранений https://godotengine.org/asset-library/asset/3765 вряд ли присутствующие в треде напишут толковее (я проверил код).
> Кто тебе такой бред сказал? Всё есть и работает:
Я кстати не в первый раз вижу длиннопосты с подобными воззрениями на движок. Складывается ощущение, что какой-то хуй, ни разу не открывавший годот, залез в тред и жирно набрасывает движкосрача на вентилятор.
>>4812
> мол, в разработке игр есть fun part, когда ты делаешь непосредственно игру, а есть огромная куча всего, что сделать всё равно необходимо, но это скучная рутина, которую игрок даже не заметит. И это касается не только сейвов, это ещё настройки, логика работы гуя, всякие там стейт-машины и куча другого.
> Ну, c'est la vie, чо.
Нужно поглядывать в ассетлиб, может оказаться, что множество бойлерплейтовых работ уже произведено, только скачивай да используй.
Вот, например, менеджер сохранений https://godotengine.org/asset-library/asset/3765 вряд ли присутствующие в треде напишут толковее (я проверил код).
>>4846
Если сохраняешь в JSON, игроки могут залезть в сохранение и подправить значения руками. Может существенно упростить работу моддерам. Может упростить жизнь желающим "читерить" в сингле. Теоретически упрощает фикс багов игры игроком (например, когда важная вещь тупо деспавнулась).
В любом случае, некоторые игроки спасибо скажут.
А что НУЖНОГО делаешь ты?
Опиши, что тебе не удаётся сейчас сохранить.
Покажи на видео, как оно сейчас загружается.
Покажи на видео, как оно должно загружаться.
Подумаем вместе, как решить твою проблему.
>подкапотная муть, которую никто не увидит
Если сохраняешь в JSON, игроки могут залезть в сохранение и подправить значения руками. Может существенно упростить работу моддерам. Может упростить жизнь желающим "читерить" в сингле. Теоретически упрощает фикс багов игры игроком (например, когда важная вещь тупо деспавнулась).
В любом случае, некоторые игроки спасибо скажут.
>>не нужно яскозал
>Не нужен тут только твой
А что НУЖНОГО делаешь ты?
Опиши, что тебе не удаётся сейчас сохранить.
Покажи на видео, как оно сейчас загружается.
Покажи на видео, как оно должно загружаться.
Подумаем вместе, как решить твою проблему.
>>4847
Какой-то бредовый плагин...
Что он предлагает? Насрать нодами в дерево? Так?
И, конечно, это всё обмазано синглтоном.
>менеджер сохранений
Какой-то бредовый плагин...
>In order to be able to manipulate those StorageAccessors, an autoload called GlobalStorageManager is defined when the plugin is activated. This is a singleton capable of collecting and sending data to all active StorageAccessors in the scene.
Что он предлагает? Насрать нодами в дерево? Так?
>игрок: CharacterBody3D
>_ сохранятор_игрока: StorageAccessor
>_ пистолет: Пуляло3D
>_ _ сохранятор_пистолета: StorageAccessor
>_ _ магазин: Node3D
>_ _ _ сохранятор_магазина: StorageAccessor
>_ портки: Портки3D
>_ _ сохранятор_портков: StorageAccessor
>_ _ шнурки: Шнурок3D
>_ _ _ сохранятор_шнурков: StorageAccessor
И, конечно, это всё обмазано синглтоном.
>>4849
Сколько тебе сказали спасибо за жсонные сохранения? Покажи на видео, где тебе говорят спасибо. Мне за мои предыдущие игры никто не сказал, сохранял в жсон, за сотни отзывов ноль про сейвы. Мне кажется править сейвы руками это еще более редкое чем обмен сейвами. В общем, все это - надуманные причины, чтобы страдать при каждой реализации сейвов. А от надуманных причин надо избавляться.
>В любом случае, некоторые игроки спасибо скажут.
Сколько тебе сказали спасибо за жсонные сохранения? Покажи на видео, где тебе говорят спасибо. Мне за мои предыдущие игры никто не сказал, сохранял в жсон, за сотни отзывов ноль про сейвы. Мне кажется править сейвы руками это еще более редкое чем обмен сейвами. В общем, все это - надуманные причины, чтобы страдать при каждой реализации сейвов. А от надуманных причин надо избавляться.
Кстати, я когда оптимизировал игру под веб/яи, вспомнил еще один минус синглтонов. Все автолоады то грузятся сразу. А надо чтобы сначала загрузился только легковесный стартовый экран. Плюс захват мыши и аудио в вебе должны включаться только после первого клика пользователя мышкой. А в плагинах то все любят пихать все в автолоады и включать сразу на старте, что просто отваливается.
Это коммент к
Так что да, тот анон прав, это в каком то смысле "насрать"
>In order to be able to manipulate those StorageAccessors, an autoload called GlobalStorageManager is defined when the plugin is activated.
Так что да, тот анон прав, это в каком то смысле "насрать"
>>4861
https://ru.wikipedia.org/wiki/Технический_долг
Вообще, я не понимаю, в чём твои "страдания"...
Какая у тебя скорость? Хотя бы 100 слов в минуту?
>>4870
Френдли фаер, ты не туда воюешь.
>>4875
Речь о том, что StorageAccessor автор этого аддона предлагает пихать везде, где нужно что-то хранить и загружать. Хрен с ним, с синглтоном - почему вместо
Автор предлагает пихать тыщи новых нод в дерево?
>причины, чтобы страдать
https://ru.wikipedia.org/wiki/Технический_долг
>...накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением качеством при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем. Технический долг обычно незаметен для конечных пользователей продукта, а связан с недостатками в сопровождаемости, тестируемости, понятности, модифицируемости, переносимости.
Вообще, я не понимаю, в чём твои "страдания"...
Какая у тебя скорость? Хотя бы 100 слов в минуту?
>>4870
Френдли фаер, ты не туда воюешь.
>>4875
Речь о том, что StorageAccessor автор этого аддона предлагает пихать везде, где нужно что-то хранить и загружать. Хрен с ним, с синглтоном - почему вместо
>MyAwesomeStorageSingletonAddon.save(id, data)
>data = MyAwesomeStorageSingletonAddon.load(id)
Автор предлагает пихать тыщи новых нод в дерево?
>>4890
Да, но нодами не рекомендуется срать.
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
И ещё есть эта статья, но немного про другое.
https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html
Это имеет смысл только если у такого компонента специфические свойства, требующие находиться непосредственно в дереве сцены без посредников.
Проблема такой системы сохранения в том, что ты размазываешь игровой объект на несколько нод, совершенно без какой-либо практической пользы.
>Годот нодовый движок.
Да, но нодами не рекомендуется срать.
https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
>Nodes are cheap to produce, but even they have their limits. A project may have tens of thousands of nodes all doing things. The more complex their behavior though, the larger the strain each one adds to a project's performance.
>Godot provides more lightweight objects for creating APIs which nodes use. Be sure to keep these in mind as options when designing how you wish to build your project's features.
И ещё есть эта статья, но немного про другое.
https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html
>Ноды используют аля компоненты.
Это имеет смысл только если у такого компонента специфические свойства, требующие находиться непосредственно в дереве сцены без посредников.
Проблема такой системы сохранения в том, что ты размазываешь игровой объект на несколько нод, совершенно без какой-либо практической пользы.
>>4897
Смысл в том, что ты вообще не пишешь ни строчки кода (не создавая зависимость внутри .gd), а только вешаешь ноду на те объекты которые хочешь сохранять.
Аналогия - создавать MeshInstance нодами или создавать их из кода. Иногда удобнее так, иногда так.
Смысл в том, что ты вообще не пишешь ни строчки кода (не создавая зависимость внутри .gd), а только вешаешь ноду на те объекты которые хочешь сохранять.
Аналогия - создавать MeshInstance нодами или создавать их из кода. Иногда удобнее так, иногда так.
976 Кб, 917x707>>4920
material_surface_set
material_surface_set
В лагерь любителей использовать ресурсы для сохранения.
Есть два любопытных класса: ResourceFormatSaver и ResourceFormatLoader
От них наследуешься и реализуешь свой собственный формат файла.
Я днём попробовал - работает. Код не покажу, ибо на другой машине. Документация в помощь, там несложно.
Могу только сказать, у меня получилось формировать файл .save с ini-форматированием внутри. А потом я еще по другому закодил и получилось бинарное содержимое внутри.
Есть два любопытных класса: ResourceFormatSaver и ResourceFormatLoader
От них наследуешься и реализуешь свой собственный формат файла.
Я днём попробовал - работает. Код не покажу, ибо на другой машине. Документация в помощь, там несложно.
Могу только сказать, у меня получилось формировать файл .save с ini-форматированием внутри. А потом я еще по другому закодил и получилось бинарное содержимое внутри.
>>4904
Выше уже кидали код, который не создаёт зависимостей:
Не нужно тут никаких дополнительных нод и синглтонов.
Просто всё происходит по иерархии:
Поток данных во время сохранения:
Поток данных во время загрузки:
Аргументируй, если считаешь это неправильным.
>не создавая зависимость внутри .gd
Выше уже кидали код, который не создаёт зависимостей:
>func load(data: Dictionary): ...
>func save() -> Dictionary: return { ... }
Не нужно тут никаких дополнительных нод и синглтонов.
Просто всё происходит по иерархии:
>A # сохраняет/загружает B, пишет/читает в/из файл/а
>_ B # сохраняет/загружает C
>_ _ C # сохраняет/загружает D
>_ _ _ D # лист дерева сцены
Поток данных во время сохранения:
>файл <- A <- B <- C <- D
Поток данных во время загрузки:
>файл -> A -> B -> C -> D
Аргументируй, если считаешь это неправильным.
>>4934
Эти классы нужны только для интеграции с инспектором в редакторе сцен:
Планируешь открывать свои .save-файлы в редакторе (как .tres)? Нет? Тогда зачем?
>ResourceFormatSaver и ResourceFormatLoader
>получилось формировать файл .save
Эти классы нужны только для интеграции с инспектором в редакторе сцен:
>Godot loads resources in the editor or in exported games using ResourceFormatLoaders.
Планируешь открывать свои .save-файлы в редакторе (как .tres)? Нет? Тогда зачем?
>>4934
Основная проблема с сохранениями/загрузками не в том, какой формат использовать, а в том, что ты каждый раз бегаешь как охуевший по всей своей кодовой базе и выискиваешь какие значения у каких объектов нужно сохранить и как их потом восстановить. А куда сохранять - похуй вообще, хоть на забор записывай. Вы вообще не туда спорите, не улавливаете сути проблемы.
Основная проблема с сохранениями/загрузками не в том, какой формат использовать, а в том, что ты каждый раз бегаешь как охуевший по всей своей кодовой базе и выискиваешь какие значения у каких объектов нужно сохранить и как их потом восстановить. А куда сохранять - похуй вообще, хоть на забор записывай. Вы вообще не туда спорите, не улавливаете сути проблемы.
>>4945
Разве? Для примера, у тебя есть: персонаж, автомобиль, квартал города, город.
Что должен сохранять/загружать персонаж? Это персонаж сам решает. Он может, например, сохранять своё состояние: бодрый, сонный, спящий, пьяный. Может сохранять одежду и вещи в сумке, которая у него с собой. Может сохранять, куда он сейчас смотрит и куда хочет добраться.
Что должен сохранять/загружать автомобиль? Автомобиль сам это решает. Он может сохранять состояние двигателя, корпуса, дверей, количество топлива, износ покрышек и прочее. В каком направлении и с какой скоростью он сейчас движется. Но также он сохраняет, кто в нём сейчас находится. Он запрашивает у того, кто в нём сидит (персонажа), и передаёт результат наружу. Или получает данные извне и передаёт их тому, кто в нём должен сидеть (персонажу). Но ему нет дела до того, как и что делает с этими данными тот, кто в нём сидит - он знает только о местах (сиденьях).
Что должен сохранять район города? Персонажей и автомобили. Но персонажи в автомобилях сохраняются по той простой причине, что за их сохранение отвечает автомобиль. При этом району города не нужно знать ни о персонажах, ни об автомобилях, он просто расставляет то, что ему предложил расставить город. То есть район города только знает о местах размещения каких-то загружаемых или сохраняемых объектах.
Допустим, ты хочешь добавить новый объект в сохранение. Придётся ли тебе лезть в код персонажа и автомобиля? Нет, если этот объект их не касается и просто валяется на дороге города. Если он касается только персонажа (элемент одежды), то он будет затрагивать только код персонажа, а код автомобиля и района города не будет о нём знать. Если он касается только автомобиля (чемодан на крыше), то он будет затрагивать только код автомобиля, но не код персонажа и района города.
Так что не вижу причин бегать по всей кодовой базе из-за системы сохранений.
>ты каждый раз бегаешь как охуевший по всей своей кодовой базе и выискиваешь какие значения у каких объектов нужно сохранить и как их потом восстановить
Разве? Для примера, у тебя есть: персонаж, автомобиль, квартал города, город.
Что должен сохранять/загружать персонаж? Это персонаж сам решает. Он может, например, сохранять своё состояние: бодрый, сонный, спящий, пьяный. Может сохранять одежду и вещи в сумке, которая у него с собой. Может сохранять, куда он сейчас смотрит и куда хочет добраться.
Что должен сохранять/загружать автомобиль? Автомобиль сам это решает. Он может сохранять состояние двигателя, корпуса, дверей, количество топлива, износ покрышек и прочее. В каком направлении и с какой скоростью он сейчас движется. Но также он сохраняет, кто в нём сейчас находится. Он запрашивает у того, кто в нём сидит (персонажа), и передаёт результат наружу. Или получает данные извне и передаёт их тому, кто в нём должен сидеть (персонажу). Но ему нет дела до того, как и что делает с этими данными тот, кто в нём сидит - он знает только о местах (сиденьях).
Что должен сохранять район города? Персонажей и автомобили. Но персонажи в автомобилях сохраняются по той простой причине, что за их сохранение отвечает автомобиль. При этом району города не нужно знать ни о персонажах, ни об автомобилях, он просто расставляет то, что ему предложил расставить город. То есть район города только знает о местах размещения каких-то загружаемых или сохраняемых объектах.
Допустим, ты хочешь добавить новый объект в сохранение. Придётся ли тебе лезть в код персонажа и автомобиля? Нет, если этот объект их не касается и просто валяется на дороге города. Если он касается только персонажа (элемент одежды), то он будет затрагивать только код персонажа, а код автомобиля и района города не будет о нём знать. Если он касается только автомобиля (чемодан на крыше), то он будет затрагивать только код автомобиля, но не код персонажа и района города.
Так что не вижу причин бегать по всей кодовой базе из-за системы сохранений.
>>4945
Разве? Для примера, у тебя есть: персонаж, автомобиль, квартал города, город.
Что должен сохранять/загружать персонаж? Это персонаж сам решает. Он может, например, сохранять своё состояние: бодрый, сонный, спящий, пьяный. Может сохранять одежду и вещи в сумке, которая у него с собой. Может сохранять, куда он сейчас смотрит и куда хочет добраться.
Что должен сохранять/загружать автомобиль? Автомобиль сам это решает. Он может сохранять состояние двигателя, корпуса, дверей, количество топлива, износ покрышек и прочее. В каком направлении и с какой скоростью он сейчас движется. Но также он сохраняет, кто в нём сейчас находится. Он запрашивает у того, кто в нём сидит (персонажа), и передаёт результат наружу. Или получает данные извне и передаёт их тому, кто в нём должен сидеть (персонажу). Но ему нет дела до того, как и что делает с этими данными тот, кто в нём сидит - он знает только о местах (сиденьях).
Что должен сохранять район города? Персонажей и автомобили. Но персонажи в автомобилях сохраняются по той простой причине, что за их сохранение отвечает автомобиль. При этом району города не нужно знать ни о персонажах, ни об автомобилях, он просто расставляет то, что ему предложил расставить город. То есть район города только знает о местах размещения каких-то загружаемых или сохраняемых объектах.
Допустим, ты хочешь добавить новый объект в сохранение. Придётся ли тебе лезть в код персонажа и автомобиля? Нет, если этот объект их не касается и просто валяется на дороге города. Если он касается только персонажа (элемент одежды), то он будет затрагивать только код персонажа, а код автомобиля и района города не будет о нём знать. Если он касается только автомобиля (чемодан на крыше), то он будет затрагивать только код автомобиля, но не код персонажа и района города.
Так что не вижу причин бегать по всей кодовой базе из-за системы сохранений.
>ты каждый раз бегаешь как охуевший по всей своей кодовой базе и выискиваешь какие значения у каких объектов нужно сохранить и как их потом восстановить
Разве? Для примера, у тебя есть: персонаж, автомобиль, квартал города, город.
Что должен сохранять/загружать персонаж? Это персонаж сам решает. Он может, например, сохранять своё состояние: бодрый, сонный, спящий, пьяный. Может сохранять одежду и вещи в сумке, которая у него с собой. Может сохранять, куда он сейчас смотрит и куда хочет добраться.
Что должен сохранять/загружать автомобиль? Автомобиль сам это решает. Он может сохранять состояние двигателя, корпуса, дверей, количество топлива, износ покрышек и прочее. В каком направлении и с какой скоростью он сейчас движется. Но также он сохраняет, кто в нём сейчас находится. Он запрашивает у того, кто в нём сидит (персонажа), и передаёт результат наружу. Или получает данные извне и передаёт их тому, кто в нём должен сидеть (персонажу). Но ему нет дела до того, как и что делает с этими данными тот, кто в нём сидит - он знает только о местах (сиденьях).
Что должен сохранять район города? Персонажей и автомобили. Но персонажи в автомобилях сохраняются по той простой причине, что за их сохранение отвечает автомобиль. При этом району города не нужно знать ни о персонажах, ни об автомобилях, он просто расставляет то, что ему предложил расставить город. То есть район города только знает о местах размещения каких-то загружаемых или сохраняемых объектах.
Допустим, ты хочешь добавить новый объект в сохранение. Придётся ли тебе лезть в код персонажа и автомобиля? Нет, если этот объект их не касается и просто валяется на дороге города. Если он касается только персонажа (элемент одежды), то он будет затрагивать только код персонажа, а код автомобиля и района города не будет о нём знать. Если он касается только автомобиля (чемодан на крыше), то он будет затрагивать только код автомобиля, но не код персонажа и района города.
Так что не вижу причин бегать по всей кодовой базе из-за системы сохранений.
>>4945
Улавливаем.
Это всё зависит от игры. Чтобы не пиздеть голословно, давай определимся о какой игре речь? Судя по намёкам выше, про анимации, физику, звуки, речь идёт об убийце скайрима/ведьмака/ассасинов одновременно?
> не улавливаете сути проблемы
Улавливаем.
> каждый раз бегаешь как охуевший по всей своей кодовой базе и выискиваешь какие значения у каких объектов нужно сохранить и как их потом восстановить
Это всё зависит от игры. Чтобы не пиздеть голословно, давай определимся о какой игре речь? Судя по намёкам выше, про анимации, физику, звуки, речь идёт об убийце скайрима/ведьмака/ассасинов одновременно?
>>4950
Итак, мы определились с тем, какие объекта какие поля хотят сохранять. Дальше-то что? Вот игрок нажал F5, что происходит после этого? Кем регистрируется нажатие F5? Какой код он начинает выполнять? Как он опрашивает персонажей и автомобили? Записывает на забор, тут мы выше определились.
Итак, мы определились с тем, какие объекта какие поля хотят сохранять. Дальше-то что? Вот игрок нажал F5, что происходит после этого? Кем регистрируется нажатие F5? Какой код он начинает выполнять? Как он опрашивает персонажей и автомобили? Записывает на забор, тут мы выше определились.
>>4940
Я не сказал что считаю это неправильным, такой код создает зависимость в виде load() save() и том что тебе надо будет при изменениях править код, а нода - создает аналогичную зависимость в дереве tscn и при изменениях тебе надо будет менять поля ноды. Вот и все.
Я не сказал что считаю это неправильным, такой код создает зависимость в виде load() save() и том что тебе надо будет при изменениях править код, а нода - создает аналогичную зависимость в дереве tscn и при изменениях тебе надо будет менять поля ноды. Вот и все.
>>4952
Менеджер - перехватчих всех необработанных нажатий обнаруживает нажатие F5, вызывает в синглотоне менеджера сохранений функцию сохранений, та любым способом обходит ноды которые нужно сохранить (хоть рекурсивно все дерево от корня, хоть объекты которые хотят сохранятся могут регистрироваться у него в каком то линейном массиве). Паттерн Visitor кстати тебе что то говорит? Там как раз обратный подход - неважно какая структура и как ее обходить, хоть приставным шагом хоть вприсядку, ты нам главное дай функцию которую вызывать для каждого объекта.
Менеджер - перехватчих всех необработанных нажатий обнаруживает нажатие F5, вызывает в синглотоне менеджера сохранений функцию сохранений, та любым способом обходит ноды которые нужно сохранить (хоть рекурсивно все дерево от корня, хоть объекты которые хотят сохранятся могут регистрироваться у него в каком то линейном массиве). Паттерн Visitor кстати тебе что то говорит? Там как раз обратный подход - неважно какая структура и как ее обходить, хоть приставным шагом хоть вприсядку, ты нам главное дай функцию которую вызывать для каждого объекта.
>>4969
Нет у тебя варианта без синглтона, потому что ты не можешь быть умнее разработчиков, которые вхуячили кучу синглтонов выполняющих свои задачи. Был бы ты умнее - ты бы тут не тралил.
- это синглтон, без него ты не перехватишь копку F5. На этом всё.
Нет у тебя варианта без синглтона, потому что ты не можешь быть умнее разработчиков, которые вхуячили кучу синглтонов выполняющих свои задачи. Был бы ты умнее - ты бы тут не тралил.
> Input
- это синглтон, без него ты не перехватишь копку F5. На этом всё.
>>4970
Я, конечно, имел в виду "не заводя свой синглтон-менеджер сейвов".
Но чисто формально, движок опенсор, и можно и Input подменить своим...
Такое может понадобиться для мультиплеерных кнопок например
Я, конечно, имел в виду "не заводя свой синглтон-менеджер сейвов".
Но чисто формально, движок опенсор, и можно и Input подменить своим...
Такое может понадобиться для мультиплеерных кнопок например
>>4951
Речь идет об универсальном решении, пригодном для игры любого типа. Например у меня есть сбор игровой аналитики, написанный еще пару лет назад. Я его копипастом вставляю во все свои игры и все работает. С сейвами хуй так сделаешь, каждый раз переизобретенный велосипед приходится вкорячивать.
>Чтобы не пиздеть голословно, давай определимся о какой игре речь? Судя по намёкам выше, про анимации, физику, звуки, речь идёт об убийце скайрима/ведьмака/ассасинов одновременно?
Речь идет об универсальном решении, пригодном для игры любого типа. Например у меня есть сбор игровой аналитики, написанный еще пару лет назад. Я его копипастом вставляю во все свои игры и все работает. С сейвами хуй так сделаешь, каждый раз переизобретенный велосипед приходится вкорячивать.
>>4844
Ничоси. А я ж вижел эти функции в доке ещё тогда, до выхода четвёрки, но придал значения именно из-за неочевидных названий.
Энивей, var_to_str и JSON.stringify дают схожие результаты и одинаково читаемы. Плюс есть ультимативное File.store_var для хранения того же самого в бинарном формате.
>Всё есть и работает:
Ничоси. А я ж вижел эти функции в доке ещё тогда, до выхода четвёрки, но придал значения именно из-за неочевидных названий.
Энивей, var_to_str и JSON.stringify дают схожие результаты и одинаково читаемы. Плюс есть ультимативное File.store_var для хранения того же самого в бинарном формате.
24 Кб, 780x880>>4961
Ты аддон видел? https://github.com/locker-godot/locker
На пикриле - то, что предлагает делать автор аддона.
Возможно, в каких-то ситуациях это имеет смысл...
>>4952
Самый простой вариант, рекурсивный брутфорс:
Конечно, это будет тормозить в случае огромного объёма сохраняемых данных. Поэтому придётся как-то резать на части и кэшировать никак не меняющиеся результаты. Но это вроде как универсальное решение, работающее независимо от структуры игры и геймплея, пока ты следуешь установленной тобой иерархии.
>>4970
Разработчики сохраняют старое API, чтоб ты не мучился с обновлением игры на новую версию движка.
>>4987
Насколько я понимаю, JSON.stringify гарантирует соответствие общепринятому стандарту JSON и позволяет выводить сразу с красивым форматированием, а var_to_str - это чисто внутренняя фича Godot для каких-то внутренних дел, которая ничего не гарантирует и, вроде бы, загоняет всё в одну строку без переносов.
>надо будет менять поля ноды
Ты аддон видел? https://github.com/locker-godot/locker
На пикриле - то, что предлагает делать автор аддона.
Возможно, в каких-то ситуациях это имеет смысл...
>>4952
>Вот игрок нажал F5, что происходит после этого?
Самый простой вариант, рекурсивный брутфорс:
>func save() -> Dictionary:
>_ var data := {}
>_ for o in objects: data[o.id] = o.save()
>_ return data
Конечно, это будет тормозить в случае огромного объёма сохраняемых данных. Поэтому придётся как-то резать на части и кэшировать никак не меняющиеся результаты. Но это вроде как универсальное решение, работающее независимо от структуры игры и геймплея, пока ты следуешь установленной тобой иерархии.
>>4970
Разработчики сохраняют старое API, чтоб ты не мучился с обновлением игры на новую версию движка.
>>4987
>дают схожие результаты
Насколько я понимаю, JSON.stringify гарантирует соответствие общепринятому стандарту JSON и позволяет выводить сразу с красивым форматированием, а var_to_str - это чисто внутренняя фича Godot для каких-то внутренних дел, которая ничего не гарантирует и, вроде бы, загоняет всё в одну строку без переносов.
>>4986
Вот уж теперь-то можно начинать делать игры
Вот уж теперь-то можно начинать делать игры
>>4986
как же хорошо что я еще не начинал делать игру
как же хорошо что я еще не начинал делать игру
Точнее, менеджер сохранений.
Висит в памяти в течение всей игровой сессии.
Содержит в себе два словаря, мутабельный и иммутабельный.
Имеет четыре метода: create(key, value, update = false), read(key, default, write_default = false), update(key, value, create = false), delete(key, only_value = false)
Методы работают со встроенными словарями таким образом, что любые изменения вносятся в мутабельный словарь, а при чтении сначала опрашивается мутабельный словарь, если в нём не найден ключ, опрашивается иммутабельный, если и в нём не найден ключ, возвращается дефолтное значение. Если нужно дефолтное значение добавлять в мутабельный словарь, если не найден ключ, то юзаем настройку через аргумент.
Так же есть массив контрольных точек, которыми являются глубокие копии мутабельного словаря. Эти контрольные точки могут быть быстро загружены из массива для быстрой загрузки без поднятия сейвов из файловой системы.
Теперь внимание.
Иммутабельный словарь - это эталонные данные игрового мира, он создаётся один раз при старте игры. Если у игры есть моды/длц, то в момент старта приложения оно опрашивает зарегистрированные моды и они предоставляют свои фрагменты данных в иммутабельный словарь. Этот словарь может быть достаточно большим и его не нужно сохранять постоянно. Он сохраняется один раз, в игровом профиле, который создаёт игрок в начале. Сейв-файлы являются сохранённым мутабельным словарём, работают как инкремент к ворлд-файлу в профиле.
Таким образом менеджер сохранений управляет следующими файлами:
1) ворлд-файл, который сохраняется редко, при создании новой игры внутри профиля, либо при изменении списка модов/длц
2) сейв-файл, один или несколько в зависимости от нужд, сохраняется часто, имеет малый размер, поскольку содержит только изменения относительно эталонного набора данных, впрочем в зависимости от величины игры сейвы тоже могут раздуваться.
3) конфиг-файл профиля, в котором хранятся настройки всего приложения в целом
То есть, игрок может полностью переключиться на другой профиль, с другим миром, сгенерированным на других сидах. Сейвы не будут подходить к ворлду, что является дополнительной защитой от читеров.
Стратегии удаления неактуальных данных являются предметом конфигурации менеджера, можно удалять их, а можно хранить, а можно предоставить эту возможность игроку.
Как происходит процесс сохранения? Устанавливается режим read_only и просто записывается мутабельный словарь в сейв-файл.
Как происходит процесс чекпойнтирования перед боссом? Просто копируется мутабельный словарь в массив чекпойнтов.
Как происходит заполнение мутабельного словаря? А вот тут вступает в дело паттерн обсервер. Объекты, которым требуется сохранить данные о себе, подписываются на КРУД-методы менеджера сохранений и при изменении своих данных, синхронизируют их со словарём. Таким образом идёт "трудолюбивое" формирование сейв-файла для "ленивого" процесса сохранения.
Как происходит загрузка? Вне зависимости от источника загрузки, чекпойнт или файл, сначала устанавливается режим read_only, испускается сигнал начала загрузки, все кто подписан на сигнал, делают свои дела, например встают на паузу и ждут дальнейших указаний. Происходит загрузка и проверка данных, если на этом этапе происходят косяки, испускается сигнал отмены, и все задействованные ноды возобновляют свои дела. Новые данные копируются в мутабельный словарь. Испускается сигнал окончания загрузки. Ноды проверяют, должны ли они существовать и если оказывается, что не должны, они выгружаются, а если оказывается, что должны, то обновляют данные о себе (не сидел у костра, а стоял на скале, например). Затем основная нода игрового мира (слово на букву с), управляющая загрузкой-выгрузкой чанков, также опрашивает менеджер на наличие нод, которые должны быть и загружает их. Загруженные ноды опрашивают менеджер на предмет актуальных данных о себе и действуют. И так пока все не обновятся. Когда все подписанные ноды отчитались об обновлении, испускается сигнал окончания обновления.
Дополнительный плюс такой системы в том, что данные об объектах доступны всегда, таким образом, в рамках исполнения квестов игроком, возможно менять состояние объектов, которые в данный момент не загружены (спиздил статую Талоса в Вайтране, а в Рифтене об этом уже знают, например, вопрос скорости передачи данных решается отдельно, например созданием объекта-таймера в потомках к основному миру, который с... существует, кхм, всегда, и сохранять таймаут этого таймера, и по окончании таймаута он произведёт изменения в данных).
Вот такой прожект. Разьебите по пунктам, в чём я не прав?
Висит в памяти в течение всей игровой сессии.
Содержит в себе два словаря, мутабельный и иммутабельный.
Имеет четыре метода: create(key, value, update = false), read(key, default, write_default = false), update(key, value, create = false), delete(key, only_value = false)
Методы работают со встроенными словарями таким образом, что любые изменения вносятся в мутабельный словарь, а при чтении сначала опрашивается мутабельный словарь, если в нём не найден ключ, опрашивается иммутабельный, если и в нём не найден ключ, возвращается дефолтное значение. Если нужно дефолтное значение добавлять в мутабельный словарь, если не найден ключ, то юзаем настройку через аргумент.
Так же есть массив контрольных точек, которыми являются глубокие копии мутабельного словаря. Эти контрольные точки могут быть быстро загружены из массива для быстрой загрузки без поднятия сейвов из файловой системы.
Теперь внимание.
Иммутабельный словарь - это эталонные данные игрового мира, он создаётся один раз при старте игры. Если у игры есть моды/длц, то в момент старта приложения оно опрашивает зарегистрированные моды и они предоставляют свои фрагменты данных в иммутабельный словарь. Этот словарь может быть достаточно большим и его не нужно сохранять постоянно. Он сохраняется один раз, в игровом профиле, который создаёт игрок в начале. Сейв-файлы являются сохранённым мутабельным словарём, работают как инкремент к ворлд-файлу в профиле.
Таким образом менеджер сохранений управляет следующими файлами:
1) ворлд-файл, который сохраняется редко, при создании новой игры внутри профиля, либо при изменении списка модов/длц
2) сейв-файл, один или несколько в зависимости от нужд, сохраняется часто, имеет малый размер, поскольку содержит только изменения относительно эталонного набора данных, впрочем в зависимости от величины игры сейвы тоже могут раздуваться.
3) конфиг-файл профиля, в котором хранятся настройки всего приложения в целом
То есть, игрок может полностью переключиться на другой профиль, с другим миром, сгенерированным на других сидах. Сейвы не будут подходить к ворлду, что является дополнительной защитой от читеров.
Стратегии удаления неактуальных данных являются предметом конфигурации менеджера, можно удалять их, а можно хранить, а можно предоставить эту возможность игроку.
Как происходит процесс сохранения? Устанавливается режим read_only и просто записывается мутабельный словарь в сейв-файл.
Как происходит процесс чекпойнтирования перед боссом? Просто копируется мутабельный словарь в массив чекпойнтов.
Как происходит заполнение мутабельного словаря? А вот тут вступает в дело паттерн обсервер. Объекты, которым требуется сохранить данные о себе, подписываются на КРУД-методы менеджера сохранений и при изменении своих данных, синхронизируют их со словарём. Таким образом идёт "трудолюбивое" формирование сейв-файла для "ленивого" процесса сохранения.
Как происходит загрузка? Вне зависимости от источника загрузки, чекпойнт или файл, сначала устанавливается режим read_only, испускается сигнал начала загрузки, все кто подписан на сигнал, делают свои дела, например встают на паузу и ждут дальнейших указаний. Происходит загрузка и проверка данных, если на этом этапе происходят косяки, испускается сигнал отмены, и все задействованные ноды возобновляют свои дела. Новые данные копируются в мутабельный словарь. Испускается сигнал окончания загрузки. Ноды проверяют, должны ли они существовать и если оказывается, что не должны, они выгружаются, а если оказывается, что должны, то обновляют данные о себе (не сидел у костра, а стоял на скале, например). Затем основная нода игрового мира (слово на букву с), управляющая загрузкой-выгрузкой чанков, также опрашивает менеджер на наличие нод, которые должны быть и загружает их. Загруженные ноды опрашивают менеджер на предмет актуальных данных о себе и действуют. И так пока все не обновятся. Когда все подписанные ноды отчитались об обновлении, испускается сигнал окончания обновления.
Дополнительный плюс такой системы в том, что данные об объектах доступны всегда, таким образом, в рамках исполнения квестов игроком, возможно менять состояние объектов, которые в данный момент не загружены (спиздил статую Талоса в Вайтране, а в Рифтене об этом уже знают, например, вопрос скорости передачи данных решается отдельно, например созданием объекта-таймера в потомках к основному миру, который с... существует, кхм, всегда, и сохранять таймаут этого таймера, и по окончании таймаута он произведёт изменения в данных).
Вот такой прожект. Разьебите по пунктам, в чём я не прав?
Точнее, менеджер сохранений.
Висит в памяти в течение всей игровой сессии.
Содержит в себе два словаря, мутабельный и иммутабельный.
Имеет четыре метода: create(key, value, update = false), read(key, default, write_default = false), update(key, value, create = false), delete(key, only_value = false)
Методы работают со встроенными словарями таким образом, что любые изменения вносятся в мутабельный словарь, а при чтении сначала опрашивается мутабельный словарь, если в нём не найден ключ, опрашивается иммутабельный, если и в нём не найден ключ, возвращается дефолтное значение. Если нужно дефолтное значение добавлять в мутабельный словарь, если не найден ключ, то юзаем настройку через аргумент.
Так же есть массив контрольных точек, которыми являются глубокие копии мутабельного словаря. Эти контрольные точки могут быть быстро загружены из массива для быстрой загрузки без поднятия сейвов из файловой системы.
Теперь внимание.
Иммутабельный словарь - это эталонные данные игрового мира, он создаётся один раз при старте игры. Если у игры есть моды/длц, то в момент старта приложения оно опрашивает зарегистрированные моды и они предоставляют свои фрагменты данных в иммутабельный словарь. Этот словарь может быть достаточно большим и его не нужно сохранять постоянно. Он сохраняется один раз, в игровом профиле, который создаёт игрок в начале. Сейв-файлы являются сохранённым мутабельным словарём, работают как инкремент к ворлд-файлу в профиле.
Таким образом менеджер сохранений управляет следующими файлами:
1) ворлд-файл, который сохраняется редко, при создании новой игры внутри профиля, либо при изменении списка модов/длц
2) сейв-файл, один или несколько в зависимости от нужд, сохраняется часто, имеет малый размер, поскольку содержит только изменения относительно эталонного набора данных, впрочем в зависимости от величины игры сейвы тоже могут раздуваться.
3) конфиг-файл профиля, в котором хранятся настройки всего приложения в целом
То есть, игрок может полностью переключиться на другой профиль, с другим миром, сгенерированным на других сидах. Сейвы не будут подходить к ворлду, что является дополнительной защитой от читеров.
Стратегии удаления неактуальных данных являются предметом конфигурации менеджера, можно удалять их, а можно хранить, а можно предоставить эту возможность игроку.
Как происходит процесс сохранения? Устанавливается режим read_only и просто записывается мутабельный словарь в сейв-файл.
Как происходит процесс чекпойнтирования перед боссом? Просто копируется мутабельный словарь в массив чекпойнтов.
Как происходит заполнение мутабельного словаря? А вот тут вступает в дело паттерн обсервер. Объекты, которым требуется сохранить данные о себе, подписываются на КРУД-методы менеджера сохранений и при изменении своих данных, синхронизируют их со словарём. Таким образом идёт "трудолюбивое" формирование сейв-файла для "ленивого" процесса сохранения.
Как происходит загрузка? Вне зависимости от источника загрузки, чекпойнт или файл, сначала устанавливается режим read_only, испускается сигнал начала загрузки, все кто подписан на сигнал, делают свои дела, например встают на паузу и ждут дальнейших указаний. Происходит загрузка и проверка данных, если на этом этапе происходят косяки, испускается сигнал отмены, и все задействованные ноды возобновляют свои дела. Новые данные копируются в мутабельный словарь. Испускается сигнал окончания загрузки. Ноды проверяют, должны ли они существовать и если оказывается, что не должны, они выгружаются, а если оказывается, что должны, то обновляют данные о себе (не сидел у костра, а стоял на скале, например). Затем основная нода игрового мира (слово на букву с), управляющая загрузкой-выгрузкой чанков, также опрашивает менеджер на наличие нод, которые должны быть и загружает их. Загруженные ноды опрашивают менеджер на предмет актуальных данных о себе и действуют. И так пока все не обновятся. Когда все подписанные ноды отчитались об обновлении, испускается сигнал окончания обновления.
Дополнительный плюс такой системы в том, что данные об объектах доступны всегда, таким образом, в рамках исполнения квестов игроком, возможно менять состояние объектов, которые в данный момент не загружены (спиздил статую Талоса в Вайтране, а в Рифтене об этом уже знают, например, вопрос скорости передачи данных решается отдельно, например созданием объекта-таймера в потомках к основному миру, который с... существует, кхм, всегда, и сохранять таймаут этого таймера, и по окончании таймаута он произведёт изменения в данных).
Вот такой прожект. Разьебите по пунктам, в чём я не прав?
Висит в памяти в течение всей игровой сессии.
Содержит в себе два словаря, мутабельный и иммутабельный.
Имеет четыре метода: create(key, value, update = false), read(key, default, write_default = false), update(key, value, create = false), delete(key, only_value = false)
Методы работают со встроенными словарями таким образом, что любые изменения вносятся в мутабельный словарь, а при чтении сначала опрашивается мутабельный словарь, если в нём не найден ключ, опрашивается иммутабельный, если и в нём не найден ключ, возвращается дефолтное значение. Если нужно дефолтное значение добавлять в мутабельный словарь, если не найден ключ, то юзаем настройку через аргумент.
Так же есть массив контрольных точек, которыми являются глубокие копии мутабельного словаря. Эти контрольные точки могут быть быстро загружены из массива для быстрой загрузки без поднятия сейвов из файловой системы.
Теперь внимание.
Иммутабельный словарь - это эталонные данные игрового мира, он создаётся один раз при старте игры. Если у игры есть моды/длц, то в момент старта приложения оно опрашивает зарегистрированные моды и они предоставляют свои фрагменты данных в иммутабельный словарь. Этот словарь может быть достаточно большим и его не нужно сохранять постоянно. Он сохраняется один раз, в игровом профиле, который создаёт игрок в начале. Сейв-файлы являются сохранённым мутабельным словарём, работают как инкремент к ворлд-файлу в профиле.
Таким образом менеджер сохранений управляет следующими файлами:
1) ворлд-файл, который сохраняется редко, при создании новой игры внутри профиля, либо при изменении списка модов/длц
2) сейв-файл, один или несколько в зависимости от нужд, сохраняется часто, имеет малый размер, поскольку содержит только изменения относительно эталонного набора данных, впрочем в зависимости от величины игры сейвы тоже могут раздуваться.
3) конфиг-файл профиля, в котором хранятся настройки всего приложения в целом
То есть, игрок может полностью переключиться на другой профиль, с другим миром, сгенерированным на других сидах. Сейвы не будут подходить к ворлду, что является дополнительной защитой от читеров.
Стратегии удаления неактуальных данных являются предметом конфигурации менеджера, можно удалять их, а можно хранить, а можно предоставить эту возможность игроку.
Как происходит процесс сохранения? Устанавливается режим read_only и просто записывается мутабельный словарь в сейв-файл.
Как происходит процесс чекпойнтирования перед боссом? Просто копируется мутабельный словарь в массив чекпойнтов.
Как происходит заполнение мутабельного словаря? А вот тут вступает в дело паттерн обсервер. Объекты, которым требуется сохранить данные о себе, подписываются на КРУД-методы менеджера сохранений и при изменении своих данных, синхронизируют их со словарём. Таким образом идёт "трудолюбивое" формирование сейв-файла для "ленивого" процесса сохранения.
Как происходит загрузка? Вне зависимости от источника загрузки, чекпойнт или файл, сначала устанавливается режим read_only, испускается сигнал начала загрузки, все кто подписан на сигнал, делают свои дела, например встают на паузу и ждут дальнейших указаний. Происходит загрузка и проверка данных, если на этом этапе происходят косяки, испускается сигнал отмены, и все задействованные ноды возобновляют свои дела. Новые данные копируются в мутабельный словарь. Испускается сигнал окончания загрузки. Ноды проверяют, должны ли они существовать и если оказывается, что не должны, они выгружаются, а если оказывается, что должны, то обновляют данные о себе (не сидел у костра, а стоял на скале, например). Затем основная нода игрового мира (слово на букву с), управляющая загрузкой-выгрузкой чанков, также опрашивает менеджер на наличие нод, которые должны быть и загружает их. Загруженные ноды опрашивают менеджер на предмет актуальных данных о себе и действуют. И так пока все не обновятся. Когда все подписанные ноды отчитались об обновлении, испускается сигнал окончания обновления.
Дополнительный плюс такой системы в том, что данные об объектах доступны всегда, таким образом, в рамках исполнения квестов игроком, возможно менять состояние объектов, которые в данный момент не загружены (спиздил статую Талоса в Вайтране, а в Рифтене об этом уже знают, например, вопрос скорости передачи данных решается отдельно, например созданием объекта-таймера в потомках к основному миру, который с... существует, кхм, всегда, и сохранять таймаут этого таймера, и по окончании таймаута он произведёт изменения в данных).
Вот такой прожект. Разьебите по пунктам, в чём я не прав?
>>5085
Дубина! Ты сейчас нарвёшься, блин! Я думаешь не смогу тебя поколотить? Я смогу тебя поколотить, балда!
Дубина! Ты сейчас нарвёшься, блин! Я думаешь не смогу тебя поколотить? Я смогу тебя поколотить, балда!
>>5047
Зачем? Может быть, лучше все 150 Гб из папки игры скопировать в другую папку?
В том, что копируешь данные из res:// в user:// чтобы... чтобы ничего не делать?
>Он сохраняется один раз, в игровом профиле, который создаёт игрок в начале.
Зачем? Может быть, лучше все 150 Гб из папки игры скопировать в другую папку?
>в чём я не прав
В том, что копируешь данные из res:// в user:// чтобы... чтобы ничего не делать?
>>5107
перехэшируй
перехэшируй
А в 4-ке html5 экспорт не поддерживает Compute shaders? Не понмю чтобы видел онлайн демок, документация по этому поводу ничего не говорит, в паре мест видел только упоминание что
misc/compute_shader_heightmap: Not supported on the Compatibility rendering method (which the web platform always uses).
Видимо речь о том что надо WebGPU, а там WebGL, который на GL ES 2.0
misc/compute_shader_heightmap: Not supported on the Compatibility rendering method (which the web platform always uses).
Видимо речь о том что надо WebGPU, а там WebGL, который на GL ES 2.0
>>5134
Я не знаю, братан.
Я не знаю, братан.
272 Кб, 680x956>>5134
https://docs.godotengine.org/en/stable/tutorials/shaders/compute_shaders.html
https://docs.godotengine.org/en/stable/tutorials/rendering/renderers.html
>документация по этому поводу ничего не говорит
https://docs.godotengine.org/en/stable/tutorials/shaders/compute_shaders.html
>Compute shaders can only be used from RenderingDevice-based renderers (the Forward+ or Mobile renderer).
https://docs.godotengine.org/en/stable/tutorials/rendering/renderers.html
>Choose Compatibility if:
>You are developing for web. In this case, Compatibility is the only choice.
Небольшой список лучшего софта в мире
https://www.youtube.com/watch?v=2HxKr0MVwQs
https://www.youtube.com/watch?v=2HxKr0MVwQs
>>5148
Справедливо, надо было повнимательнее прочитать и сделать логический вывод.
Интересно есть ли смысл нагородить, скажем, WebGPU загрузчик в js-части и коммуницировать с годотом. Так, наверное, можно и Compute Shaders в 3-ке запустить, но непонятно можно ли это вообще и не съест ли коммуницирование выгоду.
Справедливо, надо было повнимательнее прочитать и сделать логический вывод.
Интересно есть ли смысл нагородить, скажем, WebGPU загрузчик в js-части и коммуницировать с годотом. Так, наверное, можно и Compute Shaders в 3-ке запустить, но непонятно можно ли это вообще и не съест ли коммуницирование выгоду.
>>5182
Ладно, webgpu пока сырой, на пека в фуррифоксе не работает, на мобилке ни в каком.
Ладно, webgpu пока сырой, на пека в фуррифоксе не работает, на мобилке ни в каком.
>>5182
А для чего тебе вообще compute shader в веб-игре?
Что ты там считать собрался на видеокарте? Нейронки?
А для чего тебе вообще compute shader в веб-игре?
Что ты там считать собрался на видеокарте? Нейронки?
>>5227
Да разные. Конкретно мне подходит для симуляции водички и boids. И некоторые шейдеры похоже выгоднее делать через компьют, а не через чтение вьюпортов. Все что выигрывает от параллельности.
Написал большой ответ, но стер. Суть в том что это вопрос больше выбора версии движка, и я могу сделать отдельно версию 4-десктоп-компьют для шоукейза, а в вебе все равно оставаться на 3-ке с вариантом помельче, потому что буста не будет.
Да разные. Конкретно мне подходит для симуляции водички и boids. И некоторые шейдеры похоже выгоднее делать через компьют, а не через чтение вьюпортов. Все что выигрывает от параллельности.
Написал большой ответ, но стер. Суть в том что это вопрос больше выбора версии движка, и я могу сделать отдельно версию 4-десктоп-компьют для шоукейза, а в вебе все равно оставаться на 3-ке с вариантом помельче, потому что буста не будет.
>>5232
Все хочу следующую игру на SpryTile замутить (аналог CrocoTile3d) или типа https://godotengine.org/asset-library/asset/2873
Все хочу следующую игру на SpryTile замутить (аналог CrocoTile3d) или типа https://godotengine.org/asset-library/asset/2873
32 Кб, 1474x111Кстати пытался найти, можно ли как то менять размер ячейки октотри в физике или она автоматически считается. Не нашел, но зато наткнулся на упоминание в Jolt рекомендуемых размеров физ объектов (помню несколько раз вопрос поднимался в треде)
Чтобы симуляция была точнее, динамическим объектам следует быть:
размером от 0.1 до 10 метров,
иметь скорости от 0 до 500 м/c,
гравитация от 0 до 10 м/с^2.
Статическим объектам следует быть от 0.1 до 2000 метров длиной.
То есть не стоит пытаться симулировать молекулу скачущую по имперскому крейсеру.
Чтобы симуляция была точнее, динамическим объектам следует быть:
размером от 0.1 до 10 метров,
иметь скорости от 0 до 500 м/c,
гравитация от 0 до 10 м/с^2.
Статическим объектам следует быть от 0.1 до 2000 метров длиной.
То есть не стоит пытаться симулировать молекулу скачущую по имперскому крейсеру.
>>5240
Ради интереса глянул, это 1000 узлов, 1800 км/ч, то есть дозвуковые самолеты.
Блин, получается что и у огнестрела (типа калаш, m-16), и у танковых снарядов еще времен второй мировой скорость обычно раза в 2 выше.
>500 м/c
Ради интереса глянул, это 1000 узлов, 1800 км/ч, то есть дозвуковые самолеты.
Блин, получается что и у огнестрела (типа калаш, m-16), и у танковых снарядов еще времен второй мировой скорость обычно раза в 2 выше.
>>5253
Скорость в играх обычно сильно ниже 500 м/с, но физические симуляции тут ни при чём - просто игре потребуется загружать очень много декораций для движения на такой скорости где-либо кроме чистого космоса. Для реалистичных снарядов используются рейкасты; кидать RigidBody3D рационально только в случае какой-нибудь гранаты/ракеты/шара плазмы. Вообще, если ты делаешь игру, а не симулятор, то заботиться тебе придётся совсем о другом. Игры постоянно используют уловки ради фана игрока.
Для примера, скорость машин в GTA 5 намного ниже реалистичной, а игровой спидометр завышает свои показания. Почему? Потому что даже на SSD игра не всегда успевает подгружать нужные чанки города, а удерживать их все в оперативной памяти не может. Однако, это техническое ограничение скорости не мешает миллионам игроков наслаждаться игрой.
Скорость в играх обычно сильно ниже 500 м/с, но физические симуляции тут ни при чём - просто игре потребуется загружать очень много декораций для движения на такой скорости где-либо кроме чистого космоса. Для реалистичных снарядов используются рейкасты; кидать RigidBody3D рационально только в случае какой-нибудь гранаты/ракеты/шара плазмы. Вообще, если ты делаешь игру, а не симулятор, то заботиться тебе придётся совсем о другом. Игры постоянно используют уловки ради фана игрока.
Для примера, скорость машин в GTA 5 намного ниже реалистичной, а игровой спидометр завышает свои показания. Почему? Потому что даже на SSD игра не всегда успевает подгружать нужные чанки города, а удерживать их все в оперативной памяти не может. Однако, это техническое ограничение скорости не мешает миллионам игроков наслаждаться игрой.
>>5264
Только не рейкастами, а вычислением баллистической траектории, а так да.
Можно сделать вывод проще - если игра мультяшная, то можно и медленные пульки ригидобдями, а если симулятор, то надо свою баллистику и аэродинамику.
Только не рейкастами, а вычислением баллистической траектории, а так да.
Можно сделать вывод проще - если игра мультяшная, то можно и медленные пульки ригидобдями, а если симулятор, то надо свою баллистику и аэродинамику.
956 Кб, 2000x1396Мигель Де Икаса если кто из красноглазых ИТТ его помнит, везет Годот на iOS.
>>5278
Пик с айпада.
Пик с айпада.
>>5278
Лидер Mono, вроде, который трудновато было пропихивать на iOS (потому что у эппла был запрет на виртуальные машины в прогах - а то вдруг что то скачает в обход них и выполнит)
Лидер Mono, вроде, который трудновато было пропихивать на iOS (потому что у эппла был запрет на виртуальные машины в прогах - а то вдруг что то скачает в обход них и выполнит)
1,8 Мб, 1280x720давно не интересовался Годотом, потому что планировал в голове свои будущие шедевры, а тут такое... больше нет поводов НЕ делать игры, пиздец...
1,2 Мб, 1295x734>>5304
Ждём...
Ждём...
>>5309
Недостаточно долго планировал.
Недостаточно долго планировал.
3,2 Мб, mp4,852x480, 1:08
>>5325
Игорь.
Игорь.
18,5 Мб, mp4,1280x720, 1:48
>>5435
Такая ж хуйня.
А по поводу пикчи: на годоте у нас с тобой хоть недоделки есть, юнити я тоже скачивал, тогда ещё в далёком 2к18 и сразу такое оттржение "фунахуй", закрыл и удалил. Анрил4 дольше продержался, но из-за конпеляции шейдеров постоянной и он меня доебал.
А на годоте заебись, достаётся за полсекунды, в нищепекарне лежит как влитой.
Такая ж хуйня.
А по поводу пикчи: на годоте у нас с тобой хоть недоделки есть, юнити я тоже скачивал, тогда ещё в далёком 2к18 и сразу такое оттржение "фунахуй", закрыл и удалил. Анрил4 дольше продержался, но из-за конпеляции шейдеров постоянной и он меня доебал.
А на годоте заебись, достаётся за полсекунды, в нищепекарне лежит как влитой.
>>5435
>>5441
У вас скоп большой, гарантирую. Теряете интерес задолго до финального результата. Возьмите микроидею на неделю, она неизбежено распухнет до месяца, но месяца должно хватить на удержание интереса. Опубликуете первую полноценную игру - дальше легче пойдет.
Если конечно есть желание реально игры делать, а не играться в движке. Играться в движке тоже норм.
>>5441
У вас скоп большой, гарантирую. Теряете интерес задолго до финального результата. Возьмите микроидею на неделю, она неизбежено распухнет до месяца, но месяца должно хватить на удержание интереса. Опубликуете первую полноценную игру - дальше легче пойдет.
Если конечно есть желание реально игры делать, а не играться в движке. Играться в движке тоже норм.
>>5443
Да, скоп большой, хочется экшен-слешер в открытом мире с прокачкой, квестами, скиллчеками в диалогах. Но понимание объёма уже пришло.
Я делал мини-игры и доводил до играбельного состояния (тетрис, сапёр и т.п.) В общем-то сижу и играю. В общем-то цель достигнута. Ведь никто не требовал обязательно публиковать.
А игра мечты? Я уже говорил, ранее, просто сидишь у реки и ждёшь, пока по ней проплывёт релиз игры похожей на твою мечту. Потому что мы все в едином инфополе живём. Родилась у тебя мечта и полетела синхроимпульсом по резонансу Шумана в коллективное бессознательное, начала сниться людям, похожим на тебя. Если ты сам не захочешь реализовать её, то найдутся другие, да и неизвестно, твоя ли это была мечта, или она тоже приснилась тебе однажды.
Да, скоп большой, хочется экшен-слешер в открытом мире с прокачкой, квестами, скиллчеками в диалогах. Но понимание объёма уже пришло.
Я делал мини-игры и доводил до играбельного состояния (тетрис, сапёр и т.п.) В общем-то сижу и играю. В общем-то цель достигнута. Ведь никто не требовал обязательно публиковать.
А игра мечты? Я уже говорил, ранее, просто сидишь у реки и ждёшь, пока по ней проплывёт релиз игры похожей на твою мечту. Потому что мы все в едином инфополе живём. Родилась у тебя мечта и полетела синхроимпульсом по резонансу Шумана в коллективное бессознательное, начала сниться людям, похожим на тебя. Если ты сам не захочешь реализовать её, то найдутся другие, да и неизвестно, твоя ли это была мечта, или она тоже приснилась тебе однажды.
>>5447
Хочется ААА студией быть. А нужно знать свою нишу. Инди ниша удобна, хороша и востребована, особенно сейчас. Делай странное, делай новое, делай маленькое. Пройти игру на час, которая оставит впечатление, может оказаться более ценным экспириенсом для игрока чем 600 часов дрочить вышки в очередном ассассине.
>хочется экшен-слешер в открытом мире с прокачкой, квестами, скиллчеками в диалогах.
Хочется ААА студией быть. А нужно знать свою нишу. Инди ниша удобна, хороша и востребована, особенно сейчас. Делай странное, делай новое, делай маленькое. Пройти игру на час, которая оставит впечатление, может оказаться более ценным экспириенсом для игрока чем 600 часов дрочить вышки в очередном ассассине.
>>5441
И то верно, но хотелось большего...
>>5444
Технически ничего сложного, но для того, чтобы эта концепция была интересной, все эти домики должны существенно отличаться друг от друга внутри. Даже с процедурной генерацией это требует много контента, который сам по себе не доставляет удовольствия. Т.е. разработать этот контент я мог бы, но в чём его фан?
Сейчас вот думаю: может, стоило делать декорации, расставляя их как попало, авось вошёл бы во вкус и получилось бы что-то интересное. Когда на всю игру имеется 3.5 плейсхолдера, работать с ней интереса мало, прогресс совсем не ощущается. Да и навалить различного контента низкого качества несложно. Тут главное соблюдать один общий стиль/настроение. В реалистичных ААА унылое "серое" настроение.
>>5443
А как без этого? Должен быть высокий потанцевал.
Сделал за вечер твою микроидею - дальше что? В чём интерес публиковать эту микроидею, что 100500 раз реализована во всех цветах и размерах в Google Play? Выбирай любую версию, играй сколько влезет... А, не влезет, потому что микроидея == микроинтерес к ней, развод лоха на просмотр рекламы перед геймплеем. Разумеется, если ты не сливаешь 1000 часов в одну гиперказуалку с одной примитивной механикой...
Понимаю, есть люди, которые 1000 часов сливают в банальный Flappy Bird и обожают повторять его по туториалам, типа "любимый флаппи бёрд, но вместо птички самолётик", но это вообще отдельная тема, и подобным играм в принципе не нужен движок на том уровне, на котором сейчас находится Godot. Им там достаточно выводить PNG в <canvas> тег HTML5.
Какой потанцевал у флаппи бёрд? PNG заменить?
У условного "клона GTA" большой потанцевал, это ж практически свой собственный Garry's Mod, только с нормальным транспортом и сразу большой картой. Направление развития любое можно выбрать и надстраивать новые механики одну за другой.
>>5447
Легко: мобы прут по прямой, герой тупо вращается с гигантским супер-пупер гипер-мечом, VFX вспышки перекрывают 99% экрана. За вечер сделаешь базу, а остальное можно доделать как-нибудь попозже.
Понятие растяжимо, но сегодня "открытый мир" == гигантские пустыни, пустыри, пустые поляны и т.д. Следовательно, опенворлд == растянутый филлер. Реализуешь стандартный коридорный экшн, дальше заменяешь загрузочные экраны тупыми пустырями, заставляешь игрока удерживать W всю дорогу. Даже суперпопулярная GTA 5 на этом построена, с этим её дебильным шоссе на 10 км вдоль скучной пустыни. "Слешеры" вообще с камерой сверху вниз, поэтому и подгрузка чанков мира будет проще технически.
Это тоже растяжимое понятие, прокачка может быть банальным +1 к урону и всё, никто не ждёт от тебя S.P.E.C.I.A.L. в ноунейм индюшке от соло автора. Переусложнённое дерево прокачки на самом деле проще реализовать в коде, чем понять в игре (тоже филлерный контент, тебе +1 к урону или к защите?).
"Подай-принеси" квесты делаются легко. Остальные возможные квесты практически не встречаются, ибо игрокам не нравится ломать голову над задачами, а плестись за NPC - вообще своего рода наказание.
Опять же несложно, если сделать фреймворк под это.
В связи с вышеперечисленным не вижу сложности. Физических взаимодействий нет, крафта нет, даже стрельбы как таковой нет (Area3D на меч повесь). Графоманить тексты только научиться и в путь. В графическом плане - прибей камеру к потолку.
Ты просто ищешь оправдания для безделья.
Лично моя проблема с этим в том, что мне хочется собственную игру. Ты предлагаешь удочерить уже взрослого человека вместо воспитания своего - это совершенно разные действия с разным результатом. Естественно, если тебе хочется просто поиграть, тебе разницы никакой не будет, но объективно она есть.
Для примера, Vintage Story начиналась как мод для Minecraft (TerraFirmaCraft), но разрабам надоели все подводные камни Minecraft - запилили свою игру. Возникает вопрос, что им мешало просто играть в ванильный Minecraft, не делая свои модификации? Некоторым людям, видимо, хочется чего-то своего, несмотря на провальность концепции (притащили бесполезный реализм ради реализма - зачем?).
>>5464
Никогда не понимал подобного. Я в игру играю, чтоб расслабиться и отвлечься от реальности, а не чтобы почитать мысли автора в интерактивном формате... Увлекающая игра не должна обрываться через час.
Много видел hack-n-slash от ААА? Это ж инди жанр. Единственные представители от условного АА+ - это франшизы родом из древних времён. Как понимаю, нишевые жанры не получают финансирования без достаточно широко известного имени франшизы.
>у нас с тобой хоть недоделки есть
И то верно, но хотелось большего...
>>5444
>возможностью заходить в каждый дом
Технически ничего сложного, но для того, чтобы эта концепция была интересной, все эти домики должны существенно отличаться друг от друга внутри. Даже с процедурной генерацией это требует много контента, который сам по себе не доставляет удовольствия. Т.е. разработать этот контент я мог бы, но в чём его фан?
Сейчас вот думаю: может, стоило делать декорации, расставляя их как попало, авось вошёл бы во вкус и получилось бы что-то интересное. Когда на всю игру имеется 3.5 плейсхолдера, работать с ней интереса мало, прогресс совсем не ощущается. Да и навалить различного контента низкого качества несложно. Тут главное соблюдать один общий стиль/настроение. В реалистичных ААА унылое "серое" настроение.
>>5443
>У вас скоп большой
А как без этого? Должен быть высокий потанцевал.
>микроидею на неделю
Сделал за вечер твою микроидею - дальше что? В чём интерес публиковать эту микроидею, что 100500 раз реализована во всех цветах и размерах в Google Play? Выбирай любую версию, играй сколько влезет... А, не влезет, потому что микроидея == микроинтерес к ней, развод лоха на просмотр рекламы перед геймплеем. Разумеется, если ты не сливаешь 1000 часов в одну гиперказуалку с одной примитивной механикой...
Понимаю, есть люди, которые 1000 часов сливают в банальный Flappy Bird и обожают повторять его по туториалам, типа "любимый флаппи бёрд, но вместо птички самолётик", но это вообще отдельная тема, и подобным играм в принципе не нужен движок на том уровне, на котором сейчас находится Godot. Им там достаточно выводить PNG в <canvas> тег HTML5.
Какой потанцевал у флаппи бёрд? PNG заменить?
У условного "клона GTA" большой потанцевал, это ж практически свой собственный Garry's Mod, только с нормальным транспортом и сразу большой картой. Направление развития любое можно выбрать и надстраивать новые механики одну за другой.
>>5447
>хочется экшен-слешер
Легко: мобы прут по прямой, герой тупо вращается с гигантским супер-пупер гипер-мечом, VFX вспышки перекрывают 99% экрана. За вечер сделаешь базу, а остальное можно доделать как-нибудь попозже.
>в открытом мире
Понятие растяжимо, но сегодня "открытый мир" == гигантские пустыни, пустыри, пустые поляны и т.д. Следовательно, опенворлд == растянутый филлер. Реализуешь стандартный коридорный экшн, дальше заменяешь загрузочные экраны тупыми пустырями, заставляешь игрока удерживать W всю дорогу. Даже суперпопулярная GTA 5 на этом построена, с этим её дебильным шоссе на 10 км вдоль скучной пустыни. "Слешеры" вообще с камерой сверху вниз, поэтому и подгрузка чанков мира будет проще технически.
>с прокачкой
Это тоже растяжимое понятие, прокачка может быть банальным +1 к урону и всё, никто не ждёт от тебя S.P.E.C.I.A.L. в ноунейм индюшке от соло автора. Переусложнённое дерево прокачки на самом деле проще реализовать в коде, чем понять в игре (тоже филлерный контент, тебе +1 к урону или к защите?).
>квестами
"Подай-принеси" квесты делаются легко. Остальные возможные квесты практически не встречаются, ибо игрокам не нравится ломать голову над задачами, а плестись за NPC - вообще своего рода наказание.
>скиллчеками в диалогах
Опять же несложно, если сделать фреймворк под это.
>понимание объёма уже пришло
В связи с вышеперечисленным не вижу сложности. Физических взаимодействий нет, крафта нет, даже стрельбы как таковой нет (Area3D на меч повесь). Графоманить тексты только научиться и в путь. В графическом плане - прибей камеру к потолку.
Ты просто ищешь оправдания для безделья.
>проплывёт релиз игры похожей на твою мечту
Лично моя проблема с этим в том, что мне хочется собственную игру. Ты предлагаешь удочерить уже взрослого человека вместо воспитания своего - это совершенно разные действия с разным результатом. Естественно, если тебе хочется просто поиграть, тебе разницы никакой не будет, но объективно она есть.
Для примера, Vintage Story начиналась как мод для Minecraft (TerraFirmaCraft), но разрабам надоели все подводные камни Minecraft - запилили свою игру. Возникает вопрос, что им мешало просто играть в ванильный Minecraft, не делая свои модификации? Некоторым людям, видимо, хочется чего-то своего, несмотря на провальность концепции (притащили бесполезный реализм ради реализма - зачем?).
>>5464
>Пройти игру на час
Никогда не понимал подобного. Я в игру играю, чтоб расслабиться и отвлечься от реальности, а не чтобы почитать мысли автора в интерактивном формате... Увлекающая игра не должна обрываться через час.
>ААА студией быть
Много видел hack-n-slash от ААА? Это ж инди жанр. Единственные представители от условного АА+ - это франшизы родом из древних времён. Как понимаю, нишевые жанры не получают финансирования без достаточно широко известного имени франшизы.
>>5441
И то верно, но хотелось большего...
>>5444
Технически ничего сложного, но для того, чтобы эта концепция была интересной, все эти домики должны существенно отличаться друг от друга внутри. Даже с процедурной генерацией это требует много контента, который сам по себе не доставляет удовольствия. Т.е. разработать этот контент я мог бы, но в чём его фан?
Сейчас вот думаю: может, стоило делать декорации, расставляя их как попало, авось вошёл бы во вкус и получилось бы что-то интересное. Когда на всю игру имеется 3.5 плейсхолдера, работать с ней интереса мало, прогресс совсем не ощущается. Да и навалить различного контента низкого качества несложно. Тут главное соблюдать один общий стиль/настроение. В реалистичных ААА унылое "серое" настроение.
>>5443
А как без этого? Должен быть высокий потанцевал.
Сделал за вечер твою микроидею - дальше что? В чём интерес публиковать эту микроидею, что 100500 раз реализована во всех цветах и размерах в Google Play? Выбирай любую версию, играй сколько влезет... А, не влезет, потому что микроидея == микроинтерес к ней, развод лоха на просмотр рекламы перед геймплеем. Разумеется, если ты не сливаешь 1000 часов в одну гиперказуалку с одной примитивной механикой...
Понимаю, есть люди, которые 1000 часов сливают в банальный Flappy Bird и обожают повторять его по туториалам, типа "любимый флаппи бёрд, но вместо птички самолётик", но это вообще отдельная тема, и подобным играм в принципе не нужен движок на том уровне, на котором сейчас находится Godot. Им там достаточно выводить PNG в <canvas> тег HTML5.
Какой потанцевал у флаппи бёрд? PNG заменить?
У условного "клона GTA" большой потанцевал, это ж практически свой собственный Garry's Mod, только с нормальным транспортом и сразу большой картой. Направление развития любое можно выбрать и надстраивать новые механики одну за другой.
>>5447
Легко: мобы прут по прямой, герой тупо вращается с гигантским супер-пупер гипер-мечом, VFX вспышки перекрывают 99% экрана. За вечер сделаешь базу, а остальное можно доделать как-нибудь попозже.
Понятие растяжимо, но сегодня "открытый мир" == гигантские пустыни, пустыри, пустые поляны и т.д. Следовательно, опенворлд == растянутый филлер. Реализуешь стандартный коридорный экшн, дальше заменяешь загрузочные экраны тупыми пустырями, заставляешь игрока удерживать W всю дорогу. Даже суперпопулярная GTA 5 на этом построена, с этим её дебильным шоссе на 10 км вдоль скучной пустыни. "Слешеры" вообще с камерой сверху вниз, поэтому и подгрузка чанков мира будет проще технически.
Это тоже растяжимое понятие, прокачка может быть банальным +1 к урону и всё, никто не ждёт от тебя S.P.E.C.I.A.L. в ноунейм индюшке от соло автора. Переусложнённое дерево прокачки на самом деле проще реализовать в коде, чем понять в игре (тоже филлерный контент, тебе +1 к урону или к защите?).
"Подай-принеси" квесты делаются легко. Остальные возможные квесты практически не встречаются, ибо игрокам не нравится ломать голову над задачами, а плестись за NPC - вообще своего рода наказание.
Опять же несложно, если сделать фреймворк под это.
В связи с вышеперечисленным не вижу сложности. Физических взаимодействий нет, крафта нет, даже стрельбы как таковой нет (Area3D на меч повесь). Графоманить тексты только научиться и в путь. В графическом плане - прибей камеру к потолку.
Ты просто ищешь оправдания для безделья.
Лично моя проблема с этим в том, что мне хочется собственную игру. Ты предлагаешь удочерить уже взрослого человека вместо воспитания своего - это совершенно разные действия с разным результатом. Естественно, если тебе хочется просто поиграть, тебе разницы никакой не будет, но объективно она есть.
Для примера, Vintage Story начиналась как мод для Minecraft (TerraFirmaCraft), но разрабам надоели все подводные камни Minecraft - запилили свою игру. Возникает вопрос, что им мешало просто играть в ванильный Minecraft, не делая свои модификации? Некоторым людям, видимо, хочется чего-то своего, несмотря на провальность концепции (притащили бесполезный реализм ради реализма - зачем?).
>>5464
Никогда не понимал подобного. Я в игру играю, чтоб расслабиться и отвлечься от реальности, а не чтобы почитать мысли автора в интерактивном формате... Увлекающая игра не должна обрываться через час.
Много видел hack-n-slash от ААА? Это ж инди жанр. Единственные представители от условного АА+ - это франшизы родом из древних времён. Как понимаю, нишевые жанры не получают финансирования без достаточно широко известного имени франшизы.
>у нас с тобой хоть недоделки есть
И то верно, но хотелось большего...
>>5444
>возможностью заходить в каждый дом
Технически ничего сложного, но для того, чтобы эта концепция была интересной, все эти домики должны существенно отличаться друг от друга внутри. Даже с процедурной генерацией это требует много контента, который сам по себе не доставляет удовольствия. Т.е. разработать этот контент я мог бы, но в чём его фан?
Сейчас вот думаю: может, стоило делать декорации, расставляя их как попало, авось вошёл бы во вкус и получилось бы что-то интересное. Когда на всю игру имеется 3.5 плейсхолдера, работать с ней интереса мало, прогресс совсем не ощущается. Да и навалить различного контента низкого качества несложно. Тут главное соблюдать один общий стиль/настроение. В реалистичных ААА унылое "серое" настроение.
>>5443
>У вас скоп большой
А как без этого? Должен быть высокий потанцевал.
>микроидею на неделю
Сделал за вечер твою микроидею - дальше что? В чём интерес публиковать эту микроидею, что 100500 раз реализована во всех цветах и размерах в Google Play? Выбирай любую версию, играй сколько влезет... А, не влезет, потому что микроидея == микроинтерес к ней, развод лоха на просмотр рекламы перед геймплеем. Разумеется, если ты не сливаешь 1000 часов в одну гиперказуалку с одной примитивной механикой...
Понимаю, есть люди, которые 1000 часов сливают в банальный Flappy Bird и обожают повторять его по туториалам, типа "любимый флаппи бёрд, но вместо птички самолётик", но это вообще отдельная тема, и подобным играм в принципе не нужен движок на том уровне, на котором сейчас находится Godot. Им там достаточно выводить PNG в <canvas> тег HTML5.
Какой потанцевал у флаппи бёрд? PNG заменить?
У условного "клона GTA" большой потанцевал, это ж практически свой собственный Garry's Mod, только с нормальным транспортом и сразу большой картой. Направление развития любое можно выбрать и надстраивать новые механики одну за другой.
>>5447
>хочется экшен-слешер
Легко: мобы прут по прямой, герой тупо вращается с гигантским супер-пупер гипер-мечом, VFX вспышки перекрывают 99% экрана. За вечер сделаешь базу, а остальное можно доделать как-нибудь попозже.
>в открытом мире
Понятие растяжимо, но сегодня "открытый мир" == гигантские пустыни, пустыри, пустые поляны и т.д. Следовательно, опенворлд == растянутый филлер. Реализуешь стандартный коридорный экшн, дальше заменяешь загрузочные экраны тупыми пустырями, заставляешь игрока удерживать W всю дорогу. Даже суперпопулярная GTA 5 на этом построена, с этим её дебильным шоссе на 10 км вдоль скучной пустыни. "Слешеры" вообще с камерой сверху вниз, поэтому и подгрузка чанков мира будет проще технически.
>с прокачкой
Это тоже растяжимое понятие, прокачка может быть банальным +1 к урону и всё, никто не ждёт от тебя S.P.E.C.I.A.L. в ноунейм индюшке от соло автора. Переусложнённое дерево прокачки на самом деле проще реализовать в коде, чем понять в игре (тоже филлерный контент, тебе +1 к урону или к защите?).
>квестами
"Подай-принеси" квесты делаются легко. Остальные возможные квесты практически не встречаются, ибо игрокам не нравится ломать голову над задачами, а плестись за NPC - вообще своего рода наказание.
>скиллчеками в диалогах
Опять же несложно, если сделать фреймворк под это.
>понимание объёма уже пришло
В связи с вышеперечисленным не вижу сложности. Физических взаимодействий нет, крафта нет, даже стрельбы как таковой нет (Area3D на меч повесь). Графоманить тексты только научиться и в путь. В графическом плане - прибей камеру к потолку.
Ты просто ищешь оправдания для безделья.
>проплывёт релиз игры похожей на твою мечту
Лично моя проблема с этим в том, что мне хочется собственную игру. Ты предлагаешь удочерить уже взрослого человека вместо воспитания своего - это совершенно разные действия с разным результатом. Естественно, если тебе хочется просто поиграть, тебе разницы никакой не будет, но объективно она есть.
Для примера, Vintage Story начиналась как мод для Minecraft (TerraFirmaCraft), но разрабам надоели все подводные камни Minecraft - запилили свою игру. Возникает вопрос, что им мешало просто играть в ванильный Minecraft, не делая свои модификации? Некоторым людям, видимо, хочется чего-то своего, несмотря на провальность концепции (притащили бесполезный реализм ради реализма - зачем?).
>>5464
>Пройти игру на час
Никогда не понимал подобного. Я в игру играю, чтоб расслабиться и отвлечься от реальности, а не чтобы почитать мысли автора в интерактивном формате... Увлекающая игра не должна обрываться через час.
>ААА студией быть
Много видел hack-n-slash от ААА? Это ж инди жанр. Единственные представители от условного АА+ - это франшизы родом из древних времён. Как понимаю, нишевые жанры не получают финансирования без достаточно широко известного имени франшизы.
715 Кб, 3840x2160>>5475
Так все вменяемые слешеры это ААА. Иначе и быть не может. Миллион уникальных анимаций для врагов индюк не потянет. А если все враги будут просто набигать на игрока, то это заебет уже через 5 минут.
>Много видел hack-n-slash от ААА? Это ж инди жанр.
Так все вменяемые слешеры это ААА. Иначе и быть не может. Миллион уникальных анимаций для врагов индюк не потянет. А если все враги будут просто набигать на игрока, то это заебет уже через 5 минут.
>>5475
Отличный гайд как всю жизнь что-то делать но так ничего и не сделать.
Отличный гайд как всю жизнь что-то делать но так ничего и не сделать.
>>5505
Нет.
Нет.
Господа, подскажите мне пожалуйста, твердо и четко, если я буду пилить игру на Godot 4.4 используя C#, я смогу сбилдить для андроида? И будут ли какие-то ограничения в связи с этим?
>>5540
Сбилдить сможешь.
Про ограничения сказать трудно.
Насколько я знаю, поддержка там лишь частичная (через Mono и bionic-linux). Так было в 4.2 и не попадалось чтобы это менялось в текущих или в ближайшем будущем
https://godotengine.org/article/platform-state-in-csharp-for-godot-4-2/#android
В этой статье было написано:
uses the linux-bionic Mono runtime, and only supports the arm64 and x64 architectures.
The linux-bionic runtime is a Linux runtime using the Android C library, so it’s basically Android but without the JNI. This means that the Android bindings are not available, so some APIs (such as SSL) will crash the game. Use the Godot APIs when possible to avoid these issues.
Using NativeAOT should also be supported in theory, but it requires using .NET 8.0 and some manual work.
Немного покопавшись, нашел такой PR
https://github.com/godotengine/godot/pull/88803
Соответственно 3 предыдущих пункта отменяются:
Android exports now use the android runtime identifier instead of linux-bionic, this removes the restrictions we previously had:
Adds support for all Android architectures (arm32, arm64, x32, and x64), previously only the 64-bit architectures were supported.
Loads System.Security.Cryptography.Native.Android (the .NET library that binds to the Android OS crypto functions).
For Android, I don't think there should be any more unsupported APIs (starting from Godot 4.4).
Состояние NativeAOT отслежвается тут https://github.com/dotnet/runtime/issues/106748
Честно говоря, я не до конца все это понял. Думаю что твой игровой C# код всегда работал и будет работать. C# либы скачанные через nuget - скорее всего будут. Какая то экзотика, типа c++ либ - скорее всего нет.
По дефолту будет работать какой то anroid экспорт, в котором ограничений меньше, а для неработавшей криптографии написали обертку. linux-bionic с ограничениями подрубится (только?) если ты включишь экспериментальный NativeAOT в настройках csproj. Дефолтный экспорт комиилит в IL, который потом на устройстве конвертируется JIT в программу. NativeAOT бы сразу компилировал в бинарник.
Один момент например, в linux-bionic нет JNI. Вроде бы это значит что нельзя вызывать никакое API JAVA Android. А всякая аналитика, инаппы, камера вроде через него делается?
Сам я не пользуюсь ни 4-кой, ни C#, и давно не делал отдельных андроид версий (делаю только вин и веб)
Сбилдить сможешь.
Про ограничения сказать трудно.
Насколько я знаю, поддержка там лишь частичная (через Mono и bionic-linux). Так было в 4.2 и не попадалось чтобы это менялось в текущих или в ближайшем будущем
https://godotengine.org/article/platform-state-in-csharp-for-godot-4-2/#android
В этой статье было написано:
uses the linux-bionic Mono runtime, and only supports the arm64 and x64 architectures.
The linux-bionic runtime is a Linux runtime using the Android C library, so it’s basically Android but without the JNI. This means that the Android bindings are not available, so some APIs (such as SSL) will crash the game. Use the Godot APIs when possible to avoid these issues.
Using NativeAOT should also be supported in theory, but it requires using .NET 8.0 and some manual work.
Немного покопавшись, нашел такой PR
https://github.com/godotengine/godot/pull/88803
Соответственно 3 предыдущих пункта отменяются:
Android exports now use the android runtime identifier instead of linux-bionic, this removes the restrictions we previously had:
Adds support for all Android architectures (arm32, arm64, x32, and x64), previously only the 64-bit architectures were supported.
Loads System.Security.Cryptography.Native.Android (the .NET library that binds to the Android OS crypto functions).
For Android, I don't think there should be any more unsupported APIs (starting from Godot 4.4).
Состояние NativeAOT отслежвается тут https://github.com/dotnet/runtime/issues/106748
Честно говоря, я не до конца все это понял. Думаю что твой игровой C# код всегда работал и будет работать. C# либы скачанные через nuget - скорее всего будут. Какая то экзотика, типа c++ либ - скорее всего нет.
По дефолту будет работать какой то anroid экспорт, в котором ограничений меньше, а для неработавшей криптографии написали обертку. linux-bionic с ограничениями подрубится (только?) если ты включишь экспериментальный NativeAOT в настройках csproj. Дефолтный экспорт комиилит в IL, который потом на устройстве конвертируется JIT в программу. NativeAOT бы сразу компилировал в бинарник.
Один момент например, в linux-bionic нет JNI. Вроде бы это значит что нельзя вызывать никакое API JAVA Android. А всякая аналитика, инаппы, камера вроде через него делается?
Сам я не пользуюсь ни 4-кой, ни C#, и давно не делал отдельных андроид версий (делаю только вин и веб)
>>5540
Сбилдить сможешь.
Про ограничения сказать трудно.
Насколько я знаю, поддержка там лишь частичная (через Mono и bionic-linux). Так было в 4.2 и не попадалось чтобы это менялось в текущих или в ближайшем будущем
https://godotengine.org/article/platform-state-in-csharp-for-godot-4-2/#android
В этой статье было написано:
uses the linux-bionic Mono runtime, and only supports the arm64 and x64 architectures.
The linux-bionic runtime is a Linux runtime using the Android C library, so it’s basically Android but without the JNI. This means that the Android bindings are not available, so some APIs (such as SSL) will crash the game. Use the Godot APIs when possible to avoid these issues.
Using NativeAOT should also be supported in theory, but it requires using .NET 8.0 and some manual work.
Немного покопавшись, нашел такой PR
https://github.com/godotengine/godot/pull/88803
Соответственно 3 предыдущих пункта отменяются:
Android exports now use the android runtime identifier instead of linux-bionic, this removes the restrictions we previously had:
Adds support for all Android architectures (arm32, arm64, x32, and x64), previously only the 64-bit architectures were supported.
Loads System.Security.Cryptography.Native.Android (the .NET library that binds to the Android OS crypto functions).
For Android, I don't think there should be any more unsupported APIs (starting from Godot 4.4).
Состояние NativeAOT отслежвается тут https://github.com/dotnet/runtime/issues/106748
Честно говоря, я не до конца все это понял. Думаю что твой игровой C# код всегда работал и будет работать. C# либы скачанные через nuget - скорее всего будут. Какая то экзотика, типа c++ либ - скорее всего нет.
По дефолту будет работать какой то anroid экспорт, в котором ограничений меньше, а для неработавшей криптографии написали обертку. linux-bionic с ограничениями подрубится (только?) если ты включишь экспериментальный NativeAOT в настройках csproj. Дефолтный экспорт комиилит в IL, который потом на устройстве конвертируется JIT в программу. NativeAOT бы сразу компилировал в бинарник.
Один момент например, в linux-bionic нет JNI. Вроде бы это значит что нельзя вызывать никакое API JAVA Android. А всякая аналитика, инаппы, камера вроде через него делается?
Сам я не пользуюсь ни 4-кой, ни C#, и давно не делал отдельных андроид версий (делаю только вин и веб)
Сбилдить сможешь.
Про ограничения сказать трудно.
Насколько я знаю, поддержка там лишь частичная (через Mono и bionic-linux). Так было в 4.2 и не попадалось чтобы это менялось в текущих или в ближайшем будущем
https://godotengine.org/article/platform-state-in-csharp-for-godot-4-2/#android
В этой статье было написано:
uses the linux-bionic Mono runtime, and only supports the arm64 and x64 architectures.
The linux-bionic runtime is a Linux runtime using the Android C library, so it’s basically Android but without the JNI. This means that the Android bindings are not available, so some APIs (such as SSL) will crash the game. Use the Godot APIs when possible to avoid these issues.
Using NativeAOT should also be supported in theory, but it requires using .NET 8.0 and some manual work.
Немного покопавшись, нашел такой PR
https://github.com/godotengine/godot/pull/88803
Соответственно 3 предыдущих пункта отменяются:
Android exports now use the android runtime identifier instead of linux-bionic, this removes the restrictions we previously had:
Adds support for all Android architectures (arm32, arm64, x32, and x64), previously only the 64-bit architectures were supported.
Loads System.Security.Cryptography.Native.Android (the .NET library that binds to the Android OS crypto functions).
For Android, I don't think there should be any more unsupported APIs (starting from Godot 4.4).
Состояние NativeAOT отслежвается тут https://github.com/dotnet/runtime/issues/106748
Честно говоря, я не до конца все это понял. Думаю что твой игровой C# код всегда работал и будет работать. C# либы скачанные через nuget - скорее всего будут. Какая то экзотика, типа c++ либ - скорее всего нет.
По дефолту будет работать какой то anroid экспорт, в котором ограничений меньше, а для неработавшей криптографии написали обертку. linux-bionic с ограничениями подрубится (только?) если ты включишь экспериментальный NativeAOT в настройках csproj. Дефолтный экспорт комиилит в IL, который потом на устройстве конвертируется JIT в программу. NativeAOT бы сразу компилировал в бинарник.
Один момент например, в linux-bionic нет JNI. Вроде бы это значит что нельзя вызывать никакое API JAVA Android. А всякая аналитика, инаппы, камера вроде через него делается?
Сам я не пользуюсь ни 4-кой, ни C#, и давно не делал отдельных андроид версий (делаю только вин и веб)
>>5554
Это только про факт что "теперь поддерживается не только 64 бит".
Везде, и в документации, и в issue указывают что C# в Android - экспериментальный.
Это только про факт что "теперь поддерживается не только 64 бит".
Везде, и в документации, и в issue указывают что C# в Android - экспериментальный.
>>5609
Бля, как же ты заебал уже.
Всё. Аноны! Давайте на зло ему не делать игры! Не поддадимся на его наглые провокации!
Бля, как же ты заебал уже.
Всё. Аноны! Давайте на зло ему не делать игры! Не поддадимся на его наглые провокации!
>>5642
Он пишет эти посты во время своих перерывов, делая игры. Пару тредов назад говорил. У тебя же нет игр, как у безыгорника. Покажи свои игры.
Он пишет эти посты во время своих перерывов, делая игры. Пару тредов назад говорил. У тебя же нет игр, как у безыгорника. Покажи свои игры.
>>5652
Движок-то для делания игор. Ну и приложений. Делай игру и/или приложение. Давай, раз-раз.
Движок-то для делания игор. Ну и приложений. Делай игру и/или приложение. Давай, раз-раз.
177 Кб, 480x270А вы хотели бы делать игры на Нахе?
Многие говорят, дескать, ГДСкрипт похож на Питон, но я тут с утра произвёл изучения и оказалось, что ГДСкрипт намного больше похож на Нахе, а тот в свою очередь похож на доведённый до ума Паскаль скрещенный со скопами скобачьками из си.
Посмотрите.
Многие говорят, дескать, ГДСкрипт похож на Питон, но я тут с утра произвёл изучения и оказалось, что ГДСкрипт намного больше похож на Нахе, а тот в свою очередь похож на доведённый до ума Паскаль скрещенный со скопами скобачьками из си.
Посмотрите.
>>5673
Главное чтобы глаза не царапало как раст. А вообще я у мамы уже вайбкодер, так что пофиг на чем.
Главное чтобы глаза не царапало как раст. А вообще я у мамы уже вайбкодер, так что пофиг на чем.
>>4424
Тухляк, но че бы не ответить. Бро, прогресс бар тебе в помощь, нихуя не понял че за велосипеды ты мутишь.
Тухляк, но че бы не ответить. Бро, прогресс бар тебе в помощь, нихуя не понял че за велосипеды ты мутишь.
>>5805
Пояснишь свой негатив? Я реально не пойму че за велосипед. Есть контрол нода такая, прогресс бар называется, ставишь в ней заливку по часовой и вуаля вот тебе кулдаунбар, хоть круг, хоть квадрат, хоть ромб делай, хочешь свою текстуру?, берешь текстурпрогресс бар. Я искренне не понимаю ебли анона с шейдером и клипом, только если он не еба эффект сделать хочет.
Пояснишь свой негатив? Я реально не пойму че за велосипед. Есть контрол нода такая, прогресс бар называется, ставишь в ней заливку по часовой и вуаля вот тебе кулдаунбар, хоть круг, хоть квадрат, хоть ромб делай, хочешь свою текстуру?, берешь текстурпрогресс бар. Я искренне не понимаю ебли анона с шейдером и клипом, только если он не еба эффект сделать хочет.
>>5812
Где ты увидел негатив? Это был полностью позитивный совет.
Преимущества клипа обсуждались ниже, ты видимо до них не дочитал.
Где ты увидел негатив? Это был полностью позитивный совет.
Преимущества клипа обсуждались ниже, ты видимо до них не дочитал.
>>5867
ну не, пиво в бабу превращает. а мне нужен высокий уровень теста чтобы стояк был и вдохновение делать игру про секси-девочек
ну не, пиво в бабу превращает. а мне нужен высокий уровень теста чтобы стояк был и вдохновение делать игру про секси-девочек
>>5900
В хуябу. Начитаются своих спид-инфов и трясутся.
В хуябу. Начитаются своих спид-инфов и трясутся.
>>5839
Кофе + шоколад.
Кофе + шоколад.
3.х версия годота разрабатывается активней чем весь редот. Смешно.
261 Кб, 421x850Аноны, эти углы шейдером делают или нет? Если да, то не знаете, где найти похожий?
>>5933
Серые уголки? Скорее обычный спрайт. Не вижу зачем тут шейдер.
А по шейдерам - godotshaders и нейросети.
Серые уголки? Скорее обычный спрайт. Не вижу зачем тут шейдер.
А по шейдерам - godotshaders и нейросети.
>>5933
В годоте это можно сделать Control-нодами с темами и стайлбоксами.
годотшейдерс дот ком
В годоте это можно сделать Control-нодами с темами и стайлбоксами.
> где найти похожий
> шейдер
годотшейдерс дот ком
376 Кб, 1894x713>>5933
Уголок можно нарисовать:
-Спрайтом с прозрачностью как сказали выше
-Полигоном (2д или 3д выровненным по камере)
-Line2D
-Кодом через draw_line
-Двумя прямоугольниками (напр. ColorRect)
-Пока не смог придумать способ с клиппингом уголка от квадрата
-Тайлмапом в котором зажгли только нужные квадратики
-Контролами с привязкой к якорям, или например NinePatchRect
-Шейдер, там тоже десяток способов
В общем как ты заметил любой способ позволяющий нарисовать полоску (линию или прямоугольник)
Но шейдер я бы не рекомендовал.
Он получится неоптимальный, там всюду или if ... discard или ALPHA=. Вообще шейдеры прицелов-перекрестий что я видел ужасны. Там чуть ли не SDF приплетают а это куча матана работающего на бедном устройстве пользователя.
Я бы закрутил вершины прямоугольника в угол... Но так просто не получится, ведь у квадрата их всего 4, а subdivide там вроде нет. Не приплетать же 3д для такого...
Ну ладно, приплел.
Уголок можно нарисовать:
-Спрайтом с прозрачностью как сказали выше
-Полигоном (2д или 3д выровненным по камере)
-Line2D
-Кодом через draw_line
-Двумя прямоугольниками (напр. ColorRect)
-Пока не смог придумать способ с клиппингом уголка от квадрата
-Тайлмапом в котором зажгли только нужные квадратики
-Контролами с привязкой к якорям, или например NinePatchRect
-Шейдер, там тоже десяток способов
В общем как ты заметил любой способ позволяющий нарисовать полоску (линию или прямоугольник)
Но шейдер я бы не рекомендовал.
Он получится неоптимальный, там всюду или if ... discard или ALPHA=. Вообще шейдеры прицелов-перекрестий что я видел ужасны. Там чуть ли не SDF приплетают а это куча матана работающего на бедном устройстве пользователя.
Я бы закрутил вершины прямоугольника в угол... Но так просто не получится, ведь у квадрата их всего 4, а subdivide там вроде нет. Не приплетать же 3д для такого...
Ну ладно, приплел.
>>4044 (OP)
Почему Godot так сильно нагружает GPU на Android?
Godot 4.4.1, рендерер "Mobile".
Сцена 2D: один спрайт, три кнопки, текст.
FPS зафиксирован на 20 кадров в секунду.
Анимации отсутствуют, картинка статичная.
Показатели: CPU ~5%, GPU ~80%, 20 FPS.
Для сравнения: Shattered Pixel Dungeon.
В главном меню много спрайтов и анимаций.
Показатели: CPU ~20%, GPU ~5%, 60 FPS.
Почему Godot (Vulkan Mobile) грузит GPU на 80%?
Почему снижение частоты не уменьшает нагрузку?
"Compatibility" использовать не могу из-за бага...
Почему Godot так сильно нагружает GPU на Android?
Godot 4.4.1, рендерер "Mobile".
Сцена 2D: один спрайт, три кнопки, текст.
FPS зафиксирован на 20 кадров в секунду.
Анимации отсутствуют, картинка статичная.
Показатели: CPU ~5%, GPU ~80%, 20 FPS.
Для сравнения: Shattered Pixel Dungeon.
В главном меню много спрайтов и анимаций.
Показатели: CPU ~20%, GPU ~5%, 60 FPS.
Почему Godot (Vulkan Mobile) грузит GPU на 80%?
Почему снижение частоты не уменьшает нагрузку?
"Compatibility" использовать не могу из-за бага...
>>5964
А в 4-ке профайлер можно подключить к устройству? Я не пробовал.
Если у тебя 2д, то что за баг в Compatibility? Проще с ним разобраться или попробовать 3-ку, не?
А в 4-ке профайлер можно подключить к устройству? Я не пробовал.
Если у тебя 2д, то что за баг в Compatibility? Проще с ним разобраться или попробовать 3-ку, не?
>>5964
Потому что мобильные чипсеты - темный лес. Например мы недавно выяснили что часть мобилок не умеют загружать текстуры выше чем 2048х2048. А некоторые, совсем говняные, лажают с 1024.
Потому что мобильные чипсеты - темный лес. Например мы недавно выяснили что часть мобилок не умеют загружать текстуры выше чем 2048х2048. А некоторые, совсем говняные, лажают с 1024.
>>5966
Это какой процент от общего кол-ва?
>часть мобилок не умеют загружать текстуры выше чем 2048х2048
Это какой процент от общего кол-ва?
>>5967
Хз, у меня в гугл-плее процентов 10 отзывов про это было. Полагаю люди с днищефонами видят что игра 2д, значит и на говне мамонта заработает, ставят а она не работает, а тебе потом единичка в отзыв прилетает.
Хз, у меня в гугл-плее процентов 10 отзывов про это было. Полагаю люди с днищефонами видят что игра 2д, значит и на говне мамонта заработает, ставят а она не работает, а тебе потом единичка в отзыв прилетает.
>>5965
Никогда не пользовался. У меня на телефоне одно приложение с названием "игры" поверх открытого приложения показывает нагрузку CPU/GPU с FPS, достаточно точно для оценки производительности.
https://github.com/godotengine/godot/issues/80057
TL;DR: Polygon2D на Skeleton2D не отображается.
Я Godot использую, чтобы иметь удобный и при том актуальный инструмент. Если отказываться от всех удобств, тогда лучше перейти на 2D фреймворк, где ничего кроме вывода спрайтов и текста нет.
>>5966
При чём тут чипсет, лол, если дело явно в движке?
Повторяю, Shattered Pixel Dungeon летает, несмотря на относительно сложную для 2D рогалика графику. Вулкановский Godot почему-то 80% GPU съедает на минимальную статичную картинку... Очень жаль.
Алсо заметил, что игры на Godot несколько секунд загружаются на Android ДО показа сплеш-скрина, и компиляция шейдеров тут совсем ни при чём, т.к. кэширование шейдеров не ускоряет это ожидание. "Нативные" приложения открываются сразу, или моментально демонстрируют свой сплеш-скрин. Подозреваю, что-то с инициализацией движка.
>профайлер
Никогда не пользовался. У меня на телефоне одно приложение с названием "игры" поверх открытого приложения показывает нагрузку CPU/GPU с FPS, достаточно точно для оценки производительности.
>что за баг в Compatibility
https://github.com/godotengine/godot/issues/80057
TL;DR: Polygon2D на Skeleton2D не отображается.
>попробовать 3-ку, не?
Я Godot использую, чтобы иметь удобный и при том актуальный инструмент. Если отказываться от всех удобств, тогда лучше перейти на 2D фреймворк, где ничего кроме вывода спрайтов и текста нет.
>>5966
>мобильные чипсеты
При чём тут чипсет, лол, если дело явно в движке?
Повторяю, Shattered Pixel Dungeon летает, несмотря на относительно сложную для 2D рогалика графику. Вулкановский Godot почему-то 80% GPU съедает на минимальную статичную картинку... Очень жаль.
Алсо заметил, что игры на Godot несколько секунд загружаются на Android ДО показа сплеш-скрина, и компиляция шейдеров тут совсем ни при чём, т.к. кэширование шейдеров не ускоряет это ожидание. "Нативные" приложения открываются сразу, или моментально демонстрируют свой сплеш-скрин. Подозреваю, что-то с инициализацией движка.
>>5971
Это ты спрашивал недавно про C#?
>Алсо заметил, что игры на Godot несколько секунд загружаются на Android ДО показа сплеш-скрина
Это ты спрашивал недавно про C#?
>>5673
В каком месте? Haxe больше похож на Java:
В (Object) Pascal такого маразма нет.
Просто и понятно, и без уродливых скобок.
Классы тоже оформляются красиво и понятно:
Так что не надо тут. Haxe не похож на Pascal.
Паскаль-подобные, например: Ada, seed7, Lua.
К сожалению, актуальных движков нет...
>доведённый до ума Паскаль
В каком месте? Haxe больше похож на Java:
>class HelloWorld {
>_ static public function main() {
>_ _ trace("Hello World");
>_ }
>}
В (Object) Pascal такого маразма нет.
>program HelloWorld;
>begin
>_ WriteLn('Hello World');
>end.
Просто и понятно, и без уродливых скобок.
Классы тоже оформляются красиво и понятно:
>type
>_ TWorld = class // описываем класс
>_ _ procedure Hello;
>_ end;
>implementation
>_ procedure TWorld.Hello; // реализуем класс
>_ begin
>_ _ WriteLn('Hello World');
>_ end;
>var World: TWorld; // используем экземпляр класса
>begin
>_ World := TWorld.Create;
>_ World.Hello;
>end.
Так что не надо тут. Haxe не похож на Pascal.
Паскаль-подобные, например: Ada, seed7, Lua.
К сожалению, актуальных движков нет...
>>5673
В каком месте? Haxe больше похож на Java:
В (Object) Pascal такого маразма нет.
Просто и понятно, и без уродливых скобок.
Классы тоже оформляются красиво и понятно:
Так что не надо тут. Haxe не похож на Pascal.
Паскаль-подобные, например: Ada, seed7, Lua.
К сожалению, актуальных движков нет...
>доведённый до ума Паскаль
В каком месте? Haxe больше похож на Java:
>class HelloWorld {
>_ static public function main() {
>_ _ trace("Hello World");
>_ }
>}
В (Object) Pascal такого маразма нет.
>program HelloWorld;
>begin
>_ WriteLn('Hello World');
>end.
Просто и понятно, и без уродливых скобок.
Классы тоже оформляются красиво и понятно:
>type
>_ TWorld = class // описываем класс
>_ _ procedure Hello;
>_ end;
>implementation
>_ procedure TWorld.Hello; // реализуем класс
>_ begin
>_ _ WriteLn('Hello World');
>_ end;
>var World: TWorld; // используем экземпляр класса
>begin
>_ World := TWorld.Create;
>_ World.Hello;
>end.
Так что не надо тут. Haxe не похож на Pascal.
Паскаль-подобные, например: Ada, seed7, Lua.
К сожалению, актуальных движков нет...
>>5976
Вкатился в 3.2, перешёл на 4.0+ и больше не вернусь.
Если тройка такая хорошая - пусть портируют все её достоинства в четвёрку, в чём их проблема? GLES2 забросили - ладно, но ведь GLES3 и там, и там есть. Конкретно зачем откатываться и отказываться от нововведений, упрощающих разработку? Пускай разработчики портируют всё с тройки на четвёрку, конкретно в compatibility режим. Не могут? Почему? Может, в тройке просто-напросто нет ничего такого супер-крутого, что улучшило бы работу четвёрки?
Хватит советовать тройку, это легаси код, который поддерживают из-за 1.5 африканских школьников с древним пентиумом и Windows 2000 или что там у совсем уж нищих людей. У меня древний комп и то нормально тянет Godot 4.x. Другое дело что разрабы накосячили где-то и поэтому рендеринг стал дороже; должны рано или поздно пофиксить как-то. Vulkan (в теории) должен быть производительнее OpenGL, как ассемблерный код производительнее скриптов...
>3-ку пробовать
Вкатился в 3.2, перешёл на 4.0+ и больше не вернусь.
Если тройка такая хорошая - пусть портируют все её достоинства в четвёрку, в чём их проблема? GLES2 забросили - ладно, но ведь GLES3 и там, и там есть. Конкретно зачем откатываться и отказываться от нововведений, упрощающих разработку? Пускай разработчики портируют всё с тройки на четвёрку, конкретно в compatibility режим. Не могут? Почему? Может, в тройке просто-напросто нет ничего такого супер-крутого, что улучшило бы работу четвёрки?
Хватит советовать тройку, это легаси код, который поддерживают из-за 1.5 африканских школьников с древним пентиумом и Windows 2000 или что там у совсем уж нищих людей. У меня древний комп и то нормально тянет Godot 4.x. Другое дело что разрабы накосячили где-то и поэтому рендеринг стал дороже; должны рано или поздно пофиксить как-то. Vulkan (в теории) должен быть производительнее OpenGL, как ассемблерный код производительнее скриптов...
>>5977
Конкретно что ты предлагаешь профайлить?
Вывод одного спрайта на экран, без анимаций?
Отображение кнопок с надписями без иконок?
Рендеринг 20 статичных кадров в секунду?
Там нечего профайлить, это хэллоу ворлд.
Алсо, тот раз депрессия совсем придавила.
Конкретно что ты предлагаешь профайлить?
Вывод одного спрайта на экран, без анимаций?
Отображение кнопок с надписями без иконок?
Рендеринг 20 статичных кадров в секунду?
Там нечего профайлить, это хэллоу ворлд.
Алсо, тот раз депрессия совсем придавила.
>>5985
Для начала надо проверить что факт действительно имеет место.
И убедиться что нет ошибок.
А то очень часто читаешь - о, что то само тормозит. А потом - ой, это я добавлял что то тяжелое для теста (шейдер, постпроцессинг) и забыл отключить.
Во вторых проверить что измеритель не ошибается. Мало ли как он там мерит загруженность, не факт что она такая.
Можно провести такой эксперимент - запустить твою сцену и замерить за сколько часов разрядится телефон со 100% до 0%. Потом то же самое с пиксель данжном. Если существенной разницы не будет, то это или ошибка измерения, или окажется что это вообще не влияет на разряд.
Потом можно уже и закапываться в отладку.
Для начала надо проверить что факт действительно имеет место.
И убедиться что нет ошибок.
А то очень часто читаешь - о, что то само тормозит. А потом - ой, это я добавлял что то тяжелое для теста (шейдер, постпроцессинг) и забыл отключить.
Во вторых проверить что измеритель не ошибается. Мало ли как он там мерит загруженность, не факт что она такая.
Можно провести такой эксперимент - запустить твою сцену и замерить за сколько часов разрядится телефон со 100% до 0%. Потом то же самое с пиксель данжном. Если существенной разницы не будет, то это или ошибка измерения, или окажется что это вообще не влияет на разряд.
Потом можно уже и закапываться в отладку.
>>5984
С чего бы? Советую, и буду советовать тройку практически всем - для веба, для мобилок. Прекрасный стабильный движок. Пробовал опять в этом году 4-ку на джеме, и что? Были проблемы у многих запустивших. Это версия для ААА-проекта мечты будущего. Буквально пару эффектов нельзя сделать в 3-ке, да и то есть обходные пути. Это наоборот надо портировать удачные фичи из 4-ки обратно в 3-ку более активно. Вулкан в принципе оказался неудачным экспериментом, у многих производительность на нем не выросла, а просела. Может сами автора вулкана верили что он будет быстрее или вводили в заблуждение. А старый глес конечно нельзя просто взять и перенести, ведь теперь архитектура движка строится вокруг апи вулкана.
С чего бы? Советую, и буду советовать тройку практически всем - для веба, для мобилок. Прекрасный стабильный движок. Пробовал опять в этом году 4-ку на джеме, и что? Были проблемы у многих запустивших. Это версия для ААА-проекта мечты будущего. Буквально пару эффектов нельзя сделать в 3-ке, да и то есть обходные пути. Это наоборот надо портировать удачные фичи из 4-ки обратно в 3-ку более активно. Вулкан в принципе оказался неудачным экспериментом, у многих производительность на нем не выросла, а просела. Может сами автора вулкана верили что он будет быстрее или вводили в заблуждение. А старый глес конечно нельзя просто взять и перенести, ведь теперь архитектура движка строится вокруг апи вулкана.
101 Кб, 900x600Как я заебался с вашими этими вулканами и опенжлами. Жил себе не тужил, пилил свое говно в режиме компатибилити, а тут однажды проснулся ночью и подумал: а ведь есть же вулкан. А в нем есть сглаживание. А со сглаживанием у меня картинки не дрожат. А Я ЗАЕБАЛСЯ С ЭТИМ ДРОЖАНИЕМ! Решаю проблему снапанием координат по вектор.1, но там свои особенности вылезают, связанные с моим способом управления. Короче, вулкан и сглаживание. Все збс, если, конечно, не считать того, что сглаживание сглаживает (кто бы мог подумать) и КРИСПНЕСС теряется. Все збс, НО, загружаю я тут несколько десятков тысяч картинок и у меня все зависает нахуй с ошибкой ERROR: Condition "err != VK_SUCCESS" is true. Returning: FAILED. Воспроизвел хуйню в годо 4.2 и выяснилось, что это аут оф видеомемори. Ну ебаный же ты нахуй. Вернулся в компатибилити, там этой хуйни нету. Но оно процессор сильнее грузит. Короче, пиздец, сложно.
Другая хуйня, которая есть и в компатибилити — у этого вашего годо есть какой-то лимит объектов что ли. Что-то в районе 260-270 тысяч ноде2д. А потом оно просто вылетает нахуй. Грустно это. Но. Существование такого уровня масштабности и качества опен сорс софта — само по себе уже чудо, и я должен быть благодарен господу нашему Иисусу уже за это.
Другая хуйня, которая есть и в компатибилити — у этого вашего годо есть какой-то лимит объектов что ли. Что-то в районе 260-270 тысяч ноде2д. А потом оно просто вылетает нахуй. Грустно это. Но. Существование такого уровня масштабности и качества опен сорс софта — само по себе уже чудо, и я должен быть благодарен господу нашему Иисусу уже за это.
>>6018
Какие там у тебя картинки дрожат, шиз?
Какие там у тебя картинки дрожат, шиз?
>>6018
Все что больше 10 тысяч объектов - никто конечно не делает на нодах. Там уже мультимеши, визуалсерверы, самописные ecs. Это уже advanced уровень, пора расти с туториалов.
>у этого вашего годо есть какой-то лимит объектов что ли. Что-то в районе 260-270 тысяч ноде2д.
Все что больше 10 тысяч объектов - никто конечно не делает на нодах. Там уже мультимеши, визуалсерверы, самописные ecs. Это уже advanced уровень, пора расти с туториалов.
А что будет если у меня нет пола, и объект падает бесконечно? Переполнение координат, баги, лаги-фризы?
>>6022
Наверное, не знаю. Просто в какой то момент зацикли мир (телепортируй персонажа в такую же комнату на 20 километров вверх)
https://docs.godotengine.org/en/stable/tutorials/physics/large_world_coordinates.html
Наверное, не знаю. Просто в какой то момент зацикли мир (телепортируй персонажа в такую же комнату на 20 километров вверх)
https://docs.godotengine.org/en/stable/tutorials/physics/large_world_coordinates.html
>>6022
Чем дальше от центра оси координат, тем реже становится float.
Чем дальше от центра оси координат, тем реже становится float.
>>6025
Не, у меня просто мусор падает вниз и мне лень удалять его или ставить там внизу коллизию.
Не, у меня просто мусор падает вниз и мне лень удалять его или ставить там внизу коллизию.
>>6028
Да блин. Это же элементарно. Просто добавь самому объекту проверку, if global.position.y < -100.0 queue_free()
Или просто 1 Area3D на весь уровень (можно и програмно его создать) и удалять все тела влетевшие по on_body_entered.
Да блин. Это же элементарно. Просто добавь самому объекту проверку, if global.position.y < -100.0 queue_free()
Или просто 1 Area3D на весь уровень (можно и програмно его создать) и удалять все тела влетевшие по on_body_entered.
>>6032
Вот бы я проорал, если это тот же анон который выше экономит на спичках, чуть ли не считает такты ассемблера, а потом тратит ресурсы на пустое обсчитывание буквально мусора физическим движком.
Вот бы я проорал, если это тот же анон который выше экономит на спичках, чуть ли не считает такты ассемблера, а потом тратит ресурсы на пустое обсчитывание буквально мусора физическим движком.
Блин, хотел использовать CompositorEffect, а оказалось это такая низкоуровневая вещь уровня компьют шейдеров
https://github.com/pink-arcana/godot-distance-field-outlines/discussions/1
Базовый бойлерплейт на 420 строчек my ass
https://github.com/pink-arcana/godot-distance-field-outlines/blob/main/project/addons/pa_compositor_effect/base_compositor_effect.gd
Придется и дальше на вьюпортах сидеть, тут разбираться год, и еще и шейдеры на glsl
https://docs.godotengine.org/en/stable/tutorials/rendering/compositor.html
https://github.com/pink-arcana/godot-distance-field-outlines/discussions/1
Базовый бойлерплейт на 420 строчек my ass
https://github.com/pink-arcana/godot-distance-field-outlines/blob/main/project/addons/pa_compositor_effect/base_compositor_effect.gd
Придется и дальше на вьюпортах сидеть, тут разбираться год, и еще и шейдеры на glsl
https://docs.godotengine.org/en/stable/tutorials/rendering/compositor.html
64 Кб, 1265x206Блин. Получается для продвинутых спецэффектов все равно придется копировать текстуры.
1 Кб, 200x200>>5961
Подтверждаю. Ты приплёл. Достаточно от ифов избавиться и уже полегче будет. Четыре уголка - это сумма из трёх прямоугольников, которые можно без ифов сложить и высчитать величину АЛЬФА в каждой точке.
> Но шейдер я бы не рекомендовал.
> Он получится неоптимальный, там всюду или if ... discard или ALPHA=
> Ну ладно, приплел.
Подтверждаю. Ты приплёл. Достаточно от ифов избавиться и уже полегче будет. Четыре уголка - это сумма из трёх прямоугольников, которые можно без ифов сложить и высчитать величину АЛЬФА в каждой точке.
>>6052
У тебя на пиксель в сторону уехало, инфа 100%, я такой же аутист.
У тебя на пиксель в сторону уехало, инфа 100%, я такой же аутист.
2 Кб, 250x200>>6050
Так я это тоже упомянул как неоптимальное - в процитированном: там всюду ALPHA=..
Пиксельный (фрагментный) шейдер затратнее, чем вершинный (вертексный).
Потому что он считается для каждого пикселя. И для них будет несколько рассчетов (ты пишешь про сравнение с тремя квадратами ("чуть ли не SDF приплетают" - такой подход, высчитывать для каждого пикселя, попадает ли он в фигуру, оправдан для очень сложных эффектов, типа фракталов или очень аккуратно сглаженного шрифта)
из которых 99% будут для того чтобы НЕ нарисовать. Если рамка на экране занимает, скажем, 1700 х 900, то это рассчеты для полутора миллионов пикселей каждый кадр (20, 30, 60 раз в секунду) просто греет воздух.
И сравни выполняемую работу в более простом варианте (там совсем немного лишнего, и чуть чуть больше работы для вершин - которые отмечены синим), и в варианте где рисуются только прямоугольники/линии.
А потом удивляются - почему же GPU занят на 80%
Так я это тоже упомянул как неоптимальное - в процитированном: там всюду ALPHA=..
Пиксельный (фрагментный) шейдер затратнее, чем вершинный (вертексный).
Потому что он считается для каждого пикселя. И для них будет несколько рассчетов (ты пишешь про сравнение с тремя квадратами ("чуть ли не SDF приплетают" - такой подход, высчитывать для каждого пикселя, попадает ли он в фигуру, оправдан для очень сложных эффектов, типа фракталов или очень аккуратно сглаженного шрифта)
из которых 99% будут для того чтобы НЕ нарисовать. Если рамка на экране занимает, скажем, 1700 х 900, то это рассчеты для полутора миллионов пикселей каждый кадр (20, 30, 60 раз в секунду) просто греет воздух.
И сравни выполняемую работу в более простом варианте (там совсем немного лишнего, и чуть чуть больше работы для вершин - которые отмечены синим), и в варианте где рисуются только прямоугольники/линии.
А потом удивляются - почему же GPU занят на 80%
67 Кб, 800x740Смотрите, использую такую конструкцию для сохранения/загрузки ини-файла с настройками. Все работает, но мне не нравится, что я могу переименовать какую-нибудь переменную, но не внести ее новое название в VARS_TO_SAVE_LOAD. Как бы сделать, чтобы этот массив автоматически наполнялся, а я бы только как-то помечал для этого переменные при их объявлении?
>>6075
Аннотаций в гдскрипт пока не завезли
Есть @export_custom, но не знаю какие там возможности и можно ли узнать пометки из скрипта
Можно банально называть переменные m_krokodil и потом скриптом узнавать все переменные и добавлять m_* в этот массив.
Можно сделать внешнюю утилиту, которая работает как препроцессор с файлом исходника. Ну например превращает какие то комментарии специальные в то что тебе надо. Можно даже тулскриптом на том же гдскрипте и сделать.
Аннотаций в гдскрипт пока не завезли
Есть @export_custom, но не знаю какие там возможности и можно ли узнать пометки из скрипта
Можно банально называть переменные m_krokodil и потом скриптом узнавать все переменные и добавлять m_* в этот массив.
Можно сделать внешнюю утилиту, которая работает как препроцессор с файлом исходника. Ну например превращает какие то комментарии специальные в то что тебе надо. Можно даже тулскриптом на том же гдскрипте и сделать.
>>6075
Сохранял бы сценами - такой проблемы не имел бы. А чем больше/сложнее твои сейвы, тем больше тебе потеть придется. Удачи. Не забудь конверсию версий сейвов написать, кстати.
Сохранял бы сценами - такой проблемы не имел бы. А чем больше/сложнее твои сейвы, тем больше тебе потеть придется. Удачи. Не забудь конверсию версий сейвов написать, кстати.
>>6077
Это неотъемлимая часть любой игры крупнее средней.
Не надо относиться к этому как к чему то страшному. Это просто версионирование.
>Не забудь конверсию версий сейвов написать,
Это неотъемлимая часть любой игры крупнее средней.
Не надо относиться к этому как к чему то страшному. Это просто версионирование.
>>6079
С синглтоном под капотом.
С синглтоном под капотом.
>>6080
Надо. Иначе силы уйдут не на то, что необходимо. Был тут один шизик, который пиксели в паддингах кнопок подсчитывал, вместо работы над геймплеем и визуалом.
Версионирование даже во взрослых продуктах часто делает только то, что проверяет версию и говорит что не может загрузить сейвы другой версии, вместо молчаливого падения.
>Не надо относиться к этому как к чему то страшному.
Надо. Иначе силы уйдут не на то, что необходимо. Был тут один шизик, который пиксели в паддингах кнопок подсчитывал, вместо работы над геймплеем и визуалом.
Версионирование даже во взрослых продуктах часто делает только то, что проверяет версию и говорит что не может загрузить сейвы другой версии, вместо молчаливого падения.
>>6080
Почему к страшному? Я отношусь к этому как к унылому, как к верному способу выгореть от своего проекта. Унылую хуиту я и на работе написать могу, причем за деньги.
>как к чему то страшному.
Почему к страшному? Я отношусь к этому как к унылому, как к верному способу выгореть от своего проекта. Унылую хуиту я и на работе написать могу, причем за деньги.
>>6084
Так это не уныло, а просто стандартно.
Так это не уныло, а просто стандартно.
>>6082
Смотря где. В ММО в которую я играю уже лет 15, у меня все персонажи сохраняются, даже те которыми я лет 10 не заходил. Способности несколько раз переделывались, поэтому они сбрасываются во фри респек, но уровни и количество очков прокачки всегда сохраняется. Предметов там у персонажа 100-200 и еще банк и сумки ингридиентов. И все это тоже сохраняется, буквально единицы косячных предметов за все годы видел. Обычно предмет или автоапгрейдится на новую версию, или даже работает как легаси мехакника пока его не выкинешь. (Что бывает забавно если какую то механику давно понерфили). Состояние квестов и цепочек квестов тоже запоминается. Правда, там не очень много где можно вынести квестовый предмет, обычно они внутри квеста остаются, поэтому не так много за чем следить надо. Но любой квест/цепочку есть опция рестартануть, не знаю почему в сингл играх такого не делают и вынуждают играть с начала. С другой стоторны какой нибудь факторио или майнркрафт редстоун может сломаться, потому что механики поменялись.
Смотря где. В ММО в которую я играю уже лет 15, у меня все персонажи сохраняются, даже те которыми я лет 10 не заходил. Способности несколько раз переделывались, поэтому они сбрасываются во фри респек, но уровни и количество очков прокачки всегда сохраняется. Предметов там у персонажа 100-200 и еще банк и сумки ингридиентов. И все это тоже сохраняется, буквально единицы косячных предметов за все годы видел. Обычно предмет или автоапгрейдится на новую версию, или даже работает как легаси мехакника пока его не выкинешь. (Что бывает забавно если какую то механику давно понерфили). Состояние квестов и цепочек квестов тоже запоминается. Правда, там не очень много где можно вынести квестовый предмет, обычно они внутри квеста остаются, поэтому не так много за чем следить надо. Но любой квест/цепочку есть опция рестартануть, не знаю почему в сингл играх такого не делают и вынуждают играть с начала. С другой стоторны какой нибудь факторио или майнркрафт редстоун может сломаться, потому что механики поменялись.
>>6102
Потому что все топовые спецы в онлайн-дрочильнях, очевидно же.
> не знаю почему в сингл играх такого не делают
Потому что все топовые спецы в онлайн-дрочильнях, очевидно же.
>>6018
Ты их вручную, что ли, снапаешь? Лол. Посмотри в настройках проекта, там есть опции для снапинга текстурных координат, т.е. текстура будет чётко натягиваться, а ты можешь как угодно спрайты свои перемещать, координаты твои движок не изменяет.
Темпоральное сглаживание предназначено для 3D. Множество игроков его ненавидит, кстати говоря... Пиксельным 2D играм концептуально не подходит.
Откуда и зачем? Это чрезвычайно много. Следует оптимизировать через атласы: множество тайлов (спрайтов, деталей) размещается на одну текстуру. Естественно, учитывай ограничения на её размер.
Странно, у тебя ОС не объединяет VRAM с RAM? Для экономии, можно выключить мип-мапы. Есть ещё несколько вариантов импорта текстур - с разной степенью сжатия, это вроде тоже как-то влияет.
Слишком большое количество. Способы решения:
- объединять спрайты-детальки в один спрайт ещё до импортирования в движок, если можешь позволить;
- рендерить статичные декорации из множества независимых объектов в SubViewport текстуру, чтобы отображать только один объект вместо тысяч сразу (полезно в ситуации, когда TileMapLayer не подходит);
- реализовать чанковую систему в случае большого открытого мира, подгружая чанки вокруг экрана и освобождая чанки, вышедшие далеко за пределы;
- если игра предлагает зум камеры, обязательно реализовать систему Level of Detail (LOD) как в 3D, подгружая объекты с нужным уровнем деталей;
- обращаться к рендер-серверу движка вручную, не перегружая дерево сцены лишними нодами деталей;
- оптимизировать перегруженные элементы игры - например, объединять одинаковые объекты, близко расположенные друг к другу, в одну общую стопку, отображать только верхний объект в стопке и т.д.
Даже если у тебя в режиме compatibility 250000+ нод нормально работают, у тебя, видимо, мощный ПК, и на более слабом такая игра будет дико тормозить.
Ориентируйся на 20000~30000 нод в сцене.
>ЗАЕБАЛСЯ С ЭТИМ ДРОЖАНИЕМ
>снапанием координат
Ты их вручную, что ли, снапаешь? Лол. Посмотри в настройках проекта, там есть опции для снапинга текстурных координат, т.е. текстура будет чётко натягиваться, а ты можешь как угодно спрайты свои перемещать, координаты твои движок не изменяет.
>сглаживание сглаживает и КРИСПНЕСС теряется
Темпоральное сглаживание предназначено для 3D. Множество игроков его ненавидит, кстати говоря... Пиксельным 2D играм концептуально не подходит.
>несколько десятков тысяч картинок
Откуда и зачем? Это чрезвычайно много. Следует оптимизировать через атласы: множество тайлов (спрайтов, деталей) размещается на одну текстуру. Естественно, учитывай ограничения на её размер.
>и у меня все зависает
>это аут оф видеомемори
Странно, у тебя ОС не объединяет VRAM с RAM? Для экономии, можно выключить мип-мапы. Есть ещё несколько вариантов импорта текстур - с разной степенью сжатия, это вроде тоже как-то влияет.
>в районе 260-270 тысяч ноде2д
Слишком большое количество. Способы решения:
- объединять спрайты-детальки в один спрайт ещё до импортирования в движок, если можешь позволить;
- рендерить статичные декорации из множества независимых объектов в SubViewport текстуру, чтобы отображать только один объект вместо тысяч сразу (полезно в ситуации, когда TileMapLayer не подходит);
- реализовать чанковую систему в случае большого открытого мира, подгружая чанки вокруг экрана и освобождая чанки, вышедшие далеко за пределы;
- если игра предлагает зум камеры, обязательно реализовать систему Level of Detail (LOD) как в 3D, подгружая объекты с нужным уровнем деталей;
- обращаться к рендер-серверу движка вручную, не перегружая дерево сцены лишними нодами деталей;
- оптимизировать перегруженные элементы игры - например, объединять одинаковые объекты, близко расположенные друг к другу, в одну общую стопку, отображать только верхний объект в стопке и т.д.
Даже если у тебя в режиме compatibility 250000+ нод нормально работают, у тебя, видимо, мощный ПК, и на более слабом такая игра будет дико тормозить.
Ориентируйся на 20000~30000 нод в сцене.
>>6018
Ты их вручную, что ли, снапаешь? Лол. Посмотри в настройках проекта, там есть опции для снапинга текстурных координат, т.е. текстура будет чётко натягиваться, а ты можешь как угодно спрайты свои перемещать, координаты твои движок не изменяет.
Темпоральное сглаживание предназначено для 3D. Множество игроков его ненавидит, кстати говоря... Пиксельным 2D играм концептуально не подходит.
Откуда и зачем? Это чрезвычайно много. Следует оптимизировать через атласы: множество тайлов (спрайтов, деталей) размещается на одну текстуру. Естественно, учитывай ограничения на её размер.
Странно, у тебя ОС не объединяет VRAM с RAM? Для экономии, можно выключить мип-мапы. Есть ещё несколько вариантов импорта текстур - с разной степенью сжатия, это вроде тоже как-то влияет.
Слишком большое количество. Способы решения:
- объединять спрайты-детальки в один спрайт ещё до импортирования в движок, если можешь позволить;
- рендерить статичные декорации из множества независимых объектов в SubViewport текстуру, чтобы отображать только один объект вместо тысяч сразу (полезно в ситуации, когда TileMapLayer не подходит);
- реализовать чанковую систему в случае большого открытого мира, подгружая чанки вокруг экрана и освобождая чанки, вышедшие далеко за пределы;
- если игра предлагает зум камеры, обязательно реализовать систему Level of Detail (LOD) как в 3D, подгружая объекты с нужным уровнем деталей;
- обращаться к рендер-серверу движка вручную, не перегружая дерево сцены лишними нодами деталей;
- оптимизировать перегруженные элементы игры - например, объединять одинаковые объекты, близко расположенные друг к другу, в одну общую стопку, отображать только верхний объект в стопке и т.д.
Даже если у тебя в режиме compatibility 250000+ нод нормально работают, у тебя, видимо, мощный ПК, и на более слабом такая игра будет дико тормозить.
Ориентируйся на 20000~30000 нод в сцене.
>ЗАЕБАЛСЯ С ЭТИМ ДРОЖАНИЕМ
>снапанием координат
Ты их вручную, что ли, снапаешь? Лол. Посмотри в настройках проекта, там есть опции для снапинга текстурных координат, т.е. текстура будет чётко натягиваться, а ты можешь как угодно спрайты свои перемещать, координаты твои движок не изменяет.
>сглаживание сглаживает и КРИСПНЕСС теряется
Темпоральное сглаживание предназначено для 3D. Множество игроков его ненавидит, кстати говоря... Пиксельным 2D играм концептуально не подходит.
>несколько десятков тысяч картинок
Откуда и зачем? Это чрезвычайно много. Следует оптимизировать через атласы: множество тайлов (спрайтов, деталей) размещается на одну текстуру. Естественно, учитывай ограничения на её размер.
>и у меня все зависает
>это аут оф видеомемори
Странно, у тебя ОС не объединяет VRAM с RAM? Для экономии, можно выключить мип-мапы. Есть ещё несколько вариантов импорта текстур - с разной степенью сжатия, это вроде тоже как-то влияет.
>в районе 260-270 тысяч ноде2д
Слишком большое количество. Способы решения:
- объединять спрайты-детальки в один спрайт ещё до импортирования в движок, если можешь позволить;
- рендерить статичные декорации из множества независимых объектов в SubViewport текстуру, чтобы отображать только один объект вместо тысяч сразу (полезно в ситуации, когда TileMapLayer не подходит);
- реализовать чанковую систему в случае большого открытого мира, подгружая чанки вокруг экрана и освобождая чанки, вышедшие далеко за пределы;
- если игра предлагает зум камеры, обязательно реализовать систему Level of Detail (LOD) как в 3D, подгружая объекты с нужным уровнем деталей;
- обращаться к рендер-серверу движка вручную, не перегружая дерево сцены лишними нодами деталей;
- оптимизировать перегруженные элементы игры - например, объединять одинаковые объекты, близко расположенные друг к другу, в одну общую стопку, отображать только верхний объект в стопке и т.д.
Даже если у тебя в режиме compatibility 250000+ нод нормально работают, у тебя, видимо, мощный ПК, и на более слабом такая игра будет дико тормозить.
Ориентируйся на 20000~30000 нод в сцене.
>>6075
Просто сделай через Dictionary, например:
Сохранение:
Загрузка:
Итого, у тебя Dictionary состоит из:
1. Key - исходное имя (новой) переменной.
2. Value - актуальное имя (старой) переменной.
Т.е. "исходное": "актуальное", или так:
StringName, по идее, лучше подходит, чем String.
Алсо, типизация Array и Dictionary ускоряет код.
Слишком многого хочешь...
>>6102
Сохраняются они на сервере, в базе данных.
В худшем случае сисадмин ручками правит.
Алсо, у ММО всего один актуальный "сейв".
А ты думал, почему ММО сервера лежат?
Две причины:
1. В сингле ты всю игру за 10 часов проходишь.
В ММОРПГ ты РАБотаешь 10 лет как минимум.
2. В сингле многие не доходят даже до 50%.
В ММОРПГ всё держится на доверии олдов.
Т.е. в ММО это важно, а в сингле можно забить.
>>6077
Ага, имел бы совсем другие проблемы.
>>6082
1. Система версий нужна уже после релиза.
2. После релиза 99.99% проектов уходят на дно.
3. Ушедший на дно проект обновлять смысла нет.
4. ???
5. Профита нет, но и проблем ведь тоже нет - win!
Если анон делает систему версий - он успешный...
Долгоживущие игры делают как-то так:
- версия 1.2 может открыть сейвы 1.1 и 1.0.
- версия 1.3 может открыть сейвы 1.2 и 1.1.
- версия 1.4 может открыть сейвы 1.3 и 1.2.
И т.д., чтобы кодовая база не раздувалась.
Хочешь открыть сейв из 1.0 в 1.4?
1. Скачай версию 1.2 и пересохрани сейв в ней.
2. Вернись на версию 1.4 и открой сейв из 1.2.
Приблизительно так реализовано в Minecraft.
Важно понимать, что у вас за игра сохраняется?
- Кинематическая новелла на два часа чтения?
- Игра-коллекция пошаговых головоломок?
- Прямой, как кишка, сюжетный экшен?
- Нелинейная экшн-РПГ на 69 часов?
- Симулятор жизни на 9000 часов?
- Айдл-кликер на 100500 часов?
- Песочница на всю жизнь?
- Метаверс с играми?
- Мета-метаверс?
- Реальность?
- Жизнь?
>переименовать какую-нибудь переменную
Просто сделай через Dictionary, например:
>var cow # транс-корова (биологически крокодил)
>var milk # даже не спрашивай, откуда оно...
>const MAP: Dictionary[StringName, StringName] = {
>_ &"crocodile": &"cow",
>_ &"tears": &"milk",
>_ # и т.д.
>}
Сохранение:
>for key in MAP:
>_ file.set_value(CS, key, get(MAP[key]))
Загрузка:
>for key in MAP:
>_ set(MAP[key], file.get_value(CS, key, get(MAP[key])))
Итого, у тебя Dictionary состоит из:
1. Key - исходное имя (новой) переменной.
2. Value - актуальное имя (старой) переменной.
Т.е. "исходное": "актуальное", или так:
>"актуальное" == MAP["исходное"]
StringName, по идее, лучше подходит, чем String.
Алсо, типизация Array и Dictionary ускоряет код.
>автоматически наполнялся
Слишком многого хочешь...
>>6102
>В ММО... все персонажи сохраняются
Сохраняются они на сервере, в базе данных.
В худшем случае сисадмин ручками правит.
Алсо, у ММО всего один актуальный "сейв".
А ты думал, почему ММО сервера лежат?
>почему в сингл играх такого не делают
>вынуждают играть с начала
Две причины:
1. В сингле ты всю игру за 10 часов проходишь.
В ММОРПГ ты РАБотаешь 10 лет как минимум.
2. В сингле многие не доходят даже до 50%.
В ММОРПГ всё держится на доверии олдов.
Т.е. в ММО это важно, а в сингле можно забить.
>>6077
>сценами такой проблемы не имел бы
Ага, имел бы совсем другие проблемы.
>>6082
>силы уйдут не на то, что необходимо
1. Система версий нужна уже после релиза.
2. После релиза 99.99% проектов уходят на дно.
3. Ушедший на дно проект обновлять смысла нет.
4. ???
5. Профита нет, но и проблем ведь тоже нет - win!
Если анон делает систему версий - он успешный...
>говорит что не может загрузить сейвы
Долгоживущие игры делают как-то так:
- версия 1.2 может открыть сейвы 1.1 и 1.0.
- версия 1.3 может открыть сейвы 1.2 и 1.1.
- версия 1.4 может открыть сейвы 1.3 и 1.2.
И т.д., чтобы кодовая база не раздувалась.
Хочешь открыть сейв из 1.0 в 1.4?
1. Скачай версию 1.2 и пересохрани сейв в ней.
2. Вернись на версию 1.4 и открой сейв из 1.2.
Приблизительно так реализовано в Minecraft.
Важно понимать, что у вас за игра сохраняется?
- Кинематическая новелла на два часа чтения?
- Игра-коллекция пошаговых головоломок?
- Прямой, как кишка, сюжетный экшен?
- Нелинейная экшн-РПГ на 69 часов?
- Симулятор жизни на 9000 часов?
- Айдл-кликер на 100500 часов?
- Песочница на всю жизнь?
- Метаверс с играми?
- Мета-метаверс?
- Реальность?
- Жизнь?
>>6075
Просто сделай через Dictionary, например:
Сохранение:
Загрузка:
Итого, у тебя Dictionary состоит из:
1. Key - исходное имя (новой) переменной.
2. Value - актуальное имя (старой) переменной.
Т.е. "исходное": "актуальное", или так:
StringName, по идее, лучше подходит, чем String.
Алсо, типизация Array и Dictionary ускоряет код.
Слишком многого хочешь...
>>6102
Сохраняются они на сервере, в базе данных.
В худшем случае сисадмин ручками правит.
Алсо, у ММО всего один актуальный "сейв".
А ты думал, почему ММО сервера лежат?
Две причины:
1. В сингле ты всю игру за 10 часов проходишь.
В ММОРПГ ты РАБотаешь 10 лет как минимум.
2. В сингле многие не доходят даже до 50%.
В ММОРПГ всё держится на доверии олдов.
Т.е. в ММО это важно, а в сингле можно забить.
>>6077
Ага, имел бы совсем другие проблемы.
>>6082
1. Система версий нужна уже после релиза.
2. После релиза 99.99% проектов уходят на дно.
3. Ушедший на дно проект обновлять смысла нет.
4. ???
5. Профита нет, но и проблем ведь тоже нет - win!
Если анон делает систему версий - он успешный...
Долгоживущие игры делают как-то так:
- версия 1.2 может открыть сейвы 1.1 и 1.0.
- версия 1.3 может открыть сейвы 1.2 и 1.1.
- версия 1.4 может открыть сейвы 1.3 и 1.2.
И т.д., чтобы кодовая база не раздувалась.
Хочешь открыть сейв из 1.0 в 1.4?
1. Скачай версию 1.2 и пересохрани сейв в ней.
2. Вернись на версию 1.4 и открой сейв из 1.2.
Приблизительно так реализовано в Minecraft.
Важно понимать, что у вас за игра сохраняется?
- Кинематическая новелла на два часа чтения?
- Игра-коллекция пошаговых головоломок?
- Прямой, как кишка, сюжетный экшен?
- Нелинейная экшн-РПГ на 69 часов?
- Симулятор жизни на 9000 часов?
- Айдл-кликер на 100500 часов?
- Песочница на всю жизнь?
- Метаверс с играми?
- Мета-метаверс?
- Реальность?
- Жизнь?
>переименовать какую-нибудь переменную
Просто сделай через Dictionary, например:
>var cow # транс-корова (биологически крокодил)
>var milk # даже не спрашивай, откуда оно...
>const MAP: Dictionary[StringName, StringName] = {
>_ &"crocodile": &"cow",
>_ &"tears": &"milk",
>_ # и т.д.
>}
Сохранение:
>for key in MAP:
>_ file.set_value(CS, key, get(MAP[key]))
Загрузка:
>for key in MAP:
>_ set(MAP[key], file.get_value(CS, key, get(MAP[key])))
Итого, у тебя Dictionary состоит из:
1. Key - исходное имя (новой) переменной.
2. Value - актуальное имя (старой) переменной.
Т.е. "исходное": "актуальное", или так:
>"актуальное" == MAP["исходное"]
StringName, по идее, лучше подходит, чем String.
Алсо, типизация Array и Dictionary ускоряет код.
>автоматически наполнялся
Слишком многого хочешь...
>>6102
>В ММО... все персонажи сохраняются
Сохраняются они на сервере, в базе данных.
В худшем случае сисадмин ручками правит.
Алсо, у ММО всего один актуальный "сейв".
А ты думал, почему ММО сервера лежат?
>почему в сингл играх такого не делают
>вынуждают играть с начала
Две причины:
1. В сингле ты всю игру за 10 часов проходишь.
В ММОРПГ ты РАБотаешь 10 лет как минимум.
2. В сингле многие не доходят даже до 50%.
В ММОРПГ всё держится на доверии олдов.
Т.е. в ММО это важно, а в сингле можно забить.
>>6077
>сценами такой проблемы не имел бы
Ага, имел бы совсем другие проблемы.
>>6082
>силы уйдут не на то, что необходимо
1. Система версий нужна уже после релиза.
2. После релиза 99.99% проектов уходят на дно.
3. Ушедший на дно проект обновлять смысла нет.
4. ???
5. Профита нет, но и проблем ведь тоже нет - win!
Если анон делает систему версий - он успешный...
>говорит что не может загрузить сейвы
Долгоживущие игры делают как-то так:
- версия 1.2 может открыть сейвы 1.1 и 1.0.
- версия 1.3 может открыть сейвы 1.2 и 1.1.
- версия 1.4 может открыть сейвы 1.3 и 1.2.
И т.д., чтобы кодовая база не раздувалась.
Хочешь открыть сейв из 1.0 в 1.4?
1. Скачай версию 1.2 и пересохрани сейв в ней.
2. Вернись на версию 1.4 и открой сейв из 1.2.
Приблизительно так реализовано в Minecraft.
Важно понимать, что у вас за игра сохраняется?
- Кинематическая новелла на два часа чтения?
- Игра-коллекция пошаговых головоломок?
- Прямой, как кишка, сюжетный экшен?
- Нелинейная экшн-РПГ на 69 часов?
- Симулятор жизни на 9000 часов?
- Айдл-кликер на 100500 часов?
- Песочница на всю жизнь?
- Метаверс с играми?
- Мета-метаверс?
- Реальность?
- Жизнь?
>>6075
Смотри. Если переменная не изменилась в процессе игры, то и сохранять её не надо, так? Если это так, то ты можешь юзать сеттеры в нужных переменных и пустой массив VARS_TO_SAVE_LOAD. В сеттере переменная добавляет себя в этот массив. Ты всё равно можешь забыть, но так шансов забыть меньше, ведь сеттер прямо рядом с названием переменной.
Эх, в шарпе на этот счёт есть автоподстановка имени вызывающей переменной. Там уж точно не забыл бы.
> мне не нравится, что я могу переименовать какую-нибудь переменную, но не внести ее новое название в VARS_TO_SAVE_LOAD. Как бы сделать, чтобы этот массив автоматически наполнялся, а я бы только как-то помечал для этого переменные при их объявлении?
Смотри. Если переменная не изменилась в процессе игры, то и сохранять её не надо, так? Если это так, то ты можешь юзать сеттеры в нужных переменных и пустой массив VARS_TO_SAVE_LOAD. В сеттере переменная добавляет себя в этот массив. Ты всё равно можешь забыть, но так шансов забыть меньше, ведь сеттер прямо рядом с названием переменной.
> var krokodil: int = 62500:
> . set(v):
> . . if v != krokodil:
> . . . krokodil = v
> . . . VARS_TO_SAVE_LOAD.append(&"krokodil")
Эх, в шарпе на этот счёт есть автоподстановка имени вызывающей переменной. Там уж точно не забыл бы.
>>6102
Во-первых, делают.
Во-вторых, в сингле обычно можно загрузиться, а перед началом миссии чекпоинт.
В-третьих, переиграть нельзя в тех играх, где это важная часть геймплея: например, рогаликах; да и в упомянутом майнкрафте тоже. А в условной жта - грузись и переигрывай сколько влезет.
>Но любой квест/цепочку есть опция рестартануть, не знаю почему в сингл играх такого не делают и вынуждают играть с начала.
Во-первых, делают.
Во-вторых, в сингле обычно можно загрузиться, а перед началом миссии чекпоинт.
В-третьих, переиграть нельзя в тех играх, где это важная часть геймплея: например, рогаликах; да и в упомянутом майнкрафте тоже. А в условной жта - грузись и переигрывай сколько влезет.
>>6145
Я имел в виду скорее такую ситуацию: у меня есть в папке старый сейв игры, а игра с тех пор уже обновилась и при загрузке в сейве сломанный квест, играй сначала. А ты скорее о случае когда игрок в текущей версии немного откатывает
Кстати майнкрафт вполне переигрывался. У меня был домашний семейный сераер и там просто бэкапилась папка с миром. Пару раз откатывали при какой то кривой непрогрузке или когда кто то упал в лаву из за лага.
Я имел в виду скорее такую ситуацию: у меня есть в папке старый сейв игры, а игра с тех пор уже обновилась и при загрузке в сейве сломанный квест, играй сначала. А ты скорее о случае когда игрок в текущей версии немного откатывает
Кстати майнкрафт вполне переигрывался. У меня был домашний семейный сераер и там просто бэкапилась папка с миром. Пару раз откатывали при какой то кривой непрогрузке или когда кто то упал в лаву из за лага.
209 Кб, 940x1604>>6075
Сделал!
https://pastebin.com/raw/uXa4n18F
Для сохранения переменной в ини просто помечаем ее как @export
Это для настроек, не для сейвов
>>6076
>>6134
>>6141
Все это не то, но спасибо энивей
Сделал!
https://pastebin.com/raw/uXa4n18F
Для сохранения переменной в ини просто помечаем ее как @export
Это для настроек, не для сейвов
>>6076
>>6134
>>6141
Все это не то, но спасибо энивей
>>4044 (OP)
Ребят, юзайте кэширование. Вот вам пример на фибоначах. Делал тут фибоначи академические и охуел от скорости вычисления рекурсии. Немного подумал и решил прикрутить простенький кэш. И вот пожалуйста часы сократились до микросекунд.
Ребят, юзайте кэширование. Вот вам пример на фибоначах. Делал тут фибоначи академические и охуел от скорости вычисления рекурсии. Немного подумал и решил прикрутить простенький кэш. И вот пожалуйста часы сократились до микросекунд.
>>6154
Читал когда-то про динамическое программирование и мемоизацию, но на практике не использовал. Хотя, наверное, всякие поиски пути типа астар к этому относятся. Тут вроде наглядно https://brestprog.by/topics/dp/
Читал когда-то про динамическое программирование и мемоизацию, но на практике не использовал. Хотя, наверное, всякие поиски пути типа астар к этому относятся. Тут вроде наглядно https://brestprog.by/topics/dp/
>>6158
Удобно, не спорю. Просто интересно что быстрее - мета или обычный словарь с доступом по ключам. У тебя там еще строки форматятся - потенциальный прирост скорости, если избавиться.
>Ну мета это уже готовый словарь, созданный вместе с экземпляром
Удобно, не спорю. Просто интересно что быстрее - мета или обычный словарь с доступом по ключам. У тебя там еще строки форматятся - потенциальный прирост скорости, если избавиться.
>>6141
В GDScript сеттеры не вызываются со значением по умолчанию. Т.е. даже если у тебя есть присваивание:
Для значения "62500" сеттер не будет вызван. Это не ошибка: так и задумано ради производительности. Обсуждение на гитхабе предлагает делать так:
Чтоб принудительно вызывать сеттер для любых возможных значений, включая по умолчанию, если действительно нужно всегда вызывать сеттер.
>>6146
Такое вряд ли исправить опцией "переиграть квест". Вообще, зависит от игры. Подобная опция может вырывать игрока из погружения в мир игры - как в ММОРПГ, но у них суть в отношениях с людьми, а не с неигровыми персонажами или игровым миром.
>>6147
В твоём варианте настройки пользователя будут сбрасываться до значений по умолчанию после переименования переменной в твоём скрипте. А предыдущие значения будут висеть в .ini без дела. Соответственно, если хочешь поддерживать старые сохранения (даже если это только биндинги клавиш), желательно сделать карту "старое имя - новое имя".
>юзать сеттеры
В GDScript сеттеры не вызываются со значением по умолчанию. Т.е. даже если у тебя есть присваивание:
>var krokodil: int = 62500: set(v): ...
Для значения "62500" сеттер не будет вызван. Это не ошибка: так и задумано ради производительности. Обсуждение на гитхабе предлагает делать так:
>func _ready() -> void: krokodil = krokodil
Чтоб принудительно вызывать сеттер для любых возможных значений, включая по умолчанию, если действительно нужно всегда вызывать сеттер.
>>6146
>при загрузке в сейве сломанный квест
Такое вряд ли исправить опцией "переиграть квест". Вообще, зависит от игры. Подобная опция может вырывать игрока из погружения в мир игры - как в ММОРПГ, но у них суть в отношениях с людьми, а не с неигровыми персонажами или игровым миром.
>>6147
>Это для настроек
В твоём варианте настройки пользователя будут сбрасываться до значений по умолчанию после переименования переменной в твоём скрипте. А предыдущие значения будут висеть в .ini без дела. Соответственно, если хочешь поддерживать старые сохранения (даже если это только биндинги клавиш), желательно сделать карту "старое имя - новое имя".
>>6154
Как сказали выше, ты тут тратишь время на лишние операции со строками. Непонятно, зачем ты вообще написал так, ибо это даже печатать неудобно, лол. И метаданные принадлежат объекту, а не классу, т.е. засоряешь оперативную память лишними копиями.
Вот так лучше сделать, обобщённый пример:
Dictionary может принимать любой тип как ключ.
Почему static? Потому что это "чистая функция":
https://ru.wikipedia.org/wiki/Чистота_функции
Так мы шарим кэш между всеми экземплярами.
Подводные камни кэширования вычислений:
1. Возможно только для чистых функций. А в играх большинство функций либо завязаны на побочные эффекты (подвигать спрайт, поменять текст), либо недетерминированные (один ввод - разные ответы). Часто тебе приходится числа Фибоначчи вычислять?
2. Если функция используется часто и для очень разнообразных, редко повторяющихся значений, например, миллионные доли float, то кэш быстро раздувается и при этом редко используется. Ещё большой вопрос, будет ли запрос к такому кэшу действительно быстрее вычисления с нуля.
В общем, концепция кэша привлекательна, но её использование должно быть очень аккуратным и мотивированным реальной потребностью. Часто оказывается, что теоретическая оптимизация в реальности ухудшает производительность, когда применяется к реальным задачам, а не к простому вычислению какого-то ряда абстрактных чисел. Фокусируйтесь на игровых механиках и том, какие ощущения создаёт игра, а оптимизировать будете значительно позже (если игра вообще получится).
И вообще, если ВДРУГ нужно вычислять миллионы абстрактных чисел каждый кадр, то эффективнее перенести алгоритм на C++, чем изобретать какие-то костыли для GDScript. Тем не менее, изначальный прототип лучше собрать чисто на GDScript, т.к. это значительно быстрее в плане проектирования игры. Поэтому прекращайте забивать себе голову этими оптимизациями и просто делайте свои игры.
>get_meta("fib_%s_cache" % idx)
Как сказали выше, ты тут тратишь время на лишние операции со строками. Непонятно, зачем ты вообще написал так, ибо это даже печатать неудобно, лол. И метаданные принадлежат объекту, а не классу, т.е. засоряешь оперативную память лишними копиями.
Вот так лучше сделать, обобщённый пример:
>static var fun_cache: Dictionary[InType, OutType] = {}
>static func fun(data: InType) -> OutType:
>_ if data not in fun_cache:
>_ _ fun_cache[data] = ... # вычисление значения
>_ return fun_cache[data]
Dictionary может принимать любой тип как ключ.
Почему static? Потому что это "чистая функция":
https://ru.wikipedia.org/wiki/Чистота_функции
Так мы шарим кэш между всеми экземплярами.
Подводные камни кэширования вычислений:
1. Возможно только для чистых функций. А в играх большинство функций либо завязаны на побочные эффекты (подвигать спрайт, поменять текст), либо недетерминированные (один ввод - разные ответы). Часто тебе приходится числа Фибоначчи вычислять?
2. Если функция используется часто и для очень разнообразных, редко повторяющихся значений, например, миллионные доли float, то кэш быстро раздувается и при этом редко используется. Ещё большой вопрос, будет ли запрос к такому кэшу действительно быстрее вычисления с нуля.
В общем, концепция кэша привлекательна, но её использование должно быть очень аккуратным и мотивированным реальной потребностью. Часто оказывается, что теоретическая оптимизация в реальности ухудшает производительность, когда применяется к реальным задачам, а не к простому вычислению какого-то ряда абстрактных чисел. Фокусируйтесь на игровых механиках и том, какие ощущения создаёт игра, а оптимизировать будете значительно позже (если игра вообще получится).
И вообще, если ВДРУГ нужно вычислять миллионы абстрактных чисел каждый кадр, то эффективнее перенести алгоритм на C++, чем изобретать какие-то костыли для GDScript. Тем не менее, изначальный прототип лучше собрать чисто на GDScript, т.к. это значительно быстрее в плане проектирования игры. Поэтому прекращайте забивать себе голову этими оптимизациями и просто делайте свои игры.
>>6154
Как сказали выше, ты тут тратишь время на лишние операции со строками. Непонятно, зачем ты вообще написал так, ибо это даже печатать неудобно, лол. И метаданные принадлежат объекту, а не классу, т.е. засоряешь оперативную память лишними копиями.
Вот так лучше сделать, обобщённый пример:
Dictionary может принимать любой тип как ключ.
Почему static? Потому что это "чистая функция":
https://ru.wikipedia.org/wiki/Чистота_функции
Так мы шарим кэш между всеми экземплярами.
Подводные камни кэширования вычислений:
1. Возможно только для чистых функций. А в играх большинство функций либо завязаны на побочные эффекты (подвигать спрайт, поменять текст), либо недетерминированные (один ввод - разные ответы). Часто тебе приходится числа Фибоначчи вычислять?
2. Если функция используется часто и для очень разнообразных, редко повторяющихся значений, например, миллионные доли float, то кэш быстро раздувается и при этом редко используется. Ещё большой вопрос, будет ли запрос к такому кэшу действительно быстрее вычисления с нуля.
В общем, концепция кэша привлекательна, но её использование должно быть очень аккуратным и мотивированным реальной потребностью. Часто оказывается, что теоретическая оптимизация в реальности ухудшает производительность, когда применяется к реальным задачам, а не к простому вычислению какого-то ряда абстрактных чисел. Фокусируйтесь на игровых механиках и том, какие ощущения создаёт игра, а оптимизировать будете значительно позже (если игра вообще получится).
И вообще, если ВДРУГ нужно вычислять миллионы абстрактных чисел каждый кадр, то эффективнее перенести алгоритм на C++, чем изобретать какие-то костыли для GDScript. Тем не менее, изначальный прототип лучше собрать чисто на GDScript, т.к. это значительно быстрее в плане проектирования игры. Поэтому прекращайте забивать себе голову этими оптимизациями и просто делайте свои игры.
>get_meta("fib_%s_cache" % idx)
Как сказали выше, ты тут тратишь время на лишние операции со строками. Непонятно, зачем ты вообще написал так, ибо это даже печатать неудобно, лол. И метаданные принадлежат объекту, а не классу, т.е. засоряешь оперативную память лишними копиями.
Вот так лучше сделать, обобщённый пример:
>static var fun_cache: Dictionary[InType, OutType] = {}
>static func fun(data: InType) -> OutType:
>_ if data not in fun_cache:
>_ _ fun_cache[data] = ... # вычисление значения
>_ return fun_cache[data]
Dictionary может принимать любой тип как ключ.
Почему static? Потому что это "чистая функция":
https://ru.wikipedia.org/wiki/Чистота_функции
Так мы шарим кэш между всеми экземплярами.
Подводные камни кэширования вычислений:
1. Возможно только для чистых функций. А в играх большинство функций либо завязаны на побочные эффекты (подвигать спрайт, поменять текст), либо недетерминированные (один ввод - разные ответы). Часто тебе приходится числа Фибоначчи вычислять?
2. Если функция используется часто и для очень разнообразных, редко повторяющихся значений, например, миллионные доли float, то кэш быстро раздувается и при этом редко используется. Ещё большой вопрос, будет ли запрос к такому кэшу действительно быстрее вычисления с нуля.
В общем, концепция кэша привлекательна, но её использование должно быть очень аккуратным и мотивированным реальной потребностью. Часто оказывается, что теоретическая оптимизация в реальности ухудшает производительность, когда применяется к реальным задачам, а не к простому вычислению какого-то ряда абстрактных чисел. Фокусируйтесь на игровых механиках и том, какие ощущения создаёт игра, а оптимизировать будете значительно позже (если игра вообще получится).
И вообще, если ВДРУГ нужно вычислять миллионы абстрактных чисел каждый кадр, то эффективнее перенести алгоритм на C++, чем изобретать какие-то костыли для GDScript. Тем не менее, изначальный прототип лучше собрать чисто на GDScript, т.к. это значительно быстрее в плане проектирования игры. Поэтому прекращайте забивать себе голову этими оптимизациями и просто делайте свои игры.
>>6172
Наверняка Хуан рано или поздно завезёт нативизацию, как у эпиков. Поэтому можно будет одной кнопкой превратить скрипт в ГДЭкстеншон на крестах, и отправить на конпеляцию. Затем убедившись что сконпелировалось, открыть сгенерированый проект в ИДЕ, и начать настоящие оптимизации.
> Поэтому прекращайте забивать себе голову этими оптимизациями и просто делайте свои игры.
Наверняка Хуан рано или поздно завезёт нативизацию, как у эпиков. Поэтому можно будет одной кнопкой превратить скрипт в ГДЭкстеншон на крестах, и отправить на конпеляцию. Затем убедившись что сконпелировалось, открыть сгенерированый проект в ИДЕ, и начать настоящие оптимизации.
>>6175
Еще лучше!
Еще лучше!
>>6177
А можешь показать пример со скринами?
А можешь показать пример со скринами?
>>6181
Ну я хз, выглядит, как утка, крякает как утка.
Ну я хз, выглядит, как утка, крякает как утка.
>>6186
Ну не останавливайся же, не забудь показать откуда он берет тайм.
Ну не останавливайся же, не забудь показать откуда он берет тайм.
>>6160
Пожалуйста, пости скриншоты на языке оригинала. Переводчики всегда утрачивают нюансы, а кому так необходим перевод на русский - все автоматические переводчики сегодня умеют переводить скриншоты.
>>6173
А загружать как? Его оригинальный код смотрит в специальный массив с именами и ищет эти имена в загруженном файле. Нет имени в массиве - не будет загружено сохранённое в прошлый раз значение...
>>6174
Давно обсуждали JIT и AOT компиляцию, а также конвертирование в C/C++. Проблема в том, что для поддержки из коробки нужен крайне компактный и стабильный компилятор C под совместимой с MIT лицензией, а подходящего что-то не нашли. Давно проверял, но сомневаюсь, что что-то поменялось.
Напомню, что типизацию для Array и Dictionary нам завезли как quality of life фичи - типизация позволяет значительно упростить использование инспектора. А производительность тут была приятным бонусом. Т.е. выжимать максимум из GDScript никто не торопится.
Они ж её вроде удалили? В UE4 было, в UE5 нет. В интернете пишут, что фича была нестабильной - в достаточно сложных проектах крашила игру. Если корпорация ниасилила, Godot вряд ли потянет сам (поэтому ищут готовый компилятор в нативный код).
Конечно, есть вариант требовать установку большого компилятора типа GCC/MSVC/Clang или что там ещё. Кажется, этого хотят избежать для базовой версии.
Короч, интерпретируемые языки на порядки проще разрабатывать, чем компиляторы в нативный код.
Пожалуйста, пости скриншоты на языке оригинала. Переводчики всегда утрачивают нюансы, а кому так необходим перевод на русский - все автоматические переводчики сегодня умеют переводить скриншоты.
>>6173
>сохранять её не надо
А загружать как? Его оригинальный код смотрит в специальный массив с именами и ищет эти имена в загруженном файле. Нет имени в массиве - не будет загружено сохранённое в прошлый раз значение...
>>6174
>Хуан рано или поздно завезёт нативизацию
Давно обсуждали JIT и AOT компиляцию, а также конвертирование в C/C++. Проблема в том, что для поддержки из коробки нужен крайне компактный и стабильный компилятор C под совместимой с MIT лицензией, а подходящего что-то не нашли. Давно проверял, но сомневаюсь, что что-то поменялось.
Напомню, что типизацию для Array и Dictionary нам завезли как quality of life фичи - типизация позволяет значительно упростить использование инспектора. А производительность тут была приятным бонусом. Т.е. выжимать максимум из GDScript никто не торопится.
>как у эпиков
Они ж её вроде удалили? В UE4 было, в UE5 нет. В интернете пишут, что фича была нестабильной - в достаточно сложных проектах крашила игру. Если корпорация ниасилила, Godot вряд ли потянет сам (поэтому ищут готовый компилятор в нативный код).
Конечно, есть вариант требовать установку большого компилятора типа GCC/MSVC/Clang или что там ещё. Кажется, этого хотят избежать для базовой версии.
Короч, интерпретируемые языки на порядки проще разрабатывать, чем компиляторы в нативный код.
>>6190
Хехе
x86_64 zig-windows-x86_64 79MiB
x86_64 zig-linux-x86_64 47MiB
https://github.com/ziglang/zig/blob/master/LICENSE
>нужен крайне компактный и стабильный компилятор C под совместимой с MIT лицензией,
Хехе
x86_64 zig-windows-x86_64 79MiB
x86_64 zig-linux-x86_64 47MiB
https://github.com/ziglang/zig/blob/master/LICENSE
>>6190
Братииишка, аноооон. Переменная имеет значение по умолчанию. Его не надо загружать.
> А загружать как?
Братииишка, аноооон. Переменная имеет значение по умолчанию. Его не надо загружать.
>>6191
Я в ахуе с братишек ИТТ.
> нужен компилятор С
> ммм, наверное ему нужен компилятор с_чем_то, посоветую ему свой зиг
Я в ахуе с братишек ИТТ.
>>6194
Если так, то извиняюсь, это нужно было прояснить сразу, иначе со стороны незнакомому с этими проектами выглядит именно как братишковость.
Если так, то извиняюсь, это нужно было прояснить сразу, иначе со стороны незнакомому с этими проектами выглядит именно как братишковость.
>>6192
Играем 1-й раз, переменная по умолчанию 42.
Поиграли, переменная поменялась на 27
Первое сохранение, записалось 27.
Завтра загружаем игру, прочиталось 27.
Играем дальше, но переменная не затронута
Делаем второе сохранение, переменная не менялась, записывать не надо
Послезавтра загружаем 2-й сейв, там пусто, переменная по умолчанию снова 42
Классная система.
Играем 1-й раз, переменная по умолчанию 42.
Поиграли, переменная поменялась на 27
Первое сохранение, записалось 27.
Завтра загружаем игру, прочиталось 27.
Играем дальше, но переменная не затронута
Делаем второе сохранение, переменная не менялась, записывать не надо
Послезавтра загружаем 2-й сейв, там пусто, переменная по умолчанию снова 42
Классная система.
>>6196
Я на защите диплома? Окееей. Вот тут ошибка:
Я на защите диплома? Окееей. Вот тут ошибка:
> Играем дальше, но переменная не затронута
> Делаем второе сохранение, переменная не менялась, записывать не надо
>>6197
Твои слова?
Хотя сли ты имел в виду не "не изменилась в процессе игры", а "не изменилась относительно дефолтного значения" или "изменилась в процессе игры ИЛИ не в процессе игры при загрузке", тогда ок.
Твои слова?
>Если переменная не изменилась в процессе игры, то и сохранять её не надо, так?
Хотя сли ты имел в виду не "не изменилась в процессе игры", а "не изменилась относительно дефолтного значения" или "изменилась в процессе игры ИЛИ не в процессе игры при загрузке", тогда ок.
>>6198
Никакого "имел" ввиду. Логика либо есть, либо её нет.
>>6196
Никакого "имел" ввиду. Логика либо есть, либо её нет.
>>6196
> Поиграли, переменная поменялась на 27 (сеттер вызван, поле добавлено)
> Первое сохранение, записалось 27.
> Завтра загружаем игру, прочиталось 27 (сеттер вызван, поле добавлено)
> Играем дальше, но переменная не затронута (затронута)
> Делаем второе сохранение, переменная не менялась (менялась), записывать не надо (надо)
>>6183
Лично я люблю Llama 3.x и часто общаюсь с ней, она ощутимо помогает упорядочить мысли и прочее, но генерировать код через LLM реально ненадёжно - качественно не получится, а исправлять тяжело. Особенно когда задача сложная и нетипичная, т.е. нерешаема простым копипастом кода из интернета.
На что обучены LLM? Искать подходящий токен в последовательности. Как они ищут? Благодаря статистическим взаимосвязям в данных. Скажем, натренированная на сотнях тысяч психологических материалов LLM будет способна понять, если слова пользователя выражают грусть и одиночество - она подберёт подходящие слова по аналогии с тем, что понаписали в интернете и книгах миллионы людей: подбодрит, утешит, даст какой-нибудь совет, просто выслушает, задаст какие-то находящие вопросы. Чрезвычайно полезный компаньон в этом плане.
Но генерация кода принципиально отличается: в разговорной речи допустимо менять слова как на синонимичные, так и местами, и даже пропускать очевидное собеседнику. Мозг человека обучен на извлечение смысла из максимально загрязнённой информации, и поэтому мы даже не замечаем, как собеседник (или в данном случае LLM) допускает определённые ошибки или неточности. Результат достигается за счёт мощности нашего мозга, что принципиально скрыта где-то в бессознательном. Буквально даже восприятие LLM собеседником - деятельность нашего мозга, натягивающего ярлык "человек" даже на простые вещи (антропоморфизм).
С программным кодом всё в точности наоборот: что напишешь, то компьютер и выполнит, и не факт, что результат тебя обрадует. А подходящих примеров в интернете много только для тривиальных задач, что решаются типичным студентом чисто для практики. Дополнительно создаёт проблем то, что код игры ты вынужден поддерживать (перечитывать, исправлять, дополнять) весь жизненный цикл игры, тогда как абстрактные диалоги с LLM имеют ценность лишь в процессе общения, и поэтому ошибки не страшны. Соответственно и цена ошибки в коде выше, чем у случайного выражения в разговорной речи.
Короче говоря, LLM прекрасно подходят на роль виртуального собеседника для обсуждения каких-то бытовых мелочей, психологии, философии и прочей графомании, в которой настроение и эмоции важнее объективной точности. Сгенерировать код они могут только если ты просишь банальность, тысячекратно скопипащенную в интернете, и не планируешь это поддерживать дольше своего нажатия ctrl+c/ctrl+v.
Я на 100% уверен, что в будущем ИИ сможет взять ответственность за всё программирование и люди перестанут писать код вручную, а "программист" и "разработчик" исчезнут как классы, т.к. ИИ сможет справиться со всем без мясных мешков. Но LLM принципиально не подходят на эту роль, или, как минимум, текущие архитектуры LLM не подходят. Программиста сможет заменить полноценная искусственная личность, живущая сама по себе, независимо от мясной прослойки между стулом и клавиатурой. А LLM только пересказывают то, что, по статистике, должно следовать за запросом. Без постоянного взаимодействия со средой и активной адаптации это всё слишком далеко до идеала. LLM, теоретически, только часть системы, но не факт, что получится нарастить нужное вокруг текущих LLM.
Извиняюсь за стену текста, наболело. Попробуйте сгенерировать проект сложнее популярных и потом поддерживайте его несколько лет, исправляя все найденные игроками ошибки и добавляя новые возможности. От LLM польза будет только на этапе обсуждения концепции игры и психологии игроков.
Лично я люблю Llama 3.x и часто общаюсь с ней, она ощутимо помогает упорядочить мысли и прочее, но генерировать код через LLM реально ненадёжно - качественно не получится, а исправлять тяжело. Особенно когда задача сложная и нетипичная, т.е. нерешаема простым копипастом кода из интернета.
На что обучены LLM? Искать подходящий токен в последовательности. Как они ищут? Благодаря статистическим взаимосвязям в данных. Скажем, натренированная на сотнях тысяч психологических материалов LLM будет способна понять, если слова пользователя выражают грусть и одиночество - она подберёт подходящие слова по аналогии с тем, что понаписали в интернете и книгах миллионы людей: подбодрит, утешит, даст какой-нибудь совет, просто выслушает, задаст какие-то находящие вопросы. Чрезвычайно полезный компаньон в этом плане.
Но генерация кода принципиально отличается: в разговорной речи допустимо менять слова как на синонимичные, так и местами, и даже пропускать очевидное собеседнику. Мозг человека обучен на извлечение смысла из максимально загрязнённой информации, и поэтому мы даже не замечаем, как собеседник (или в данном случае LLM) допускает определённые ошибки или неточности. Результат достигается за счёт мощности нашего мозга, что принципиально скрыта где-то в бессознательном. Буквально даже восприятие LLM собеседником - деятельность нашего мозга, натягивающего ярлык "человек" даже на простые вещи (антропоморфизм).
С программным кодом всё в точности наоборот: что напишешь, то компьютер и выполнит, и не факт, что результат тебя обрадует. А подходящих примеров в интернете много только для тривиальных задач, что решаются типичным студентом чисто для практики. Дополнительно создаёт проблем то, что код игры ты вынужден поддерживать (перечитывать, исправлять, дополнять) весь жизненный цикл игры, тогда как абстрактные диалоги с LLM имеют ценность лишь в процессе общения, и поэтому ошибки не страшны. Соответственно и цена ошибки в коде выше, чем у случайного выражения в разговорной речи.
Короче говоря, LLM прекрасно подходят на роль виртуального собеседника для обсуждения каких-то бытовых мелочей, психологии, философии и прочей графомании, в которой настроение и эмоции важнее объективной точности. Сгенерировать код они могут только если ты просишь банальность, тысячекратно скопипащенную в интернете, и не планируешь это поддерживать дольше своего нажатия ctrl+c/ctrl+v.
Я на 100% уверен, что в будущем ИИ сможет взять ответственность за всё программирование и люди перестанут писать код вручную, а "программист" и "разработчик" исчезнут как классы, т.к. ИИ сможет справиться со всем без мясных мешков. Но LLM принципиально не подходят на эту роль, или, как минимум, текущие архитектуры LLM не подходят. Программиста сможет заменить полноценная искусственная личность, живущая сама по себе, независимо от мясной прослойки между стулом и клавиатурой. А LLM только пересказывают то, что, по статистике, должно следовать за запросом. Без постоянного взаимодействия со средой и активной адаптации это всё слишком далеко до идеала. LLM, теоретически, только часть системы, но не факт, что получится нарастить нужное вокруг текущих LLM.
Извиняюсь за стену текста, наболело. Попробуйте сгенерировать проект сложнее популярных и потом поддерживайте его несколько лет, исправляя все найденные игроками ошибки и добавляя новые возможности. От LLM польза будет только на этапе обсуждения концепции игры и психологии игроков.
>>6183
Лично я люблю Llama 3.x и часто общаюсь с ней, она ощутимо помогает упорядочить мысли и прочее, но генерировать код через LLM реально ненадёжно - качественно не получится, а исправлять тяжело. Особенно когда задача сложная и нетипичная, т.е. нерешаема простым копипастом кода из интернета.
На что обучены LLM? Искать подходящий токен в последовательности. Как они ищут? Благодаря статистическим взаимосвязям в данных. Скажем, натренированная на сотнях тысяч психологических материалов LLM будет способна понять, если слова пользователя выражают грусть и одиночество - она подберёт подходящие слова по аналогии с тем, что понаписали в интернете и книгах миллионы людей: подбодрит, утешит, даст какой-нибудь совет, просто выслушает, задаст какие-то находящие вопросы. Чрезвычайно полезный компаньон в этом плане.
Но генерация кода принципиально отличается: в разговорной речи допустимо менять слова как на синонимичные, так и местами, и даже пропускать очевидное собеседнику. Мозг человека обучен на извлечение смысла из максимально загрязнённой информации, и поэтому мы даже не замечаем, как собеседник (или в данном случае LLM) допускает определённые ошибки или неточности. Результат достигается за счёт мощности нашего мозга, что принципиально скрыта где-то в бессознательном. Буквально даже восприятие LLM собеседником - деятельность нашего мозга, натягивающего ярлык "человек" даже на простые вещи (антропоморфизм).
С программным кодом всё в точности наоборот: что напишешь, то компьютер и выполнит, и не факт, что результат тебя обрадует. А подходящих примеров в интернете много только для тривиальных задач, что решаются типичным студентом чисто для практики. Дополнительно создаёт проблем то, что код игры ты вынужден поддерживать (перечитывать, исправлять, дополнять) весь жизненный цикл игры, тогда как абстрактные диалоги с LLM имеют ценность лишь в процессе общения, и поэтому ошибки не страшны. Соответственно и цена ошибки в коде выше, чем у случайного выражения в разговорной речи.
Короче говоря, LLM прекрасно подходят на роль виртуального собеседника для обсуждения каких-то бытовых мелочей, психологии, философии и прочей графомании, в которой настроение и эмоции важнее объективной точности. Сгенерировать код они могут только если ты просишь банальность, тысячекратно скопипащенную в интернете, и не планируешь это поддерживать дольше своего нажатия ctrl+c/ctrl+v.
Я на 100% уверен, что в будущем ИИ сможет взять ответственность за всё программирование и люди перестанут писать код вручную, а "программист" и "разработчик" исчезнут как классы, т.к. ИИ сможет справиться со всем без мясных мешков. Но LLM принципиально не подходят на эту роль, или, как минимум, текущие архитектуры LLM не подходят. Программиста сможет заменить полноценная искусственная личность, живущая сама по себе, независимо от мясной прослойки между стулом и клавиатурой. А LLM только пересказывают то, что, по статистике, должно следовать за запросом. Без постоянного взаимодействия со средой и активной адаптации это всё слишком далеко до идеала. LLM, теоретически, только часть системы, но не факт, что получится нарастить нужное вокруг текущих LLM.
Извиняюсь за стену текста, наболело. Попробуйте сгенерировать проект сложнее популярных и потом поддерживайте его несколько лет, исправляя все найденные игроками ошибки и добавляя новые возможности. От LLM польза будет только на этапе обсуждения концепции игры и психологии игроков.
Лично я люблю Llama 3.x и часто общаюсь с ней, она ощутимо помогает упорядочить мысли и прочее, но генерировать код через LLM реально ненадёжно - качественно не получится, а исправлять тяжело. Особенно когда задача сложная и нетипичная, т.е. нерешаема простым копипастом кода из интернета.
На что обучены LLM? Искать подходящий токен в последовательности. Как они ищут? Благодаря статистическим взаимосвязям в данных. Скажем, натренированная на сотнях тысяч психологических материалов LLM будет способна понять, если слова пользователя выражают грусть и одиночество - она подберёт подходящие слова по аналогии с тем, что понаписали в интернете и книгах миллионы людей: подбодрит, утешит, даст какой-нибудь совет, просто выслушает, задаст какие-то находящие вопросы. Чрезвычайно полезный компаньон в этом плане.
Но генерация кода принципиально отличается: в разговорной речи допустимо менять слова как на синонимичные, так и местами, и даже пропускать очевидное собеседнику. Мозг человека обучен на извлечение смысла из максимально загрязнённой информации, и поэтому мы даже не замечаем, как собеседник (или в данном случае LLM) допускает определённые ошибки или неточности. Результат достигается за счёт мощности нашего мозга, что принципиально скрыта где-то в бессознательном. Буквально даже восприятие LLM собеседником - деятельность нашего мозга, натягивающего ярлык "человек" даже на простые вещи (антропоморфизм).
С программным кодом всё в точности наоборот: что напишешь, то компьютер и выполнит, и не факт, что результат тебя обрадует. А подходящих примеров в интернете много только для тривиальных задач, что решаются типичным студентом чисто для практики. Дополнительно создаёт проблем то, что код игры ты вынужден поддерживать (перечитывать, исправлять, дополнять) весь жизненный цикл игры, тогда как абстрактные диалоги с LLM имеют ценность лишь в процессе общения, и поэтому ошибки не страшны. Соответственно и цена ошибки в коде выше, чем у случайного выражения в разговорной речи.
Короче говоря, LLM прекрасно подходят на роль виртуального собеседника для обсуждения каких-то бытовых мелочей, психологии, философии и прочей графомании, в которой настроение и эмоции важнее объективной точности. Сгенерировать код они могут только если ты просишь банальность, тысячекратно скопипащенную в интернете, и не планируешь это поддерживать дольше своего нажатия ctrl+c/ctrl+v.
Я на 100% уверен, что в будущем ИИ сможет взять ответственность за всё программирование и люди перестанут писать код вручную, а "программист" и "разработчик" исчезнут как классы, т.к. ИИ сможет справиться со всем без мясных мешков. Но LLM принципиально не подходят на эту роль, или, как минимум, текущие архитектуры LLM не подходят. Программиста сможет заменить полноценная искусственная личность, живущая сама по себе, независимо от мясной прослойки между стулом и клавиатурой. А LLM только пересказывают то, что, по статистике, должно следовать за запросом. Без постоянного взаимодействия со средой и активной адаптации это всё слишком далеко до идеала. LLM, теоретически, только часть системы, но не факт, что получится нарастить нужное вокруг текущих LLM.
Извиняюсь за стену текста, наболело. Попробуйте сгенерировать проект сложнее популярных и потом поддерживайте его несколько лет, исправляя все найденные игроками ошибки и добавляя новые возможности. От LLM польза будет только на этапе обсуждения концепции игры и психологии игроков.
>>6202
Я не люблю и не пользуюсь. Скрины привёл исключительно потому что УТКА позволяет пообщаться с этими вашими ламами бесплатно без регистрации, заскринить и выложить на двачи.
Я не люблю и не пользуюсь. Скрины привёл исключительно потому что УТКА позволяет пообщаться с этими вашими ламами бесплатно без регистрации, заскринить и выложить на двачи.
4 Кб, 632x539Как предотвратить тычок по интерактивным предметам (сундук, ящик, кнопка), находящимися ЗА стеной? Сразу подумал отключать оружие, если оно прошло через стену, но тогда вся боевка становится кривой.
>>6204
Рейкаст очевидный очевиден. Рейкаст бросаешь до объекта, который задетектил своим существующим кодом, и если рейкаст проходит, значит объект в прямой видимости, иначе, объект чем-то закрыт и мы всё отменяем.
Рейкаст очевидный очевиден. Рейкаст бросаешь до объекта, который задетектил своим существующим кодом, и если рейкаст проходит, значит объект в прямой видимости, иначе, объект чем-то закрыт и мы всё отменяем.
>>6204
А зачем ты вообще позволяешь оружию проходить сквозь стену? Что мешает дать ему коллайдер или не давать атаковать когда стоишь вплотную?
А зачем ты вообще позволяешь оружию проходить сквозь стену? Что мешает дать ему коллайдер или не давать атаковать когда стоишь вплотную?
>>6192
Перечитай код со скриншота >>6075.
Особое внимание обрати на load_config().
В частности, тебя должна интересовать строчка:
И следующая сразу за ней тоже.
Внимание, вопросы:
Когда и чем ты заполняешь VARS_TO_SAVE_LOAD?
В какой момент обычно выполняется load_config()?
Что будет, если в VARS_TO_SAVE_LOAD чего-то нет?
>значение по умолчанию. Его не надо загружать.
Перечитай код со скриншота >>6075.
Особое внимание обрати на load_config().
В частности, тебя должна интересовать строчка:
>for var_name: String in VARS_TO_SAVE_LOAD:
И следующая сразу за ней тоже.
Внимание, вопросы:
Когда и чем ты заполняешь VARS_TO_SAVE_LOAD?
В какой момент обычно выполняется load_config()?
Что будет, если в VARS_TO_SAVE_LOAD чего-то нет?
>>6205
Как я могу отменить получение сигнала? Оружие - area2d, сундук - area2d, сундук открывается как только в него входит area2d оружия. Допустим я оружием задетектил сундук, бросаю в него рейкаст от игрока, НО в момент когда я оружием задетектил сундук, сундук уже задетектил оружие и начал открываться.
>>6207
Коллайдер со стенами раньше был - оружие отскакивало от стены и прерывало атаку. В узких коридорах слишком бесяче игралось, я все же не дарк соулс делаю. Поэтому убрал.
Как я могу отменить получение сигнала? Оружие - area2d, сундук - area2d, сундук открывается как только в него входит area2d оружия. Допустим я оружием задетектил сундук, бросаю в него рейкаст от игрока, НО в момент когда я оружием задетектил сундук, сундук уже задетектил оружие и начал открываться.
>>6207
Коллайдер со стенами раньше был - оружие отскакивало от стены и прерывало атаку. В узких коридорах слишком бесяче игралось, я все же не дарк соулс делаю. Поэтому убрал.
>>6209
Ну не открывай сундук пока не получишь не только сигнал, но и подтверждение от рейкаста.
Ну не открывай сундук пока не получишь не только сигнал, но и подтверждение от рейкаста.
>>6200
У тебя тут неточность в логике более высокого порядка, но это не так важно.
Главное что это выглядит как система, которая рано или поздно заполнится всеми переменными, в результате они будут сохраняться даже если не изменялись в процессе игры (в данной сессии), то есть система будет аналогична сохранению всех переменных или всей сцены, только с оверхедом который ни для чего не нужен.
У тебя тут неточность в логике более высокого порядка, но это не так важно.
Главное что это выглядит как система, которая рано или поздно заполнится всеми переменными, в результате они будут сохраняться даже если не изменялись в процессе игры (в данной сессии), то есть система будет аналогична сохранению всех переменных или всей сцены, только с оверхедом который ни для чего не нужен.
>>6212
Слои.
Слои.
>>6212
Да игры вообще непростая штука.
Да игры вообще непростая штука.
>>6209
Зачем? Сундук - это пассивный объект.
1. Вешаешь обработчик Area2D оружия на оружие.
2. В обработчике проверяешь рейкаст.
3. Посылаешь команду объекту.
Area сундука отключи мониторинг совсем.
Слои и маски:
Сундук: слои - "hitbox", маски - нет.
Меч: слои - нет, маски - "hitbox".
Стены: слои - "wall", маски - нет.
Луч: маски - "wall".
Меч игнорит стены, луч ищет стены.
Сундук, стены - ничего не ищут.
Меч ищет хитбоксы.
>сундук уже задетектил оружие
Зачем? Сундук - это пассивный объект.
1. Вешаешь обработчик Area2D оружия на оружие.
2. В обработчике проверяешь рейкаст.
3. Посылаешь команду объекту.
>func on_hurt_box_area_entered(area):
>_ if "hit" in area: # или настрой маски нормально...
>_ _ ray.target_position = area.global_position - ...
>_ _ ray.force_raycast_update()
>_ _ if not ray.is_colliding(): # настрой маски...
>_ _ _ area.hit()
Area сундука отключи мониторинг совсем.
Слои и маски:
Сундук: слои - "hitbox", маски - нет.
Меч: слои - нет, маски - "hitbox".
Стены: слои - "wall", маски - нет.
Луч: маски - "wall".
Меч игнорит стены, луч ищет стены.
Сундук, стены - ничего не ищут.
Меч ищет хитбоксы.
>>6216
Перепутал термины hitbox и hurtbox...
Hitbox - зона удара, например, бейсбольная бита.
Hurtbox - зона получения урона, например, голова.
Но в принципе без разницы, как это всё называть...
Перепутал термины hitbox и hurtbox...
Hitbox - зона удара, например, бейсбольная бита.
Hurtbox - зона получения урона, например, голова.
Но в принципе без разницы, как это всё называть...
>>6204
А может это не баг а фича? Не ставь сундуки и кнопки рядом со стеной чтобы игрок не смог их достать. Или ставь, чтобы смог. Называется левел дизайн.
А может это не баг а фича? Не ставь сундуки и кнопки рядом со стеной чтобы игрок не смог их достать. Или ставь, чтобы смог. Называется левел дизайн.
https://www.reddit.com/r/godot/comments/1hvrbtl/game_scaling_for_my_pixelart_game_explanation_in/
Может кому пригодится, для пиксельарт веба самое то.
Может кому пригодится, для пиксельарт веба самое то.
>>6239
код мультиплеерной кнопки сначала покажи
код мультиплеерной кнопки сначала покажи
Ладно, уговорили, сделал проверку прямой видимости рейкастом. Пришлось кучу старого кода перелопатить. Спасибки.
>>6239
А раньше у тебя сундук проверял, кто или что в него попадает или что пытается с ним сделать? Это путь в запутанный код, где сундук ссылается на никак не связанные сущности в огромном if else if else if else.
У тебя есть событие - нанесение урона. Есть какие-то объекты, способные нанести урон, и те, что способны воспринимать урон. Логика нанесения урона должна принадлежать первой категории объектов, а логика получения урона - второй категории объектов. Общий интерфейс абстрагирует "урон" от любых объектов.
Начнём с принимающих урон. У них есть метод hit(), опционально имеющий какие-то параметры урона, например, там может быть величина урона или его категория - урон огнём должен поджигать объект. Соответственно, объект ждёт вызов метода hit() и обрабатывает поступающие в него аргументы.
Для примера, если нанести 10 очков урона огнём, металлический столб пострадает, но не загорится; громадное дерево выдержит урон, но загорится; а картонная коробка просто вспыхнет и исчезнет. Все перечисленные действия - реализации hit() у разных объектов. Снаружи этих объектов мы не знаем, как поведёт себя объект после вызова этой функции.
Далее, у нас есть разные наносители урона. Это разнообразные объекты, вызывающие hit() у всех принимающих урон объектов. Они знают, как его правильно вызывать, какие аргументы передавать, однако, им без разницы, что произойдёт дальше. У каждого свой набор аргументов, и своя логика, выполняющаяся до обращения к этому методу.
Несколько примеров:
1. Обычный меч вращается и каждый тик проверяет пересечение с объектами, у которых есть метод hit(). Сначала проверяет, может ли он "донянуться", потом проверяет собственную скорость и направление движения, суммирует урон по формуле и передаёт. Раскрученный меч наносит больше урона, чем если легонько ткнуть кончиком неподвожного меча - вот рассчёт этого урона непосредственно у меча.
2. Стрела летит по траектории, пока не столкнётся с препятствием или объектом с методом hit(). А может отскакивать и лететь дальше, или пролететь насквозь. Огненная стрела добавляет в hit() DamageType.FIRE, а ледяная, соответственно, DamageType.ICE. Может рассчитывать урон от собственной скорости.
3. Фаерболл летит как стрела, но при столкновении создаёт большую зону Area2D, перебирает всё, что попалось в неё с методом hit(), вычисляет до них расстояния, оценивает препятствия, и, наконец, последовательно вызывает у них hit() с разными значениями урона. Аналогично с гранатой, но у неё создание зоны поражения будет по таймеру, а вот столкновение с препятствиями даёт только отскок. Закопанная мина работает аналогично, но ждёт пересечения с чем-либо сверху, а не двигается.
4. Молния движется по случайной траектории или пытается найти ближайшую цель с hit() и дальше передаёт значение урона с DamageType.ELECTRIC. Разумеется, для реализма молния должна также проверять токопроводность объекта - но это будет пассивное свойство объекта, а не логика. Логика конкретного объекта просто принимает урон.
5. NPC могут пользоваться тем же оружием, что и персонаж игрока, т.е. код у них общий. А могут иметь уникальные виды атак, как часто бывает у "боссов". Независимо от типа атаки, код NPC ищет цели с реализованным методом hit() и даёт им урон, что он вычислил по каким-то своим формулам. Примут они полученный урон или нет кода NPC не касается.
В общем и целом, дамагеры не знают о том, что они дамажат, но знают, как они должны дамажить. А их жертвы не знают, от кого у них дамаг, но знают, как реагировать на разные категории дамага. Дамаг - абстракция, делающая тех и других независимыми.
Например, нанесение урона огнём по площади:
Не важно, что такое target - в него прилетел огонь.
Получание урона, например, деревом (Буратино):
И т.д. Не важно, от кого прилетело - важно "что".
>Каждому такую проверку вставлять?
А раньше у тебя сундук проверял, кто или что в него попадает или что пытается с ним сделать? Это путь в запутанный код, где сундук ссылается на никак не связанные сущности в огромном if else if else if else.
У тебя есть событие - нанесение урона. Есть какие-то объекты, способные нанести урон, и те, что способны воспринимать урон. Логика нанесения урона должна принадлежать первой категории объектов, а логика получения урона - второй категории объектов. Общий интерфейс абстрагирует "урон" от любых объектов.
Начнём с принимающих урон. У них есть метод hit(), опционально имеющий какие-то параметры урона, например, там может быть величина урона или его категория - урон огнём должен поджигать объект. Соответственно, объект ждёт вызов метода hit() и обрабатывает поступающие в него аргументы.
Для примера, если нанести 10 очков урона огнём, металлический столб пострадает, но не загорится; громадное дерево выдержит урон, но загорится; а картонная коробка просто вспыхнет и исчезнет. Все перечисленные действия - реализации hit() у разных объектов. Снаружи этих объектов мы не знаем, как поведёт себя объект после вызова этой функции.
Далее, у нас есть разные наносители урона. Это разнообразные объекты, вызывающие hit() у всех принимающих урон объектов. Они знают, как его правильно вызывать, какие аргументы передавать, однако, им без разницы, что произойдёт дальше. У каждого свой набор аргументов, и своя логика, выполняющаяся до обращения к этому методу.
Несколько примеров:
1. Обычный меч вращается и каждый тик проверяет пересечение с объектами, у которых есть метод hit(). Сначала проверяет, может ли он "донянуться", потом проверяет собственную скорость и направление движения, суммирует урон по формуле и передаёт. Раскрученный меч наносит больше урона, чем если легонько ткнуть кончиком неподвожного меча - вот рассчёт этого урона непосредственно у меча.
2. Стрела летит по траектории, пока не столкнётся с препятствием или объектом с методом hit(). А может отскакивать и лететь дальше, или пролететь насквозь. Огненная стрела добавляет в hit() DamageType.FIRE, а ледяная, соответственно, DamageType.ICE. Может рассчитывать урон от собственной скорости.
3. Фаерболл летит как стрела, но при столкновении создаёт большую зону Area2D, перебирает всё, что попалось в неё с методом hit(), вычисляет до них расстояния, оценивает препятствия, и, наконец, последовательно вызывает у них hit() с разными значениями урона. Аналогично с гранатой, но у неё создание зоны поражения будет по таймеру, а вот столкновение с препятствиями даёт только отскок. Закопанная мина работает аналогично, но ждёт пересечения с чем-либо сверху, а не двигается.
4. Молния движется по случайной траектории или пытается найти ближайшую цель с hit() и дальше передаёт значение урона с DamageType.ELECTRIC. Разумеется, для реализма молния должна также проверять токопроводность объекта - но это будет пассивное свойство объекта, а не логика. Логика конкретного объекта просто принимает урон.
5. NPC могут пользоваться тем же оружием, что и персонаж игрока, т.е. код у них общий. А могут иметь уникальные виды атак, как часто бывает у "боссов". Независимо от типа атаки, код NPC ищет цели с реализованным методом hit() и даёт им урон, что он вычислил по каким-то своим формулам. Примут они полученный урон или нет кода NPC не касается.
В общем и целом, дамагеры не знают о том, что они дамажат, но знают, как они должны дамажить. А их жертвы не знают, от кого у них дамаг, но знают, как реагировать на разные категории дамага. Дамаг - абстракция, делающая тех и других независимыми.
Например, нанесение урона огнём по площади:
>for target in get_overlapping_areas()
>_ target.hit(distance_to(target), DamageType.FIRE)
Не важно, что такое target - в него прилетел огонь.
Получание урона, например, деревом (Буратино):
>func hit(value: float, damage_type: DamageType):
>match damage_type:
>_ DamageType.NORMAL: # меч, стрела, пуля...
>_ _ health -= value
>_ DamageType.FIRE: # фаерболл, граната...
>_ _ set_on_fire()
>_ _ health -= value
>_ DamageType.ELECTRIC: # молния, шокер...
>_ _ if value > insulation: # пробитие диэлектрика
>_ _ _ health -= value - insulation
>_ _ _ set_on_fire() # дерево -> загорается
>_ _ _ boost_speed() # Буратино -> аж трясёт
>_ DamageType.VOID: # допустим, чёрная дыра
>_ _ queue_free()
И т.д. Не важно, от кого прилетело - важно "что".
>>6239
А раньше у тебя сундук проверял, кто или что в него попадает или что пытается с ним сделать? Это путь в запутанный код, где сундук ссылается на никак не связанные сущности в огромном if else if else if else.
У тебя есть событие - нанесение урона. Есть какие-то объекты, способные нанести урон, и те, что способны воспринимать урон. Логика нанесения урона должна принадлежать первой категории объектов, а логика получения урона - второй категории объектов. Общий интерфейс абстрагирует "урон" от любых объектов.
Начнём с принимающих урон. У них есть метод hit(), опционально имеющий какие-то параметры урона, например, там может быть величина урона или его категория - урон огнём должен поджигать объект. Соответственно, объект ждёт вызов метода hit() и обрабатывает поступающие в него аргументы.
Для примера, если нанести 10 очков урона огнём, металлический столб пострадает, но не загорится; громадное дерево выдержит урон, но загорится; а картонная коробка просто вспыхнет и исчезнет. Все перечисленные действия - реализации hit() у разных объектов. Снаружи этих объектов мы не знаем, как поведёт себя объект после вызова этой функции.
Далее, у нас есть разные наносители урона. Это разнообразные объекты, вызывающие hit() у всех принимающих урон объектов. Они знают, как его правильно вызывать, какие аргументы передавать, однако, им без разницы, что произойдёт дальше. У каждого свой набор аргументов, и своя логика, выполняющаяся до обращения к этому методу.
Несколько примеров:
1. Обычный меч вращается и каждый тик проверяет пересечение с объектами, у которых есть метод hit(). Сначала проверяет, может ли он "донянуться", потом проверяет собственную скорость и направление движения, суммирует урон по формуле и передаёт. Раскрученный меч наносит больше урона, чем если легонько ткнуть кончиком неподвожного меча - вот рассчёт этого урона непосредственно у меча.
2. Стрела летит по траектории, пока не столкнётся с препятствием или объектом с методом hit(). А может отскакивать и лететь дальше, или пролететь насквозь. Огненная стрела добавляет в hit() DamageType.FIRE, а ледяная, соответственно, DamageType.ICE. Может рассчитывать урон от собственной скорости.
3. Фаерболл летит как стрела, но при столкновении создаёт большую зону Area2D, перебирает всё, что попалось в неё с методом hit(), вычисляет до них расстояния, оценивает препятствия, и, наконец, последовательно вызывает у них hit() с разными значениями урона. Аналогично с гранатой, но у неё создание зоны поражения будет по таймеру, а вот столкновение с препятствиями даёт только отскок. Закопанная мина работает аналогично, но ждёт пересечения с чем-либо сверху, а не двигается.
4. Молния движется по случайной траектории или пытается найти ближайшую цель с hit() и дальше передаёт значение урона с DamageType.ELECTRIC. Разумеется, для реализма молния должна также проверять токопроводность объекта - но это будет пассивное свойство объекта, а не логика. Логика конкретного объекта просто принимает урон.
5. NPC могут пользоваться тем же оружием, что и персонаж игрока, т.е. код у них общий. А могут иметь уникальные виды атак, как часто бывает у "боссов". Независимо от типа атаки, код NPC ищет цели с реализованным методом hit() и даёт им урон, что он вычислил по каким-то своим формулам. Примут они полученный урон или нет кода NPC не касается.
В общем и целом, дамагеры не знают о том, что они дамажат, но знают, как они должны дамажить. А их жертвы не знают, от кого у них дамаг, но знают, как реагировать на разные категории дамага. Дамаг - абстракция, делающая тех и других независимыми.
Например, нанесение урона огнём по площади:
Не важно, что такое target - в него прилетел огонь.
Получание урона, например, деревом (Буратино):
И т.д. Не важно, от кого прилетело - важно "что".
>Каждому такую проверку вставлять?
А раньше у тебя сундук проверял, кто или что в него попадает или что пытается с ним сделать? Это путь в запутанный код, где сундук ссылается на никак не связанные сущности в огромном if else if else if else.
У тебя есть событие - нанесение урона. Есть какие-то объекты, способные нанести урон, и те, что способны воспринимать урон. Логика нанесения урона должна принадлежать первой категории объектов, а логика получения урона - второй категории объектов. Общий интерфейс абстрагирует "урон" от любых объектов.
Начнём с принимающих урон. У них есть метод hit(), опционально имеющий какие-то параметры урона, например, там может быть величина урона или его категория - урон огнём должен поджигать объект. Соответственно, объект ждёт вызов метода hit() и обрабатывает поступающие в него аргументы.
Для примера, если нанести 10 очков урона огнём, металлический столб пострадает, но не загорится; громадное дерево выдержит урон, но загорится; а картонная коробка просто вспыхнет и исчезнет. Все перечисленные действия - реализации hit() у разных объектов. Снаружи этих объектов мы не знаем, как поведёт себя объект после вызова этой функции.
Далее, у нас есть разные наносители урона. Это разнообразные объекты, вызывающие hit() у всех принимающих урон объектов. Они знают, как его правильно вызывать, какие аргументы передавать, однако, им без разницы, что произойдёт дальше. У каждого свой набор аргументов, и своя логика, выполняющаяся до обращения к этому методу.
Несколько примеров:
1. Обычный меч вращается и каждый тик проверяет пересечение с объектами, у которых есть метод hit(). Сначала проверяет, может ли он "донянуться", потом проверяет собственную скорость и направление движения, суммирует урон по формуле и передаёт. Раскрученный меч наносит больше урона, чем если легонько ткнуть кончиком неподвожного меча - вот рассчёт этого урона непосредственно у меча.
2. Стрела летит по траектории, пока не столкнётся с препятствием или объектом с методом hit(). А может отскакивать и лететь дальше, или пролететь насквозь. Огненная стрела добавляет в hit() DamageType.FIRE, а ледяная, соответственно, DamageType.ICE. Может рассчитывать урон от собственной скорости.
3. Фаерболл летит как стрела, но при столкновении создаёт большую зону Area2D, перебирает всё, что попалось в неё с методом hit(), вычисляет до них расстояния, оценивает препятствия, и, наконец, последовательно вызывает у них hit() с разными значениями урона. Аналогично с гранатой, но у неё создание зоны поражения будет по таймеру, а вот столкновение с препятствиями даёт только отскок. Закопанная мина работает аналогично, но ждёт пересечения с чем-либо сверху, а не двигается.
4. Молния движется по случайной траектории или пытается найти ближайшую цель с hit() и дальше передаёт значение урона с DamageType.ELECTRIC. Разумеется, для реализма молния должна также проверять токопроводность объекта - но это будет пассивное свойство объекта, а не логика. Логика конкретного объекта просто принимает урон.
5. NPC могут пользоваться тем же оружием, что и персонаж игрока, т.е. код у них общий. А могут иметь уникальные виды атак, как часто бывает у "боссов". Независимо от типа атаки, код NPC ищет цели с реализованным методом hit() и даёт им урон, что он вычислил по каким-то своим формулам. Примут они полученный урон или нет кода NPC не касается.
В общем и целом, дамагеры не знают о том, что они дамажат, но знают, как они должны дамажить. А их жертвы не знают, от кого у них дамаг, но знают, как реагировать на разные категории дамага. Дамаг - абстракция, делающая тех и других независимыми.
Например, нанесение урона огнём по площади:
>for target in get_overlapping_areas()
>_ target.hit(distance_to(target), DamageType.FIRE)
Не важно, что такое target - в него прилетел огонь.
Получание урона, например, деревом (Буратино):
>func hit(value: float, damage_type: DamageType):
>match damage_type:
>_ DamageType.NORMAL: # меч, стрела, пуля...
>_ _ health -= value
>_ DamageType.FIRE: # фаерболл, граната...
>_ _ set_on_fire()
>_ _ health -= value
>_ DamageType.ELECTRIC: # молния, шокер...
>_ _ if value > insulation: # пробитие диэлектрика
>_ _ _ health -= value - insulation
>_ _ _ set_on_fire() # дерево -> загорается
>_ _ _ boost_speed() # Буратино -> аж трясёт
>_ DamageType.VOID: # допустим, чёрная дыра
>_ _ queue_free()
И т.д. Не важно, от кого прилетело - важно "что".
>>6264
Лайк 👍
Лайк 👍
>>6264
Не читал но тоже лайкну.
Не читал но тоже лайкну.
>>6289
При желании придраться всегда есть к чему, ну например, матч по енуму желательно завершать общим шаблоном который принтует в консоль:
>>6264
Таким образом, когда разраб добавит новый тип в свой енум, ему в консоль посыпятся напоминания, где нужно поправить код.
При желании придраться всегда есть к чему, ну например, матч по енуму желательно завершать общим шаблоном который принтует в консоль:
>>6264
> match damage_type:
> - - - _ : print("Unknown damage type. Object: %s" % name)
Таким образом, когда разраб добавит новый тип в свой енум, ему в консоль посыпятся напоминания, где нужно поправить код.
>>6293
Энное количество тредов назад ИТТ сидел анон, заливший свой платформер на яндекс игры в прямом эфире. Так что можно.
Энное количество тредов назад ИТТ сидел анон, заливший свой платформер на яндекс игры в прямом эфире. Так что можно.
>>6295
Однако монетизации он там набрал, если не ошибаюсь, пару копеек.
Однако монетизации он там набрал, если не ошибаюсь, пару копеек.
>>6290
Тогда нужен не обычный print, а
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-method-print-debug
- выводит ссылку на файл и строчку кода;
https://docs.godotengine.org/en/stable/classes/class_%40globalscope.html#class-globalscope-method-push-error
- добавит ошибку в дебаггер со ссылкой на код;
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-method-assert
- остановит выполнение проекта, укажет строчку.
Ещё можно сделать так:
Тогда добавлять нужно только в одно место. Конечно, придётся перепроверить, что новый тип урона хорошо соответствует всем объектам - т.е. им не требуется перезаписывать поведение по умолчанию.
Также было бы неплохо сделать класс урона:
Чтобы не исправлять заголовок функции:
Когда захочется добавить новый параметр урона.
Тогда нанесение урона будет примерно таким:
Или можно передать один урон многим целям:
- что-то типа коктейля Молотова.
В идеале для этого нужен "struct"/"record"-тип, но в GDScript такого пока нет (обсуждают), а Dictionary не способен помочь в данном случае (нет подсказок). Создание нового RefCounted не так уж затратно, несколько десятков каждый кадр - допустимо; для "буллетхелла" такой способ, конечно, не подходит.
>напоминания, где нужно поправить код
Тогда нужен не обычный print, а
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-method-print-debug
- выводит ссылку на файл и строчку кода;
https://docs.godotengine.org/en/stable/classes/class_%40globalscope.html#class-globalscope-method-push-error
- добавит ошибку в дебаггер со ссылкой на код;
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-method-assert
- остановит выполнение проекта, укажет строчку.
Ещё можно сделать так:
>class_name HurtBox extends Area2D
>signal damaged()
>@export var health: Health
>func hit(...): ...
>class_name HurtBoxWood extends HurtBox
>func hit(...):
>_ match type:
>_ _ FIRE: ... return
>_ _ ELECTRIC: ... return
>_ super(...) # урон по умолчанию
Тогда добавлять нужно только в одно место. Конечно, придётся перепроверить, что новый тип урона хорошо соответствует всем объектам - т.е. им не требуется перезаписывать поведение по умолчанию.
Также было бы неплохо сделать класс урона:
>class_name Damage extends RefCounted
>enum Type { NORMAL, FIRE, ICE, ELECTRIC, ... }
>var type: Type
>var amount: float
>var direction: Vector2
>... # и т.д.
>func _init(_amount: float, _type := Type.NORMAL, ...):
Чтобы не исправлять заголовок функции:
>func hit(damage: Damage) -> void:
Когда захочется добавить новый параметр урона.
Тогда нанесение урона будет примерно таким:
>target.hit(Damage.new(5, Damage.Type.FIRE))
Или можно передать один урон многим целям:
>var damage := Damage.new(5, Damage.Type.FIRE)
>for target in targets: target.hit(damage)
- что-то типа коктейля Молотова.
В идеале для этого нужен "struct"/"record"-тип, но в GDScript такого пока нет (обсуждают), а Dictionary не способен помочь в данном случае (нет подсказок). Создание нового RefCounted не так уж затратно, несколько десятков каждый кадр - допустимо; для "буллетхелла" такой способ, конечно, не подходит.
>>6290
Тогда нужен не обычный print, а
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-method-print-debug
- выводит ссылку на файл и строчку кода;
https://docs.godotengine.org/en/stable/classes/class_%40globalscope.html#class-globalscope-method-push-error
- добавит ошибку в дебаггер со ссылкой на код;
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-method-assert
- остановит выполнение проекта, укажет строчку.
Ещё можно сделать так:
Тогда добавлять нужно только в одно место. Конечно, придётся перепроверить, что новый тип урона хорошо соответствует всем объектам - т.е. им не требуется перезаписывать поведение по умолчанию.
Также было бы неплохо сделать класс урона:
Чтобы не исправлять заголовок функции:
Когда захочется добавить новый параметр урона.
Тогда нанесение урона будет примерно таким:
Или можно передать один урон многим целям:
- что-то типа коктейля Молотова.
В идеале для этого нужен "struct"/"record"-тип, но в GDScript такого пока нет (обсуждают), а Dictionary не способен помочь в данном случае (нет подсказок). Создание нового RefCounted не так уж затратно, несколько десятков каждый кадр - допустимо; для "буллетхелла" такой способ, конечно, не подходит.
>напоминания, где нужно поправить код
Тогда нужен не обычный print, а
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-method-print-debug
- выводит ссылку на файл и строчку кода;
https://docs.godotengine.org/en/stable/classes/class_%40globalscope.html#class-globalscope-method-push-error
- добавит ошибку в дебаггер со ссылкой на код;
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-method-assert
- остановит выполнение проекта, укажет строчку.
Ещё можно сделать так:
>class_name HurtBox extends Area2D
>signal damaged()
>@export var health: Health
>func hit(...): ...
>class_name HurtBoxWood extends HurtBox
>func hit(...):
>_ match type:
>_ _ FIRE: ... return
>_ _ ELECTRIC: ... return
>_ super(...) # урон по умолчанию
Тогда добавлять нужно только в одно место. Конечно, придётся перепроверить, что новый тип урона хорошо соответствует всем объектам - т.е. им не требуется перезаписывать поведение по умолчанию.
Также было бы неплохо сделать класс урона:
>class_name Damage extends RefCounted
>enum Type { NORMAL, FIRE, ICE, ELECTRIC, ... }
>var type: Type
>var amount: float
>var direction: Vector2
>... # и т.д.
>func _init(_amount: float, _type := Type.NORMAL, ...):
Чтобы не исправлять заголовок функции:
>func hit(damage: Damage) -> void:
Когда захочется добавить новый параметр урона.
Тогда нанесение урона будет примерно таким:
>target.hit(Damage.new(5, Damage.Type.FIRE))
Или можно передать один урон многим целям:
>var damage := Damage.new(5, Damage.Type.FIRE)
>for target in targets: target.hit(damage)
- что-то типа коктейля Молотова.
В идеале для этого нужен "struct"/"record"-тип, но в GDScript такого пока нет (обсуждают), а Dictionary не способен помочь в данном случае (нет подсказок). Создание нового RefCounted не так уж затратно, несколько десятков каждый кадр - допустимо; для "буллетхелла" такой способ, конечно, не подходит.
Только что узнал что чекбокс local_coords у партиклей заставляет их игнорить не только позицию родителя, но и скалирование. Кайф.
Про звук. Насколько важно чтобы все файлы были одного формата/битрейта? Если я тупо натаскаю с фрисаунда различных файлов, какие подводные вылезут? Сомневаюсь что кто-то на слух отличит что карканье вороны в два раза ниже качеством чем хлопанье дверью.
>>6301
Наверное это потому, что внутри нет позиции и скейла, а только единая матрица трансформа.
Наверное это потому, что внутри нет позиции и скейла, а только единая матрица трансформа.
>>6383
Пару лет назад столкнулся с такой темой.
Нужно было около 50 эффектов для звуков, и десяток мелодий.
Много что попиздил с инета, и камень предкновения стала нормализация звука для одной волной частоты.
Короче, у каждого файла звукового есть минимальная и максимальная частота диапозона и в игре это работает так - игрок поставил 10% звук стал тише, а поставил 50% громче, но из-за различия диапозонов в файлах на одни 10% пиздец как громко, а на других 50% тихо.
Решилось трабла очень просто, скачал Audacity и каждому файлу поправил диапозон, и получилась конфетка. Из подводных только может быть небольшая ебля если в системе нету библиотек для экспорта в mp3, нужно вручную будет наворачивать.
Пару лет назад столкнулся с такой темой.
Нужно было около 50 эффектов для звуков, и десяток мелодий.
Много что попиздил с инета, и камень предкновения стала нормализация звука для одной волной частоты.
Короче, у каждого файла звукового есть минимальная и максимальная частота диапозона и в игре это работает так - игрок поставил 10% звук стал тише, а поставил 50% громче, но из-за различия диапозонов в файлах на одни 10% пиздец как громко, а на других 50% тихо.
Решилось трабла очень просто, скачал Audacity и каждому файлу поправил диапозон, и получилась конфетка. Из подводных только может быть небольшая ебля если в системе нету библиотек для экспорта в mp3, нужно вручную будет наворачивать.
>>6394
Можно ffmpeg -i input.mp3 -filter:a "volume=0.5" output.mp3
Можно ffmpeg -i input.mp3 -filter:a "volume=0.5" output.mp3
>>6297
Хм, а что если их в пул закатать?
> Создание нового RefCounted не так уж затратно, несколько десятков каждый кадр - допустимо; для "буллетхелла" такой способ, конечно, не подходит.
Хм, а что если их в пул закатать?
>>6394
Разве это не решается ползунком volumne_db на AudioStreamPlayer ноде?
>игрок поставил 10% звук стал тише, а поставил 50% громче, но из-за различия диапозонов в файлах на одни 10% пиздец как громко, а на других 50% тихо.
Разве это не решается ползунком volumne_db на AudioStreamPlayer ноде?
Гугловский гемини 2.5 мой новый лучший друг для гдскрипта. Держу в курсе, скринов как всегда не даю.
22 Кб, 530x260>>6560
Это онлайн API, разве оно доступно?
Или ты из Канады своей капчуешь?
Как используешь? Тупо ctrl+c/ctrl+v?
Капча на дваче что-то знает...
>Гугловский гемини
Это онлайн API, разве оно доступно?
Или ты из Канады своей капчуешь?
>скринов как всегда не даю
Как используешь? Тупо ctrl+c/ctrl+v?
Капча на дваче что-то знает...
31 Кб, 372x401>>6567
gemini.google.com, сверху-слева выбираешь 2.5 pro, нужен гугловский аккаунт и впн, плотить не надо. https:// не забудь, а www. не надо
Еще на aistudio.google.com доступно вместе с другими более экспериментальными моделями.
Да, разговариваю с ней в чатике и копипащу туда-сюда.
gemini.google.com, сверху-слева выбираешь 2.5 pro, нужен гугловский аккаунт и впн, плотить не надо. https:// не забудь, а www. не надо
Еще на aistudio.google.com доступно вместе с другими более экспериментальными моделями.
Да, разговариваю с ней в чатике и копипащу туда-сюда.
>>6588
Ну и зачем оно в таком виде нужно, ты маркетолог?
И как, сразу получается, или что-то в стиле:
...и так до бесконечности?
Имхо, вручную быстрее, чем мучиться с нейронкой...
>аккаунт и впн
Ну и зачем оно в таком виде нужно, ты маркетолог?
>копипащу туда-сюда
И как, сразу получается, или что-то в стиле:
>реши задачу такую-то...
>вот код: ... (ctrl+c/ctrl+v)
>ой, мне выдаёт ошибку бла-бла-бла, что это?
>извините, вот код: ... (ctrl+c/ctrl+v)
>ой, мне выдаёт ошибку бла-бла-бла, что это?
>извините, вот код: ... (ctrl+c/ctrl+v)
>ой, мне выдаёт ошибку бла-бла-бла, что это?
>извините, вот код: ... (ctrl+c/ctrl+v)
>ой, мне выдаёт ошибку бла-бла-бла, что это?
...и так до бесконечности?
Имхо, вручную быстрее, чем мучиться с нейронкой...
Я пробовал написать нейронкой компьют шейдер. Простой получилось с 1,5 попытки (там была опечатка в 1 скобке). А вот более сложный - с нескольких попыток не заработал. Хотя я рабочие примеры скармливал. А сам я пока не разобрался в теме чтобы понять что не так.
>>6635
Быстрее чем делать вручную, быстрее чем выискивать примеры и копаться в документации, быстрее чем спрашивать в ИТТ. Впрочем, мне некогда тебя убеждать, я слишком ускорен.
Быстрее чем делать вручную, быстрее чем выискивать примеры и копаться в документации, быстрее чем спрашивать в ИТТ. Впрочем, мне некогда тебя убеждать, я слишком ускорен.
Если кваду выключить cull_mode то он будет отображаться с двух сторон. А я делал кубы толщиной 0.001. Такие дела.
>>6666
И ты теперь знаешь.
И ты теперь знаешь.
Немного оффтоп, но кто-нибудь знает бесплатную опенсурс IDE для Python, которая была бы как Godot Editor, только вместо GDScript там были бы подсказки из модулей Python? А то сейчас пытаюсь изучать PyTorch (для нейронок, которые, если получатся, попробую подключить в Godot), но редактор "IDLE" хуже Блокнота Windows... Такой позор, неужели разработчики Python ниасилили свой редактор запилить? У них что, денег меньше, чем у Godot? Какой же всё-таки Godot крутой... VSCode не предлагать - уже пробовал и удалил, совсем не похоже на Godot.
>>6665
Зачем? Один квад обычно используется для отображения билбордов/партиклей, а билборды/партикли всегда смотрят в камеру - сзади ты их никак увидеть в игре не можешь. Если у тебя физическая табличка, зафиксированная в пространстве (как, например, в Minecraft), то лучше кубик растянуть - так освещение будет нормальным и она не будет "исчезать", когда смотришь на неё строго сбоку/сверху/снизу.
Для билбордов квад вручную создавать не надо - есть специальные ноды:
https://docs.godotengine.org/en/stable/classes/class_spritebase3d.html
https://docs.godotengine.org/en/stable/classes/class_label3d.html
>>6665
>кваду отображаться с двух сторон
Зачем? Один квад обычно используется для отображения билбордов/партиклей, а билборды/партикли всегда смотрят в камеру - сзади ты их никак увидеть в игре не можешь. Если у тебя физическая табличка, зафиксированная в пространстве (как, например, в Minecraft), то лучше кубик растянуть - так освещение будет нормальным и она не будет "исчезать", когда смотришь на неё строго сбоку/сверху/снизу.
Для билбордов квад вручную создавать не надо - есть специальные ноды:
https://docs.godotengine.org/en/stable/classes/class_spritebase3d.html
https://docs.godotengine.org/en/stable/classes/class_label3d.html
90 Кб, 1024x724>>6673
Видел, но там всё сложно с лицензиями...
Скачал Spyder (лицензия MIT), но пока не пробовал.
Настроил вот Kate Editor, достаточно удобно для начала.
Если б Tyson Tan не нарисовал, я б даже не узнал про неё.
>>6674
Ты его вручную как меш деформируешь? Или через систему частиц?
https://docs.godotengine.org/en/stable/tutorials/3d/particles/trails.html
Так и не понял, для чего их можно использовать кроме "фонтанчика"...
>Pycharm
Видел, но там всё сложно с лицензиями...
Скачал Spyder (лицензия MIT), но пока не пробовал.
Настроил вот Kate Editor, достаточно удобно для начала.
Если б Tyson Tan не нарисовал, я б даже не узнал про неё.
>>6674
>Шлейф делал, плоский.
Ты его вручную как меш деформируешь? Или через систему частиц?
https://docs.godotengine.org/en/stable/tutorials/3d/particles/trails.html
Так и не понял, для чего их можно использовать кроме "фонтанчика"...
>>6672
В смысле "не похож"? Ну и вообще расширяется аддонами.
>VSCode не предлагать - уже пробовал и удалил, совсем не похоже на Godot.
В смысле "не похож"? Ну и вообще расширяется аддонами.
Опять UV ебаные уехали, опять переделывать. Вот куда надо нейронки вставлять надо - в разметку UV. И прямо плагином в годот.
>>6680
Я когда-то в гедите учился программировать, для него тогда удивительно много плагинов было. Потом на Geany перешел, тоже рекомендую. А потом пошло-поехало.
>>6680
>Kate
Я когда-то в гедите учился программировать, для него тогда удивительно много плагинов было. Потом на Geany перешел, тоже рекомендую. А потом пошло-поехало.
>>6707
Можно ведь в материале сдвинуть/масштабировать. Редактирование меша (тем более добавление новых вершин) должно быть до создания UV-развёртки.
Думаю, тут всё зависит от твоей задачи. У UV много возможных применений в современных шейдерах, поэтому вряд ли "нейронка" угадает твоё желание.
>>6686 >>6694
Дело не в шрифте и не в автодополнении...
>>6534
Вообще, план был таким:
I. Лепим простую нейронку по слоям, например:
0) Входной слой - непрерывный поток сигналов. Его содержимое не так важно, как стабильность потока (относительно циклов обновления всей нейронки).
1) Разреженные случайные слои, которые никак не обучаются. Нужны для повышения размерности - из плотного облака получается много удалённых точек.
2) Слои с обучением без учителя по правилу Хебба. В теории, стягивают изначально близкие точки так, что образуются группы. Регуляризация оставляет ~1% активных нейронов, чтобы остальные не обучались.
3.а) Предобученные с учителем слои, которые могут классифицировать ввод как "хорошо" и "плохо". Они используются только для дообучения слоёв 3.б. Не обучаются сами по себе (тут ещё нужно подумать).
3.б) Слои, обучающиеся с подкреплением (RL). Тут регуляризация как в 2 или ещё жёстче, пока не знаю. Смысл в том, чтобы линейно соединить слои 2 и 4. Их дообучение должно быть с задержкой по времени...
4) Случайные слои без обучения и/или по Хеббу, подключаются напрямую к 3.б. Их смысл в том, чтоб превратить простую активацию в сложный паттерн. Теоретически, могут заучивать частые паттерны, но рандомной активации может оказаться достаточно.
5) Выходной слой даёт абстрактный вектор, значение которого зависит от определения конкретного агента.
II. Вставляем эту простую нейронку в игру на Godot и смотрим на поведение. Потом можно добавить слои, иерархию, память/рекуррентность - посмотрим по результатам экспериментов, если заработает...
Пока что ничего из этого не сделал, только пытаюсь разобраться, что мне вообще для этого всего нужно. Наверное, нужно всё-таки GUI-морду на Godot сразу сделать, поднять TCP/IP связь с бэкендом на Python и дальше уже разбираться, что тыкать в API PyTorch? Потому что "вслепую" через командную строку я это тестировать точно не хочу, и морда в любом случае потребуется рано или поздно. И через TCP/IP смогу заменить бэкенд в будущем на что захочется.
Как вам такая идея? Какие подводные?
>UV уехали
Можно ведь в материале сдвинуть/масштабировать. Редактирование меша (тем более добавление новых вершин) должно быть до создания UV-развёртки.
>нейронки вставлять в разметку UV
Думаю, тут всё зависит от твоей задачи. У UV много возможных применений в современных шейдерах, поэтому вряд ли "нейронка" угадает твоё желание.
>>6686 >>6694
>шревты из годота подтянуть
Дело не в шрифте и не в автодополнении...
>>6534
>Чтобы потом делать ими игры, верно?
Вообще, план был таким:
I. Лепим простую нейронку по слоям, например:
0) Входной слой - непрерывный поток сигналов. Его содержимое не так важно, как стабильность потока (относительно циклов обновления всей нейронки).
1) Разреженные случайные слои, которые никак не обучаются. Нужны для повышения размерности - из плотного облака получается много удалённых точек.
2) Слои с обучением без учителя по правилу Хебба. В теории, стягивают изначально близкие точки так, что образуются группы. Регуляризация оставляет ~1% активных нейронов, чтобы остальные не обучались.
3.а) Предобученные с учителем слои, которые могут классифицировать ввод как "хорошо" и "плохо". Они используются только для дообучения слоёв 3.б. Не обучаются сами по себе (тут ещё нужно подумать).
3.б) Слои, обучающиеся с подкреплением (RL). Тут регуляризация как в 2 или ещё жёстче, пока не знаю. Смысл в том, чтобы линейно соединить слои 2 и 4. Их дообучение должно быть с задержкой по времени...
4) Случайные слои без обучения и/или по Хеббу, подключаются напрямую к 3.б. Их смысл в том, чтоб превратить простую активацию в сложный паттерн. Теоретически, могут заучивать частые паттерны, но рандомной активации может оказаться достаточно.
5) Выходной слой даёт абстрактный вектор, значение которого зависит от определения конкретного агента.
II. Вставляем эту простую нейронку в игру на Godot и смотрим на поведение. Потом можно добавить слои, иерархию, память/рекуррентность - посмотрим по результатам экспериментов, если заработает...
Пока что ничего из этого не сделал, только пытаюсь разобраться, что мне вообще для этого всего нужно. Наверное, нужно всё-таки GUI-морду на Godot сразу сделать, поднять TCP/IP связь с бэкендом на Python и дальше уже разбираться, что тыкать в API PyTorch? Потому что "вслепую" через командную строку я это тестировать точно не хочу, и морда в любом случае потребуется рано или поздно. И через TCP/IP смогу заменить бэкенд в будущем на что захочется.
Как вам такая идея? Какие подводные?
>>6707
Можно ведь в материале сдвинуть/масштабировать. Редактирование меша (тем более добавление новых вершин) должно быть до создания UV-развёртки.
Думаю, тут всё зависит от твоей задачи. У UV много возможных применений в современных шейдерах, поэтому вряд ли "нейронка" угадает твоё желание.
>>6686 >>6694
Дело не в шрифте и не в автодополнении...
>>6534
Вообще, план был таким:
I. Лепим простую нейронку по слоям, например:
0) Входной слой - непрерывный поток сигналов. Его содержимое не так важно, как стабильность потока (относительно циклов обновления всей нейронки).
1) Разреженные случайные слои, которые никак не обучаются. Нужны для повышения размерности - из плотного облака получается много удалённых точек.
2) Слои с обучением без учителя по правилу Хебба. В теории, стягивают изначально близкие точки так, что образуются группы. Регуляризация оставляет ~1% активных нейронов, чтобы остальные не обучались.
3.а) Предобученные с учителем слои, которые могут классифицировать ввод как "хорошо" и "плохо". Они используются только для дообучения слоёв 3.б. Не обучаются сами по себе (тут ещё нужно подумать).
3.б) Слои, обучающиеся с подкреплением (RL). Тут регуляризация как в 2 или ещё жёстче, пока не знаю. Смысл в том, чтобы линейно соединить слои 2 и 4. Их дообучение должно быть с задержкой по времени...
4) Случайные слои без обучения и/или по Хеббу, подключаются напрямую к 3.б. Их смысл в том, чтоб превратить простую активацию в сложный паттерн. Теоретически, могут заучивать частые паттерны, но рандомной активации может оказаться достаточно.
5) Выходной слой даёт абстрактный вектор, значение которого зависит от определения конкретного агента.
II. Вставляем эту простую нейронку в игру на Godot и смотрим на поведение. Потом можно добавить слои, иерархию, память/рекуррентность - посмотрим по результатам экспериментов, если заработает...
Пока что ничего из этого не сделал, только пытаюсь разобраться, что мне вообще для этого всего нужно. Наверное, нужно всё-таки GUI-морду на Godot сразу сделать, поднять TCP/IP связь с бэкендом на Python и дальше уже разбираться, что тыкать в API PyTorch? Потому что "вслепую" через командную строку я это тестировать точно не хочу, и морда в любом случае потребуется рано или поздно. И через TCP/IP смогу заменить бэкенд в будущем на что захочется.
Как вам такая идея? Какие подводные?
>UV уехали
Можно ведь в материале сдвинуть/масштабировать. Редактирование меша (тем более добавление новых вершин) должно быть до создания UV-развёртки.
>нейронки вставлять в разметку UV
Думаю, тут всё зависит от твоей задачи. У UV много возможных применений в современных шейдерах, поэтому вряд ли "нейронка" угадает твоё желание.
>>6686 >>6694
>шревты из годота подтянуть
Дело не в шрифте и не в автодополнении...
>>6534
>Чтобы потом делать ими игры, верно?
Вообще, план был таким:
I. Лепим простую нейронку по слоям, например:
0) Входной слой - непрерывный поток сигналов. Его содержимое не так важно, как стабильность потока (относительно циклов обновления всей нейронки).
1) Разреженные случайные слои, которые никак не обучаются. Нужны для повышения размерности - из плотного облака получается много удалённых точек.
2) Слои с обучением без учителя по правилу Хебба. В теории, стягивают изначально близкие точки так, что образуются группы. Регуляризация оставляет ~1% активных нейронов, чтобы остальные не обучались.
3.а) Предобученные с учителем слои, которые могут классифицировать ввод как "хорошо" и "плохо". Они используются только для дообучения слоёв 3.б. Не обучаются сами по себе (тут ещё нужно подумать).
3.б) Слои, обучающиеся с подкреплением (RL). Тут регуляризация как в 2 или ещё жёстче, пока не знаю. Смысл в том, чтобы линейно соединить слои 2 и 4. Их дообучение должно быть с задержкой по времени...
4) Случайные слои без обучения и/или по Хеббу, подключаются напрямую к 3.б. Их смысл в том, чтоб превратить простую активацию в сложный паттерн. Теоретически, могут заучивать частые паттерны, но рандомной активации может оказаться достаточно.
5) Выходной слой даёт абстрактный вектор, значение которого зависит от определения конкретного агента.
II. Вставляем эту простую нейронку в игру на Godot и смотрим на поведение. Потом можно добавить слои, иерархию, память/рекуррентность - посмотрим по результатам экспериментов, если заработает...
Пока что ничего из этого не сделал, только пытаюсь разобраться, что мне вообще для этого всего нужно. Наверное, нужно всё-таки GUI-морду на Godot сразу сделать, поднять TCP/IP связь с бэкендом на Python и дальше уже разбираться, что тыкать в API PyTorch? Потому что "вслепую" через командную строку я это тестировать точно не хочу, и морда в любом случае потребуется рано или поздно. И через TCP/IP смогу заменить бэкенд в будущем на что захочется.
Как вам такая идея? Какие подводные?
>>6715
Ну так ты напиши, в чем тогда дело.
Ну так ты напиши, в чем тогда дело.
884 Кб, 1376x842Делайте игры
Вы наверное слышали про популярную новую игру, Nomad Idle
А тут узнаю что какой то Мохаммед просто взял украл ее у автора и выложил на iOS. И 2 месяца уже не удаляют.
https://www.reddit.com/r/godot/comments/1irnr0g/my_godot_game_demo_has_been_uploaded_to_ios_im/
Проект легко восстановить из файлов самой игры и пересобрать...
Все таки ИМХО если планируешь популярную игру, лучше делать на C++, это хотя бы отсеит таких воришек которые берут по верхам...
А тут узнаю что какой то Мохаммед просто взял украл ее у автора и выложил на iOS. И 2 месяца уже не удаляют.
https://www.reddit.com/r/godot/comments/1irnr0g/my_godot_game_demo_has_been_uploaded_to_ios_im/
Проект легко восстановить из файлов самой игры и пересобрать...
Все таки ИМХО если планируешь популярную игру, лучше делать на C++, это хотя бы отсеит таких воришек которые берут по верхам...
>>6775
Есть истории похлеще. Раньше находились тролли, которые регистрировали права на твою игру (например в США) и потом шантажировали тебя. Типа либо ты отдаёшь 50% с дохода, либо мы отправляем страйк и твою игру удаляют нахуй.
Есть истории похлеще. Раньше находились тролли, которые регистрировали права на твою игру (например в США) и потом шантажировали тебя. Типа либо ты отдаёшь 50% с дохода, либо мы отправляем страйк и твою игру удаляют нахуй.
>>6775
Зато представь какой сильный пиар-ход - везде пожалуешься, везде посочувствуют, везде посмотрят на твою игру. Я бы ради такого сам у себя украл.
Заебешься. Лучше так: https://docs.godotengine.org/en/stable/contributing/development/compiling/compiling_with_script_encryption_key.html
Зато представь какой сильный пиар-ход - везде пожалуешься, везде посочувствуют, везде посмотрят на твою игру. Я бы ради такого сам у себя украл.
>на С++
Заебешься. Лучше так: https://docs.godotengine.org/en/stable/contributing/development/compiling/compiling_with_script_encryption_key.html
>>6794
Это не самая сильная защита, подумай сам. Чтобы игра запустилась, скрипты должны быть расшифрованы. Чтобы быть расшифрованы, ключ должен быть записан в самом экзешнике. И правда, на гитхабе есть какой то устаревший код который ищет кусок функции, загружающей ключ.
Да, кстати, при этом методе шаблоны движка надо перекомпилировать. Так что там и до с++ недалеко.
Это не самая сильная защита, подумай сам. Чтобы игра запустилась, скрипты должны быть расшифрованы. Чтобы быть расшифрованы, ключ должен быть записан в самом экзешнике. И правда, на гитхабе есть какой то устаревший код который ищет кусок функции, загружающей ключ.
Да, кстати, при этом методе шаблоны движка надо перекомпилировать. Так что там и до с++ недалеко.
Уже несколько дней пытаюсь прикрутить имакс к LSP гадоу. Вроде как заработало наконец, пришлось только с lsp-mode на eglot найс название перейти. Еще чтоб сниппеты подгрузились приходится ctrl+s на сценке нажимать, что немного непривычно.
Знает кто-нибудь как к имаксу прикрутить перетаскивание ноды? Чтоб она сразу в @onready превращалась. Есть готовые решения?
Знает кто-нибудь как к имаксу прикрутить перетаскивание ноды? Чтоб она сразу в @onready превращалась. Есть готовые решения?
>>6796
Никакая защита не идеальная, поэтому любые денувы-хуювы взламывают на раз-два. Вопрос в нахождении баланса между замедлением своей разработки и защитой финального продукта. Меня бы плюсы замедлили раза в 3 как минимум.
Никакая защита не идеальная, поэтому любые денувы-хуювы взламывают на раз-два. Вопрос в нахождении баланса между замедлением своей разработки и защитой финального продукта. Меня бы плюсы замедлили раза в 3 как минимум.
>>6807
Не ломают денувы и тем более на раз два. Есть всего несколько случаев когда разрабы забыли его включить или убрать дебаг.
Так а мы куда то торопимся? Игру мечты можно делать годами. Все равно бОльшую часть времени просто не делаешь игру. Кроме того ты не учел что со временем ты натренируешься в крестах и скорость вырастет, это только поначалу долго.
Не ломают денувы и тем более на раз два. Есть всего несколько случаев когда разрабы забыли его включить или убрать дебаг.
Так а мы куда то торопимся? Игру мечты можно делать годами. Все равно бОльшую часть времени просто не делаешь игру. Кроме того ты не учел что со временем ты натренируешься в крестах и скорость вырастет, это только поначалу долго.
>>6810
Загуглишь сам, если не лень. Взломов больше чем невзломов.
>Не ломают денувы и тем более на раз два
Загуглишь сам, если не лень. Взломов больше чем невзломов.
>>6810
У меня игр мечты штук 20, а жизнь одна, и сейчас бы всю жизнь пердолить одну игру на плюсах.
У меня игр мечты штук 20, а жизнь одна, и сейчас бы всю жизнь пердолить одну игру на плюсах.
>>6848
Так и я к тому же... Какая разница сколько игр мечты не сделать. Простая арифметика - раз ты мог бы сделать всего 1 игру на крестах, а на гдскрипте ты пишешь в 3 раза быстрее, то за жизнь ты успел бы все равно только 3 из 30...
Так и я к тому же... Какая разница сколько игр мечты не сделать. Простая арифметика - раз ты мог бы сделать всего 1 игру на крестах, а на гдскрипте ты пишешь в 3 раза быстрее, то за жизнь ты успел бы все равно только 3 из 30...
>>6888
Это не так работает. Это как бы ты идешь пешком и получаешь удовольствие от самой ходьбы. Поэтому не так важно пройдешь ты 3км или 1км, ты же все время шел. Чуть чуть больше будет удовлетворение потому что ты достиг цели, но это в пропорции к проведенным минутам будет может быть 0,001%, а не 3000%.
Это не так работает. Это как бы ты идешь пешком и получаешь удовольствие от самой ходьбы. Поэтому не так важно пройдешь ты 3км или 1км, ты же все время шел. Чуть чуть больше будет удовлетворение потому что ты достиг цели, но это в пропорции к проведенным минутам будет может быть 0,001%, а не 3000%.
>>6891
Именно так и работает, поэтому скоро выкладываю четвертую игру в демку. А про то, что у тебя иначе работает - ну хз, к мозгоправу сходи, таблеточки попей, потрогай траву.
Именно так и работает, поэтому скоро выкладываю четвертую игру в демку. А про то, что у тебя иначе работает - ну хз, к мозгоправу сходи, таблеточки попей, потрогай траву.
>>6898
Так нет разницы. Например в один год ты делаешь 4 месяца 4 демки, а в другой 4 месяца 1 большую демку - но смысл одинаковый, ты делаешь 4 месяца и в эти 4 месяца получаешь некий постоянный уровень удовольствия. А сам момент выкладывания он слишком кратковременный, потому что даже если там разовое удовольствие большое (но оно ограничено физиологией), то в перемножении на время получения все равно его меньше чем суммарное постоянное фоновое удовольствие.
Одна большая вспышка огня не погреет тебя так же хорошо как греет небольшой камин в течении 4 месяцев.
Ты не напьешься одним глотком озера так же хорошо как бутылочками воды каждый день.
Хех, похоже это тебе стоит заглянуть к врачу.
Так нет разницы. Например в один год ты делаешь 4 месяца 4 демки, а в другой 4 месяца 1 большую демку - но смысл одинаковый, ты делаешь 4 месяца и в эти 4 месяца получаешь некий постоянный уровень удовольствия. А сам момент выкладывания он слишком кратковременный, потому что даже если там разовое удовольствие большое (но оно ограничено физиологией), то в перемножении на время получения все равно его меньше чем суммарное постоянное фоновое удовольствие.
Одна большая вспышка огня не погреет тебя так же хорошо как греет небольшой камин в течении 4 месяцев.
Ты не напьешься одним глотком озера так же хорошо как бутылочками воды каждый день.
Хех, похоже это тебе стоит заглянуть к врачу.
>>6901
Чего? Ну нет, я спустя годы читаю отзывы к своим старым играм. Их все еще пишут, а в игры все еще играют. Особый кайф найти чей-нибудь свежий летсплей на ютубе, и смотреть как чел фейсом реагирует на крошечную деталь, над которой я работал годы назад.
Используя твою аналогию - это не озеро и не бутылочка, это река. Такие дела.
А непосредственно _выкладывание_ наоборот, геморная суета, бесконечные метаданные, баннеры, описания, скриншоты разных форматов, перерезать-пережимать их под разные площадки. Будто вилкой сортир чистишь. Вот то, что идет после выкладывания - вот в этом суть.
>А сам момент выкладывания он слишком кратковременный
Чего? Ну нет, я спустя годы читаю отзывы к своим старым играм. Их все еще пишут, а в игры все еще играют. Особый кайф найти чей-нибудь свежий летсплей на ютубе, и смотреть как чел фейсом реагирует на крошечную деталь, над которой я работал годы назад.
Используя твою аналогию - это не озеро и не бутылочка, это река. Такие дела.
А непосредственно _выкладывание_ наоборот, геморная суета, бесконечные метаданные, баннеры, описания, скриншоты разных форматов, перерезать-пережимать их под разные площадки. Будто вилкой сортир чистишь. Вот то, что идет после выкладывания - вот в этом суть.
4 Мб, 1920x1080В плане саунд дизайна - куда лучше идти, в 8битный звук или в реализм, если визуальный дизайн - лоуполи 3д?
Скрин не мой, пощу для передачи стиля.
Скрин не мой, пощу для передачи стиля.
>>6919
В 16-битный. Ну или реалистик саунд зашакалить до 8бит/11кГц. Или в стиле хипстерского инди из начала десятых: укулеле и Casio VL-1.
В 16-битный. Ну или реалистик саунд зашакалить до 8бит/11кГц. Или в стиле хипстерского инди из начала десятых: укулеле и Casio VL-1.
755 Кб, 979x745Заебался неделать action игры, слишком сложно. надо браться за пошаг
Очередная игра, за которой я следил, продалась примерно никак, не смотря на периодический пиар на главной и в соцсетях годота. 3 года разработки.
Гайз, подскажите пожалуйста, с гугл плей сечас реально вывести деньги будучи гражданином РФ? Мне нравится годотя, я перодически делаю игру, но хотелось бы уверенности в завтрашнем дне так сказать
>>6987
По-моему они нагло спиздили визуальный стиль у какой-то игры. Я точно подобное уже видел.
По-моему они нагло спиздили визуальный стиль у какой-то игры. Я точно подобное уже видел.
>>6987
Игроки даже не знают, что такое годот, не говоря уже о каких-то его соцсетях. Да им этого и не надо знать. То есть, в целом очень странно пиарить игру в таких местах.
Игроки даже не знают, что такое годот, не говоря уже о каких-то его соцсетях. Да им этого и не надо знать. То есть, в целом очень странно пиарить игру в таких местах.
>>6990
Давно подумываю сделать игру на годоте, а какую то незначительную утилиту (какой нибудь генератор текстур) ней на другом движке - и пиарить в чужом сообществе.
Давно подумываю сделать игру на годоте, а какую то незначительную утилиту (какой нибудь генератор текстур) ней на другом движке - и пиарить в чужом сообществе.
264 Кб, 704x371>>6990
Понятное дело что пиарить игру среди таких же геймдевов как ты - дохлое дело. Но все же главная годота лучше чем стандартное "постишь в собственные соцсети, получаешь 5 лайков и ноль продаж".
Понятное дело что пиарить игру среди таких же геймдевов как ты - дохлое дело. Но все же главная годота лучше чем стандартное "постишь в собственные соцсети, получаешь 5 лайков и ноль продаж".
58 Кб, 788x294Я тут обнаружил, что проблему навигационной сетки на крышах зданий можно решить сделав крышам скалирование -1 -1 -1. Еще это удобный способ исключить область из навмеша - ставим куб-коллайдер посреди навмеша, склариуем его в минусы, теперь эта область исключена, а крышка куба в сетку не добавилась.
>>7084
:(
:(
370 Кб, 829x365всем ку. я новичок в godot и решил помочь своему другу с созданием уровней. делаю их в jackhammer и тестирую в кске лол, потому что хорошо знаю этот редактор и мне лень разбираться с чем-то новым. но я столкнулся с такой проблемой, как рельеф — делать его в хаммере сущий ад, + ещё лимит по размерам мешает делать большие карты. поэтому хочу спросить у знающих: есть ли какие-нибудь редакторы, заточенные под godot, в которых с рельефом работать легче? и ваще на сколько целесообразно делать уровни для игры в хаммере?
>>7321
Хм интересно ща буду тестить
Хм интересно ща буду тестить
>>7342
Странно, почему? В сплатмапе 4 канала, это база. Ты наверное что-то недонастроил.
Странно, почему? В сплатмапе 4 канала, это база. Ты наверное что-то недонастроил.
>>7342
Не 2, а 32.
Не 2, а 32.
Хорошо, а если мы возьмем систему сейвов на PackedScen'ах и при загрузке проверим ее на вызовы OS и сетевые вызовы, и если что - не будем их исполнять? Безопасно?
>>7367
Нет, не безопасно. Гугли квайн (программа результатом работы которой является её же текст) например. Толковый хацкер наперёд просчитает все твои ходы и сделает код, в котором не будет системносетевых вызовов, но они будут.
Нет, не безопасно. Гугли квайн (программа результатом работы которой является её же текст) например. Толковый хацкер наперёд просчитает все твои ходы и сделает код, в котором не будет системносетевых вызовов, но они будут.
>>7380
Спасибо за иллюстрацию.
Спасибо за иллюстрацию.
>>4303
Пердёж в вакуум из страны пердежных пони. Ищешь коммит который фиксит этот конкретный баг в библиотеке по названиям коммитов и применяешь его или сам чинишь, обычно это изи.
Пердёж в вакуум из страны пердежных пони. Ищешь коммит который фиксит этот конкретный баг в библиотеке по названиям коммитов и применяешь его или сам чинишь, обычно это изи.
>>7387
Ты такие вещи дивану предлагаешь, это же надо самому конпелировать(!) Он уже на скачивании scons обосрётся.
Ты такие вещи дивану предлагаешь, это же надо самому конпелировать(!) Он уже на скачивании scons обосрётся.
>>7380
Так калл тоже в бан, ибо кал.
Так калл тоже в бан, ибо кал.
>>4404
Ебало адаптера представил? А ведь в рамках 1 аудиосинглтона, куда стучится вся игра (потому что игра относительно этого аудио синглтона сама является синглтоном, так как звук поступает на этот аудиосервер только из игровых подсистем и более ниоткуда) - может быть реализован список адаптеров под все, включая небо и аллаха. С физикой ещё проще - 2 физики - 2 синглтона/1 синглтон с пробросом типа реализуемой физики по дженерику в каждый метод её вызова. Будет менее красиво зато модульно. А иных решений нет потому что физика это тебе не в тапки срать, там мир нужно синхронизировать и считать по тику. Можно ещё виртуализировать игру в контейнер, но по факту в рамках контейнера будут те же 2 синглтона, просто живущие пока жив контейнер.
>как же так, как же так, как же так....
Ебало адаптера представил? А ведь в рамках 1 аудиосинглтона, куда стучится вся игра (потому что игра относительно этого аудио синглтона сама является синглтоном, так как звук поступает на этот аудиосервер только из игровых подсистем и более ниоткуда) - может быть реализован список адаптеров под все, включая небо и аллаха. С физикой ещё проще - 2 физики - 2 синглтона/1 синглтон с пробросом типа реализуемой физики по дженерику в каждый метод её вызова. Будет менее красиво зато модульно. А иных решений нет потому что физика это тебе не в тапки срать, там мир нужно синхронизировать и считать по тику. Можно ещё виртуализировать игру в контейнер, но по факту в рамках контейнера будут те же 2 синглтона, просто живущие пока жив контейнер.
>>6987
Потому что квест и дерьмовый трейлер, где толком ничего не показали кроме унылых пряток и мимими собачки. Графику вылизали хорошо, но когда в трейлере 3 раза показывают один и тот же фрагмент - это какая-то клиника. Может ещё какой-нибудь стример наткнется и люди подзатарят, если игра рил цепляющая, но кроме классной стилизованной графики и демонстрации что годот умеет вот так - я лично ничего не увидел.
Потому что квест и дерьмовый трейлер, где толком ничего не показали кроме унылых пряток и мимими собачки. Графику вылизали хорошо, но когда в трейлере 3 раза показывают один и тот же фрагмент - это какая-то клиника. Может ещё какой-нибудь стример наткнется и люди подзатарят, если игра рил цепляющая, но кроме классной стилизованной графики и демонстрации что годот умеет вот так - я лично ничего не увидел.
>>7390
Ты ему ещё и отвечаешь? Он же поехавший. Ты не обратил внимание, что с ним прекратили диалог 400 постов назад?
Ты ему ещё и отвечаешь? Он же поехавший. Ты не обратил внимание, что с ним прекратили диалог 400 постов назад?
>>7393
Я после 2 месячного воздержания залетел покакать в треды и улететь, не обещав вернуться, так что не заметил. Впрочем анон так и не смог аргументированно доказать потребность в синглтонах, попутно показав свои сомнительные наработки по worlddatasingleton, что так-то ещё сомнительнее чем аудиосервер. Я бы предпочел создавать сервис-синглтон со всеми статичными данными, а уж из мира создавать что-то живущее в контейнере из миров, по меньшей мере такая конструкция сможет подняться в тестовом окружении не дергая лишних зависимостей и позволяя множить миры для разных целей. Хотя конкретно в этом аспекте - я только предполагаю по названию синглтона.
Я после 2 месячного воздержания залетел покакать в треды и улететь, не обещав вернуться, так что не заметил. Впрочем анон так и не смог аргументированно доказать потребность в синглтонах, попутно показав свои сомнительные наработки по worlddatasingleton, что так-то ещё сомнительнее чем аудиосервер. Я бы предпочел создавать сервис-синглтон со всеми статичными данными, а уж из мира создавать что-то живущее в контейнере из миров, по меньшей мере такая конструкция сможет подняться в тестовом окружении не дергая лишних зависимостей и позволяя множить миры для разных целей. Хотя конкретно в этом аспекте - я только предполагаю по названию синглтона.
>>7397
Обесняю. Когда поехавший видит слово "синглтон", он дорисовывает в своём воображении, что ты программируешь двери синглтоном. А ты программируешь движок. Что бы ты не сказал, он переспрашивает, "а если тебе потребуются мультиплеерные кнопки, тогда что будешь делать?"
Поэтому в общем-то что либо объяснять ему нет смысла, просто делай своё дело. Удачи. Ждём релиза.
Обесняю. Когда поехавший видит слово "синглтон", он дорисовывает в своём воображении, что ты программируешь двери синглтоном. А ты программируешь движок. Что бы ты не сказал, он переспрашивает, "а если тебе потребуются мультиплеерные кнопки, тогда что будешь делать?"
Поэтому в общем-то что либо объяснять ему нет смысла, просто делай своё дело. Удачи. Ждём релиза.
>>7394
Они все регулярно обновляются, и я кочую к тому, кто лучший на данный момент. Грок с гдскриптом до сих пор тупит, по моему опыту.
Они все регулярно обновляются, и я кочую к тому, кто лучший на данный момент. Грок с гдскриптом до сих пор тупит, по моему опыту.
>>7393
За базар ответишь?
Так возразить нечего было, вот и не ответили.
> Он же поехавший.
За базар ответишь?
>Ты не обратил внимание, что с ним прекратили диалог 400 постов назад?
Так возразить нечего было, вот и не ответили.
>>7398
Просто запомни - синглтон плохо. Все. Больше ничего про него знать не надо. То, что кто то делает плохо, не значит что тебе надо копировать и делать плохо. Я это пишу как работавший 10 лет программистом и несколько раз выкорчевываший синглтоны по работе, потому что менеджмент хочет фичу, а кодеры накодили синглтон не позволяющий расширение. Или придется отвечать - нет, фичу добавить нельзя. А зачем так делать? Мне вот не нравится когда в ишьюях годота отвечают что что-то нельзя сделать - перефразируя какого то старого миллионера, я беру инструмент не для того чтобы мне говорили что сделать нельзя, а чтобы сказали как им сделать.
А мультиплеерные кнопки пишет другой анон, но и ему я подскзывал. У нас тут тред взаипомощи, а не обзывания других поехавшими.
Просто запомни - синглтон плохо. Все. Больше ничего про него знать не надо. То, что кто то делает плохо, не значит что тебе надо копировать и делать плохо. Я это пишу как работавший 10 лет программистом и несколько раз выкорчевываший синглтоны по работе, потому что менеджмент хочет фичу, а кодеры накодили синглтон не позволяющий расширение. Или придется отвечать - нет, фичу добавить нельзя. А зачем так делать? Мне вот не нравится когда в ишьюях годота отвечают что что-то нельзя сделать - перефразируя какого то старого миллионера, я беру инструмент не для того чтобы мне говорили что сделать нельзя, а чтобы сказали как им сделать.
А мультиплеерные кнопки пишет другой анон, но и ему я подскзывал. У нас тут тред взаипомощи, а не обзывания других поехавшими.
>>7407
какой ещё менеджмент, ты поехавший? напоминаешь армейских генеральских дедов, которые приходят к гражданским людям и заставляют всех строем ходить, вплоть до грудных детей
игра это одноразовый продукт, высрал - забыл, плевать какой там код
особенно, если это инди игра
какой ещё менеджмент, ты поехавший? напоминаешь армейских генеральских дедов, которые приходят к гражданским людям и заставляют всех строем ходить, вплоть до грудных детей
игра это одноразовый продукт, высрал - забыл, плевать какой там код
особенно, если это инди игра
>>7407
Сорян, я как программист с 13 летним стажем подозреваю что ты просто не разобрался с чужим кодом, и под указанием недальновидного начальства пошел его ломать. Не значит что там было что-то не так.
Сорян, я как программист с 13 летним стажем подозреваю что ты просто не разобрался с чужим кодом, и под указанием недальновидного начальства пошел его ломать. Не значит что там было что-то не так.
>>7407
А какое тебе дело чем заниматься? Тебе больше заплатят если не надо будет корчевать синглтоны, а сразу накатывать фичу? И знаешь какие синглтоны кстати не надо корчевать? А такие, которые не имеют сайд-эффектов на бизнес логику и не являются точками доступа к ее состояниям. Таким образом можно совершенно спокойно совать в сервисы все что попадет под такие критерии и быть уверенным что потом возможен разве что небольшой рефакторинг апи, что в нашем гейдев болоте дело житейское.
>Выкорчевал синглтон на работе
А какое тебе дело чем заниматься? Тебе больше заплатят если не надо будет корчевать синглтоны, а сразу накатывать фичу? И знаешь какие синглтоны кстати не надо корчевать? А такие, которые не имеют сайд-эффектов на бизнес логику и не являются точками доступа к ее состояниям. Таким образом можно совершенно спокойно совать в сервисы все что попадет под такие критерии и быть уверенным что потом возможен разве что небольшой рефакторинг апи, что в нашем гейдев болоте дело житейское.
Синглтон! Синглтон! Единственный в мире малыш-синглтон!
Велком-строка для переката готова. Теперь заготавливаем арт.
Велком-строка для переката готова. Теперь заготавливаем арт.
>>6987
Твиттер и геймдев-каналы на Реддит и в соцсетях бесполезны. Геймдев-разработчики не покупают игры других разработчиков, а простые игроки там не обитают.
Твиттер и геймдев-каналы на Реддит и в соцсетях бесполезны. Геймдев-разработчики не покупают игры других разработчиков, а простые игроки там не обитают.
>>7499
А в не-геймдев каналы хуй пролезешь. У меня один аккаунт на реддите бан словил за попытку самопиара в небольшом геймерском сабреддите.
А в не-геймдев каналы хуй пролезешь. У меня один аккаунт на реддите бан словил за попытку самопиара в небольшом геймерском сабреддите.
https://www.youtube.com/watch?v=747w5Zjm-C4
Когда в Годот завезут разрушение моделей и окружающего мира?
Когда в Годот завезут разрушение моделей и окружающего мира?
22 Кб, 101x95>>7579
Когда твой скилл вырастет выше сранья на харкаче.
Когда твой скилл вырастет выше сранья на харкаче.
>>7579
Если ты имеешь в виду "в ядро движка", то никогда - туда стараются не добавлять фичи которые будут нужны малому проценту разрабов.
Если же речь про "добавить возможность" - она и так давно есть. Я лет 6 назад тут на твг постил игру где можно было копать heightmap (не совсем в реальном времени), и Holer с дырявой уткой. С давних пор есть куча аддонов, позволяющих и разрезать меши, и разрушать их, и воксельные карты делать.
Покормил фальку
Если ты имеешь в виду "в ядро движка", то никогда - туда стараются не добавлять фичи которые будут нужны малому проценту разрабов.
Если же речь про "добавить возможность" - она и так давно есть. Я лет 6 назад тут на твг постил игру где можно было копать heightmap (не совсем в реальном времени), и Holer с дырявой уткой. С давних пор есть куча аддонов, позволяющих и разрезать меши, и разрушать их, и воксельные карты делать.
Покормил фальку
Какую игру можно сделать для Яндекс игр с персонажем фнаф. У меня есть скин Фредди 2д.
>>7611
Это та залупа для детей? Заверни туда еще крипера и курочку из майнкрафта, будет отличная шавуха для школоты.
>фнаф
Это та залупа для детей? Заверни туда еще крипера и курочку из майнкрафта, будет отличная шавуха для школоты.
>>7611
Три-в-ряд сделай. И если игрок не сложил 3+ комбинаций - выскакивает скримак. Базарю, все продажи твои.
Три-в-ряд сделай. И если игрок не сложил 3+ комбинаций - выскакивает скримак. Базарю, все продажи твои.
Анончики, каким способом лучше всего имитировать воду, с учётом того, что игрок находится в батискафе? Чёт не догоняю
>>7617
Смотря чего у тебя за игра. У меня топ-даун 3д, поэтому я просто квад на землю кидаю и норм.
Смотря чего у тебя за игра. У меня топ-даун 3д, поэтому я просто квад на землю кидаю и норм.
>>7619
Наложи шейдер на окно, или откуда там игрок выглядывает.
Наложи шейдер на окно, или откуда там игрок выглядывает.
>>7617
Вода в играх это обычно комбинация нескольких приемов, где-то 5-6 (и в одной сущности "вода" я не припомню чтобы было все сразу)
Если у тебя игра ТОЛЬКО под водой, то тебе подойдет туман + шейдер в котором искажается картинка https://godotshaders.com/shader/underwater-camera-effect/
Если ты видишь дно ( и оно не очень глубоко) то тебе может понадобиться еще каустика и возможно god rays
Если ты видишь из под воды наверх поверхность, то там еще надо что-то добавить, например https://godotshaders.com/shader/snells-window/ и может понадобиться рисовать уже саму поверхность воды - обычно это просто волновой шейдер который не учитывает объекты. Если он учитывает (пускает круги вокруг объектов) то там надо шейдер посложнее. Если нужна плавучесть для покачивания объектов на волнах то там тоже становится сложнее - надо синхронизировать с таймером шейдера движение вершин условного меша-модели.
Если у тебя всплытие, то все становится еще сложнее. Там можно например рендерить сцену два раза, одну половину с подводным шейдером и второую обычно + надо рисовать волнистую линию поверх всего которая будет служить разделителем среды и ее надо синхронизировать с анимацией волн.
Если надо брызги, потоки рек, пена, прибой, то это тоже обычно отдельными шейдерами делается относительно примитивными самими по себе. (плоскость с текстурой на который брызги нарисованы). Симуляции жидкости тут практически никогда не касаются, если нужна еще и она (например реалистичное затопление при пробоине) то это уже отдельная история.
Вода в играх это обычно комбинация нескольких приемов, где-то 5-6 (и в одной сущности "вода" я не припомню чтобы было все сразу)
Если у тебя игра ТОЛЬКО под водой, то тебе подойдет туман + шейдер в котором искажается картинка https://godotshaders.com/shader/underwater-camera-effect/
Если ты видишь дно ( и оно не очень глубоко) то тебе может понадобиться еще каустика и возможно god rays
Если ты видишь из под воды наверх поверхность, то там еще надо что-то добавить, например https://godotshaders.com/shader/snells-window/ и может понадобиться рисовать уже саму поверхность воды - обычно это просто волновой шейдер который не учитывает объекты. Если он учитывает (пускает круги вокруг объектов) то там надо шейдер посложнее. Если нужна плавучесть для покачивания объектов на волнах то там тоже становится сложнее - надо синхронизировать с таймером шейдера движение вершин условного меша-модели.
Если у тебя всплытие, то все становится еще сложнее. Там можно например рендерить сцену два раза, одну половину с подводным шейдером и второую обычно + надо рисовать волнистую линию поверх всего которая будет служить разделителем среды и ее надо синхронизировать с анимацией волн.
Если надо брызги, потоки рек, пена, прибой, то это тоже обычно отдельными шейдерами делается относительно примитивными самими по себе. (плоскость с текстурой на который брызги нарисованы). Симуляции жидкости тут практически никогда не касаются, если нужна еще и она (например реалистичное затопление при пробоине) то это уже отдельная история.
>>7681
Литералли ми
Литералли ми
>>7703
Нет ты. Банально плагины найти не можешь, чмоха безрукая, а лезешь йобы делать. Дно.
Нет ты. Банально плагины найти не можешь, чмоха безрукая, а лезешь йобы делать. Дно.
Вот бы мультикам рендер завезли, как же заебали эти вьюпорты блядские.
>>7662
Спасибо за развернутый ответ, анончик. Возьму первый способ
Спасибо за развернутый ответ, анончик. Возьму первый способ
>>7729
Так ты дно ноускилльное необучаемое, у тебя следующий вопрос будет - а как его поставить. А как использовать. А как, а как. С ложечки весь проект тебя кормить не будут.
Еще раз, иди флаппи берд делай. Хотя ты и на нем завалишься.
Так ты дно ноускилльное необучаемое, у тебя следующий вопрос будет - а как его поставить. А как использовать. А как, а как. С ложечки весь проект тебя кормить не будут.
Еще раз, иди флаппи берд делай. Хотя ты и на нем завалишься.
